Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)
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)
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)
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 or
Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)
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)
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(&logmsg); strbuf_addf(&oldsection, "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 add
Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)
Æ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)
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 scratch with the benefit of
Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)
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)
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)
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)
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)
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)
> > * 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)
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)
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 it instead of a hand-rolled substitute. * jt/subprocess-handshake (2017-07-26) 3 commits - sub-process: refactor handshake to common function - Documentation: migrate sub-process docs to header