On Wed, Oct 25, 2006 at 02:19:15AM -0700, David Rientjes wrote:

quoted text
> No, my criticism is against the added complexity which makes the 
> modification of git increasingly difficult with every new release.  It's a 

OK, you seemed to imply problems for end users in your first paragraph,
which is what I was responding to.

quoted text
> _current_ needs.  For any experienced shell programmer it is so much 
> easier to go in and change an option or pipe to a different command or 
> comment out a simple shell command in a .sh file than editing the C code.  

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.

quoted text
> And sometimes it's necessary to have several different variations of that 
> command which is very easy with slightly renamed .sh files instead of 
> adding on more and more flags to commands that have become so complex at 
> this point that it's difficult to know the basics of how to manage a 
> project.

You can do the same thing in C. In fact, look at how similar
git-whatchanged, git-log, and git-diff are.

I don't understand how a C->shell conversion has anything to do with
options being added. If you look at all of the conversions, they
replicate the interface _exactly_.

quoted text
> 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?

quoted text
> as you treat Linux development; let's be honest and say that 99% of the 
> necessary git functionality was there almost a year ago and ever since 
> nothing of absolute necessity has been added that serious developers care 
> about in a revision control system.  Look at LKML, nobody is waiting on 

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.

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.

quoted text
> Absolutely.  I think I've actually documented that fairly well.  Back in 

Where?

quoted text
> the day git was a very concise, well-written package.  Today, a tour 
> through the source code for the latest release leaves a lot to be desired 
> for any serious C programmer.

I don't agree, but since you haven't provided anything specific enough
to discuss, there's not much to say.

quoted text
> Functionality wise, no.  But in terms of being able to _customize_ my 
> version of git depending on how I want to use it, I've lost hope on the 
> whole idea.  It's a shame too because it appears as though the original 

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)?

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html