Re: Clean history

[John Mandereau]

2008/8/18 Reinhold Kainhofer <address@hidden>:
> What I usually do is to either
>
> 1) First pull and then commit (only if I have not yet locally committed any
> changes!)
>
> 2) If I already have local commits, like in this case, I do a
>    "git fetch"
> which will not update the current files, but download the latest history to
> the .git dir. Then I do a
>    "git rebase origin"
> which takes the local commits and tries to append them to the latest master
> from the server.
> There might be some conflicts, though, if the same parts of the same files
> have been modified on the server, too. In this case you'll have to open the
> conflicting file, search for the <<<< indicating the problem spots and
> resolve it manually. Afterwards do a "git add conflicting-file-name" and "git
> rebase --continue". Now you'll locally have the latest master and on top of
> that all your local commits. No additional merge commits are created.

This is sane practice, but 2) is too cumbersome to do when a lot of
your commits conflict with upstream; in this case, it's easier to
merge so you fix conflicts only once in the merge commit. BTW I don't
know how you want to handle dev/texi2html merging, but I prefer
merging over rebasing: fixing conflicts in makefiles is error-prone if
you have to do it for a lot of commits. BTW I'm looking at
dev/texi2html docs building, this will be my only work on Lily until
main issues are fixed there.

I recently took the habit to rebase after pulling in case I don't have
conflicts, but your method is even cleaner, and not more difficult
when pushing a few commits.

Thanks,
John