I want "fast forward my workdir to upstream if it's safe"

I want "fast forward my workdir to upstream if it's safe"

[Randal L. Schwartz]

For the past few years, within any given 12 hour period, at least
one person on #git would come up with the use case with which I'm
really familiar (having needed it many times myself):

  I have a workdir tracking a remote.
  I may or may not have made local edits... I can't remember.
  I may or may not have made local commits... I can't remember.
  But the upstream might now have changed... please update me *safely*.

Seriously, this comes up, a lot.  Typically, from a cron job updater,
but often just "what can I do to make sure I'm up to date".

So, what I need is a command, likely an option to "git merge" that says "do
everything that a git merge would do except abort if it would have been a
merge commit".  In other words, abort if the workdir is dirty or is not a
fast-forward update to the upstream.  Bonus if it exits non-zero if
something went wrong.

Please don't tell me "use these three commands in this script".
I want a *command* I can tell people in #git.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: I want "fast forward my workdir to upstream if it's safe"

[Wincent Colaiuta]

El 7/5/2009, a las 23:40, Randal L. Schwartz escribió:

> For the past few years, within any given 12 hour period, at least
> one person on #git would come up with the use case with which I'm
> really familiar (having needed it many times myself):
>
>  I have a workdir tracking a remote.
>  I may or may not have made local edits... I can't remember.
>  I may or may not have made local commits... I can't remember.
>  But the upstream might now have changed... please update me *safely*.
>
> Seriously, this comes up, a lot.  Typically, from a cron job updater,
> but often just "what can I do to make sure I'm up to date".
>
> So, what I need is a command, likely an option to "git merge" that  
> says "do
> everything that a git merge would do except abort if it would have  
> been a
> merge commit".  In other words, abort if the workdir is dirty or is  
> not a
> fast-forward update to the upstream.  Bonus if it exits non-zero if
> something went wrong.
>
> Please don't tell me "use these three commands in this script".
> I want a *command* I can tell people in #git.

"git status"?

# On branch master
# Your branch is ahead of 'origin/master' by 46 commits.
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working  
directory)
#
#       modified:   foo
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       bar

Re: I want "fast forward my workdir to upstream if it's safe"

[Randal L. Schwartz]

>>>>> "Wincent" == Wincent Colaiuta <win@wincent.com> writes:

>> I want a *command* I can tell people in #git.

Wincent> "git status"?

Wincent> # On branch master
Wincent> # Your branch is ahead of 'origin/master' by 46 commits.
Wincent> #
Wincent> # Changed but not updated:
Wincent> #   (use "git add <file>..." to update what will be committed)
Wincent> #   (use "git checkout -- <file>..." to discard changes in working  directory)
Wincent> #
Wincent> #       modified:   foo
Wincent> #
Wincent> # Untracked files:
Wincent> #   (use "git add <file>..." to include in what will be committed)
Wincent> #
Wincent> #       bar

Now, you expect them to parse that in a script?  "git status" is porcelain,
not plumbing, and can change from version to version, and has.

I want a command I can put in a cron job that Does The Right Thing.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: I want "fast forward my workdir to upstream if it's safe"

[Jeff King]

On Thu, May 07, 2009 at 02:40:00PM -0700, Randal L. Schwartz wrote:

> So, what I need is a command, likely an option to "git merge" that says "do
> everything that a git merge would do except abort if it would have been a
> merge commit".  In other words, abort if the workdir is dirty or is not a
> fast-forward update to the upstream.  Bonus if it exits non-zero if
> something went wrong.

Can you define more clearly what you want, because you are asking for
conflicting things. "abort if it would have been a merge commit" is
purely about fast forward. But it sounds like you also care about "would
merge have succeeded". So I think you are asking for:

  1. There are no local commits on the branch.

and one of:

  2a. There are no local edits.

  2b. There are no local edits in the same files as those that are
      affected by any new commits from upstream.

  2c. Any local edits you have done would not cause a conflict if merged
      with what's in upstream.

And before I discuss those further, let me address:

> Please don't tell me "use these three commands in this script".
> I want a *command* I can tell people in #git.

by saying that I don't think there is currently a single command to
cover both (1) and (2) (any of the (2) options). So we need to talk
about "use these three commands in a script" for a moment to figure out
what such a command _should_ do, and then we can talk about putting it
into a single command (and presumably making that command part of the
git distribution) that you can tell people about in #git.

Both (1) and (2) involve finding out who your upstream is. As of 1.6.3,
this is easy to do as:

  upstream=`git for-each-ref --format='%(upstream)' `git symbolic-ref HEAD`

One you have that, (1) is easy:

  test -z "`git rev-list -1 $upstream..HEAD`"

(2a) is also pretty easy:

  git diff-files --quiet && git diff-index --quiet

(2b) is a bit harder, but do-able:

  git diff-tree --name-only HEAD $upstream | sort >them
  (git diff-files --name-only; git diff-index --name-only) | sort >us
  test -z "`comm -12 us them`"

(2c) is the trickiest (and of course, therefore probably the one you
want ;) ).  I'm not sure there is a simple way to do it short of hacking
git-merge to actually try the merge and roll it back. Because you really
have to deal not just with merging actual text file content but with
custom merge drivers.

So what is it that you're looking for?

-Peff

PS I took your request at face value, but I actually think this question
shows that the asker is not using git as it was intended. Unless you are
very clueful (i.e., willing to sort out any mess caused by a failed
merge), you should almost certainly be merging with a clean working
tree. In other words, you should not be afraid of making a commit, and
_then_ merging, as you might be in a non-distributed VCS.

Re: I want "fast forward my workdir to upstream if it's safe"

[Andreas Ericsson]

Jeff King wrote:
> On Thu, May 07, 2009 at 02:40:00PM -0700, Randal L. Schwartz wrote:
> 
>> So, what I need is a command, likely an option to "git merge" that says "do
>> everything that a git merge would do except abort if it would have been a
>> merge commit".  In other words, abort if the workdir is dirty or is not a
>> fast-forward update to the upstream.  Bonus if it exits non-zero if
>> something went wrong.
> 
> Can you define more clearly what you want, because you are asking for
> conflicting things. "abort if it would have been a merge commit" is
> purely about fast forward. But it sounds like you also care about "would
> merge have succeeded". So I think you are asking for:
> 
>   1. There are no local commits on the branch.
> 
> and one of:
> 
>   2a. There are no local edits.
> 
>   2b. There are no local edits in the same files as those that are
>       affected by any new commits from upstream.
> 
>   2c. Any local edits you have done would not cause a conflict if merged
>       with what's in upstream.
> 
> And before I discuss those further, let me address:
> 
>> Please don't tell me "use these three commands in this script".
>> I want a *command* I can tell people in #git.
> 
> by saying that I don't think there is currently a single command to
> cover both (1) and (2) (any of the (2) options). So we need to talk
> about "use these three commands in a script" for a moment to figure out
> what such a command _should_ do, and then we can talk about putting it
> into a single command (and presumably making that command part of the
> git distribution) that you can tell people about in #git.
> 
> Both (1) and (2) involve finding out who your upstream is. As of 1.6.3,
> this is easy to do as:
> 
>   upstream=`git for-each-ref --format='%(upstream)' `git symbolic-ref HEAD`
> 
> One you have that, (1) is easy:
> 
>   test -z "`git rev-list -1 $upstream..HEAD`"
> 
> (2a) is also pretty easy:
> 
>   git diff-files --quiet && git diff-index --quiet
> 
> (2b) is a bit harder, but do-able:
> 
>   git diff-tree --name-only HEAD $upstream | sort >them
>   (git diff-files --name-only; git diff-index --name-only) | sort >us
>   test -z "`comm -12 us them`"
> 
> (2c) is the trickiest (and of course, therefore probably the one you
> want ;) ).  I'm not sure there is a simple way to do it short of hacking
> git-merge to actually try the merge and roll it back. Because you really
> have to deal not just with merging actual text file content but with
> custom merge drivers.
> 

The "rolling back" part is about as simple as
* never touch the worktree (only use in-index merge)
* preserve the last HEAD commit object name
* preserve the index

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: I want "fast forward my workdir to upstream if it's safe"

[Jeff King]

On Fri, May 08, 2009 at 08:53:22AM +0200, Andreas Ericsson wrote:

>> (2b) is a bit harder, but do-able:
>>
>>   git diff-tree --name-only HEAD $upstream | sort >them
>>   (git diff-files --name-only; git diff-index --name-only) | sort >us
>>   test -z "`comm -12 us them`"
>>
>> (2c) is the trickiest (and of course, therefore probably the one you
>> want ;) ).  I'm not sure there is a simple way to do it short of hacking
>> git-merge to actually try the merge and roll it back. Because you really
>> have to deal not just with merging actual text file content but with
>> custom merge drivers.
>>
>
> The "rolling back" part is about as simple as
> * never touch the worktree (only use in-index merge)
> * preserve the last HEAD commit object name
> * preserve the index

If you are just doing in-index merge, then (2b) works fine. You know you
aren't doing any file-level merging. The advantage of (2c) is that
non-conflicting merges in files would are "safe".

-Peff

Re: I want "fast forward my workdir to upstream if it's safe"

[Eyvind Bernhardsen]

On 8. mai. 2009, at 04.30, Jeff King wrote:

> On Thu, May 07, 2009 at 02:40:00PM -0700, Randal L. Schwartz wrote:
>
>> So, what I need is a command, likely an option to "git merge" that  
>> says "do
>> everything that a git merge would do except abort if it would have  
>> been a
>> merge commit".  In other words, abort if the workdir is dirty or is  
>> not a
>> fast-forward update to the upstream.  Bonus if it exits non-zero if
>> something went wrong.
>
> Can you define more clearly what you want, because you are asking for
> conflicting things. "abort if it would have been a merge commit" is
> purely about fast forward. But it sounds like you also care about  
> "would
> merge have succeeded". So I think you are asking for:
>
>  1. There are no local commits on the branch.
>
> and one of:
>
>  2a. There are no local edits.
>
>  2b. There are no local edits in the same files as those that are
>      affected by any new commits from upstream.
>
>  2c. Any local edits you have done would not cause a conflict if  
> merged
>      with what's in upstream.

I read it as a request for pull/merge --ff-only (based on "abort if  
the workdir is dirty or is not a fast-forward update").  This feature  
has been implemented twice, but never included:

http://article.gmane.org/gmane.comp.version-control.git/76787
http://article.gmane.org/gmane.comp.version-control.git/107768
http://article.gmane.org/gmane.comp.version-control.git/80284
-- 
Eyvind Bernhardsen

Re: I want "fast forward my workdir to upstream if it's safe"

[Randal L. Schwartz]

>>>>> "Eyvind" == Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:

Eyvind> http://article.gmane.org/gmane.comp.version-control.git/76787
Eyvind> http://article.gmane.org/gmane.comp.version-control.git/107768
Eyvind> http://article.gmane.org/gmane.comp.version-control.git/80284

Yes. Precisely.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: I want "fast forward my workdir to upstream if it's safe"

[Junio C Hamano]

Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:

> I read it as a request for pull/merge --ff-only (based on "abort if
> the workdir is dirty or is not a fast-forward update").  This feature
> has been implemented twice, but never included:

Interesting.  Do you mean twice they were both found lacking, substandard,
useless, uninteresting, buggy, incorrect, or all of the above?  Or was it
just somebody simply forgot to apply a perfect patchset twice?

Re: I want "fast forward my workdir to upstream if it's safe"

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:
> Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:
> 
> > I read it as a request for pull/merge --ff-only (based on "abort if
> > the workdir is dirty or is not a fast-forward update").  This feature
> > has been implemented twice, but never included:
> 
> Interesting.  Do you mean twice they were both found lacking, substandard,
> useless, uninteresting, buggy, incorrect, or all of the above?  Or was it
> just somebody simply forgot to apply a perfect patchset twice?

I think (if I remember correctly) that they were once to be split into
just --ff-only and --ff=<strategy>, and once there were almost ready,
and either feature freeze happened, or the author didn't have time to
resend corrected patches, or both.

I cc-ed authors of both versions (longer by Sverre, only --ff-only by
Yuval)
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: I want "fast forward my workdir to upstream if it's safe"

[Miles Bader]

Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:
> I read it as a request for pull/merge --ff-only (based on "abort if the
> workdir is dirty or is not a fast-forward update").  This feature  has
> been implemented twice, but never included:

I'd also like such a feature.

[It seems like such an obvious partner to "--no-ff" (etc), that it's
kind of surprising it isn't there already -- I think there have been
multiple times in the past where I've spent time grovelling the
pull/merge documentation looking for the right option name to do this,
only to give up in confusion when I couldn't find it...]

-Miles

-- 
Love is the difficult realization that something other than oneself is real.
[Iris Murdoch]

Re: I want "fast forward my workdir to upstream if it's safe"

[Eyvind Bernhardsen]

On 8. mai. 2009, at 17.57, Junio C Hamano wrote:

> Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:
>
>> I read it as a request for pull/merge --ff-only (based on "abort if
>> the workdir is dirty or is not a fast-forward update").  This feature
>> has been implemented twice, but never included:
>
> Interesting.  Do you mean twice they were both found lacking,  
> substandard,
> useless, uninteresting, buggy, incorrect, or all of the above?  Or  
> was it
> just somebody simply forgot to apply a perfect patchset twice?

Sorry, I should have summarised.

I guess Yuval explained what happened to his patch himself.  Sverre's  
was dropped after a fair amount of discussion and several rounds, but  
his series added multiple fast-forward strategies, not just "ff-only".

The last reference I can find to it in the archives is Dscho asking  
for the feature to be held off pending the builtinification of git- 
merge (http://article.gmane.org/gmane.comp.version-control.git/ 
82623).  Sverre probably lost interest in following up after that.

It looks like there's some interest behind the "--ff=only" feature  
now, at least.  I remembered the thread because of it; I wanted to  
replace a "git reset --hard" in my workflow with something slightly  
safer, and --ff=only would have fit.
-- 
Eyvind Bernhardsen