On Thu, Jul 23, 2015 at 3:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: > >> But other projects prefer to keep the messy history intact. >> For one thing, it makes collaboration on a topic easier, as >> developers can simply pull from each other during the messy >> development. And two, that history may later be useful when >> tracking down a bug, because it gives more insight into the >> actual thought process of the developer. >> >> But in this latter case you want _two_ views of history. You >> may want to see the "simple" version in which a series of >> fully-formed topics hit the branch (and you would like to >> see the diff of their final form). Or you may want to see >> the messy details, because you are digging into a bug >> related to the topic. > > While I can see the reasoning behind the above [*1*], I am not sure > if the output with "--first-parent" would always be a good match for > the "simple" version. Wouldn't the people who keep these messy > histories also those who merge project trunk into a random topic and > push the result back as the updated project trunk? Admittedly, that > merely is saying that "--first-parent" is not a solution to such a > project, and does not say much about the usefulness of the new > configuration, so I'd queue it as-is. > > [Footnote] > > *1* I do not necessarily agree, though. The history being messy is > a sign that "the actual thought process of the developer" was > not clearly expressed in the work, and it is not likely that you > have more insight by looking at it---you will see more mess, for > certain, though. > -- > 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 Based on the work I've done with people who don't mind "messy" history, I find that they tend to break the first-parent rule fairly often, and I don't personally find much value in the "mess" of their history. However, I think the ability for git-am to see a patch series cover-letter and include a merge message would be valuable, as there is often information lost in the cover letter when you apply a series. I'm not sure how much work this would take in practice though. I think some projects definitely benefit from the first-parent setup, and it could be valuable, but I do tend to agree with Junio here that the mess is always helpful. If may be helpful if people's commit messages on that mess are good, but generally those that don't take the time to rebase local work and re-express the commit messages are not going to leave insightful messages the first time. However, have the ability to view history this way is still possibly valuable. Regards, Jake -- 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