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
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