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
Applyin...
[ message continues ]

Well... This one kind of hard: git-rebase _cannot_ know whether it is

safe to just drop all changes in the index and work tree (you could

have made the changes on purpose). It was decided not to drop

anything. You always can do
    $ git reset --hard # kills all changes in index and work tree

    $ git rebase --skip
Yes. It was the last commit. You were just too unlucky to hit all the

hard cases your first day.
-

It wasn't a no-op patch. It had conflicts which you resolved to the
There seems to be some bug in rebase that makes it fail in this case.

Someone on #git also reported that --abort failed to reset his branch to

the old head in a similar case, but I didn't manage to reproduce that

yet (well, I didn't try that hard), so I don't know if it's really a bug

or a misuse by that guy.
Björn

-

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,
Isn't that obvious?  To prevent you from accidentally losing a commit.
Ciao,

Dscho
-

The commit would not change anything, so what is there to lose?
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

In case it is not obvious...
A rebase conflict resolution that results in emptiness is a

rather rare event (especially because rebase drops upfront the

identical changes from the set of commits to be replayed), but

it does happen.  One could argue that "rebase --continue" can

notice that the resolved index is identical to the tree of the

HEAD commit and skip it automatically.
Given an index that is identical to HEAD, however, it is not

easy to safely determine if that is because the patch did not

apply at all, or the patch was applied with conflicts _and_ the

user decided to make the patch a no-op by resolving.  The

automatic droppage of the commit needs to happen only on the

latter and never on the former.
-

Funny how 2 of my first 3 commits suffer from this "rather rare event",

and it was not Friday, 13 ;)
--

Sergei.

-

Hi,
They are rare events.  In your case I guess that subtly different versions

were _actually_ applied (such as white space fixes), which is why such a

rare event hit you.
Ciao,

Dscho
-

I'm using git to track some changes I submitted to a project that's

mainly text, and that I only get release tarballs of.  On my most recent

rebase all my patches got applied, but the text also got re-wrapped and

re-indented at the same time.  So all but I think one or two of a dozen

patches ended up with a conflict resolution and then --skip.
Which may not be a case git's really intended for--fair enough.  But

I've found it's pretty common in my kernel work too.  Either I'm

rebasing against changes I made myself, or else a maintainer took my

changes but fixed up some minor style problems along the way.
--b.

-

Probably some additional clue could be displayed for the user benefit.

This might solve the issue nicely.
Nicolas

-

Wouldn't there be a conflict in the index?  A conflict which can only be

resolved by adding?  Which then results in a question whether you forgot

to add?
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

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.

-

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

-

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.

-

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*

-