+1 to Subramanya. Roan Kattouw wrote: > Although squashing and amending has downsides, there is also an > advantage: now that Jenkins is set up properly for mediawiki/core.git > , we will never put commits in master that don't pass the tests. With > the fixup commit model, intermediate commits often won't pass the > tests or even lint, which leads to false positives in git bisect and > makes things like rolling back deployments harder. > > Roan
It should be possible to only bisect on the left-branch of merges. If git doesn't have such feature, it should be added. In fact, it's very likely that it's what it uses when start and end are in the same line, but as the merged commits can also have that ancestor, it might also go there. We would need to store multiple commits as non-fastforwards, even if descending from head, but that's trivial. What I have trouble with is in imagining the UI for reviewing a topic branch, with perhaps several commits per "step". Always registering as a merge, has succh as storing the merger name as the commiter, but I'd like keeping them as fest-forwards having for one-commit changes. I think the history would easily get hard to browse. Also, I don't like how when browsing a merge (eg. gitk) you are not shown the actual changes to the repository (which for us is the left-parent). Anyone knows of a way to do so? Regards _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
