On Wed, 25 Oct 2006, Jeff King wrote: > Yes, it's true that some operations might be easier to play with in the > shell. However, does it actually come up that you want to modify > existing git programs? The more common usage seems to be gluing the > plumbing together in interesting ways, and that is still very much > supported. > Yes, it does. I'll give you an example from six months ago: there was a need for the group that I work with to support a faster type of hashing function for whatever reason. This would have been simple with previous versions of git, but if you've ever looked at the SHA1 code in git, you'll realize that you're probably better off never trying to touch it. There is absolutely _no_ abstraction of it at all and the code is so deeply coupled in the source that abstracting it away is a pain. Likewise, there is always room for personal or organizational tweaks on the part of the developer. Things like distributed pulling and merging should actually be pretty simple to implement if the complexity wasn't so high in the merge-* family. This is something I implemented after an enormous headache because we were dealing with very large projects: yes, larger than the Linux kernel. And this is _exactly_ where piping would help; we have implementations of distributed grep over very large datasets (on the order of terabytes). > You can do the same thing in C. In fact, look at how similar > git-whatchanged, git-log, and git-diff are. > No you can't. Making a one line addition, commenting out a line, or changing a simple flag in a shell script is much easier. And like I already said, you can save multiple versions for your common use if you work on a specific project much of the time and change how it operates depending on the needs of that one project so you never need to do it again or you can _distribute_ that shell file to your colleagues so that everybody is doing their work via the same method. This makes it so you can just say "type X, then type Y, then type Z" and everybody is operating together without training them on how to use git. > > This all became very obvious when the tutorials came out on "how to use > > git in 20 commands or less" effectively. These tutorials shouldn't need > > to exist with an information manager that started as a quick, efficient, > > and _simple_ project. You're treating git development in the same light > > Sorry, I don't see how this is related to the programming language _at > all_. Are you arguing that the interface of git should be simplified so > that such tutorials aren't necessary? If so, then please elaborate, as > I'm sure many here would like to hear proposals for improvements. If > you're arguing that git now has too many features, then which features > do you consider extraneous? > It's not, it's related to the original vision of git which was meant for efficiency and simplicity. A year ago it was very easy to pick up the package and start using it effectively within a couple hours. Keep in mind that this was without tutorials, it was just reading man pages. Today it would be very difficult to know what the essential commands are and how to use them simply to get the job done, unless you use the tutorials. This _inherently_ goes against the approach of trying to provide something that is simple to the developer. Revision control is something that should exist in the background that does it's simple job very efficiently. Unfortunately git has tried to move its presence into the foreground and requiring developers to spend more time on learning the system. Have you never tried to show other people git without giving them a tutorial on the most common uses? Try it and you'll see the confusion. That _specifically_ illustrates the ever-increasing lack of simplicity that git has acquired. > I don't agree with this. There are tons of enhancements that I find > useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I > think other developers ARE using. There are scalability and performance > improvements. And there are new things on the way (Junio's pickaxe work) > that will hopefully make git even more useful than it already is. > There are _not_ scalability improvements. There may be some slight performance improvements, but definitely not scalability. If you have ever tried to use git to manage terabytes of data, you will see this becomes very clear. And "rebasing with 3-way merge" is not something often used in industry anyway if you've followed the more common models for revision control within large companies with thousands of engineers. Typically they all work off mainline. > If you don't think recent git versions are worthwhile, then why don't > you run an old version? You can even use git to cherry-pick patches onto > your personal branch. > I do. And that's why I would recommend to any serious developer to use 1.2.4; this same version that I used for kernel development at Google. > Where? > Few months back here on the mailing list. When I tried cleaning up even one program, I got the response back from the original author "why fix a non-problem?" because his argument was that since it worked the code doesn't matter. http://marc.theaimsgroup.com/?l=git&m=115589472706036 And that is simply one thread of larger conversations that have taken place off-list and aren't archived. > I don't agree, but since you haven't provided anything specific enough > to discuss, there's not much to say. > If there's a question about some of the sloppiness in the git source code as it stands today, that's a much bigger issue than the sloppiness. My advice would be to pick up a copy of K&R's 2nd edition C programming language book, read it, and then take a tour of the source code. > Can you name one customization that you would like to perform now that > you feel can't be easily done (and presumably that would have been > easier in the past)? > Yes, those mentioned above. David - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html