Skip to contentSkip to conversation

Self-inflicted "abort" in a newbie attempt at read-only exploration of a cloned repository?

DISCUSSION Thierry Moreau 3 participants 6 messages Apr 5, 2018 – Apr 6, 2018

lore
Share & tools
lore
#0 lore raw

Dear GIT enthusiasts!

This ends up with a "git checkout" command aborting. A bit frustrating at the early stage of GIT learning curve.

My first goal is to clone repositories locally in order to explore the various linux kernel versions, with the rich GIT metadata.

Thus, I clone:

$  git clone --branch linux-4.16.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable
$  git -C linux-stable/ branch
* linux-4.16.y

So far so good. Then, I want to extract an earlier kernel version into a tmp dir:

$  mkdir tmp
$  git -C linux-stable/ --work-tree $PWD/tmp/ checkout linux-4.15.y
$  git -C linux-stable/ branch
* linux-4.15.y
  linux-4.16.y

I got my extracted 4.15 version but the source repository (index? ...?) has somehow changed. Let me try something silly:

$  git -C linux-stable/ --work-tree $PWD/tmp/ checkout linux-4.14.y
$  git -C linux-stable/ branch
* linux-4.14.y
  linux-4.15.y
  linux-4.16.y

I indeed switched my extracted version from 4.15 to 4.14, but I am puzzled that the local source repository (linux-stable) is modified. Then I try to bring it back closer to its original state, just to keep things tidy:

$  git -C linux-stable/ checkout linux-4.16.y

And this command aborts, both with Git versions 2.01 and 2.17. Here is the truncated command output:

error: Your local changes to the following files would be overwritten by checkout:

	.gitignore
	.mailmap
	Documentation/00-INDEX
	Documentation/ABI/obsolete/sysfs-gpio
	Documentation/ABI/stable/sysfs-bus-vmbus
	Documentation/ABI/stable/sysfs-devices
	[... ...]
	Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
	Documentation/devicetree/bindings/arm/omap/crossbar.txt
	Documentation/devicetree/bindings/arm/omap/ctrl.txt
	Documentation/devicetree/bindings/arm/realtek.txt
	Documentation/devicetree/bindings/arm/rock
error: The following untracked working tree files would be overwritten by checkout:
	Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html
	Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
	Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg
	Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg
	Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg
	[... ...]
	arch/riscv/include/asm/smp.h
	arch/riscv/include/asm/spinlock.h
	arch/riscv/include/asm/spinlock_types.h
	arch/riscv/include/asm/string.h
	arch/riscv/include/

Aborting

Questions:
=========

Is there a GIT tutorial that begins with my stated goal of an extract-only usage of cloned GIT repositories? (Maybe the root cause is my reluctance to learn the more involved GIT usages.)

Does the above reproducible abort deserve attention?

Any suggestion for my stated goal?

Thanks in advance,

- Thierry Moreau

#1 lore raw
Quoted 16 lines · Thierry Moreau

Dear GIT enthusiasts!

This ends up with a "git checkout" command aborting. A bit frustrating at the early stage of GIT learning curve.

My first goal is to clone repositories locally in order to explore the various linux kernel versions, with the rich GIT metadata.

Thus, I clone:

$  git clone --branch linux-4.16.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-stable
$  git -C linux-stable/ branch
* linux-4.16.y
Quoted 8 lines

So far so good. Then, I want to extract an earlier kernel version into a tmp dir:

$  mkdir tmp
$  git -C linux-stable/ --work-tree $PWD/tmp/ checkout linux-4.15.y
$  git -C linux-stable/ branch
* linux-4.15.y
  linux-4.16.y

The documentation for --work-tree says:

--work-tree=<path>

Set the path to the working tree. It can be an absolute path or a path relative to the current working directory. This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in git-config(1) for a more detailed discussion).

So passing --work-tree tells Git where to store your _files_, but it's still using the same .git directory.

If your goal is to have worktrees for various versions, that implies the git worktree [1] command might be more along the lines of what you're looking for. An invocation based on above might look like this:

$ git -C linux-stable/ worktree add $PWD/tmp/ checkout linux-4.15.y

That should leave linux-4.16.y checked out in linux-stable, while creating a full work tree in $PWD/tmp that has 4.15.y checked out.

Note that worktree is a newer git command. 2.17 has it, but old versions like 2.1 won't.

[1] https://git-scm.com/docs/git-worktree

Hope this helps!
Bryan

#2 lore raw
Quoted 37 lines · Bryan Turner
Quoted 16 lines · Thierry Moreau

Dear GIT enthusiasts!

This ends up with a "git checkout" command aborting. A bit frustrating at the early stage of GIT learning curve.

My first goal is to clone repositories locally in order to explore the various linux kernel versions, with the rich GIT metadata.

Thus, I clone:

$  git clone --branch linux-4.16.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-stable
$  git -C linux-stable/ branch
* linux-4.16.y
Quoted 8 lines

So far so good. Then, I want to extract an earlier kernel version into a tmp dir:

$  mkdir tmp
$  git -C linux-stable/ --work-tree $PWD/tmp/ checkout linux-4.15.y
$  git -C linux-stable/ branch
* linux-4.15.y
  linux-4.16.y

The documentation for --work-tree says:

--work-tree=<path>

Set the path to the working tree. It can be an absolute path or a path relative to the current working directory. This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in git-config(1) for a more detailed discussion).

Quoted 7 lines

So passing --work-tree tells Git where to store your _files_, but it's still using the same .git directory.

If your goal is to have worktrees for various versions, that implies the git worktree [1] command might be more along the lines of what you're looking for. An invocation based on above might look like this:

$ git -C linux-stable/ worktree add $PWD/tmp/ checkout linux-4.15.y

Apologies, I didn't mean to have the "checkout" in that.

$ git -C linux-stable/ worktree add $PWD/tmp/ linux-4.15.y
Quoted 11 lines

That should leave linux-4.16.y checked out in linux-stable, while creating a full work tree in $PWD/tmp that has 4.15.y checked out.

Note that worktree is a newer git command. 2.17 has it, but old versions like 2.1 won't.

[1] https://git-scm.com/docs/git-worktree

Hope this helps!
Bryan

#3 lore raw
Quoted 5 lines · Bryan Turner
Quoted 4 lines · Bryan Turner

So passing --work-tree tells Git where to store your _files_, but it's still using the same .git directory.

Quoted 18 lines
Quoted 4 lines

If your goal is to have worktrees for various versions, that implies the git worktree [1] command might be more along the lines of what you're looking for. An invocation based on above might look like this:

$ git -C linux-stable/ worktree add $PWD/tmp/ checkout linux-4.15.y

Apologies, I didn't mean to have the "checkout" in that.

$ git -C linux-stable/ worktree add $PWD/tmp/ linux-4.15.y
Quoted 10 lines

That should leave linux-4.16.y checked out in linux-stable, while creating a full work tree in $PWD/tmp that has 4.15.y checked out.

Note that worktree is a newer git command. 2.17 has it, but old versions like 2.1 won't.

[1] https://git-scm.com/docs/git-worktree

Hope this helps!

For sure, it helps! Thanks.

- Thierry

#4 lore raw
In reply to Bryan Turner
Quoted 10 lines · Bryan Turner

The documentation for --work-tree says:

--work-tree=<path>

Set the path to the working tree. It can be an absolute path or a path relative to the current working directory. This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in git-config(1) for a more detailed discussion).

Quoted 7 lines

So passing --work-tree tells Git where to store your _files_, but it's still using the same .git directory.

If your goal is to have worktrees for various versions, that implies the git worktree [1] command might be more along the lines of what you're looking for. An invocation based on above might look like this:

$ git -C linux-stable/ worktree add $PWD/tmp/ checkout linux-4.15.y

Everything you've said here is completely accurate. But the original report does make me wonder if we've set up users for failure by overloading the term "worktree". Clearly it means two very different things in:

  git --work-tree=foo

and

git worktree add foo

I'm not sure what to do about it at this point, though. :(

-Peff

#5 lore raw
Quoted 25 lines · Jeff King
Quoted 10 lines · Bryan Turner

The documentation for --work-tree says:

--work-tree=<path>

Set the path to the working tree. It can be an absolute path or a path relative to the current working directory. This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in git-config(1) for a more detailed discussion).

Quoted 7 lines

So passing --work-tree tells Git where to store your _files_, but it's still using the same .git directory.

If your goal is to have worktrees for various versions, that implies the git worktree [1] command might be more along the lines of what you're looking for. An invocation based on above might look like this:

$ git -C linux-stable/ worktree add $PWD/tmp/ checkout linux-4.15.y

Everything you've said here is completely accurate. But the original report does make me wonder if we've set up users for failure by overloading the term "worktree". Clearly it means two very different things in:

Quoted 8 lines
   git --work-tree=foo

and

git worktree add foo

I'm not sure what to do about it at this point, though. :(

The documentation for 'git worktree add' was adequate for my problem solving process. My difficulty occurred because I used an earlier GIT version. The terminology overloading might not be a big issue.

Regards,

- Thierry