On 22 February 2013 11:14, David Woodhouse <dw...@infradead.org> wrote: > 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? >
I don't recall using "git show" before so I was curious what it was. Basically, it's "git log -1 -p". "git log" can take qualifiers, like many of git's commands. This is good as far as I'm concerned, but I realise you're citing that as one of it's bad features. So, I can do: git log -1 git log -10 git log <commit id> git log <commit id> -2 git log -p git log -p -1 git log -p <commit id> ... you get the idea. I don't ever see a *need* for git show, although now that I know it can save me a bit of typing, I might start using it. Oh, and "git show" can also take the same parameters, such "-2" or a commit id too, so you can "show" a number of commits and/or a specific commit. > 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 > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
