Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > David Kastrup venit, vidit, dixit 02.12.2009 10:32: >> >> sometimes there are changes which would seem better to restructure into >> more than one commit, with a non-operative intermediate state. >> >> What I am thinking of is something like >> >> a) change an API (small but highly intricate patch warranting thorough >> line-by-line review to make sure it's fine) >> b) adapt all existing callers (really large but utterly trivial patch) > > A quick solution with current git would be "replace": Say, in > A-B-C-D > you want B and C to be considered an "atom" for bisection. So, "git > replace" C by a commit C' which is B+C squashed and has A as its parent: > A-C'-D. That would lose B and C. The idea was to have this available publically. > Alternatively, if you want this to be distributed more easily and think > of it at the time of committing, producing a DAG like > > A--C'--D > \ / > B--C > > with C' as the first parent of D may help during bisection. I.e., you > keep the detailed history on the side branch and squash it together on > the --first-parent-line, with C,C' being tree-same. That would seem to be more or less accomplished by putting B-C on a side-branch, then merge that branch into A (C' basically being the merge commit). So the DAG would be something like A------D \ / B--C If B-C is a local branch, will their history make it through to a remote repository when you push D? It seems like this workflow could possibly meet my criteria when one has push access to the repo in question. If one passes D upstream via git-format-patch, however, it would appear that just the equivalent of C' makes it upstream, with the B-C history staying local. Not sure what will happen when upstream pulls D. Further comments/insights? -- David Kastrup -- 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