Felipe Contreras venit, vidit, dixit 16.05.2013 10:09:
> On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber
> <g...@drmicha.warpmail.net> 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:
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html