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

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

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.

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.

The use-case is the following. When I hack on e.g. git.git I'm on "master" with configured upstream info:

    $ git log @{u}..

Because if I don't care about 'master' another shorter way to say:

    $ git checkout -b topic -t origin/master

Is:

    $ git branch -m topic

That's how I start hacking on "topic", now let's say I've submitted that and want to start on topic-2 after getting feedback:

    # While still on topic
    $ git branch -c topic-2

So it's just a way to get something exactly like -m except the "move && checkout" logic is changed to "copy && checkout".

That's arguably another sensible way to do a /subset/ of what 'git branch -c' does (or something in addition to this patch). But there's another use-case it won't cover, i.e. the two-arg branch -m/-c manipulating a branch that HEAD doesn't point to:

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

You can now do that with -c to s/move/copy/, but couldn't do this with checkout unless you wastefully and needlessly updated the working tree.

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.

I just started this from the POV of using branch -m and wanting something like that which didn't remove the old thing when it was done as its last step, which seemed easy to implement & explain.

As noted above I think it probably makes sense to also have something like [--config-from|-c] for checkout, which would have a related but not exactly the same use-case.