On 11/07/2012 02:04 PM, Pádraig Brady wrote: >> thanks - although I still don't see much gain to have such jumbo >> > commits instead of ~20 little, on-topic ones which would also make >> > it easier for future looks back in git history in order to find out >> > why something has been changed the way it has been changed, see e.g. >> > the build system rework of Stefano. Your choice. > Yes it's a trade off between short term and long term info. > There is no value for example in keeping my whitespace fixup > patch separate, nor fixes that were particular to the local branch > (like the mem leak fix) as they may confuse future investigations. > In future when doing `git blame` we can see immediately the change > related to df --output. Also the shortlog generated in release > announcements is more feature focused than implementation focused. > So while I'm not convinced on the roll-up approach, it seems > like the better approach going forward.
Ideally, we'd have both: the bunch of single revisions and a single merge commit, i.e., retain the development line on a separate branch ... maybe that's overkill. Have a nice day, Berny
