Re: [PATCH] merge: Preserve ORIG_HEAD if already up-to-date with remote.

[Kunal Gangakhedkar <kunal.gangakhedkar@gmail.com>]

On Wednesday 15 Jun 2011 4:44:28 am Junio C Hamano wrote:
> Kunal Gangakhedkar <kunal.gangakhedkar@gmail.com> writes:
> > Do not update ORIG_HEAD ref to current HEAD if the repo is already
> > in-sync with the remote.
> > 
> > Otherwise, it becomes difficult to keep track of last set of changes.
> > 
> > With this patch, it's possible to do a diffstat/log for last set of
> > changes even after a pull/merge that returns 'Already up-to-date'.
> 
> I am not sure what you mean.  If you are behind remote A and remote B is
> behind remote A, i.e.
> 
> 	You -- (fast forwards) --> B -- (fast forwards) --> A
> 
> then you should be able to expect these:
> 	: point zero
> 
> 	$ git pull A
>         $ git diff/log ORIG_HEAD.. ;# shows how your tree and history
>         			    # are updated wrt point zero above
> 
> 	: point one
> 
> 	$ git pull B
>         $ git diff/log ORIG_HEAD.. ;# shows how your tree and history
>         			    # are updated wrt point one above
> 
> If your patch is to stop recording ORIG_HEAD for the second "git pull"
> above, I fail to see how that could be a good change.
> 
> If you want to drive "pull" from a script (e.g. cron) and want to have
> precise control of what happens depending on how HEAD is updated, your
> script has enough freedom and flexibility to do so before running "pull",
> I think.  E.g.
> 
> 	. $(git --exec-path)/git-sh-setup
> 
> 	CURRENT=$(git rev-parse HEAD^0) || die "Eh? No Head?"
>         git pull || die "pull fails"
>         UPDATED=$(git rev-parse HEAD^0)
>         if test "$CURRENT" = "$UPDATED"
>         then
> 		exit 0; # nothing happened
> 	fi
> 	git shortlog --no-merges $CURRENT..$UPDATED
>         git diff --stat --summary $CURRENT..$UPDATED

Sorry, got caught up in butt-load of work..

Well, that's not what I meant.
The default diffstat at the end of merge/ff/pull already gives the required 
info.

The problem comes when the remote _does not_ have updates since last pull.
With a 'git pull' next time around (i.e. with no updates in the remote), 
ORIG_HEAD is moved to the current HEAD and the range of commits in the last 
changeset are lost. That is, I can no longer figure out the contents of the 
last changeset.

To give an example, let's track the following sequence:

	$ git clone git://url/of/super-awesome/project.git  	(0)
		.... hack hack hack in remote ....
		.... remote is fast-forwarded ...
	$ git pull									(1)
		... you got the changes ....
		.... hack hack hack in remote ....
		.... remote is fast-forwarded ...
	$ git pull									(2)
		... you got the changes ....
		... now, everybody is on vacation, so, no updates in remote ...
	$ git pull									(3)
		... you get 'Already up-to-date.' message ...
		... everybody is still on vacation, so, no updates in remote  ...
	$ git pull									(4) 
		... you get 'Already up-to-date.' message ...

In the current situation, at the end of (3) above, ORIG_HEAD is moved to the 
then HEAD. So, after (3), if I try to do 
	git diff/log ORIG_HEAD..
I'd get an empty changeset - i.e. I've lost the *last updated* changeset 
information.

What my patch does is keep ORIG_HEAD at its current state in (3) - so that 
changeset info is still available after (3) until there is an update in 
tracked branch of remote. At which point, ORIG_HEAD will be forwarded again
to the then HEAD and HEAD will point to the newly merged HEAD to reflect the 
changes from remote.

This way, the *latest* changeset is always available for inspection whether 
there's been an update in remote or not. I can safely do 
	git diff/log ORIG_HEAD..
after (4) as well and I'd still get the required information.

I've included config/cmdline options in the patch to force-update ORIG_HEAD so 
that current behavior is retained.

Please let me know if it makes sense.

I've written a simple test script for the functionality, but I'm not sure how 
to name it. Currently, in my working copy, it's called 
	t5555-merge-preserve-orig-head.sh
If that's fine, I'll send it in another patch for review. Otherwise, please 
suggest a good name for it.

Thanks,
Kunal