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

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.

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

"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

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.

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

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:

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.

Jeff King wrote:

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

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

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

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

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

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

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?

Junio C Hamano <gitster@pobox.com> writes:

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)

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

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 <eyvind-git@orakel.ntnu.no> writes:

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