The process I've been using to keep my patches current with the latest
development is this:
git checkout linus && git pull linus
git checkout work
When I'm ready to merge,
git resolve work linus "Update with head"
git tag basis
This lets me diff against basis even when the linus branch continues
to follow the latest developments.
Today, I wanted to move everything forward. But the resolve failed to
merge some files. In fact, one file was apparently so thorny that
resolve just gave up and left no working file. Bothersome, but I
recovered by moving back to the previous work point.
Then, I found git-rebase which seems to be more what I'd like to use
since it moves my patches along on top of the main development line.
git rebase linus
This time, almost everything merged without a hitch except for the
thorny file from before. I edited the file, removing the conflict
markers, and started a build. But what I found was that some of the
changes I'd made were no longer present. Several files showed no sign
of the patches even though the kernel versions hadn't changed.
So, I have a couple of questions:
1) Am I using rebase correctly?
2) If not, did it leave some of my changes uncommitted and hidden
somewhere? git-ls-files --unmerged shows no sign of them.
3) Do I have to pull all of my patches off, apply them to the head
of the tree, and only use git-rebase to make this work?
4) Should I prefer rebase over resolve?
On Fri, 24 Mar 2006, Marc Singer wrote:
The process I've been using to keep my patches current with the latest
development is this:
git checkout linus && git pull linus
git checkout work
You'd be much more efficient if you just did
git fetch linus
which avoids switching back-and-forth (and speeds up the pull too, since
it doesn't need to update any working directories).
When I'm ready to merge,
git resolve work linus "Update with head"
No, don't do this.
"git resolve" is the _old_ stupid merger, which isn't very helpful at all.
So please use
git merge "Merge with Linus" work linus
instead, which will use the proper "recursive" merge functionality.
Then, I found git-rebase which seems to be more what I'd like to use
since it moves my patches along on top of the main development line.
git rebase linus
This time, almost everything merged without a hitch except for the
thorny file from before. I edited the file, removing the conflict
markers, and started a build. But what I found was that some of the
changes I'd made were no longer present.
Yeah, "git rebase" is not _nearly_ as intuitive as doing a real merge.
What happened was that you resolved the thorny merge, but the rebase had
stopped when it hit it, so it never actually did the rest of the rebase.
Which explains why some of your changes are no longer present: they are
still in the "rebase queue".
1) Am I using rebase correctly?
Yes, but you missed the fact that unlike "git merge", rebasing really is a
"move one commit at a time" thing, and it stopped on the middle.
4) Should I prefer rebase over resolve?
You should never do "resolve", it's very oldfashioned. If you want to
merge, just use "git merge", which will do the right thing.
As to rebase, it often is very nice, but on the other hand, it leaves
things in a total mess when it fails, which is a pity. Maybe there's a
nice way to just continue, but I end up just doing a
git reset --hard ORIG_HEAD
to undo the failed rebase.
Junio, is there some magic to restart a rebase after you've fixed up the
conflicts?
Linus