Working without patchbomb (was something vaguely about bookmarks)

Matt Mackall mpm at selenic.com
Tue Jun 21 12:19:48 CDT 2011


On Tue, 2011-06-21 at 19:37 +0300, Idan Kamara wrote:
> On Mon, Jun 20, 2011 at 11:33 AM, Martin Geisler <mg at aragost.com> wrote:
> > Idan Kamara <idankk86 at gmail.com> writes:
> >
> >> On Sun, Jun 19, 2011 at 8:14 PM, Martin Geisler <mg at lazybytes.net> wrote:
> >>
> >>> With today's Mercurial, there is a non-significant cost associated
> >>> with maintaining a clean history: you have to use MQ or similar and
> >>> that destroys *collaboration* -- unless you are okay with dealing
> >>> with patches to patches.
> >>
> >> I don't think it does. Like others have said, there's nothing
> >> preventing you from publishing a public repo, where all interested
> >> individuals can collaborate.
> >
> > I claim that you cannot collaborate (efficiently) on a versioned patch
> > repository. I've never seen it happen. It is hard enough to work
> > together on files using patches -- working together on second-order
> > patches makes things much harder.
> 
> I haven't suggested otherwise. I'm just saying that if you want to
> collaborate, do it on a separate repo, without mq.
> 
> >
> > Personally, I've worked on a set of versioned MQ patches with Henrik and
> > I think it only worked because we took turns editing the patches.
> >
> >>> We have bugfixes in the Mercurial history today [...]
> >>
> >> Of course no code is perfect. But if you have the option of not having
> >> that extra commit for the bug fix, which is what we strive for by
> >> sending patches to the list for others to review, would you not prefer
> >> that?
> >
> > Not necessarily. That way of thinking can be a waste of time -- trying
> > to make the history look nice instead of letting it be informative.
> >
> 
> I don't know, I guess it depends. When working on a series in an
> organized manner (patches split up nicely etc), I find it natural,
> not a waste of time.
> 
> >>> One tool that we don't really use today is the merge commit. We
> >>> almost only merge because we have to: main and crew diverged and
> >>> needs to be merged. The other merge commits are accidental and carry
> >>> no interesting commit message or meaning. The only significant merges
> >>> are when default is merged into stable in preparation for a release.
> >>
> >> That's because there's no need to.
> >
> > I think it is because we've told everybody: "send us a patch and we'll
> > rebase it for you when we apply it -- it's now your own problem to get
> > rid of your old changeset". It is *strange* to me that the development
> > of Mercurial itself builds so heavily on discouraged practices such as
> > strip and rebase.
> >
> 
> I agree here. I think it might be nicer for contributors if their
> patches got applied with --exact and merged into the main line,
> rather than rebased.
> 
> My usual workflow is something like this:
> 
> $ hg qnew patch1
> ...
> $ hg qnew patch2
> ...
> $ hg email -o
> <patches get queued upstream>
> $ hg pull
> $ hg qpop -a
> $ hg qrm patch1 patch2 ...
> $ hg upd
> 
> Sometimes I qfinish+strip.
> 
> Where it could have been:
> 
> $ hg pull <brings merge commit>
> $ hg qfinish -a
> $ hg upd
> 
> For a couple of patches it's no big deal. But if I have a lot
> of patches waiting to be queued/still in progress, it can
> be a mess sometimes.
> 
> OTOH if you look at git's graph, it's not so easy on the eyes:
> 
> http://paste.pocoo.org/show/416271/
> http://i.imgur.com/CoXmZ.png
> 
> It does however, allow you to see all csets on a certain
> feature branch, next to each other in a nice way.
> 
> >> Imagine every contributor would merge upstream to his series every
> >> time he pulled instead of rebasing.
> >>
> >> It would clutter the history to the point it becomes unreadable, those
> >> merges aren't interesting to anyone. The merges you and whoever's
> >> working with you on your feature are no different imo.
> >
> > It would only be branches where people collaborate (published branches)
> > that would use merge, private branches can still be rebased.
> >
> > But yes, the history will be more complicated. We're building a tool
> > that can handle this, right? :-)
> >
> >> If you look at the kernel, where it's split to subsystems and
> >> maintainers pull other peoples work, then merging makes sense. Because
> >> people pull from the maintainers, and rebasing would make those
> >> peoples redo all their work.
> >
> > I know, I know... we have the same with the hg-i18n repository. I'm just
> > wondering if we're silly for not using that model more.
> >
> > I cannot be the only one who have looked at our development process and
> > thought "hey, wait a moment... they use *patches*? and they implicitly
> > *rebase* them all the time? Why don't they use their own tool more?"
> >
> > I know the answer is that email is incredibly flexible, but I also know
> > that we've talked about the problem of losing patches at the last two
> > sprints. Bitbucket just launched a nice 'pull request' feature that
> > would let us get some overview back: people make a pull request on
> > Bitbucket and we can reject/accept them there.
> 
> Yeah that sounds nice, although I think the main review process
> should stay in the mailing list.
> 
> It might also help crew members to pull changes that way
> rather than doing it from the mailbox, depends on their workflow.
> (but since Matt is queuing like 95% of the patches, he might
> not want to change his workflow)

Historical note: the crew repo was created on the initiative of the
crew, not at my prompting. The crew itself was originally self-appointed
too. I think I may have even been on vacation. But a bunch of people
(some of them current members of crew) seem to be laboring under the
misconception that "crew" is my idea of the Right Way To Do Things. It's
not - it's simply an organically formed structure that continues to be
convenient.

Feel free to work in your own repos! Feel free to send pull requests! 

But expect that if your changes aren't so obviously good/boring that
they don't need a public airing/review on the list, I'll have you post
patches. Reviewing changes by replying to emails on a public mailing
list is far and away the best way to do it. It gives everyone a chance
to be involved and engaged in a way that "pull this URL, please" won't.

Feel free to include a pull URL in your patchbombs - I may even honor
it!

(But: if you're working on GSoC, I'm going to make you post to the list
anyway, just for the practice.)

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list