Pieter Praet wrote:
> On Sat, 3 Aug 2013 02:10:27 +0530, Ramkumar Ramachandra <[email protected]>
> wrote:
>> [...] Note that --abort can have unpleasant
>> consequences when merge is run on a dirty worktree.
>
> Which is why `magit-merge-abort' is bound to a capital "A" instead
> of lowercase *and* we're prompted "Abort merge?" before our work
> receives a one-way ticket to digital oblivion. :)
>
> Unless I misinterpreted that?
Yeah, see git-merge(1):
--abort::
Abort the current conflict resolution process, and
try to reconstruct the pre-merge state.
+
If there were uncommitted worktree changes present when the merge
started, 'git merge --abort' will in some cases be unable to
reconstruct these changes. It is therefore recommended to always
commit or stash your changes before running 'git merge'.
+
'git merge --abort' is equivalent to 'git reset --merge' when
`MERGE_HEAD` is present.
(This text was improved recently)
Note the "in some cases" (sketchy because it's not easy to explain
which cases without code). In most cases, it will reconstruct the
pre-merge state just fine.
>> On a related note, you might also want to support pull/ rebase on a
>> dirty worktree leveraging rebase.autostash (new feature).
>
> Interesting time-saver indeed!
>
> I tend to avoid release candidates of essential software though,
> so I'll look into it when I git me some fresh (stable) git.
git.git master is very stable: many of us use it for day-to-day development.
> I'm due for an update anyway (this patch series was sent using a
> fairly dated v1.7.11.1).
As is apparent from your format-patch footer. I personally try to run
the newest versions of everything (kernel lags by ~2 months though),
so I can get involved with development.
--
---
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
