[oe] Git versus Hg

[Paul Sokolovsky]

Hello,

On Thu, 13 Mar 2008 10:26:00 -0400
"Cliff Brake" <cliff.brake at gmail.com> wrote:

> On Thu, Mar 13, 2008 at 4:15 AM, Paul Sokolovsky <pmiscml at gmail.com>
> wrote:
> >  On Wed, 12 Mar 2008 10:08:26 -0400
> >  "Cliff Brake" <cliff.brake at gmail.com> wrote:
> >  > Mercurial looks very interesting and nice in many aspects, but I
> >  > have not used it yet.  It seems to me one of the fundamental
> >  > differences is the concept of cheap/easy local branches.
> >  > Mercurial is working on something like that
> >  > (http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches),
> >  > but it is obviously not central to its philosophy like git .
> >  > The idea of creating many local branches a normal port of your
> >  > development workflow seems unique to git. As the gitmagic link
> >  > below states, it makes it very easy to switch context to fix a
> >  > bug, and then resume work on another feature.
> >
> >  Ok, so let's finally visualize how this unique feature would apply
> > to OE. So, we have set up all the BBPATH, build dir to reference to
> > OE working copy. Now, one magic spell, and OE working copy
> > transmogrifies into something else than it was before. What's next?
> >
> >  1. Suppose that we have thought that before, and prepared separate
> >  build dir for this another local branch. Here, it's important to
> > not miss which build dir to use for which of workdir's phases of
> > moon. That's a bit harder that it would be with branches checked
> > out into separate workdirs, but careful people indeed can run many
> > days before making mistake. But all in all, "lightweight branching
> > in OE" is not that "lightweight" as just issuing SCM command.
> 
> I would use git branches for working on features at the tip of OE, and
> branches are also very useful for keeping track of customizations at
> several points in a source tree's history.  For example with kernel
> work on one project, I have the following branches:
> 
>   2.6.23-rc4-rt1
>   2.6.24-rt1
[]

List is long, I'm glad it's ok for you keep track on so many things.

> 
> Git branches allow me to keep the old branch for reference if I ever
> need to go back to it, and easily move it forward to a new point in
> the kernel development.  I suppose the same thing can be done with
> tags.  I really don't like the idea of creating separate
> repositories/workspaces for different branches.  But, with different
> tools, you just develop a different workflow.  With monotone, I use
> overlays ...
> 
> >  2. Now suppose that we don't think that multiple builddirs is a
> > must. Then, we rm -rf tmp/ with each branch switch, or what? Btw, I
> > wonder how kernel people *actually* deal with that problem. Because
> > only CS freshman would buy into "very easy to switch context to fix
> > a bug, and then resume work on another feature." Real developers
> > know, that fixes are accompanied by testing.
> 
> This is a valid concern, but again the assumption is that if you are
> using git branches in OE, it is probably near the tip of the OE tree.

Ok, let's record in our minds this assumption, and be prepared to add
it do docs/howtos/best practices, and ready to answer users' concerns
regarding that.

> Bitbake -c clean works well.  If you move back in time, then cleaning
> tmp or switching tmp is obviously advised.
> 
> BTW, the kernel build system _can_ handle switching branches very well
> without "make clean".  I routinely switch branches in a workspace and
> type make without cleaning and it just works.  Try it sometime, you
> may like it :-)  I may be a CS freshman, but that is irrelevant
> because it does work very well and many people use it.

I obviously didn't mean you, referring to some authors of git "marketing
materials" who admit to having git as their first SCM, and not much
experience with other systems at all (like gitmagic author admits
explicitly for example).

And I'm glad that kernel build system handles that well - I assume it
has special support for such usage. That reminds that "repo control"
tool is actually only part of complete SCM picture, it includes
integration with build system, test system, issue tracking, etc. And OE
may not be well suited for that yet, and we should be prepared to make
changes towards that. That's another inference we can make, worthy
keeping in mind.

> 
> Interesting discussion and good points.  I guess the bottom line is
> there are different tools, and different people will have different
> preferences because people work differently, which is fine.  I'm ok
> with either choice (not that it really matters), and I'm not opposed
> to learning something new -- matter of fact, I would love a good
> excuse to learn hg.  I do think it is difficult for anyone to make
> informed decisions about tools of this complexity without having used
> it to do real work.  That is where most of us stand with hg.

I'm also ok with either tool, but I'm very much would like to have
internal confidence that we selected the tool based on weighting
different criteria and selecting best compromise based on them
(because it's going to be compromise, not the sole winner). And I also
let me to maintain belief that the more OE developers will participate
in this discussion, looking at the matter from different angles, and
getting similar confidence, the better.

> 
> I still maintain that that tools do impact developer workflow, and
> this should be a serious consideration when selecting tools.  What is
> the workflow that will maximize the productivity and output of the OE
> community?  The tool selection should follow.

I personally try to speak and advocate from a point of view of a
newcomer and hobbyist, who want to just add some software or device
support to OE, and thus would want to learn as little as possible on
the global scale (they don't know git or hg, that's it, which one
easier to use and learn for them). And I do so because other developers
IMHO don't look from that point of view too often, and yet that's
important user group to OE, without them we simply won't grow well
enough.

> 
> Cliff
> 
> -- 
> =======================
> Cliff Brake
> http://bec-systems.com



-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com