From: Jakub Narebski <jnareb@gmail.com>
To: Bryan Donlan <bdonlan@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
John Tapsell <johnflux@gmail.com>,
Jay Soffian <jaysoffian@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: git merge --abort
Date: Sat, 21 Feb 2009 00:34:58 -0800 (PST) [thread overview]
Message-ID: <m3ocwwrxtg.fsf@localhost.localdomain> (raw)
In-Reply-To: <3e8340490902202328r7caca98q973c17dc163e2028@mail.gmail.com>
Bryan Donlan <bdonlan@gmail.com> writes:
> On Fri, Feb 20, 2009 at 12:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
>
> Perhaps a better approach would be to stash the pre-merge state in the
> reflog, then? That is, manufacture a pre-merge commit containing all
> files changed in the working copy, and add it to the reflog prior to
> performing a merge. git merge --abort can then simply check whether
> the top reflog entry is a pre-merge state, and if so, reset --hard to
> it, then reset the index to the parent of our pre-merge commit.
>
> This would also nicely handle the case where the user tries some
> random things before deciding to abort the merge.
Perhaps this is the case fo "feature that waits for a user", namely
'git stash --no-reset', which would save a state just in case, perhaps
in a separate area and not refs/stash (ORIG_STASH perhaps?).
What do you think about this idea?
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2009-02-21 8:36 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
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 [this message]
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=m3ocwwrxtg.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=bdonlan@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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 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.