Re: Newbie: report of first experience with git-rebase.

Björn Steinbrink [off-list ref] writes:

On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:

quoted

Hello,

I've made my first attempt at tracking my changes to upstream git
repository using git-fetch/git-rebase workflow. I did three commits to
my master branch, and then upstream incorporated two of them in slightly
modified form, so that some conflicts are to be expected. I did
git-fetch followed by git-rebase, and finally have got the end result I
hoped for, but there were some confusion along the way. I think I'd post
the log of the session here along with my thoughts so that an interested
person could see how it works for a newbie (my thoughts and non-git
actions at the time of rebasing are marked with 'me>' prefix):

$ git fetch
[...]
$ git rebase origin
First, rewinding head to replay your work on top of it...
HEAD is now at 9c51414... Merge branch 'maint' into HEAD

Applying Fix a typo.

Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d
Committed: 983e907b1360c17c7ac925d6035d82cc7243f406

Applying Use new syntax (-m option) for git-merge.

error: patch failed: Documentation/core-tutorial.txt:878
error: Documentation/core-tutorial.txt: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged Documentation/core-tutorial.txt
CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt
Failed to merge in the changes.
Patch failed at 0002.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> Nice, this conflict is expected.
me> Editing Documentation/core-tutorial.txt to resolve the
me> conflict... Conflict is resolved so that the working file matches
me> upstream version.

$ git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

me> Nice helpful message, -- need to do git-add

$ git add Documentation/core-tutorial.txt
$ git rebase --continue

Applying Use new syntax (-m option) for git-merge.

No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> What?! I just did the git-add! Moreover, before I did git-add, the
me> error was different and helpful. Something went wrong? 
me> Well, it's unlikely, but maybe I made a mistake of not specifying
me> the 'origin'?

$ git rebase --continue origin

Applying Use new syntax (-m option) for git-merge.

No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I
me> need to skip it? Let's try the --skip:

$ git rebase --skip

Applying Fix SYNOPSIS.

error: patch failed: Documentation/git-merge.txt:10
error: Documentation/git-merge.txt: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged Documentation/git-merge.txt
CONFLICT (content): Merge conflict in Documentation/git-merge.txt
Failed to merge in the changes.
Patch failed at 0003.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> Aha, that's it! But why git didn't just skip the no-op patch

It wasn't a no-op patch. It had conflicts which you resolved to the
upstream version and _then_ you had a no-op.

Yes, and that's the problem. Why 'git --continue' didn't just skip this
patch that *already became no-op* after conflict resolution and forced
me to explicitly use 'git --skip' instead?

This forces one to use 'git --skip' if the patch happens to become a
no-op after conflict resolution, and 'git --continue' otherwise. Why
this complication?

-- 
Sergei.

Hi,

On Wed, 31 Oct 2007, Sergei Organov wrote:

Yes, and that's the problem. Why 'git --continue' didn't just skip this 
patch that *already became no-op* after conflict resolution and forced 
me to explicitly use 'git --skip' instead?

Isn't that obvious?  To prevent you from accidentally losing a commit.

Ciao,
Dscho

On Wed, Oct 31, 2007 at 09:12:06PM +0000, Johannes Schindelin wrote:

Hi,

On Wed, 31 Oct 2007, Sergei Organov wrote:

quoted

Yes, and that's the problem. Why 'git --continue' didn't just skip this 
patch that *already became no-op* after conflict resolution and forced 
me to explicitly use 'git --skip' instead?

Isn't that obvious?  To prevent you from accidentally losing a commit.

That would make sense to me if this was a mistake that could easily
happen.

I'd assumed that in the case of a conflict that stopped the rebase
process, the index and working tree are always left dirty, so that if
they both agree with the HEAD at the time of commit, then it's because
the user explicitly made them that way.

I ran into the same confusion as the original poster when starting to
use rebase, so I suspect it's common.

--b.

J. Bruce Fields wrote:

I ran into the same confusion as the original poster when starting to
use rebase, so I suspect it's common.
  

I've been using rebase just about every day for close to a year and it 
*still* annoys me when it happens. Especially the "Did you forget to git 
add?" part of the message. The thought that always goes through my head 
is, "No, Mr. Rebase, I did NOT forget to git add. I remembered to git 
add, then you were too stupid to do the right thing after that."

Just happened to me this morning, in fact: I had a quick hack in place 
to work around a bug, the bug got fixed for real, and I rebased. In the 
process of conflict resolution I saw that my workaround wasn't needed 
any more and accepted the upstream version of that particular part of 
the file. Ran git-add on it, then rebase --continue, and boom, was 
accused of forgetting to run git-add.

It is a minor annoyance and nowadays I just sigh a bit and run --skip 
instead, but it'd be nice if it didn't happen. I don't like having to 
care whether or not I happened to change other files in a particular 
commit after I resolve conflicts in one file in favor of the upstream 
version.

-Steve

On Wed, 31 Oct 2007, Steven Grimm wrote:

J. Bruce Fields wrote:

quoted

I ran into the same confusion as the original poster when starting to
use rebase, so I suspect it's common.
  

I've been using rebase just about every day for close to a year and it *still*
annoys me when it happens. Especially the "Did you forget to git add?" part of
the message. The thought that always goes through my head is, "No, Mr. Rebase,
I did NOT forget to git add. I remembered to git add, then you were too stupid
to do the right thing after that."

Just happened to me this morning, in fact: I had a quick hack in place to work
around a bug, the bug got fixed for real, and I rebased. In the process of
conflict resolution I saw that my workaround wasn't needed any more and
accepted the upstream version of that particular part of the file. Ran git-add
on it, then rebase --continue, and boom, was accused of forgetting to run
git-add.

It is a minor annoyance and nowadays I just sigh a bit and run --skip instead,
but it'd be nice if it didn't happen. I don't like having to care whether or
not I happened to change other files in a particular commit after I resolve
conflicts in one file in favor of the upstream version.

I think it's worth requiring you to say --skip in order to acknowledge 
that you won't have as many commits and you'll lose the commit message. On 
the other hand, the message should probably suggest that you might want to 
skip this commit instead of suggesting that you come up with some other 
change to include in it.

Certainly, if "git diff" returns no changes, "git add" is a bad 
suggestion, and it would be nicer to suggest something possibly correct.

	-Daniel
*This .sig left intentionally blank*

On Wed, Oct 31, 2007 at 03:06:20PM -0700, Steven Grimm wrote:

I've been using rebase just about every day for close to a year and it 
*still* annoys me when it happens. Especially the "Did you forget to git 
add?" part of the message. The thought that always goes through my head is, 
"No, Mr. Rebase, I did NOT forget to git add. I remembered to git add, then 
you were too stupid to do the right thing after that."

Just happened to me this morning, in fact: I had a quick hack in place to 
work around a bug, the bug got fixed for real, and I rebased. In the 
process of conflict resolution I saw that my workaround wasn't needed any 
more and accepted the upstream version of that particular part of the file. 
Ran git-add on it, then rebase --continue, and boom, was accused of 
forgetting to run git-add.

It is a minor annoyance and nowadays I just sigh a bit and run --skip 
instead, but it'd be nice if it didn't happen. I don't like having to care 
whether or not I happened to change other files in a particular commit 
after I resolve conflicts in one file in favor of the upstream version.

Yeah, I think a message saying "patch is now empty, skipping..." would
be sufficient to let the user know what's going on.  This doesn't seem
so perilous to me that it's worth requiring a positive acknowledgement.

--b.