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