Re: dealing with local patches - mercurial queues over bzr/git checkout

[Achim Gratz]

Eli Zaretskii writes:
> But then you lose history of each patch, I presume: each patch appears
> as a single flat changeset with no history.  When I work on a
> non-trivial feature in a local branch, I make lots of small commits,
> each one implementing a small sub-feature or a part thereof, usually
> after testing the part that was added.  This history is useful later,
> when the whole series is merged to mainline, because if there's a
> regression, bisecting a series of small commits is easier than a
> single large commit.

I find that in Git simply rebasing the local branch on top of upstream
(which can be configured to be done instead of a merge when you "pull")
keeps that history inside the local branch intact while producing a nice
linear history when you finally push it upstream (with or without
rewriting it before the push), without the messiness of many superfluous
merges.  If you have lots of changes that create merge conflicts, you'll
want to find a way to (almost) automatically deal with them, but you'd
have the same problem with actual merges.

It's a slightly different workflow than what you will find in most
tutorials, but I feel it actually works better than patch stacks (I've
also tried stgit and topgit and concluded they would perhaps be useful
or even preferrable in other situations, but not for this).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs