On Thu, 2008-10-30 at 20:31 -0400, Jeff King wrote: > > Some suggestions, which have been briefly scanned over by some of the > > (remaining) GitTogether attendees. Please keep it constructive! :) > Thanks for putting this together. No problem! Thanks for responding. I've been amazed that it seems to have been largely taken well :) But there are still very important changes required. > > + * 'git status' would encourage the user to use > > + 'git diff --staged' to see staged changes as a patch > > I notice the commit template message getting longer and longer. Maybe it > is time for status.verbosetemplate (which could default to true, I just > want to be able to turn it off). Right. We'll have to work through that when we look at how 'git status' output is displayed. There may be some people who parse the existing output, but they should get to read the release notes about the proper ways to do that. I think the whole output could do with a shake-up. > > + * 'git undo' would do what 'git checkout HEAD --' does now > This is an awful name, IMHO. It doesn't point out _what_ you're undoing, As others have said, yes. > So I think with your stage/unstage, we have: > > W->S: stage > H->S: unstage > S->W: ? > S->H: commit (no paths) > W->H: commit (paths or -a) > H->W: ? > > So I think we can note something: movement commands are related based on > their _destination_. So since both of the missing ones impact the > working tree, they should have a related name. An interesting observation. I still think it's OK to use 'git revert-files' for this; it just seems so long. Switches could specify where to and from. > Side note: there are actually _other_ places you might want to move > content. Like a stash. So now you can think of it as: > > stash > ^ ^ > / \ > / \ > v v > HEAD <--> stage <--> working tree > > So maybe we just need a "git content" command. And then you can "git > content --from=HEAD --to=tree <paths>" or "git content --from=tree > --to=stash", with all equally supporting "--interactive". And of course > I am kidding, because typing that would be awful. But I think > conceptually, it makes sense. To me, anyway. Again interesting, you could look at the stash as a whole bunch of staged commits yet to happen. Of course, adding a file when the version in HEAD doesn't match the version in the base of the stash is a bit insane, so should probably be an error. I'll have a ponder over this and whether there is a simple word for this all. > > + * 'git branch --switch' : alternative to checkout > > Blech. I think switching branches is the one thing that checkout does > unconfusedly. And this is much more typing. Not to mention that So I > would rather see "git switch" if checkout is somehow unpalatable. > > But I don't know that it is. This seems like an attempt to say "branch > operations should all be part of 'git branch'". But checkout isn't > necessarily a branch operation. Consider detaching HEAD to a tag. Should > it be "git tag --switch"? You're right with all that. I don't think that it is necessarily wrong to have two ways to get at functionality, depending on whether you start with the noun or the verb first; so long as it doesn't introduce confusion. And if anything, I think --switch is wrong; --checkout is probably more consistent. I think I might have to mark this one as [maybe], and make it --checkout - as you say, it would need to go on all the other commands that are nouns and able to be checked out to be consistent. Let's see how that looks in round 2. > > + * 'git push --matching' does what 'git push' does today (without > > + explicit configuration) > > I think this is reasonable even without other changes, just to override > any configuration. Excellent, I have another vote towards this push sanity! :) > > + * 'git push' with no ref args and no 'push =' configuration does > > + what: > > + 'git push origin $(git symbolic-ref HEAD | sed "s!refs/heads/!!")' > > + does today. ie, it only pushes the current branch. > > + If a branch was defined in branch.<name>.push, push to that ref > > + instead of the matching one. If there is no matching ref, and > > + there is a branch.<name>.merge, push back there. > > There was a thread between me and Junio some months ago that touched on > this. I don't remember all of the arguments, but it was resolved to keep > the current behavior. Any proposal along these lines should at least > revisit and respond to those arguments. Right. So, before round 2, I'll read and attempt to summarise that thread - assuming I can find it! :) > > + * 'git push' to checked out branch of non-bare repository not > > + allowed without special configuration. Configuration available > I have this patch done and sitting in my repo, but I need to add the > "without special configuration" bit and add tests and docs. Looking forward to that! Thanks. > > + * 'git branch' should default to '--color=auto -v' > This should at least be configurable (even if it defaults to "on"). "-v" > is more expensive, and not always wanted. > > I, for one, just use "git branch" to get the current branch. I don't > know of a more obvious way to ask for it (and please don't mention an > ever-changing bash prompt). What's wrong with 'git symbolic-ref HEAD' ? *ducks* Of course 'git branch -q' would then be the quick version, or 'git br' (after git config --global alias.br 'branch -q') Another command people often want is 'git info' to tell them stuff like they might get from 'git status' or 'git remote' but without all the file details... > > + * 'git tag -l' should show more information > > I remember somebody talking about this, but not the details. Which > information? Oh, good point. Basically the same stuff that 'git branch -v' shows; in any case, its behaviour should be relatively consistent compared to 'git branch'. > > + * 'git init --server' (or similar) should do everything required for > > + exporting:: > > +---- > > +chmod -R a+rX > > +touch git-daemon-export-ok > > +git gc > > +git update-server-info > > +chmod u+x .git/hooks/post-update > > +git config core.sharedrepository=1 > > +---- > > But not all of those things are necessarily related, and some of them > have security implications. I would hate to get a bug report like "I > used --server because I wanted to share my content via dumb http, but my > repo was p0wned because of too-loose group permissions." ok. That should come down to the detail of how '--server' is specified, I think. I'll expand on that during round 2. Sam. -- 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
