From: Junio C Hamano <hidden> Date: 2016-07-19 18:05:10
Antoine Tenart [off-list ref] writes:
Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename <path>) as the worktree name when the --name option
isn't used.
Two new test cases are added to ensure the --name option does not break
other functionalities and is working properly.
Finally, the documentation is updated to reflect this --name option
addition.
Signed-off-by: Antoine Tenart <redacted>
---
Hmm, is this related to an earlier discussion
https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
in any way, or is it an independent invention?
The conclusion of that discussion thread was roughly "users
shouldn't even _care_ about the name, and if they have to use name
to identify the worktrees to do certain things right now, reducing
the need for such 'certain things', not making it easy to give a
user-defined name to a worktree, is the way to go", IIRC.
On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano [off-list ref] wrote:
Antoine Tenart [off-list ref] writes:
quoted
Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename <path>) as the worktree name when the --name option
isn't used.
Two new test cases are added to ensure the --name option does not break
other functionalities and is working properly.
Finally, the documentation is updated to reflect this --name option
addition.
Signed-off-by: Antoine Tenart <redacted>
---
Hmm, is this related to an earlier discussion
https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
in any way, or is it an independent invention?
The conclusion of that discussion thread was roughly "users
shouldn't even _care_ about the name, and if they have to use name
to identify the worktrees to do certain things right now, reducing
the need for such 'certain things', not making it easy to give a
user-defined name to a worktree, is the way to go", IIRC.
080739b (worktree.c: find_worktree() search by path suffix -
2016-06-13) from 'next' should help identify worktrees in this case by
specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
type all that when 'project0/foo' is something long, and bash
completion probably does not help much either.
Note that we may need a unique name elsewhere too, e.g.
refs/worktrees/xyz (even though we haven't settled on this yet). Then
xyz would be more exposed to the user and an easily recognizable name
would be a good thing.
--
Duy
From: Antoine Tenart <hidden> Date: 2016-07-19 18:45:18
Hi,
On Tue, Jul 19, 2016 at 11:04:59AM -0700, Junio C Hamano wrote:
quoted
Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename <path>) as the worktree name when the --name option
isn't used.
Completely independent. I made a quick search before doing this... too
quick :-)
The conclusion of that discussion thread was roughly "users
shouldn't even _care_ about the name, and if they have to use name
to identify the worktrees to do certain things right now, reducing
the need for such 'certain things', not making it easy to give a
user-defined name to a worktree, is the way to go", IIRC.
I agree that users shouldn't have to deal with this in most cases, and
that's still the default behaviour with this patch. But some use cases
require to change this default name: I use the same repository for each
of my projects using the Linux kernel while working on them in parallel.
So I end up with something like: project1/linux, project2/linux etc...
where other names than 'linux' in each project directory wouldn't really
make sense.
Being able to manually define the name can also be useful in some (rare)
cases, where you reorganize your project directory tree. But that's not
a strong argument for adding this option :-)
There might be other solutions, so I'm open for discussion. I just find
this not-that-magic solution useful.
Thanks!
--
Antoine
From: Eric Sunshine <hidden> Date: 2016-07-19 18:52:47
On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano [off-list ref] wrote:
Antoine Tenart [off-list ref] writes:
quoted
Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename <path>) as the worktree name when the --name option
isn't used.
Hmm, is this related to an earlier discussion
https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
in any way, or is it an independent invention?
The conclusion of that discussion thread was roughly "users
shouldn't even _care_ about the name, and if they have to use name
to identify the worktrees to do certain things right now, reducing
the need for such 'certain things', not making it easy to give a
user-defined name to a worktree, is the way to go", IIRC.
From: Antoine Tenart <hidden> Date: 2016-07-19 18:54:59
On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano [off-list ref] wrote:
080739b (worktree.c: find_worktree() search by path suffix -
2016-06-13) from 'next' should help identify worktrees in this case by
specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
type all that when 'project0/foo' is something long, and bash
completion probably does not help much either.
So with this I'll be able to create new worktrees, using paths having
the same basename, but in different let's say "project directories"?
Note that we may need a unique name elsewhere too, e.g.
refs/worktrees/xyz (even though we haven't settled on this yet). Then
xyz would be more exposed to the user and an easily recognizable name
would be a good thing.
Having a recognisable name surely is a good thing, when performing some
(rare) manual operations. Like moving a worktree (or is there a command
for this?)
Thanks,
--
Antoine
On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart [off-list ref] wrote:
On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
quoted
On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano [off-list ref] wrote:
080739b (worktree.c: find_worktree() search by path suffix -
2016-06-13) from 'next' should help identify worktrees in this case by
specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
type all that when 'project0/foo' is something long, and bash
completion probably does not help much either.
So with this I'll be able to create new worktrees, using paths having
the same basename, but in different let's say "project directories"?
Well, internal name is still out of your control, but if you want to
do something to a worktree you can say "do project0/foo". With 'next'
those verbs can be lock and unlock. We probably can make 'worktree
list' take filter and show just one worktree (and just add "git
worktree show" for that).
quoted
Note that we may need a unique name elsewhere too, e.g.
refs/worktrees/xyz (even though we haven't settled on this yet). Then
xyz would be more exposed to the user and an easily recognizable name
would be a good thing.
Having a recognisable name surely is a good thing, when performing some
(rare) manual operations.
What I had in mind was "git log --decorate=more-than-full", foo/HEAD
and foo1/HEAD
do not look as good as project0/HEAD and project1/HEAD (*)
Like moving a worktree (or is there a command for this?)
Don't touch it. I've been waiting patiently for that patch series to
be reviewed :)
--
Duy
From: Eric Sunshine <hidden> Date: 2016-07-19 19:21:39
On Tue, Jul 19, 2016 at 3:04 PM, Duy Nguyen [off-list ref] wrote:
On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart [off-list ref] wrote:
quoted
Like moving a worktree (or is there a command for this?)
Don't touch it. I've been waiting patiently for that patch series to
be reviewed :)
For newcomers, "that patch series" refers to [1].
If it's any consolation (probably not), I'm still trying to find an
opportunity to review it, however, my computer time is severely
limited these days. In fact, I'm so far behind, I still haven't
reviewed the worktree-lock re-roll (which probably has already hit
'master').
[1]: http://thread.gmane.org/gmane.comp.version-control.git/298194
From: Antoine Tenart <hidden> Date: 2016-07-19 19:35:37
On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart [off-list ref] wrote:
quoted
On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
quoted
On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano [off-list ref] wrote:
080739b (worktree.c: find_worktree() search by path suffix -
2016-06-13) from 'next' should help identify worktrees in this case by
specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
type all that when 'project0/foo' is something long, and bash
completion probably does not help much either.
So with this I'll be able to create new worktrees, using paths having
the same basename, but in different let's say "project directories"?
Well, internal name is still out of your control, but if you want to
do something to a worktree you can say "do project0/foo". With 'next'
those verbs can be lock and unlock. We probably can make 'worktree
list' take filter and show just one worktree (and just add "git
worktree show" for that).
Hmm, so if I understand correctly my use case still won't be supported,
as adding a new worktree with the same basename will fail. Or did I miss
something?
--
Antoine
From: Antoine Tenart <hidden> Date: 2016-07-20 06:41:33
Hello Eric,
On Tue, Jul 19, 2016 at 02:52:42PM -0400, Eric Sunshine wrote:
On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano [off-list ref] wrote:
quoted
Antoine Tenart [off-list ref] writes:
quoted
Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename <path>) as the worktree name when the --name option
isn't used.
Hmm, is this related to an earlier discussion
https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
in any way, or is it an independent invention?
The conclusion of that discussion thread was roughly "users
shouldn't even _care_ about the name, and if they have to use name
to identify the worktrees to do certain things right now, reducing
the need for such 'certain things', not making it easy to give a
user-defined name to a worktree, is the way to go", IIRC.
Thanks for the links, I've had a look at the discussion. The problem
that raised it was a bit different: it was about reorganizing projects
and directory trees, no about creating a new worktree with the same
basename as an existing one. I've also had a look at 080739b,
introducing find_worktree(), but I don't think that would solve the
issue either.
So we've left with two solutions: being able to specify the worktree
name or having an arbitrary ID (plus some modifications to `git worktree
list`) as you proposed. I guess you prefer the later solution. Is there
any plan to do this, or anything in progress?
Thanks,
--
Antoine
On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart [off-list ref] wrote:
On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
quoted
On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart [off-list ref] wrote:
quoted
On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
quoted
On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano [off-list ref] wrote:
080739b (worktree.c: find_worktree() search by path suffix -
2016-06-13) from 'next' should help identify worktrees in this case by
specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
type all that when 'project0/foo' is something long, and bash
completion probably does not help much either.
So with this I'll be able to create new worktrees, using paths having
the same basename, but in different let's say "project directories"?
Well, internal name is still out of your control, but if you want to
do something to a worktree you can say "do project0/foo". With 'next'
those verbs can be lock and unlock. We probably can make 'worktree
list' take filter and show just one worktree (and just add "git
worktree show" for that).
Hmm, so if I understand correctly my use case still won't be supported,
as adding a new worktree with the same basename will fail. Or did I miss
something?
Hm... _what_ fails? If you create two worktrees project0/foo and
project1/foo, you'll get .git/worktrees/foo and .git/worktrees/foo1
but worktree creation should succeed both times. As long as you don't
have to look into .git/worktrees/ everything should be fine, you won't
see foo vs foo1.
If you absolutely have to, I'm thinking of "git --rev-parse
--worktree=<xxx> --git-dir" (or something similar) that will give you
$GIT_DIR to a specific worktree (e.g. .git/worktrees/foo or
.git/worktrees/foo1). Then you can specify "git rev-parse
--worktree=project0/foo --git-dir" and still don't have to see foo vs
foo1.
--
Duy
From: Antoine Tenart <hidden> Date: 2016-07-20 16:12:39
On Wed, Jul 20, 2016 at 04:54:40PM +0200, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart [off-list ref] wrote:
quoted
Hmm, so if I understand correctly my use case still won't be supported,
as adding a new worktree with the same basename will fail. Or did I miss
something?
Hm... _what_ fails? If you create two worktrees project0/foo and
project1/foo, you'll get .git/worktrees/foo and .git/worktrees/foo1
but worktree creation should succeed both times. As long as you don't
have to look into .git/worktrees/ everything should be fine, you won't
see foo vs foo1.
You're right, I don't know why I was sure this wasn't working... Sorry
for the noise :-)
--
Antoine