From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: Christian Halstrick <christian.halstrick@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: why is merging with unstaged changes allowed when rebasing is not?
Date: Sun, 06 Mar 2011 20:38:37 -0600 [thread overview]
Message-ID: <4D74452D.2010104@gmail.com> (raw)
In-Reply-To: <AANLkTi=dnyaPTX0Y43nbAGp46NtscKT3a2idxEhkreMm@mail.gmail.com>
On 3/4/2011 10:32 AM, Christian Halstrick wrote:
> Isn't it inconsistent that I can merge with unstaged changes in my
> work-tree but not rebase? I agree that both should fail if the
> operation would have to touch the file which has unstaged changes. But
> if not - why don't we allow the rebase? (Is it just because we
> technically do a "git reset --hard" during the rebase which fails on
> unstaged changes?). Here is how tried it out:
>
> git init
> touch a b
> git add a b
> git commit -m initial
> echo "a-master">> a
> git commit -a -m "modified a on master"
> git checkout -b side HEAD~1
> touch c
> git add c
> git commit -m "added c on side"
> echo "b-side">> b
> # git rebase master -> would fail complaining about unstaged changes
> # git merge master -> would not fail
>
> Even a 'git checkout master; git cherry-pick side' works well (but
> updates the wrong branch)
>
> Ciao
> Chris
food for thought:
git-merge manpage: "Warning: Running git merge with uncommitted changes
is discouraged: while possible, it leaves you in a state that is hard to
back out of in the case of a conflict."
I would imagine that if its a bad idea for git-merge, its a really bad
idea for git-rebase...
v/r,
neal
prev parent reply other threads:[~2011-03-07 2:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 16:32 why is merging with unstaged changes allowed when rebasing is not? Christian Halstrick
2011-03-04 17:53 ` Junio C Hamano
2011-03-07 2:38 ` Neal Kreitzinger [this message]
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=4D74452D.2010104@gmail.com \
--to=nkreitzinger@gmail.com \
--cc=christian.halstrick@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.