"Paul A. Kennedy" <pakenned@xxxxxxxxx> writes:
>> "rebase --abort" is typically used to get rid of conflicted mess the
>> user does not want to resolve right now, and "stash" would not be a
>> sensible thing to use in such a situation, I think. Doesn't it even
>> refuse to work if there is a conflicted entry in the index?
>
> Thanks for thinking about this with me.
>
> After contemplating your messages, I think that it's unreasonable to
> expect git rebase --abort to be able to properly handle content from
> completely outside the repo and only placed in the index.
The essense of "--abort" is to bring your index and the working tree
state back to the state you had before you got into a conflicted
mess.
For paths that still have higher/conflicted stages in the index, it
is easy to decide what should happen. Because we do not even allow
rebase to start with an index with conflicted paths, they must have
come from the rebase operation itself, so matching them to what is
in the HEAD (and removing such conflicted paths that are not in the
HEAD) is always the right thing.
But for paths in the index that are already resolved at stage #0,
it is not simple. They can come from
(1) a clean automatic resolution (including the case where the
rebase did not even touch the path).
(2) a conflict that was resolved manually and then "git add"ed.
(3) manual "git add" of a path that a mechanical part of the rebase
operation did not touch at all.
For (1) and (2), it is the right thing to match with HEAD and
to remove the path if it is not in HEAD (e.g. the path may have
appeared by attempting to replay a change to add it).
For (3), a change may update existing files in HEAD or it may add a
new path not in HEAD. Ideally, the former should be reverted to
HEAD, and the latter should be only reverted in the index but leave
the file in the working tree untracked.
But there is no good way to tell these three classes apart,
unfortunately. With recent Git, I think you can tell paths in
category (2) by noticing that they have "REUC" entries for them in
the index extension section.
The only case we may want to behave differently is "git add" that
adds a path that does not exist (at any stage) to the index, so
theoretically, we could teach the end-user facing "git add" to leave
a new extension entry to the index, teach "git reset --no-so-hard"
to notice the index extension to leave the path in the working tree
when reverting to a HEAD that does not have such a path and use it
in "rebase --abort" codepath. Which would also allow us to be less
aggressive in a case like this:
... have many untracked and unignored paths
$ git add .
... oops, I did not mean it
$ git reset --hard
... double-oops, these untracked paths are all gone
But that is "theoretical" primarily because it is unclear what the
exhaustive set of situations where we must clear such a "this is
newly added" mark to avoid false positives. After "git commit" that
records such a path in a commit is obviously one of them, but that
is not the only one, and every place we forget to clear the mark
will be a cause of confusion.
Alternatively, perhaps we could create the "REUC" extension for
category (1) paths as well. Then "git reset --not-so-hard $commit"
could be changed to behave the same way as it does today, except
that it would not remove paths without "REUC" extension entry from
the working tree.
> + Untracked files added to the index will not be unstaged, and
> + therefore, not present in the working directory upon abort.
> + Unstage files before the abort, or stash untracked content before
> + starting the rebase (see linkgit:git-stash[1]).
"Unstage files" is a less than ideal suggestion.
$ git rebase
... oops conflicted
... ouch, this is too much for me to resolve
$ git reset
$ git rebase --abort
would leave a path that was introduced by the change being replayed
in the working tree, which may later interfere when you try to
checkout a branch that does have that path. At least it has to be
"Unstage such files that were untracked and added by you" to be
helpful, I think.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html