Junio C Hamano <junkio@xxxxxxx> writes:
> * jc/checkout (Thu Mar 29 01:23:12 2007 -0700) 4 commits
> + Use BASE index extension in git-commit and git-merge.
> + update-index --{set,get}-base
> + Add BASE index extension.
> + checkout: allow detaching to HEAD even when switching to the tip
> of a branch
>
> I've rewritten the bottom commit not to require an explicit -d
> option when detaching. You can say "git checkout master^0"
> instead to get a detached head that is at the tip of master. I
> may make that one commit graduate to 'master' earlier than
> others.
>
> This series is primarily to make it safer when somebody else
> updates the tip of the branch you have currently checked out.
> As I said in previous messages, I think the series covers basic
> operations fine but there probably are gaps in the coverage.
> Motivated volunteers are needed to fill them.
Regarding this series, if you find a command sequence that does
this:
(1) A command that is BASE aware (e.g. "git commit") is used to
point HEAD at a commit and records it in the index; and then,
(2) A command that is not yet BASE aware moves the HEAD
(perhaps creating a commit) but does not cause the
previously recorded BASE in the index to be updated to
point at the new HEAD (e.g. "git am");
your next invocation of a command that is BASE aware would barf,
saying something like:
* The index is based on 'c053f05... My earlier commit made in (1).', however, the HEAD
points at different commit '4fc2da4... The last of commits made with (2).'
When this happens, please first run "git-runstatus" [*1*] and
"git-diff HEAD" to see if this is a false positive. If the
output shows the differences from the HEAD you expect to see and
you are sure your index is derived from the current HEAD, and
not the error message indicates (in the above example, c053f05
is such a wrong commit), that means you ran some command that
needs to be taught about the BASE.
A work-around until that command is fixed is to run this:
$ git update-index --set-base `git-rev-parse HEAD`
This corrects the base commit recorded in the index to match
your current HEAD commit to allows you to keep going.
Motivated volunteers can help us further by doing two more
things. One is obviously to report such a case and identify
such a BASE unaware command, and even better, make it BASE
aware and send in patches.
Another thing is to make a habit of running 'git update-index
--get-base' after doing any git operation to see if the index
correctly records the base commit.
Currently, when git-read-tree is used to update the index, the
base information is discarded, and 'git update-index --get-base'
will return empty. Commands that are already BASE aware will
not trigger when the index does not record any base. This is to
prevent too many false positives while this safety feature is
still in development, but that means more false negatives. We
should minimize this base clobbering so that we can use multiple
work trees tied to the same repository more safely.
I'll follow-up this message with four patch series to make "git am"
and "git reset" BASE aware.
[Footnote]
*1* We need to fix "git status" to be usable for this as well,
but currently it shares much of its code with "git commit" and
triggers the same false positive)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html