On Tue, Apr 16, 2013 at 5:20 AM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> wrote:
> Matthieu Moy wrote:
> No. Ultimately, the entry point of all these invocations is
> git-rebase.sh. The plan is to refactor calls from git-rebase.sh to
> git-rebase--*.sh scripts so that those scripts return control to
> git-rebase.sh, which will be the final exit point. The logic is very
> simple: On the very first invocation of rebase (ie. no existing rebase
> in progress), stash. If the return statement from the specific rebase
> script is 1 (which means that there are conflicts to be resolved),
> exit as usual. If it is 0 (which means that the rebase completely
> successfully), pop the stash before exiting as usual.
>
> What's so complicated about that? I'm against leaking the autostash
> implementation detail into specific rebases, because I value a clean
> and pleasant implementation over everything else.
It can be more complex than you realize.
$ git pull --rebase --stash
It seems that there is already a .git/rebase-apply directory, and
I wonder if you are in the middle of another rebase. If that is the
case, please try
git rebase (--continue | --abort | --skip)
If that is not the case, please
rm -fr .git/rebase-apply
and run me again. I am stopping in case you still have something
valuable there.
If I follow the latter advice about 'rm -rf', who will remember that
'rebase' had something stashed, and what will they do with it when
they do?
What if it is weeks or months later? I would be surprised to see
long-forgotten wip show up in my workspace all of a sudden.
Phil
--
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