Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-08 Thread Igor Djordjevic 
On 08/08/2017 15:14, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Aug 07 2017, Igor Djordjevic jotted:
>> On 07/08/2017 23:25, Igor Djordjevic wrote:
>>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
 On Sat, Aug 05 2017, Junio C. Hamano jotted:
> I actually consider "branch" to *never* invoking a checkout.  Even
> when "git branch -m A B" happens to be done when your checked out
> branch is A and you end up being on B.  That is not a "checkout".

 I think we just have a different mental model of what "checkout"
 means. In my mind any operation that updates the HEAD to point to a new
 branch is a checkout of that branch.
>>>
>>> If I may, from a side-viewer`s point of view, it seems you`re
>>> thinking in low-level implementation details, where what Junio
>>> describes seems more as a high-level, conceptual/end-user`s point of
>>> view.
> 
> Yeah, I think that's a fair summary. Also I didn't mean to de-rail this
> whole thread on what "checkout" really means, just explain what I meant
> with previous comments, since there seemed to be confusion about that.
> 
>>> Needing to update HEAD reference once we "rename" a branch, too, what
>>> you consider a "checkout", seems to be required only because branch
>>> name _is_ the branch reference in Git, so we need to update HEAD to
>>> point to a new/renamed branch reference -- but it`s still the same
>>> branch, conceptually.
> 
> It's not *required* we could do one of three things:
> 
>  1) Do what we do now, i.e. rename the branch/reflog & check out the new
> name.
> 
>  2) Rename the branch/reflog and checkout HEAD^0, i.e. say "the branch
> is now elsewhere, but we haven't moved your commit".
> 
>  3) Just not run replace_each_worktree_head_symref() which would end up
>  on a branch with no commits, i.e. an orphan branch.
> 
> Now, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we
> should do that, but it's illustrative that #1 is not some required
> inevitability in terms of explaining what's happening with the new name
> being checked out (i.e. HEAD being updated).

I think we agree, but we`re talking from different standpoints again.

You say "it *can* be done *but* it doesn`t make sense", where I say 
"it *can`t* be done *because* it doesn`t make sense".

Implementation wise, of course it can be done differently, but 
conceptually it would be wrong (or confusing, at least), thus 
different implementation, while theoretically possible, may not be a 
sane option, thus it`s impractical (not to say "impossible").

By "required", I really meant "required in order to be conceptually 
sane".

>>> Documentation for "git-checkout" states that it is used to "*Switch
>>> branches*...[snip]", and that is not what happens here.
> 
> That's just the summary at the top but not the full story of what
> git-checkout does. E.g. you can checkout a bare SHA1 which is not
> switching branches, or a tag or whatever.

I disagree, by checking out a bare SHA1 (or tag or whatever) I`d say 
you *are* still switching branches - conceptually, at least.

When you move from a named branch to (yet) unnamed one, you are 
switching branches. Same goes for when you switch from one unnamed 
branch to another (named or unnamed).

Might be "detached HEAD" is not something we call an "unnamed 
branch", but that`s what it practically is.

>>> Implementation-wise it does because we can`t do it differently at the
>>> moment, but in user`s eyes it`s still the same branch, so no switch
>>> is made as far as the user is concerned.
> 
> Kind of, it's also worthwhile to think about that in some sense no
> switch would be performed as far as the user is concerned by taking
> option #2, i.e. we'd be in the same working tree / you could still make
> commits.
> 
> You just couldn't make new commits on your "master" which is now called
> "topic" and get new commits on "topic". I think it makes sense to do
> that, but again, it's illustrative that it's not inevitable for
> discussing the implementation.

But your second paragraph exactly explains why it`s not the same with 
option #2 (I guess you mean "no HEAD update to point to renamed 
branch" here) - if user renames branch "master" to "topic", it`s 
natural to expect that next commit is made on "topic" (which is now a 
new name for "master", conceptually still being the same, just 
renamed branch).

Ending up in limbo, in a detached HEAD state, or even worse, still 
being on a branch with an old name "master" (which conceptually 
shouldn`t exist anymore, being known as "topic" now), would be 
confusing, to say the least, and conceptually wrong, I would add.

>>> In a different implementation, where branches would have permanent
>>> references other than their names, no HEAD update would be needed as
>>> the reference would still be the same, no matter the name change,
>>> making the `git branch -m` situation clear even from your standpoint,
>>> I`d say.
>>>
> Really from the end-user's point of

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-08 Thread Ævar Arnfjörð Bjarmason 

On Mon, Aug 07 2017, Igor Djordjevic jotted:

> On 07/08/2017 23:25, Igor Djordjevic wrote:
>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
>>> On Sat, Aug 05 2017, Junio C. Hamano jotted:
 I actually consider "branch" to *never* invoking a checkout.  Even
 when "git branch -m A B" happens to be done when your checked out
 branch is A and you end up being on B.  That is not a "checkout".
>>>
>>> I think we just have a different mental model of what "checkout"
>>> means. In my mind any operation that updates the HEAD to point to a new
>>> branch is a checkout of that branch.
>>
>> If I may, from a side-viewer`s point of view, it seems you`re
>> thinking in low-level implementation details, where what Junio
>> describes seems more as a high-level, conceptual/end-user`s point of
>> view.

Yeah, I think that's a fair summary. Also I didn't mean to de-rail this
whole thread on what "checkout" really means, just explain what I meant
with previous comments, since there seemed to be confusion about that.

>> Needing to update HEAD reference once we "rename" a branch, too, what
>> you consider a "checkout", seems to be required only because branch
>> name _is_ the branch reference in Git, so we need to update HEAD to
>> point to a new/renamed branch reference -- but it`s still the same
>> branch, conceptually.

It's not *required* we could do one of three things:

 1) Do what we do now, i.e. rename the branch/reflog & check out the new
name.

 2) Rename the branch/reflog and checkout HEAD^0, i.e. say "the branch
is now elsewhere, but we haven't moved your commit".

 3) Just not run replace_each_worktree_head_symref() which would end up
 on a branch with no commits, i.e. an orphan branch.

Now, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we
should do that, but it's illustrative that #1 is not some required
inevitability in terms of explaining what's happening with the new name
being checked out (i.e. HEAD being updated).

>> Documentation for "git-checkout" states that it is used to "*Switch
>> branches*...[snip]", and that is not what happens here.

That's just the summary at the top but not the full story of what
git-checkout does. E.g. you can checkout a bare SHA1 which is not
switching branches, or a tag or whatever.

>> Implementation-wise it does because we can`t do it differently at the
>> moment, but in user`s eyes it`s still the same branch, so no switch
>> is made as far as the user is concerned.

Kind of, it's also worthwhile to think about that in some sense no
switch would be performed as far as the user is concerned by taking
option #2, i.e. we'd be in the same working tree / you could still make
commits.

You just couldn't make new commits on your "master" which is now called
"topic" and get new commits on "topic". I think it makes sense to do
that, but again, it's illustrative that it's not inevitable for
discussing the implementation.

>> In a different implementation, where branches would have permanent
>> references other than their names, no HEAD update would be needed as
>> the reference would still be the same, no matter the name change,
>> making the `git branch -m` situation clear even from your standpoint,
>> I`d say.
>>
 Really from the end-user's point of view that is not a checkout.
 The user renamed the branch A and the same conceptual entity, which
 is a branch, is now called B.  If that branch was what was checked
 out (IOW, if that branch was what would be grown by one commit if
 the user did "git commit"), then now that branch's name is B.  It is
 natural if you ask "symbolic-ref HEAD" what branch is checked out
 after renaming A to B (and A happened to be what was checked out),
 the answer chould be B.

 It's like the city you live in changed the name of the street your
 house is on.  You do not call movers, you do not do anything, but
 your address changes.
>>>
>>> Yeah I see what you mean, although this analogy rapidly breaks down when
>>> you poke at it as shown above. My house (a sha1) can be on any number of
>>> streets and new ones can be added/removed all the time without changing
>>> where my house is at.
>>
>> I may be missing something, but I find the house/address analogy a
>> good one, actually, as I understood that "house" resembles a branch
>> reference HEAD is pointing to, not a sha1.
>>
>> Even further, and that might be the point of confusion, "house" seems
>> to be more like a "permanent branch reference" I mentioned above,
>> where your address can change (branch being renamed), but you would
>> still be in the same house (HEAD would still point to the same
>> permanent branch reference).
>>
>> If you move to another house, only then would HEAD change to point to
>> another (permanent) branch reference (a different house), and that
>> would be a checkout.

I've yet to see a good real-world analogy of "DAG with labels", which is
all git really is, that doesn't break down

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-07 Thread Igor Djordjevic 
On 07/08/2017 23:25, Igor Djordjevic wrote:
> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
>> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>>> I actually consider "branch" to *never* invoking a checkout.  Even
>>> when "git branch -m A B" happens to be done when your checked out
>>> branch is A and you end up being on B.  That is not a "checkout".
>>
>> I think we just have a different mental model of what "checkout"
>> means. In my mind any operation that updates the HEAD to point to a new
>> branch is a checkout of that branch.
> 
> If I may, from a side-viewer`s point of view, it seems you`re 
> thinking in low-level implementation details, where what Junio 
> describes seems more as a high-level, conceptual/end-user`s point of 
> view.
> 
> Needing to update HEAD reference once we "rename" a branch, too, what 
> you consider a "checkout", seems to be required only because branch 
> name _is_ the branch reference in Git, so we need to update HEAD to 
> point to a new/renamed branch reference -- but it`s still the same 
> branch, conceptually.
> 
> Documentation for "git-checkout" states that it is used to "*Switch 
> branches*...[snip]", and that is not what happens here. 
> Implementation-wise it does because we can`t do it differently at the 
> moment, but in user`s eyes it`s still the same branch, so no switch 
> is made as far as the user is concerned.
> 
> In a different implementation, where branches would have permanent 
> references other than their names, no HEAD update would be needed as 
> the reference would still be the same, no matter the name change, 
> making the `git branch -m` situation clear even from your standpoint, 
> I`d say.
> 
>>> Really from the end-user's point of view that is not a checkout.
>>> The user renamed the branch A and the same conceptual entity, which
>>> is a branch, is now called B.  If that branch was what was checked
>>> out (IOW, if that branch was what would be grown by one commit if
>>> the user did "git commit"), then now that branch's name is B.  It is
>>> natural if you ask "symbolic-ref HEAD" what branch is checked out
>>> after renaming A to B (and A happened to be what was checked out),
>>> the answer chould be B.
>>>
>>> It's like the city you live in changed the name of the street your
>>> house is on.  You do not call movers, you do not do anything, but
>>> your address changes.
>>
>> Yeah I see what you mean, although this analogy rapidly breaks down when
>> you poke at it as shown above. My house (a sha1) can be on any number of
>> streets and new ones can be added/removed all the time without changing
>> where my house is at.
> 
> I may be missing something, but I find the house/address analogy a 
> good one, actually, as I understood that "house" resembles a branch 
> reference HEAD is pointing to, not a sha1.
> 
> Even further, and that might be the point of confusion, "house" seems 
> to be more like a "permanent branch reference" I mentioned above, 
> where your address can change (branch being renamed), but you would 
> still be in the same house (HEAD would still point to the same 
> permanent branch reference).
> 
> If you move to another house, only then would HEAD change to point to 
> another (permanent) branch reference (a different house), and that 
> would be a checkout.
> 
> Yes, it`s not really how it works from the inside, but I think that`s 
> irrelevant for the end-user experience :)
> 
>> So it's just a way to get something exactly like -m except the "move &&
>> checkout" logic is changed to "copy && checkout".
>
> Again, it seems the "checkout" part of "move && checkout" you`re 
> talking about is a user-wise unnecessary implementation detail. For 
> the user, it`s just a simple "move", staying on the same, but renamed 
> branch, thus no branch switching occurred (no "checkout", as per 
> documentation).

All this said, having you mentioning the two argument version:

> $ git checkout master
> $ git branch -m topic avar/topic

... exactly proves the point that "git branch -m" is not expected to 
involve a checkout, even from implementation perspective. It`s just a 
consequence of needing to update the (now obsolete) reference HEAD 
points to (only) when the branch we`re renaming (moving) is the one 
that is currently checked-out.

> Yeah it's not something I'm interested in or have a use-case for,
> although I think in the same way we have -t for checkout it might be
> sensible to have e.g.:
> 
> $ git checkout -b topic-2 -c topic -t origin/master
> 
> Where the new -c or --config-from would mean "...and get the config from
> 'topic'". Such a name would probably be less confusing than
> --super-b[branch?] which to be implies some ongoing hierarchical
> relationship.

This, on the other hand, sounds sensible, staying true to the 
existing logic. In the same manner you can do either:

$ git branch topic -t origin/master
$ git checkout topic

... or shorter equivalent:

$ git checkout -b topic -t

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-07 Thread Igor Djordjevic 
On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>> I actually consider "branch" to *never* invoking a checkout.  Even
>> when "git branch -m A B" happens to be done when your checked out
>> branch is A and you end up being on B.  That is not a "checkout".
> 
> I think we just have a different mental model of what "checkout"
> means. In my mind any operation that updates the HEAD to point to a new
> branch is a checkout of that branch.

If I may, from a side-viewer`s point of view, it seems you`re 
thinking in low-level implementation details, where what Junio 
describes seems more as a high-level, conceptual/end-user`s point of 
view.

Needing to update HEAD reference once we "rename" a branch, too, what 
you consider a "checkout", seems to be required only because branch 
name _is_ the branch reference in Git, so we need to update HEAD to 
point to a new/renamed branch reference -- but it`s still the same 
branch, conceptually.

Documentation for "git-checkout" states that it is used to "*Switch 
branches*...[snip]", and that is not what happens here. 
Implementation-wise it does because we can`t do it differently at the 
moment, but in user`s eyes it`s still the same branch, so no switch 
is made as far as the user is concerned.

In a different implementation, where branches would have permanent 
references other than their names, no HEAD update would be needed as 
the reference would still be the same, no matter the name change, 
making the `git branch -m` situation clear even from your standpoint, 
I`d say.

>> Really from the end-user's point of view that is not a checkout.
>> The user renamed the branch A and the same conceptual entity, which
>> is a branch, is now called B.  If that branch was what was checked
>> out (IOW, if that branch was what would be grown by one commit if
>> the user did "git commit"), then now that branch's name is B.  It is
>> natural if you ask "symbolic-ref HEAD" what branch is checked out
>> after renaming A to B (and A happened to be what was checked out),
>> the answer chould be B.
>>
>> It's like the city you live in changed the name of the street your
>> house is on.  You do not call movers, you do not do anything, but
>> your address changes.
> 
> Yeah I see what you mean, although this analogy rapidly breaks down when
> you poke at it as shown above. My house (a sha1) can be on any number of
> streets and new ones can be added/removed all the time without changing
> where my house is at.

I may be missing something, but I find the house/address analogy a 
good one, actually, as I understood that "house" resembles a branch 
reference HEAD is pointing to, not a sha1.

Even further, and that might be the point of confusion, "house" seems 
to be more like a "permanent branch reference" I mentioned above, 
where your address can change (branch being renamed), but you would 
still be in the same house (HEAD would still point to the same 
permanent branch reference).

If you move to another house, only then would HEAD change to point to 
another (permanent) branch reference (a different house), and that 
would be a checkout.

Yes, it`s not really how it works from the inside, but I think that`s 
irrelevant for the end-user experience :)

> So it's just a way to get something exactly like -m except the "move &&
> checkout" logic is changed to "copy && checkout".
Again, it seems the "checkout" part of "move && checkout" you`re 
talking about is a user-wise unnecessary implementation detail. For 
the user, it`s just a simple "move", staying on the same, but renamed 
branch, thus no branch switching occurred (no "checkout", as per 
documentation).

Regards,
Buga

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-06 Thread Ævar Arnfjörð Bjarmason 

On Sat, Aug 05 2017, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason  writes:
>
>> 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   | Y| N | N   | N
>>| N   |
>> | checkout | Y| N | N   | N
>>| Y   |
>> | checkout -b   | Y| N | Y   | N
>>| Y   |
>> | branch -m| Y| Y | N   | Y
>>| Y   |
>> | NEW: branch -c   | Y| N | Y   | Y
>>| Y   |
>> 
>> |+--+---+-+-+-|
>
> I actually consider "branch" to *never* invoking a checkout.  Even
> when "git branch -m A B" happens to be done when your checked out
> branch is A and you end up being on B.  That is not a "checkout".

I think we just have a different mental model of what "checkout"
means. In my mind any operation that updates the HEAD to point to a new
branch is a checkout of that branch.

In the interest of explaining what I mean with the above and not proving
you wrong or whatever, consider a basic implementation of git before
pack-refs or whatever.

You could then copy a branch name like:

$ cp .git/refs/heads/{master,master-copy}

Get your currently checked out branch with:

$ cat .git/HEAD
ref: refs/heads/master

And you could then implement "git checkout" like:

$ echo "ref: refs/heads/master-copy" >.git/HEAD

This still works today. Now if I make a commit it goes on the
.git/refs/heads/master-copy branch.

Now let's say I wanted to rename the 'master' branch. This would rename
it:

$ mv .git/refs/heads/{master,trunk}

But it wouldn't check it out, my HEAD would still point to master:

$ git log
fatal: your current branch 'master' does not have any commits yet
$ git log --oneline -1 trunk
8b18718 (trunk) moo

To check it out I need:

$ echo "ref: refs/heads/trunk" >.git/HEAD

Which yields:

$ git log --oneline -1 HEAD
8b18718 (HEAD -> trunk) moo

The mv sans the "echo" is what we'd get if we did:

diff --git a/builtin/branch.c b/builtin/branch.c
index 8a0595e115..62ed1a8e20 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -493,9 +493,6 @@ static void rename_branch(const char *oldname, const 
char *newname, int force)
if (recovery)
warning(_("Renamed a misnamed branch '%s' away"), 
oldref.buf + 11);

-   if (replace_each_worktree_head_symref(oldref.buf, newref.buf, 
logmsg.buf))
-   die(_("Branch renamed to %s, but HEAD is not updated!"), 
newname);
-
strbuf_release();

strbuf_addf(, "branch.%s", oldref.buf + 11);

I.e. the last step of "git branch -m" is checking out the branch by
updating the HEAD. Now let's compile git like that and rename "master"
to "trunk":

$ git symbolic-ref HEAD
refs/heads/master
$ ./git-branch -m trunk
$ git symbolic-ref HEAD
refs/heads/master
$ git show
fatal: your current branch 'master' does not have any commits yet

Now let's do the equivalent of that removed
replace_each_worktree_head_symref():

$ git checkout trunk
Switched to branch 'trunk'

And voila:

$ git symbolic-ref HEAD
refs/heads/trunk

This is why I'm saying that "git branch -m" involves a checkout. Because
it is literally exactly the case that it could be replaced by a
shellscript whose last step is a "git checkout" of the new branch.

Anyway, none of that changes what we /should/ be doing on the fact that
"git branch -m" not updating the HEAD would be rather useless. I just
wanted to explain what I was talking about and why I was talking about
"checkout" in that context.

> Really from the end-user's point of view that is not a checkout.
> The user renamed the branch A and the same conceptual entity, which
> is a branch, is now called B.  If that branch was what was checked
> out (IOW, if that branch was what would be grown by one commit if
> the user did "git commit"), then now that branch's name is B.  It is
> natural if you ask "symbolic-ref HEAD" what branch is checked out
> after renaming A to B (and A happened to be what was checked out),
> the answer chould be B.
>
> It's like the city you live in changed the name of the street your
> house is on.  You do not call movers, you do not do anything, but
> your

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-05 Thread Junio C Hamano 
Ævar Arnfjörð Bjarmason  writes:

> 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   | Y| N | N   | N 
>   | N   |
> | checkout | Y| N | N   | N 
>   | Y   |
> | checkout -b   | Y| N | Y   | N 
>   | Y   |
> | branch -m| Y| Y | N   | Y 
>   | Y   |
> | NEW: branch -c   | Y| N | Y   | Y 
>   | Y   |
> 
> |+--+---+-+-+-|

I actually consider "branch" to *never* invoking a checkout.  Even
when "git branch -m A B" happens to be done when your checked out
branch is A and you end up being on B.  That is not a "checkout".

Really from the end-user's point of view that is not a checkout.
The user renamed the branch A and the same conceptual entity, which
is a branch, is now called B.  If that branch was what was checked
out (IOW, if that branch was what would be grown by one commit if
the user did "git commit"), then now that branch's name is B.  It is
natural if you ask "symbolic-ref HEAD" what branch is checked out
after renaming A to B (and A happened to be what was checked out),
the answer chould be B.

It's like the city you live in changed the name of the street your
house is on.  You do not call movers, you do not do anything, but
your address changes.

> I.e. have "branch -c " 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   | Y| Y | N
>| Y   | Y   |
> [... so is branch -m but included for context ...]
> | NEW: checkout --super-b -b   | Y| N | Y
>| Y   | Y   |
> 
> |---+--+---+-+-+-|

You are talking backwards.  I do not want "branch -c A B", even when
A happens to be what is checked out, to check out branch B.  You and
Sahil were who wanted to check out branch B while doing so, and I
just tried to guess why you two wanted to have such a behaviour that
did not make much sense to me.  And my guess was "perhaps they want
a way to create a new branch starting from another branch, and check
it out, and do so in a single end-user operation".  

I am not particulary interested in such an operation; in my guess,
you two are.  And the "super-b" thing was a suggestion to you two:
If you so desperately want such an operation, then don't make
"branch --copy A B" that operation.  Such an operation better fits
in "checkout", not "branch".

If you are not interested in such an operation, then that is fine.
Do not add the "super-b" mode to "checkout".

But I won't defend a "branch --copy A B" that checks out B when
users and other people like Ramsay think that such a behaviour is
illogical, because I do think it is, too.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-05 Thread Ævar Arnfjörð Bjarmason 

On Thu, Aug 03 2017, Junio C. Hamano jotted:

> Sahil Dua  writes:
>
>> Ah! I had skipped this reply from Ramsay earlier.
>>
>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
>> ...
  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   | Y| N | N   | N   
| N   |
| checkout | Y| N | N   | N   
| Y   |
| checkout -b   | Y| N | Y   | N   
| Y   |
| branch -m| Y| Y | N   | Y   
| Y   |
| NEW: branch -c   | 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   | Y| N | Y   | Y   
| {-Y, +N}|

|+--+---+-+-+-|

I.e. have "branch -c " 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   | Y| Y | N  
 | Y   | Y   |
[... so is branch -m but included for context ...]
| NEW: checkout --super-b -b   | 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

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-03 Thread Ramsay Jones 


On 03/08/17 22:07, Junio C Hamano wrote:
> Sahil Dua  writes:
> 
>> Ah! I had skipped this reply from Ramsay earlier.
>>
>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
>> ...
  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

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-03 Thread Junio C Hamano 
Sahil Dua  writes:

>>
>> * sd/branch-copy (2017-06-18) 3 commits
>>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>>  + branch: add a --copy (-c) option to go with --move (-m)
>>  + branch: add test for -m renaming multiple config sections
>>  + config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Will cook in 'next'.
>
> Junio, are we still waiting for interaction with other patches to
> settle down or simply cooking it further for any potential
> feedback/suggestions on this?

No, "waiting for other topics to settle" was a long time ago.
During the pre-release feature freeze, nothing will be merged to
'master', unless it is a trivially correct bugfix or a regression
fix.  This one is neither.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-03 Thread Junio C Hamano 
Sahil Dua  writes:

> Ah! I had skipped this reply from Ramsay earlier.
>
> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
> ...
>>>  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.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-03 Thread Sahil Dua 
Ah! I had skipped this reply from Ramsay earlier.

On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
 wrote:
>
>
> On 31/07/17 23:30, Junio C Hamano wrote:
> [snip]
>>
>> * sd/branch-copy (2017-06-18) 3 commits
>>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>>  + branch: add a --copy (-c) option to go with --move (-m)
>>  + branch: add test for -m renaming multiple config sections
>>  + config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Will cook in 'next'.
>>
>>  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 think it's really a matter of how this feature is seen from the
end-user point of view. If we consider example "branch --copy master
backup" - obviously, switching to backup isn't the ideal situation.
However, if we consider the example above, switching makes sense. None
of them is going to be correct in 100% cases. :)

> However, I guess the worst that
> would happen, is that it would gain another 'wort' (--option) to
> turn off the "switches to backup" branch. :-D
>
> I didn't want you to think that the lack of comments on this was
> because everybody agreed that it was a good idea.
>
> ATB,
> Ramsay Jones
>
>

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-03 Thread Stefan Beller 
On Thu, Aug 3, 2017 at 1:17 PM, Sahil Dua  wrote:
>>
>> * sd/branch-copy (2017-06-18) 3 commits
>>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>>  + branch: add a --copy (-c) option to go with --move (-m)
>>  + branch: add test for -m renaming multiple config sections
>>  + config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Will cook in 'next'.
>
> Junio, are we still waiting for interaction with other patches to
> settle down or simply cooking it further for any potential
> feedback/suggestions on this?

I think anything currently cooking in next is waiting for the next
release to happen, and then progress to master IIUC eventually
unless noted otherwise.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-08-03 Thread Sahil Dua 
>
> * sd/branch-copy (2017-06-18) 3 commits
>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>  + branch: add a --copy (-c) option to go with --move (-m)
>  + branch: add test for -m renaming multiple config sections
>  + config: create a function to format section headers
>
>  "git branch" learned "-c/-C" to create and switch to a new branch
>  by copying an existing one.
>
>  Will cook in 'next'.

Junio, are we still waiting for interaction with other patches to
settle down or simply cooking it further for any potential
feedback/suggestions on this?

>
>  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'.
>

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-07-31 Thread Ramsay Jones 


On 31/07/17 23:30, Junio C Hamano wrote:
[snip]
> 
> * sd/branch-copy (2017-06-18) 3 commits
>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>  + branch: add a --copy (-c) option to go with --move (-m)
>  + branch: add test for -m renaming multiple config sections
>  + config: create a function to format section headers
> 
>  "git branch" learned "-c/-C" to create and switch to a new branch
>  by copying an existing one.
> 
>  Will cook in 'next'.
> 
>  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. However, I guess the worst that
would happen, is that it would gain another 'wort' (--option) to
turn off the "switches to backup" branch. :-D

I didn't want you to think that the lack of comments on this was
because everybody agreed that it was a good idea.

ATB,
Ramsay Jones

What's cooking in git.git (Jul 2017, #09; Mon, 31)

2017-07-31 Thread Junio C Hamano 
Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

Even though -rc2 was scheduled for today, I'll wait for a few days
so that we can tag with updated l10n; there isn't much change since
the first release candidate.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* js/blame-lib (2017-07-24) 1 commit
  (merged to 'next' on 2017-07-26 at db0d081012)
 + blame: fix memory corruption scrambling revision name in error message

 A hotfix to a topic already in 'master'.

--
[New Topics]

* as/diff-options-grammofix (2017-07-31) 1 commit
 - diff-options doc: grammar fix

 A grammofix.

--
[Stalled]

* mg/status-in-progress-info (2017-05-10) 2 commits
 - status --short --inprogress: spell it as --in-progress
 - status: show in-progress info for short status

 "git status" learns an option to report various operations
 (e.g. "merging") that the user is in the middle of.

 cf. 


* nd/worktree-move (2017-04-20) 6 commits
 - worktree remove: new command
 - worktree move: refuse to move worktrees with submodules
 - worktree move: accept destination as directory
 - worktree move: new command
 - worktree.c: add update_worktree_location()
 - worktree.c: add validate_worktree()

 "git worktree" learned move and remove subcommands.

 Expecting a reroll.
 cf. <20170420101024.7593-1-pclo...@gmail.com>
 cf. <20170421145916.mknekgqzhxffu...@sigill.intra.peff.net>
 cf. 


* sg/clone-refspec-from-command-line-config (2017-06-16) 2 commits
 - Documentation/clone: document ignored configuration variables
 - clone: respect additional configured fetch refspecs during initial fetch
 (this branch is used by sg/remote-no-string-refspecs.)

 "git clone -c var=val" is a way to set configuration variables in
 the resulting repository, but it is more useful to also make these
 variables take effect while the initial clone is happening,
 e.g. these configuration variables could be fetch refspecs.

 Waiting for a response.
 cf. <20170617112228.vugswym4o4owf...@sigill.intra.peff.net>
 cf. 


* js/rebase-i-final (2017-07-27) 10 commits
 - rebase -i: rearrange fixup/squash lines using the rebase--helper
 - t3415: test fixup with wrapped oneline
 - rebase -i: skip unnecessary picks using the rebase--helper
 - rebase -i: check for missing commits in the rebase--helper
 - t3404: relax rebase.missingCommitsCheck tests
 - rebase -i: also expand/collapse the SHA-1s via the rebase--helper
 - rebase -i: do not invent onelines when expanding/collapsing SHA-1s
 - rebase -i: remove useless indentation
 - rebase -i: generate the script via rebase--helper
 - t3415: verify that an empty instructionFormat is handled as before

 The final batch to "git rebase -i" updates to move more code from
 the shell script to C.

 Expecting a reroll.


* bp/fsmonitor (2017-06-12) 6 commits
 - fsmonitor: add a sample query-fsmonitor hook script for Watchman
 - fsmonitor: add documentation for the fsmonitor extension.
 - fsmonitor: add test cases for fsmonitor extension
 - fsmonitor: teach git to optionally utilize a file system monitor to speed up 
detecting new or changed files.
 - dir: make lookup_untracked() available outside of dir.c
 - bswap: add 64 bit endianness helper get_be64

 We learned to talk to watchman to speed up "git status".

 Expecting a reroll.
 cf. 

--
[Cooking]

* ah/doc-wserrorhighlight (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at cd1bb28d95)
 + doc: add missing values "none" and "default" for diff.wsErrorHighlight

 Doc update.

 Will cook in 'next'.


* dc/fmt-merge-msg-microcleanup (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at 6df06eb788)
 + fmt-merge-msg: fix coding style

 Code cleanup.

 Will cook in 'next'.


* js/git-gui-msgfmt-on-windows (2017-07-25) 7 commits
 - Merge branch 'js/msgfmt-on-windows' of ../git-gui into 
js/git-gui-msgfmt-on-windows
 - git-gui (MinGW): make use of MSys2's msgfmt
 - Merge remote-tracking branch 'philoakley/dup-gui'
 - git gui: allow for a long recentrepo list
 - git gui: de-dup selected repo from recentrepo history
 - git gui: cope with duplicates in _get_recentrepo
 - git-gui: remove duplicate entries from .gitconfig's gui.recentrepo

 Because recent Git for Windows do come with a real msgfmt, the
 build procedure for git-gui has been updated to use