Tidying history is helpful. It enables people to go off on experimental tangent branches knowing that they can bring order out of chaos when they're ready. It also means that we don't have to have patches merged that break inkscape. It's good to keep a clean history, and you can use bisect to find problems in that case.
Uhm, I don't see how changing the number of revisions would effect how the patch applies in any case. Neither would which changing which revision the branch started on.
I don't think Max was saying that, when you are on a personal branch, you might commit something that you later discover breaks Inkscape. Git allows you to reorganize/rework your commits before they are pushed, so that each of your commits leaves Inkscape working. That way, when you merge back in trunk, all revisions are valid. This seemed like the goal of the svn trunk at some point: always have the development version working because some people use that for actual work.
I assure you that I go on experimental tangent branches regularly, that's simply the kind of person that I am. The histories there are still important even though you'd never see them unless you started really delving into the revision history to see each commit. When I merge it into main is when I write a more useful message about what really changed, as most people only look at the history of trunk anyway.
I am not sure whether this is specific to git or a general behaviour, but in git, when you merge back a branch, you see its full history in the trunk, not just the merge commit. For example, let say your history is something like (best viewed with a fixed width font): master: A--B-------C-------D-- \ / branch: --A'---B'--/ A,B,C are commits on the master (=trunk); A',B' are commits on the branch; D is your merge commit. After the merge, "git log" on the trunk will show: D B' C A' B A You get all the commits, in chronological order, *including* those on the branch. So you don't "only look at the history of the trunk". Of course git keeps a memory of what was on the branch and what was on the master but you still see everything from the master. This is a reason why it is sometimes interesting to rework your branch history before a merge. I don't know whether this is a feature or a drawback, but this is the way (I think) it works.
JiHO --- http://maururu.net