Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2012-03-20 09:36:22

> Well the evidence is hard ... but let me try to replay my
> experience. I am sure, the next guy will step up and tell me that i
> did it totally wrong (actually happened when i tried to collaborate
> on said project using git).
> 
> So, the journey starts about a year ago or so. I decided i need to
> check out this new project i heard about. I was (actually still am)
> very determined to contribute to that project, so i cloned the
> repository, browsed the code etc. eventually i decided to fork this
> project cause i wanted to get some hacking done. That is what i did.
> Then life happened and i had to postpone the work on the project.
> A few months later, I got a new assignment to contribute a module
> for that project. Remember, i still got that (public) fork lying
> around.
> So i tried to get it up to date. First bummer. I don't remember
> which commands i tried in which order, but merge didn't really work,
> and i messed up during rebase. the result was, that i spent an
> entire day trying to figure out how to get this outdated fork
> uptodate to start hacking again. Also, since trying to learn this
> new git tool and its cool branches and stuff, i had of course
> multiple local branches lying around, never really figured how to
> properly maintain that (origin branch, master fork branch, origin
> feature branch1, etc. ...) and constantly pushed to the wrong
> branches and/or repos (luckily, I didn't have any write rights to
> the repository i forked from). And not to forget that i wanted to
> try some feature X from branch Y, but needed to combine that with my
> feature Z on branch U.
> Essentially, whenever I tried to publicly show my progress to
> someone, I ended up totally confused, and in a complete local litter
> box of branches, where half of them didn't really do what they were
> supposed to (like remote tracking).
> I needed to search the internets for how to accomplish task X that
> wasn't a simple "git add" or "git commit". Asking people after i
> didn't know any further lead to the answer that i shouldn't have
> executed command X in the first place. D'oh, that was how i read it
> on the internets ...
> I am sorry, this isn't a really detailed usage story, missing all
> the commands etc. that is why I wasn't clearer in the first place.
> To be perfectly honest, i even forgot most of the git usage i
> learned back then. I hope you can still relate a little to what I am
> talking about.
> 
> But yeah ... this is the memory that makes me arguing against git.
> Also, it is the reason why i argue against all those "advantages"
> people see over using git. I clearly fail to see them cause i
> miserably failed in actually trying to use them.
> 
> My $0.02 ...
> 
> P.S.: In this case, the usage of git actually prevented me to make
> the contribution i wanted to do. Nevertheless I was able to
> contribute a tiny bit. But well ...
>

Thanks a lot!

My first thought here is: It's all about the mental concepts!
Just a little, perhaps commonly understandable, example before coming
to Git etc.: Starting with C++, I found it fascinating (especially
templates), and at the beginning it was all hard work --- but at some
point things started to flow, I got an intuitive feeling for it, and could
just "write" code (with templates). That's an example for the mental
concepts, or perhaps "mental images", mental maps, I'm referring to,
and which one needs to work (live).

Also a disclosure: I personally use Git all over the place, private projects,
software projects, university work, and I am very satisfied with it.
In the same sense, it flows, things work out (mostly) as expected, it
helps me a lot. Compared to what you describe above, I am perhaps a more
conservative user --- if I really want to use a new feature, I better create
some experimental repositories first, make experiments, until I start being
able to predict what should happen.

It has been said that Mercurial and Git aren't that different: I think in a certain
sense that's true, but then, more fundamentally, it's very misleading.
Branching and the understanding of what is "history" are such complicated concepts
(inherently!), that the differences crucially matter, make a big difference, when it comes
to the point that you want to do more complicated things, and this in a
*comfortable* way (that you (intuitively) know what you are doing).

Unfortunately in the whole literature on computing (and also mathematics; sometimes
computer science is a bit better, at least wants to do things better) little
attention is on concepts: a stream of commands / actions is shown to you,
and from that you are supposed to learn something. The Internet is great for
technical details (amazing StackOverflow and related sides), but when it comes
to greater pictures, the underlying world models, there is not much (though, again,
on StackOverflow there is some help).

It would be a great thing if Boost could come up with "best practice", mental
maps, advice and role models how to do the standard actions required to work
with Git (w.r.t. Boost).

If you really jump into the complexity of the world of SCM, which Git I believe offers you,
without careful preparations, huhuhu, if I may say, there you go and the sharks are
waiting. You can branch, stash, sub-something, remote here and there, a bit of history surgery,
and this all at once, all mixed together ...
And there are also practical problems: you mention pushing to the wrong branches ---
this can happen, and one has to develop a certain discipline to avoid that. Before
starting to work, "git status" on the command line, or rescanning with git-gui
is a must.

So, to conclude, I believe that if Boost provides workflow models, with
general explanations and examples how to do it (command-line *and* git-gui+gitk
would be great --- git-gui and gitk are such a great help, but they are overlooked
so often), for the common actions, and there is a bit of culture to sustain
these efforts, expand and improve it, then Git will be a great tool for Boost.
(There is, of course, a little devil in Git, the seduction by all these possibilities,
and a bit care is needed.)

Oliver