On Tue, Apr 16, 2013 at 5:20 AM, Ramkumar Ramachandra
<artag...@gmail.com> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to