git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: John Tapsell <johnflux@gmail.com>
Cc: Jay Soffian <jaysoffian@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: git merge --abort
Date: Thu, 19 Feb 2009 21:24:49 -0800	[thread overview]
Message-ID: <7v7i3lk7dp.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <43d8ce650902192047g383a5cc1re6697e8009ad72fc@mail.gmail.com> (John Tapsell's message of "Fri, 20 Feb 2009 04:47:39 +0000")

John Tapsell <johnflux@gmail.com> writes:

> 2009/2/19 Jay Soffian <jaysoffian@gmail.com>:
>> On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell <johnflux@gmail.com> wrote:
>>> There's no reliable way of getting back to the state before the merge?
>>
>> Sure there is. Commit or stash before you merge, so that your index
>> and working copy are clean.
>
> Could a stash be done automatically by the merge command, for just a case?

It cuts both ways.  For people who work on a well organized project
(i.e. highly modularized) and tend to keep local changes in the work tree
while doing a lot of merges, running "stash" every time would (1) remove
the local change from the work tree, which he has to remember to manually
unstash after resolving conflicts in the merge (which would not have
conflicted with the local change anyway), which is an additional work for
no real gain, and (2) clutter his stash.  My gut feeling is that it is a
change that affects the way the end user has to work that is sufficiently
different and disruptive for no real gain.

If you read the original message more carefully, you will notice that the
suggested "git merge --abort" would break down *only* if the user messes
with the state conflicted merge left.  And an unmanageable conflicts are
much rare compared to most merges that autoresolve, so you should optimze
for the common case while giving a way to gain safety only when needed.

Probably a much better workflow, if we add "merge --abort", would be:

    $ edit ;# unrelated local changes are still here
    $ git pull ;# or merge or whatever
    ... oops, large conflict ...
    ... look and see if it can easily be resolved ...
    ... otherwise
    $ git merge --abort
    $ git stash
    $ git pull ;# or whatever, try again
    ... the same conflict but this time you only need to worry
    ... about the merge itself
    ... resolve, review, test to convince yourself that your
    ... resolution is good and then...
    $ git commit
    $ git stash pop

  reply	other threads:[~2009-02-20  5:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19 10:05 git merge --abort John Tapsell
2009-02-19 10:58 ` Junio C Hamano
2009-02-19 13:34   ` John Tapsell
2009-02-19 20:26     ` Jay Soffian
2009-02-20  4:47       ` John Tapsell
2009-02-20  5:24         ` Junio C Hamano [this message]
2009-02-20  8:13           ` John Tapsell
2009-02-20  8:33             ` Junio C Hamano
2009-02-20  8:42               ` John Tapsell
2009-02-21  7:28           ` Bryan Donlan
2009-02-21  8:34             ` Jakub Narebski
2009-02-21  9:18               ` Junio C Hamano
2009-02-21 10:18                 ` Jakub Narebski
2009-02-23 12:41                   ` John Tapsell
2009-02-24  1:36                     ` Junio C Hamano
2009-02-24  1:53                       ` Jakub Narebski
2009-02-24  2:01                         ` Junio C Hamano
2009-02-24  9:51                           ` Jakub Narebski

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=7v7i3lk7dp.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    --cc=johnflux@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).