Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jul 7, 2008, at 7:42 AM, Jakub Narebski wrote:

Theodore Tso <tytso@xxxxxxx> writes:

True, but (and please correct me if I'm wrong) ORIG_HEAD will always
be pointing out HEAD before the user typed pretty much any git
porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,
it you have to paw through multiple HEAD@{n} to find the 'n' which
corresponds to state before executing the git plumbing command, since
multiple git plumbing commands could have updated the HEAD's reflog,
right?

You can always use _branch_ reflog, either in the <branch>@{1} form,
or in @{1} shortcut form.  @{1} should be equovalent to ORIG_HEAD
even for rebase.

I personally expected @{1} to be identical to HEAD@{1}. Since omitting a ref usually refers to HEAD, why shouldn't omitting it when referring to the reflogs mean the HEAD log? The definition of @{1} is useful since there's no other easy way to get "current branch's reflog", but I think it's non-obvious. (Since HEAD@{1} is something completely different, I think the only other way to refer to @{1} is $ (git symbolic-ref)@{1}.)

Also, your statement is only true if ORIG_HEAD was on the branch you are currently working. If we want ORIG_HEAD to mean "state of HEAD before last command", then "git rebase upstream topic" from master should leave ORIG_HEAD pointing to master, not topic@{1}. It also is no longer true if you switch branches. Having ORIG_HEAD set to the point before a pull is useful to compare multiple branches to both the old and new position of your updated branch.

If we're going to have ORIG_HEAD set by _any_ command, we should probably come up with some consistent definition of it and set it appropriately. The first place most people encounter ORIG_HEAD is after a pull, where it acts something like a reverse of FETCH_HEAD (old state of local vs. new state of remote). However, pull only sets ORIG_HEAD by way of merge and reset sets ORIG_HEAD as well. So the current definition appears to be "the prior state of the last branch to be drastically changed." By this definition, ORIG_HEAD should be set by am and rebase as per Junio's patch.

You could make an argument for removing ORIG_HEAD, it's functionality being replaced by the reflogs. At this point, it's a rather established bit of git, and I think has usefulness of it's own.

~~ Brian
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux