Re: git merge --abort

Jakub Narebski [off-list ref] writes:

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?).

Isn't that Nana's "git stash --keep" patch posted a few weeks ago sitting
in "pu"?

On Sat, 21 Feb 2009, Junio C Hamano wrote:

Jakub Narebski [off-list ref] writes:

quoted

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?).

Isn't that Nana's "git stash --keep" patch posted a few weeks ago sitting
in "pu"?

Almost exactly.

When using it as a safety measure (perhaps enabled via configuration
variable, similarly to core.safecrlf or diff.autoRefreshIndex) we would
probably want to not save it in 'refs/stash' stack, but in single-use
ORIG_STATE (similar to HEAD reflog vs. ORIG_HEAD). And of course have
"git merge --abort" (or even "git pull --abort") as a porcelain.

-- 
Jakub Narebski
Poland

2009/2/21 Jakub Narebski [off-list ref]:

On Sat, 21 Feb 2009, Junio C Hamano wrote:

quoted

Jakub Narebski [off-list ref] writes:

quoted

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?).

Isn't that Nana's "git stash --keep" patch posted a few weeks ago sitting
in "pu"?

Almost exactly.

When using it as a safety measure (perhaps enabled via configuration
variable, similarly to core.safecrlf or diff.autoRefreshIndex) we would
probably want to not save it in 'refs/stash' stack, but in single-use
ORIG_STATE (similar to HEAD reflog vs. ORIG_HEAD). And of course have
"git merge --abort" (or even "git pull --abort") as a porcelain.

It sounds like we have some sort of plan then.  Will Nana's patch be
committed into mainline git?  Then we can add the --abort porcelain

John Tapsell [off-list ref] writes:

It sounds like we have some sort of plan then.  Will Nana's patch be
committed into mainline git?  Then we can add the --abort porcelain

I do not know what plan you are talking about, but that's not how the
development works.  If something is merged to 'pu', and you have a cool
feature you would want to take advantage of it, you can build your cool
feature on top of that particular topic.  If the result looks reasonable
they would cook for a while in 'next' for further polishing and then
finally go to 'mainline'.

I personally did not think "--keep" would need to be be part of a
reasonable "merge --abort" implementation, but I may have missed some
description of a viable design discussed on the list.

Junio C Hamano wrote:

John Tapsell [off-list ref] writes:

quoted

It sounds like we have some sort of plan then.  Will Nana's patch be
committed into mainline git?  Then we can add the --abort porcelain

I do not know what plan you are talking about, but that's not how the
development works.  If something is merged to 'pu', and you have a cool
feature you would want to take advantage of it, you can build your cool
feature on top of that particular topic.  If the result looks reasonable
they would cook for a while in 'next' for further polishing and then
finally go to 'mainline'.

I personally did not think "--keep" would need to be be part of a
reasonable "merge --abort" implementation, but I may have missed some
description of a viable design discussed on the list.

My idea was that merge would do the following:

  $ <save stash into MERGE_STASH or similar, no reset>
  $ <do a merge>

Then we have two possibilities:

  # merge failed with conflicts
  $ git merge --abort (would unstash MERGE_STASH and delete it)

  # we created merge conflict
  $ <MERGE_STASH is removed together with MERGE_HEAD>

-- 
Jakub Narebski
Poland