Sahil Dua [off-list ref] writes:
Ah! I had skipped this reply from Ramsay earlier.
On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
...
quoted
quoted
I personally do not think "branch --copy master backup" while on
"master" that switches to "backup" is a good UI, and I *will* say
"I told you so" when users complain after we merge this down to
'master'.
I wouldn't normally comment on an issue like this because I am
not very good at specifying, designing and evaluating UIs (so
who in their right mind would listen to me). ;-)
FWIW, I suspect that I would not like using this interface either
and would, therefore, not use it.
Does that mean you'd use it when "branch --copy feature-branch
new-feature-branch" in the case when you would want to start working
on a new branch (to modify or experiment with your current feature
branch) on top of a branch keeping intact all the configuration and
logs?
I am not Ramsay, but your choice of branch names in your question,
i.e. "branch --copy feature new-feature", is what we do not agree
with in the first place, especially when we are *on* the "feature"
branch.
We view "copy A B" as a way to make a back-up of A in B. I.e. We
want to keep working on A, but just in case we screw up badly, make
a backup copy of A in B, so that we can recover by a "branch --move
B A" later if needed. So touching B is the last thing we want to do
after "copy A B" operation---hence we do not want to switch to B.
That is not to say that you are wrong to wish to create a new
branch, check it out and start working on it with a single command.
We already have such a command all Git users are accustomed to,
which is "git checkout -b new-feature-branch feature-branch".
That existing command does not copy things other than the commit
object name from "feature-branch", and I do not think it should by
default. But I do not think it is wrong to extend it with a new
option (think of it as "checkout --super-b" ;-) to copy other things
like branch descriptions etc.
So from that point of view, your new feature conceptually fits a lot
better to "git checkout", and does not belong to "git branch". That
is why I do not think "git branch --copy A B" while you are on A
should check out B after creating the copy.
On 03/08/17 22:07, Junio C Hamano wrote:
Sahil Dua [off-list ref] writes:
quoted
Ah! I had skipped this reply from Ramsay earlier.
On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
...
quoted
quoted
I personally do not think "branch --copy master backup" while on
"master" that switches to "backup" is a good UI, and I *will* say
"I told you so" when users complain after we merge this down to
'master'.
I wouldn't normally comment on an issue like this because I am
not very good at specifying, designing and evaluating UIs (so
who in their right mind would listen to me). ;-)
FWIW, I suspect that I would not like using this interface either
and would, therefore, not use it.
Does that mean you'd use it when "branch --copy feature-branch
new-feature-branch" in the case when you would want to start working
on a new branch (to modify or experiment with your current feature
branch) on top of a branch keeping intact all the configuration and
logs?
I am not Ramsay, but your choice of branch names in your question,
i.e. "branch --copy feature new-feature", is what we do not agree
with in the first place, especially when we are *on* the "feature"
branch.
We view "copy A B" as a way to make a back-up of A in B. I.e. We
want to keep working on A, but just in case we screw up badly, make
a backup copy of A in B, so that we can recover by a "branch --move
B A" later if needed. So touching B is the last thing we want to do
after "copy A B" operation---hence we do not want to switch to B.
I couldn't have said this better. ;-)
That is not to say that you are wrong to wish to create a new
branch, check it out and start working on it with a single command.
We already have such a command all Git users are accustomed to,
which is "git checkout -b new-feature-branch feature-branch".
Indeed, I wouldn't think of doing anything else. (That may be
because I've been using git too long, of course).
That existing command does not copy things other than the commit
object name from "feature-branch", and I do not think it should by
default. But I do not think it is wrong to extend it with a new
option (think of it as "checkout --super-b" ;-) to copy other things
like branch descriptions etc.
Hmm, I've never felt the lack of copying any attributes from
the origin branch. So, I'm not convinced a "--super-b" is needed
(but if other people feel the need, then why not).
So from that point of view, your new feature conceptually fits a lot
better to "git checkout", and does not belong to "git branch". That
is why I do not think "git branch --copy A B" while you are on A
should check out B after creating the copy.
I agree (but lukewarm on the --super-b idea). :-D
ATB,
Ramsay Jones
On Thu, Aug 03 2017, Junio C. Hamano jotted:
Sahil Dua [off-list ref] writes:
quoted
Ah! I had skipped this reply from Ramsay earlier.
On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
...
quoted
quoted
I personally do not think "branch --copy master backup" while on
"master" that switches to "backup" is a good UI, and I *will* say
"I told you so" when users complain after we merge this down to
'master'.
I wouldn't normally comment on an issue like this because I am
not very good at specifying, designing and evaluating UIs (so
who in their right mind would listen to me). ;-)
FWIW, I suspect that I would not like using this interface either
and would, therefore, not use it.
Does that mean you'd use it when "branch --copy feature-branch
new-feature-branch" in the case when you would want to start working
on a new branch (to modify or experiment with your current feature
branch) on top of a branch keeping intact all the configuration and
logs?
I am not Ramsay, but your choice of branch names in your question,
i.e. "branch --copy feature new-feature", is what we do not agree
with in the first place, especially when we are *on* the "feature"
branch.
We view "copy A B" as a way to make a back-up of A in B. I.e. We
want to keep working on A, but just in case we screw up badly, make
a backup copy of A in B, so that we can recover by a "branch --move
B A" later if needed. So touching B is the last thing we want to do
after "copy A B" operation---hence we do not want to switch to B.
That is not to say that you are wrong to wish to create a new
branch, check it out and start working on it with a single command.
We already have such a command all Git users are accustomed to,
which is "git checkout -b new-feature-branch feature-branch".
That existing command does not copy things other than the commit
object name from "feature-branch", and I do not think it should by
default. But I do not think it is wrong to extend it with a new
option (think of it as "checkout --super-b" ;-) to copy other things
like branch descriptions etc.
So from that point of view, your new feature conceptually fits a lot
better to "git checkout", and does not belong to "git branch". That
is why I do not think "git branch --copy A B" while you are on A
should check out B after creating the copy.
We've talked how this UX should look before on-list. Rather than
re-hashing the arguments I had before I thought it was useful to present
it as a table. Here's how the patch looks now:
|----------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
|----------------------------+--------------+-------+---------+-----------------+-------------|
| branch <name> | Y | N | N | N | N |
| checkout <name> | Y | N | N | N | Y |
| checkout -b <name> <start> | Y | N | Y | N | Y |
| branch -m <name> | Y | Y | N | Y | Y |
| NEW: branch -c <name> | Y | N | Y | Y | Y |
|----------------------------+--------------+-------+---------+-----------------+-------------|
In previous discussion my understanding was that you preferred the
following (as an ad-hoc word-diff)
|----------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
[... stuff above this point is the same ...]
| NEW: branch -c <name> | Y | N | Y | Y | {-Y, +N} |
|----------------------------+--------------+-------+---------+-----------------+-------------|
I.e. have "branch -c <name>" but just make it not checkout the new
thing. What you're describing above sounds to me like:
|-------------------------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
[... stuff above this point is the same ...]
| branch -m <name> | Y | Y | N | Y | Y |
[... so is branch -m but included for context ...]
| NEW: checkout --super-b -b <name> <start> | Y | N | Y | Y | Y |
|-------------------------------------------+--------------+-------+---------+-----------------+-------------|
As (IIRC) noted in some earlier mail of mine: I don't disagree with what
you're suggesting, and this horror of a checkout/branch UX is not
something anyone would have made from scratch with the benefit of
hindsight.
However we have 2x commands that checkout branches now and do some
combination of creating, moving and copying them (with & without
config).
I think given that we have "branch -m <name>" already introducing a
"branch -c <name>" that does exactly the same thing except "leaves old
name behind" was the simplest thing both in terms of explaining it to
users and to implement, since all the code except removing the old
config section will be shared with "branch -m".
But having this "checkout --super-b -b <name> <start>" would make the UX
even uglier, since now we have a command that does 99% of what "branch
-m <name>" does, but is invoked differently.
I think this end state would make more sense:
|----------------------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
|----------------------------------------+--------------+-------+---------+-----------------+-------------|
| branch <name> | Y | N | N | N | N |
| checkout <name> | Y | N | N | N | Y |
| checkout -b <name> <start> | Y | N | Y | N | Y |
| DEPRECATED (WARNS): branch -m <name> | Y | Y | N | Y | Y |
| NEW: checkout --move -b <name> <start> | Y | Y | N | Y | Y |
| NEW: checkout --copy -b <name> <start> | Y | N | Y | Y | Y |
|----------------------------------------+--------------+-------+---------+-----------------+-------------|
I.e. let's just move this functionality to "git checkout" and deprecate
"branch -m" (which we could alias to begin with to checkout --move".
I think *that* would make sense, but not the half-assed solution of
moving a new checkout command to git-checkout while we have an analogous
checkout command in git-branch without being deprecated.