With this series, I am taking hints from Linus and trying to
illustrate a problem, show an approach to its solution and code
minimally to get others interested enough to follow through.
[PATCH 1/3] Add BASE index extension.
[PATCH 2/3] update-index --{set,get}-base
[PATCH 3/3] Use BASE index extension in git-commit and git-merge.
The problem description and the strategy to solve it are in the
commit log message of [PATCH 3/3]. There I only talk about
git-push from elsewhere while we are looking the other way, but
the same situation can also happen when you use a lightweight
shared working tree (i.e. Julian phillips's git-new-workdir) and
make a commit on a branch in one working tree while the other
working tree has a checkout of the same branch.
Let's see who are motivated enough to bite.
Junio C Hamano <junkio <at> cox.net> writes:
With this series, I am taking hints from Linus and trying to
illustrate a problem, show an approach to its solution and code
minimally to get others interested enough to follow through.
[PATCH 1/3] Add BASE index extension.
[PATCH 2/3] update-index --{set,get}-base
[PATCH 3/3] Use BASE index extension in git-commit and git-merge.
The problem description and the strategy to solve it are in the
commit log message of [PATCH 3/3]. There I only talk about
git-push from elsewhere while we are looking the other way, but
the same situation can also happen when you use a lightweight
shared working tree (i.e. Julian phillips's git-new-workdir) and
make a commit on a branch in one working tree while the other
working tree has a checkout of the same branch.
Let's see who are motivated enough to bite.
This seems very nice, not just because of under-the-hood pushes, but also wrt
the contrib/workdir thing: good to solve two slightly different problems in a
single consistent way.
Just a minor question:
From, your comments to patch 3/3 it looks like when a "commit" or "status" (or
whatever command) catches the mismatch in the head from the index-commit, it
only exits with a notice. And you also mention that recovery then happens via
head detaching (that in your example is done manually)...
If (as I am guessing) head detaching is the /only/ possible path to recovery,
wouldn't it make sense to do it automatically, storing somewhere the latest
branch one was on (e.g. to be used for subsequent merge)?
Also, in general: whenever head gets detached (e.g. by a checkout) would it make
sense to "by default" store somewhere the previous branch name? (e.g. to gain a
shorthand command to get back to the former branch)?
Thanks,
Sergio