All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Jeff King <peff@peff.net>
Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>, git@vger.kernel.org
Subject: Re: I want "fast forward my workdir to upstream if it's safe"
Date: Fri, 08 May 2009 08:53:22 +0200	[thread overview]
Message-ID: <4A03D6E2.2050708@op5.se> (raw)
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.

  reply	other threads:[~2009-05-08  6:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-07 21:40 I want "fast forward my workdir to upstream if it's safe" Randal L. Schwartz
2009-05-07 23:18 ` Wincent Colaiuta
2009-05-07 23:20   ` Randal L. Schwartz
2009-05-08  2:30 ` Jeff King
2009-05-08  6:53   ` Andreas Ericsson [this message]
2009-05-08  7:01     ` Jeff King
2009-05-08 12:34   ` Eyvind Bernhardsen
2009-05-08 14:02     ` Randal L. Schwartz
2009-05-08 15:57     ` Junio C Hamano
2009-05-08 16:15       ` Jakub Narebski
2009-05-11 20:11       ` Eyvind Bernhardsen
2009-05-08 21:34     ` Miles Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A03D6E2.2050708@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=merlyn@stonehenge.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.