Jeff King <peff@xxxxxxxx> writes: > I guess you didn't see the follow-on discussion and patch (or perhaps > you didn't care). I was holding the patch for post-1.5.3. It's > behaviorally equivalent, but a little nicer code. But now that his has > been published on master, it feels slightly like code churn. Well, post 1.5.3 may be a good time for code cleanups. I saw your patch and I think that is equivalent, just nicer and easier to read, but I had enough time to do the usual round of test for only one today. >> Johannes Schindelin (2): >> [...] >> name-rev: Fix non-shortest description > > Ditto here. His patch feels a bit hack-ish to me, and I have just posted > an alternative (which is most definitely post-1.5.3). To be honest, I > didn't expect you to take any patches on this in another -rc. I think this is about the same low impact patch as two two fixes to log family I queued to 'next', which I am very tempted to merge to 'master' by -rc7 (one is the "git log --name-status" stuff, including your suggested improvement). Yes, merge weight code felt hackish, and more importantly, favoring first parent is almost always wrong (unless done for tie-breaking) if you are really into git workflow. E.g. once you ask your subsystem person to do a merge for you and then you fast-forward from him, then the first parent history is not purely your history anymore. But for this application, such a side branch that is on the first parent chain for a short while won't be tagged by the other person anyway, so it is probably not too much of a problem. More importantly, I do not think we would want too intrusive change at this stage. - 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
