git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Shupak, Vitaly" <Vitaly.Shupak@deshaw.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Why does "git pull --rebase" require a clean git directory?
Date: Fri, 11 Dec 2020 03:42:22 +0000	[thread overview]
Message-ID: <X9LqnolNcWZvA7Bm@camp.crustytoothpaste.net> (raw)
In-Reply-To: <ea1e654cec62411884e2c260524fb05a@deshaw.com>

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On 2020-12-10 at 22:15:11, Shupak, Vitaly wrote:
> Hi,
> 
> "git pull --rebase" requires having NO uncommitted changes, even if
> the locally modified files haven't been updated upstream, or even if
> there are no changes to upstream at all. I know I could use
> --autostash, but that's inefficient and may be undesirable if it would
> create a conflict.
> 
> Would it be possible to change the behavior of "git pull --rebase" so
> that it only fails if the locally modified files conflict with the
> files modified upstream (similar to the default git pull behavior
> without --rebase)?

I suspect the reason for the difference is in how the two pieces of code
work.  A merge in general can work in a dirty tree whereas a rebase
cannot.  That, in turn, is because the merge code merges two files
internally and then writes them out to the working tree, whereas the
rebase code, at least in some cases, doesn't contain the same
precautions not to modify the working tree.

Moreover, a merge is a single operation, so it's safe to operate on a
commit and then give up.  A rebase consists of multiple operations, so
we'd have to evaluate each operation and synthesize it, internally
performing the merge (or apply) that's a part of it, in order to
determine if it would conflict.  Otherwise, we'd have to just try it and
somehow abort cleanly in the middle without otherwise dirtying the
working tree.  Right now, that abort step involves a reset --hard, which
is going to blow away your data.

So is it possible to do?  Sure.  Is it easy?  Not especially with the
current code.  So certainly it could be done if it were important to
someone, but it will likely be a good bit of work.

Sorry this wasn't the news you were hoping for.  I'd love to have some
easy solution that I could offer to send in a patch for this weekend to
solve this, but unfortunately it's not that easy.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2020-12-11  3:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 22:15 Why does "git pull --rebase" require a clean git directory? Shupak, Vitaly
2020-12-11  3:42 ` brian m. carlson [this message]
2020-12-11 21:23   ` Shupak, Vitaly
2020-12-12 11:29     ` brian m. carlson
2020-12-11 13:46 ` Phillip Susi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X9LqnolNcWZvA7Bm@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=Vitaly.Shupak@deshaw.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).