Re: why is merging with unstaged changes allowed when rebasing is not?
- From
- Neal Kreitzinger <nkreitzinger@gmail.com>
- Date
- Mar 7, 2011, 02:38 UTC
- Message-ID
- <4D74452D.2010104@gmail.com>
- In-Reply-To
- <AANLkTi=dnyaPTX0Y43nbAGp46NtscKT3a2idxEhkreMm@mail.gmail.com>
On 3/4/2011 10:32 AM, Christian Halstrick wrote:
Show 26 quoted lines
> 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