On Wednesday 15 Jun 2011 4:44:28 am Junio C Hamano wrote: > Kunal Gangakhedkar <kunal.gangakhedkar@xxxxxxxxx> 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 -- 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