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

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Are you sure?  When I do
 >     hg log -b c++11-0-1
 > , Mercurial lists every changeset made on branch c++11-0-1, and no other
 > changesets.  It knows when the branch was created, and distinguishes it
 > from the other branch it separated from.

I believe it's lying to you, unless you're using named branches.  If
you're using named branches, yes, it knows, but then you have other
problems (nodes and merges -- arguably the more important commits --
can only be on one branch, and either choice is the wrong one in some
use cases).

Specifically, in an ordinary Mercurial branch if at (2) you "hg pull"
from upstream, merging (3) and committing to get (4):

      2              2              2
     /              / \            / \
0 - 1    =>    0 - 1   *  =>  0 - 1   4
                    \ /            \ /
                     3              3

I don't see how it's possible to identify branches.  (Note that (2)
and (3) might both be nontrivial sequences of commits, so that
"branch" would be idiomatic in referring to them.)

Also, you have the question of which branch are (1) and (4) "on".  You
could argue that because (2) was committed to this repo before (3),
(1) and (4) are on (2)'s branch, but that might be semantically
incorrect: (1) - (3) - (4) is actually the planned line of development
(and (3) may have been pushed upstream before you committed (2), while
(2) is a typo fix or an out-of-the-blue "volunteer" contribution.
               
 > I think this last feature is missing in git.

Could be.  I don't have a use for it, so I can't help you there.

 > Can't say I've ever felt that to be any sort of restriction.

Come back in a year and I bet you'll have changed your mind. :-)

 > I can imagine that having nine or ten foci of development in on
 > workspace would be unworkable in the extreme.

It's no problem for me.  I typically have about that many: the
mainline, my principal feature branches (usually two or three), a
typos branch, and a few "memos on future work" branches.  There you
are, ten foci of development.

The typical "emphemeral branch" workflow (eg, typo fixes) is like this:

1) Detect a typo
2) Fix it (but don't save)
3) Save off branch name            -+
3) git stash save                   |
4) git checkout "typos"             |
5) Save file                        +- Implemented as an Emacs command
6) git commit -m "Fix typo."        |
7) git checkout <previous branch>   |
8) git stash pop                   -+

Note that only the branch name is variable, and can be automatically
determined.  So the whole thing takes a few seconds, and steps 3-8
seem to happen almost instantaneously.  (Note that I accumulate
several typos in this branch, so I usually rebase and smash the
commits to a single commit before pushing.  That's when I do a proper
log message.)  That is, in git it's "instantaneous".  In hg, it's
noticable, and in bzr it's time-consuming.  I use pipelines (my
preference now) or looms in bzr for that reason, but they are harder
to automate (possibly because I don't use them much).

The "memos" branches take more time, I haven't automated them yet.
The basic difference is that each memo branch basically amounts to a
nontrivial task ("refactor this", "apply an analogous fix here", "new
feature?")  unrelated to any currently active lines of development.
Sometimes the "memo" is nothing more than a branch ref stuck on the
current commit, but usually it involves comments in one or more files
(ugly, incomplete, probably unintelligible if you're not me).  If the
whole list of branches gets to more than about 20, I know it's time to
drop other work and clean up the name space because I'm unlikely to
get to all of these tasks.

Works for me.  Your Mileage May Vary.