On Mon, Jun 25, 2012 at 7:07 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> The "bad HEAD and no revs..." part, if we choose not to even error >>> on this, can be removed. >> >> Yea, I think we should return successfully, and warning() does that. >> But if we choose to display a message, I don't think it should be a >> warning (esp for the empty repo case). It should look like the sample >> printf below, but the v2 of the patch I submitted doesn't include the >> message. > > I said "*if* we choose not to" for a reason. It can be argued that > it technically is a regression that "git log" does *not* error out > for an unborn history, as that is different from the way the command > has behaved forever. > Yes, this is def a concern. Ok here are my thoughts on the four options: 1) Display error message and error. (current behavior) I don't agree with this, thus the patch I'm creating. 2) Display a friendlier message and error. I think this is a good option, and preserving the return code will be less likely to break things (this idea was present in my first patch). 3) Display success message and succeed. This makes sense to me, but this would be changing the behavior drastically. 4) Succeed silently I created my second patch to follow this model. I eventually chose this over 3, because I figured it was more in-tune with the rest of git's behavior with succeeding silently. So how do we break the tie between #2 and #4? I think #2 is playing it safer than #4, even though #4 is more ideal. > Again, "might want" was a key phrase. I didn't look at each and > every one of them and thought if it made sense to change their > behaviour. > Yes, I understood that. I believe I left one out. -- 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