# I want "fast forward my workdir to upstream if it's safe" 12 messages from 2009-05-07 to 2009-05-11. Participants: Randal L. Schwartz, Wincent Colaiuta, Jeff King, Andreas Ericsson, Eyvind Bernhardsen, Junio C Hamano, Jakub Narebski, Miles Bader. Thread: https://gitlist.dev/t/19240 ## Randal L. Schwartz, 2009-05-07 21:40 Subject: I want "fast forward my workdir to upstream if it's safe" Message-ID: <86prekfv7z.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86prekfv7z.fsf%40blue.stonehenge.com ``` 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 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ``` ## Wincent Colaiuta, 2009-05-07 23:18 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: URL: https://gitlist.dev/e/FC9BF880-D69F-4A56-B9FA-EF5BDBF73437%40wincent.com In-Reply-To: <86prekfv7z.fsf@blue.stonehenge.com> ``` 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 ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: foo # # Untracked files: # (use "git add ..." to include in what will be committed) # # bar ``` ## Randal L. Schwartz, 2009-05-07 23:20 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <86ljp8fqkp.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86ljp8fqkp.fsf%40blue.stonehenge.com In-Reply-To: ``` >>>>> "Wincent" == Wincent Colaiuta 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 ..." to update what will be committed) Wincent> # (use "git checkout -- ..." to discard changes in working directory) Wincent> # Wincent> # modified: foo Wincent> # Wincent> # Untracked files: Wincent> # (use "git add ..." 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 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ``` ## Jeff King, 2009-05-08 02:30 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <20090508023028.GA1218@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090508023028.GA1218%40coredump.intra.peff.net In-Reply-To: <86prekfv7z.fsf@blue.stonehenge.com> ``` 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. ``` ## Andreas Ericsson, 2009-05-08 06:53 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <4A03D6E2.2050708@op5.se> URL: https://gitlist.dev/e/4A03D6E2.2050708%40op5.se In-Reply-To: <20090508023028.GA1218@coredump.intra.peff.net> ``` 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. ``` ## Jeff King, 2009-05-08 07:01 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <20090508070119.GA12989@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090508070119.GA12989%40coredump.intra.peff.net In-Reply-To: <4A03D6E2.2050708@op5.se> ``` 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 ``` ## Eyvind Bernhardsen, 2009-05-08 12:34 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: URL: https://gitlist.dev/e/F871F2A1-DFCF-4642-BB53-7BE483A93271%40orakel.ntnu.no In-Reply-To: <20090508023028.GA1218@coredump.intra.peff.net> ``` 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 ``` ## Randal L. Schwartz, 2009-05-08 14:02 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <867i0rg0b6.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/867i0rg0b6.fsf%40blue.stonehenge.com In-Reply-To: ``` >>>>> "Eyvind" == Eyvind Bernhardsen 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 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ``` ## Junio C Hamano, 2009-05-08 15:57 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <7vk54rvb8x.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk54rvb8x.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Eyvind Bernhardsen 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? ``` ## Jakub Narebski, 2009-05-08 16:15 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: URL: https://gitlist.dev/e/m3prejmv2f.fsf%40localhost.localdomain In-Reply-To: <7vk54rvb8x.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > Eyvind Bernhardsen 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=, 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 ``` ## Miles Bader, 2009-05-08 21:34 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: <87iqkbth1c.fsf@catnip.gol.com> URL: https://gitlist.dev/e/87iqkbth1c.fsf%40catnip.gol.com In-Reply-To: ``` Eyvind Bernhardsen 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] ``` ## Eyvind Bernhardsen, 2009-05-11 20:11 Subject: Re: I want "fast forward my workdir to upstream if it's safe" Message-ID: URL: https://gitlist.dev/e/EDAB1A7F-628A-47F6-BAEB-89935E86546A%40orakel.ntnu.no In-Reply-To: <7vk54rvb8x.fsf@alter.siamese.dyndns.org> ``` On 8. mai. 2009, at 17.57, Junio C Hamano wrote: > Eyvind Bernhardsen 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 ```