Felipe Contreras venit, vidit, dixit 16.05.2013 10:09: > On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber > <git@xxxxxxxxxxxxxxxxxxxx> wrote: >> Felipe Contreras venit, vidit, dixit 16.05.2013 09:48: >>> Showing the tracking information for all the branches takes significant >>> amount of time. The user might not want that. The --no-show-tracking >>> option allows that. >> >> I really like the idea of allowing that - not just because I've >> suggested so myself in the past ;) >> >> I feel, though, that we're really exploding our option and config realm. >> For "git branch" in list mode, we are already able to stack "-v", i.e. >> "-v" and "-vv" do different things. How about maybe adding "-vvv" and >> arranging things so that the verbosity and the run time increases with >> the number of v's? >> >> -v list with sha1 + subject of last commit >> -vv add upstream branch name >> -vvv add ahead/behind info (the only costly mode) >> -vvvv same with "--cherry" (ahead/behind/same) > > Yeah, I thought about that too. > >> Or maybe combine the middle two cases into "-vv", which means it would >> be the same as "-vv", with only "-v" changing what it does now. > > Please no, I would like to see 'upstream', but not ahead/behind info. > In fact, that's my whole motivation behind this patch. I'd be fine with combining the first two also. >> Yes, this changes current behavior (at least fpr -v), which sucks >> anyways because of the costly lookup. And those scripting around "branch >> -v" should get what they deserve. (I may sound annoyed by our >> compatibility brakes, but here's a case where breaking it should be OK.) > > I also agree that it would be OK to break this. > > Alternatively, I've been thinking that we should have a v2.0 mode, or > a v2.0 branch, where all the compatibility breakage things go. We have > been so careful at not breaking things, that we have been too good at > stacking hacks and configurations all over the place, and in my > experience it's not unusual that right after an incompatibility > release, someone realizes that we forgot some compat breakage things, > and oh, well, maybe for v3.0. > > The ones I have in mind are: > > color.ui=true > merge.defaulttoupstream=true > format.coverletter=auto > branch.autosetupmerge=always > mergetool.prompt=false > > Cheers. Yes. Additionally, there are things which we can break during normal releases, but somehow the compatibility discussions have kept us from doing so. Maybe we need a clearer separation of porcellain and plumbing again? Or a clearer definition of x, y, z in x.y.z releases? We haven't even used y increases for incompatible ui changes that much. Michael -- 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