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

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

[Jarek Czekalski]

[this message is sent with 1 day delay - gnu.org seems to ignore my direct
emails]
I was thinking of writing about this since long, but now it may be more
important. The discussion concentrates on a change to the version control
system, so that it be better for the devs.

In my approach I don't pay much attention to the version control system used
by a project, because I always init a mercurial repository on top of it.
Then I use mercurial queues concept. This is a very convenient way of
maintaining local patches. The patches are stored as raw patch files and the
mercurial interface provides means of applying, reverting and reordering the
patches.

Don't you think that having a good machinery to deal with local patches
makes it less important what version control is in use? After all you use
only basic commands, like pull, push, log, commit which are so similar
between implementations. And in Emacs we have only 1-2 branches active, with
most people using but the trunk.

The concept is described in a wiki article, Use mercurial queues over svn
checkout [1]. Although I say "my approach" I was actually adviced so by
Stefan Sperling on svn mailing list (the link is inside the article).

Jarek

[1]
http://sourceforge.net/apps/mediawiki/jedit/index.php?title=Use_mercurial_queues_over_svn_checkout




--
View this message in context: http://emacs.1067599.n5.nabble.com/dealing-with-local-patches-mercurial-queues-over-bzr-git-checkout-tp308685.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

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

[Eli Zaretskii]

> Date: Mon, 6 Jan 2014 11:11:34 -0800 (PST)
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> In my approach I don't pay much attention to the version control system used
> by a project, because I always init a mercurial repository on top of it.
> Then I use mercurial queues concept. This is a very convenient way of
> maintaining local patches. The patches are stored as raw patch files and the
> mercurial interface provides means of applying, reverting and reordering the
> patches.

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.

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

[Óscar Fuentes]

Jarek Czekalski <jarekczek@poczta.onet.pl> writes:

[snip]

Isn't this the same as having one or more git branches on git for
accumulating patches and use interactive rebase + cherry pick?

Those operations are supported by Magit on a visual and intuitive form,
way easier than the staccato of commands listed on your wiki post.

P.S.: is this going to be a git vs hg technical war? Because we could
invite the Darcs folks, Fossil and even bring in bzr again.

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

[Jordi Gutiérrez Hermoso]

On Mon, 2014-01-06 at 11:11 -0800, Jarek Czekalski wrote:
> In my approach I don't pay much attention to the version control system used
> by a project, because I always init a mercurial repository on top of it.
> Then I use mercurial queues concept.

While MQ still has proponents, I think hg's Evolve feature is a much
better thing to do. The idea with evolve is that you can rewrite and
rebase commits as much as you want, even collaboratively, and it's all
safe. A commit, really, is nothing more than a patch that remembers
where it's based on, so it knows how to be merged.

For git users, Evolve is sort of like a safe "git push --force". It's
"git push --force" without any contraindications.

- Jordi G. H.

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

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Jan 06, 2014, at 09:20 PM, Eli Zaretskii wrote:

>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 agree that this is a great workflow, which feels very natural in bzr thanks
to its emphasis on mainline development.  But that's going to work quite
differently in git, since as Stephen has pointed out, git bisect seems to lack
a --first-parent switch (which log and rev-list have, though sadly are not the
default).

-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Daniel Colascione]

On 01/06/2014 11:11 AM, Jarek Czekalski wrote:
> [this message is sent with 1 day delay - gnu.org seems to ignore my direct
> emails]
> I was thinking of writing about this since long, but now it may be more
> important. The discussion concentrates on a change to the version control
> system, so that it be better for the devs.
>
> In my approach I don't pay much attention to the version control system used
> by a project, because I always init a mercurial repository on top of it.
> Then I use mercurial queues concept. This is a very convenient way of
> maintaining local patches. The patches are stored as raw patch files and the
> mercurial interface provides means of applying, reverting and reordering the
> patches.

quilt needs that approach, but git's is far cleaner because it's 
integrated into the VCS. There's no need for a queue setup when git's 
branches have all the required functionality. Mercurial's artificial 
distinction between branches and other kinds of change groupings is one 
of the things I dislike most about the system. I feel strongly that git 
got it fundamentally right and Mercurial got it fundamentally wrong.

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

[Jordi Gutiérrez Hermoso]

On Mon, 2014-01-06 at 12:09 -0800, Daniel Colascione wrote:
> Mercurial's artificial distinction between branches and other kinds
> of change groupings is one of the things I dislike most about the
> system. I feel strongly that git got it fundamentally right and
> Mercurial got it fundamentally wrong.

I agree that MQ was a mistake in hg. Git has made mistakes too, like
submodules. However, just as git has fixed submodules with subtrees,
we also have better modern alternatives to MQ, such as Evolve. In git,
without something like Evolve instead we have,

    http://www.infoq.com/news/2013/11/use-the-force/

- Jordi G. H.

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

[Jarek Czekalski]

W dniu 01/06/2014 08:20 PM, Eli Zaretskii pisze:
> 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.

If you are able to separate the complex part into sub-features, then every
subfeature becomes a local patch. The quilt gives you the ability to apply a
series of patches in a single command. However after incorporating the
patches upstream I usually delete the patches, so the history gets lost.

In general beyond some level of complexity this tool (hg queues) is too
simple. However I wouldn't call that level "non-trivial". I would say that
the border lies somewhere at "complex". The usual trade-off between
flexibility and simplicity is unavoidable. For the developers that don't
send complex patches, or are able to divide them into smaller pieces, this
simple method might be useful.

Jarek




--
View this message in context: http://emacs.1067599.n5.nabble.com/dealing-with-local-patches-mercurial-queues-over-bzr-git-checkout-tp308685p308708.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

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

[Eli Zaretskii]

> From: Barry Warsaw <barry@python.org>
> Date: Mon, 6 Jan 2014 14:49:27 -0500
> 
> I agree that this is a great workflow, which feels very natural in bzr thanks
> to its emphasis on mainline development.  But that's going to work quite
> differently in git, since as Stephen has pointed out, git bisect seems to lack
> a --first-parent switch (which log and rev-list have, though sadly are not the
> default).

Can't argue with you about git (yet), but one can still bisect
manually, right?  The branch commits are not lost in the merge, right?

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

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

[Andreas Schwab]

Achim Gratz <Stromeko@nexgo.de> writes:

> 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.

git rerere is supposed to help with repeatedly solving merge conflicts.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Mon, 06 Jan 2014 22:51:47 +0100
> 
> 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.

But then if I need to bisect the merge done by you, I see a single
large commit, instead of the series of small ones.  And that makes it
hard both to bisect and, if needed, revert a small part of the merge.

Anyway, this is an age-old argument.  I don't want to start another
one; if you like your workflow, and we decide that it is OK to do that
in Emacs development, so be it.  I just wanted to point out that what
Jarek does is not without price.

> 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 find that patch stacks are unnecessary most of the time.  Just
firing up another branch solves most of the problems that stacks are
supposed to solve.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Achim Gratz <Stromeko@nexgo.de>
>> Date: Mon, 06 Jan 2014 22:51:47 +0100
>> 
>> 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.
>
> But then if I need to bisect the merge done by you, I see a single
> large commit, instead of the series of small ones.  And that makes it
> hard both to bisect and, if needed, revert a small part of the merge.

<URL:http://code.google.com/p/lilypond/issues/detail?id=3648#c17>

-- 
David Kastrup

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

[Achim Gratz]

Eli Zaretskii writes:
> But then if I need to bisect the merge done by you, I see a single
> large commit, instead of the series of small ones.  And that makes it
> hard both to bisect and, if needed, revert a small part of the merge.

Please try it yourself.  If you use the workflow I described, there is
either no merge at all or a single merge; but all your commits, large or
small, are still present after the push including their timeline.  The
only thing different from the "standard" workflow is that there aren't
spurious merges to upstream inbetween, so it's vastly easier to follow
what you did from looking at the log.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada