George Spelvin, could you please try not mangle CC to include only emails, stripping names (e.g. "spearce@xxxxxxxxxxx" instead of "Shawn Pearce <spearce@xxxxxxxxxxx>")? "George Spelvin" <linux@xxxxxxxxxxx> writes: > On <david@xxxxxxx> wrote: >> On Wed, 20 Jul 2011, Shawn Pearce wrote: >>> If the algorithm is always "gen(A) = max(gen(P) for each parent_of(A)) >>> + 1" then it doesn't matter who merged what commits, the same commit >>> appears at the same part of the graph relative to all of its >>> ancestors, and therefore always has the same generation number. This >>> is true whether or not the commit contains the generation number. > >> I have to think about this more, but I'm wondering about cases where the >> same result ia achieved via different methods, something along the lines >> of one person developing something with _many_ commits (creating a large >> generation number) that one person merges far sooner than another, causing >> the commits that they do after the merge to have much larger generation >> numbers than someone making the same changes, but doing the merge later > > Can't happen. Using the basic algorithm as Shawn described, the > generation number is defined uniquely by the ancestor DAG. > > The generation number is the length of the longest path to a > root (zero-ancestor) commit through the DAG. > > If you look at past discussion, several people have thought it was > okay to bake into the commit precsiely because it can be computed > once and will never change. > > However, git does have some ability to amend the history DAG after > it's been written, using grafts and replace objects. These can > change generation numbers, presisely because they change the DAG. There is also another issue that I have mentioned, namely incomplete clones - which currently means shallow clone, without access to full history. Nb. grafts are so horrible hack that I would be not against turning off generation numbers if they are used. In the case of replace objects you need both non-replaced and replaced DAG generation numbers. -- Jakub Narębski -- 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