On Thu, 2013-02-21 at 18:17 -0800, Cameron Esfahani wrote: > Oh, I'm serious. > > Don't take my dislike of git to mean that I don't think we should > consider the proposal to migrate edk2 away from svn to git. If the > consensus is to switch, don't let me stand in the way.
Thanks for clarifying that.
> What follows is my rant against git. Please skip if you don't care.
>
> Git has one amazing feature: local commits. But it is hidden behind a
> terrible interface. An interface that's so bad, it wears that like a
> badge of honor.
>
> 4.4 million page hits for "what I hate about git". 2.2 million for
> "what I hate about svn". 1.4 million for "what I hate about
> subversion".
>
> Wiser people than me have referred to using git as juggling chainsaws.
I think there's a lot of truth in that, but I also think that *some* of
it is misplaced. Git lets you do a *lot* of things that a less capable
VCS simply *cannot* do. If you violate the KISS principle and actually
attempt to *use* all those features, you fairly much get what you
deserve. It's a bit like using every possible feature of the C++
language, just because it's there.
The basic workflow of git (diff, commit, log, show, push, pull) is
fairly simple and isn't at all like juggling chainsaws. It's only if you
do something more complex that it gets horrid.
I think people have a tendency to abuse the 'branch' feature, and that
is a violation of the KISS principle which tends to lead to pain. Git
makes it cheap to clone a separate *repository*, even if you're doing so
for only a few commits. There's no need to force people to deal with
branches for anything except for the purpose that we always *used* to
use branches for — actual branches of development, like bug-fixes to a
stable release.
So any time you see people talking about 'topic branches' and how to
handle them... yes, that's the juggling chainsaws bit.
Don't Do That Then.
> People pay real money to buy GUI front ends for git, so they avoid the
> command line interface.
>
> In my experience, the default options to the different git commands,
> and the options themselves, are not designed for common usage cases.
> It's designed for Linus to manage all the branches, patches, and
> submissions for Linux.
When you say 'all the branches', it makes me suspect you've been exposed
to this "a branch for every thought that enters my head" nonsense.
Truly, I'm sorry for that insanity. Please, try to forget you ever saw
it. That is *not* what we're suggesting when we suggest that EDK2 move
to git.
> Well, most of us aren't in that kind of workflow. Even the edk2
> project won't require that level of functionality from it's VCS.
>
> Here's an example. You use "git log" to get the entire log. If you
> want just a single entry, you use "git show". Yeah, that makes sense.
I sense sarcasm. If I want to see a log of all the commits, I use 'git
log'. It shows me its output in various levels of verbosity, with the
default being relatively sane.
(And unlike svn, it feeds it to $PAGER so that I can *read* it sanely
and it doesn't just scroll right off the screen and out of my
scrollback. Causing me to swear, and wait for *another* round-trip to
the server to fetch it all *again* to feed it through 'less' this time.)
A 'git log' output might look something like this...
commit 7d5c23a737d1f2b9aca34731e813aa77eaae4ab5
Author: lpleahy <lpleahy@6f19259b-4bc3-4df7-8a09-765794883524>
Date: Fri Feb 8 21:31:16 2013 +0000
Increase sockets performance by increasing the maximum buffer sizes.
Tested using: DataSource/DataSink
Signed-off-by: lpleahy
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14125 6
commit 1c740a7d05e0ce7ccdefcb453bc532aca1f8d91b
Author: lpleahy <lpleahy@6f19259b-4bc3-4df7-8a09-765794883524>
Date: Fri Feb 8 21:29:03 2013 +0000
Allow fragmentation of large UDP packets
Reviewed-by: Ankit Singh of Dell
Signed-off-by: lpleahy
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14124 6
... and if I want it to *show* me one of those commits, so I can
actually see the changes that were made, then I'll use 'git show'.
I sense sarcasm in what you said about 'log' vs. 'show', but I can't for
the life of me work out *why* :)
I appreciate that sometimes, one gets so used to certain things that one
doesn't *realise* why they're illogical. But this particular distinction
between 'log' and 'show' has *never* seemed odd to me. It seems to be
entirely right. What am I missing?
This is the same in Subversion too, isn't it? We have 'svn log' (well
'svn log | less' if you want it to be useful), and we have... erm, ...
well I concede if I ever want the equivalent of 'git show' I'll just do
a git-svn clone and use git show. Or gitk. I've never found Subversion
at all easy to use, and the constant latency of dealing with round-trips
to the server makes it horrid to experiment with.
> Another example: why isn't the "--rebase" option the default for "git
> pull"? It seems to me, that for most people, that's what they'd
> want/expect.
Some people expect that, but it's not an expectation which should be
encouraged. For those coming from a legacy VCS into the 21st century for
the first time, it's difficult to understand that history is *not* a
simple linear progression; a strict ordering. History in a *distributed*
version control system is a DAG.
If you and I each clone *today's* EDK2 tree and go off and do our own
sets of changes, then our work is pulled back into the tree (which has
moved on a little since then), we end up with the following topology
(newest at the top)
o New HEAD (merging my work)
/|
| o Upstream commit merging your work
| |\
D | C You and I both commit something in our own trees.
| | |
D | C You and I both commit something in our own trees.
| o | Newer upstream commit which came in while were were working
\ | /
o Original upstream commit we started from
|
You'll note that the full history is preserved. You and I did our work
based on the original commit at the bottom of the above diagram, and
that fact is *important*.
In a legacy system, our patches would be committed one after the other.
We'd end up with history rewritten to be linear, something like
o New HEAD
|
D My second commit
|
D
|
C
|
C
|
o 'Newer upstream commit' from above
|
o Original upstream commit we started from
In this situation, we've sent our changes in as *patches*, and they've
been applied with some minimal manual mangling in order to make them
apply and build, if the upstream changes in the interim make that
necessary.
It might be that the new commit which sneaked in while we were working
is actually something which *breaks* your new code. And either it, or
your code, might break mine. In a subtle way, rather than an obvious
"patch doesn't apply" or "code doesn't build" way.
If that happens, it basically looks like you or I didn't do *any*
testing as we went along, and our code was completely hosed from the
moment we submitted it. There is no 'known good' state in the history
that we can go back to and say "hey, it worked here. Where did it all go
wrong?" (Which is what the git-bisect tool helps you do.)
Admittedly, lots of people are *used* to losing that history, can't
quite get their heads around the whole 'history is non-linear' thing,
and don't quite want to see why it's important. And those are the people
who always want to rebase before they submit things. But they're wrong,
and it *shouldn't* be the default behaviour.
If we have the proper history, we can go back to the specific state of
your tree or mine before it was pulled, and say "hey, it works there.
I'm not going to have the guy shot for extreme stupidity after all". And
we can *see* that the problem was introduced with the merge, and take a
closer look at the interactions between the merged changes. History is
*preserved*, not lost. Which is kind of the point of revision control.
Merge conflicts like that don't happen all that often, but they *do*
happen and they are extremely painful to work out if you've actually
thrown away the true history and you're left with something that,
according to your version control system, has *never* worked.
Wow, that was a very long-winded way to say "hell no, --rebase shouldn't
be the default". But the explanation of what distributed version control
actually *means* is probably worth putting out there for the peanut
gallery.
And again, if your workflow is based around --rebase, then of *course*
the tools aren't set up to make it easy. That is *not* a good workflow,
and it's not something that's particularly optimised for.
> But I can dream of a day where the git maintainers have put the same
> care and energy that they have in the backend into the command line
> interface.
To a large extent they have, for the *sane* workflows. But there's a
*lot* of stuff that you just shouldn't be doing from day to day. And
that stuff isn't what's made easy.
> And let's be fair, when you say:
>
> > … the use of Subversion is a fairly good indicator that I'm not
>> likely to like the *code* very much either.
>
> it should be made clear that everything in that quote is subjective.
Oh, most certainly so :)
> Personally, in general, I find that if a project is open source,
> that's a good indicator, to me, that I'm probably not going to like
> the code very much.
I think that might be true for me too, in fact. There's a *lot* of code
out there, and I dislike *most* of it. In fact, I think it's fair to say
that if a project *exists*, that's a fairly good indicator that I'm not
going to like it very much :)
I tend to like projects in git more than I like projects in svn,
certainly. I cannot speak with authority even about my own subjective
opinion on "open source projects" vs. "closed source projects". I've
been lucky enough to have been exposed to relatively few of the latter
in my life, so there isn't enough data to be statistically meaningful.
And where I *have* been involved in non-open projects, I've generally
been... well, involved. So I've actually had some input into design
decisions, and that would presumably skew the results in that direction.
It's easy to observe the code of an open source project as a completely
impartial, uninvolved third party. Very hard to do that for closed
projects, in the general case.
> I can count on 2 fingers the number of open source projects that I
> think have good, well-designed and thought-out code. Funny thing,
> both of those projects currently use subversion. Again, subjective...
:)
Out of interest, which are they? Is one of them EDK2?
And if you have any thoughts on why the OpenConnect VPN client¹
*doesn't* fall under the category of "good, well-designed and
thought-out code" for you, I'd be interested to hear them. I certainly
have my own answers to that question :)
But that's fairly much off-topic, if we weren't already.
--
dwmw2
¹ http://www.infradead.org/openconnect/
http://git.infradead.org/users/dwmw2/openconnect.git (gitweb)
git://git.infradead.org/users/dwmw2/openconnect.git
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
