Re: Obscure error/warning/information message from git pull

[Yuri Khan]

On Wed, Nov 19, 2014 at 4:43 AM, Alan Mackenzie <address@hidden> wrote:
>
>> Well, given the following history (time goes from left to right):
>
>>              - C - D <- foo
>>            /
>> ... - A - B
>>            \
>>              - E - F <- bar
>
>
>> what branch commit A was made on, 'foo' or 'bar'?
>
> Quite clearly, A was committed on branch foo, since bar didn't exist at
> that time.

But git does not know that. For all it knows, bar could be the
original branch and foo branched from it at B. The history above is
symmetrical.

> Are you saying that at B, when bar is branched from foo, git discards
> all information about this branching, remembering only that there are two
> branches which are henceforth of fully equal status where before there
> was just one?

There *is* no information to discard. Heads are completely separate
from the DAG, a thin convenience layer over it, an /etc/hosts analog
for SHA1 hashes. Head names are arbitrary and can be changed at any
time. Indeed, it is a common thing for me to start development on
master and make a few commits:

$ git checkout master
$ hack; git commit
$ hack; git commit
$ hack; git commit
$ hack; git commit

           o---o---o---o *master*
         /
---o---o origin/master

Oops, it’s going out of control and I will possibly need a couple days
more and I envision a prettifying rebase down the road. Let’s make it
a feature branch.

$ git branch feature

           o---o---o---o feature, *master*
         /
---o---o origin/master

Put master where it belongs:

$ git reset --hard origin/master

           o---o---o---o feature
         /
---o---o origin/master, *master*

Now continue work:

$ git checkout feature
$ hack; git commit

           o---o---o---o---o *feature*
         /
---o---o origin/master, master

If git remembered the branch name with each commit, that retroactive
branching would not be possible.


(Nitpicker’s corner: Some will say such workflows are sloppy and a bad
practice and one should always start work on a feature branch, even if
the feature is a one-liner, and then merge it to master with a
--no-ff. They are missing the point. Git *allows* us to be sloppy and
correct mistakes afterwards, rather than require constant vigilance.)