Hi, On Tue, 31 Jan 2006, Simon Richter wrote: > Well, the important thing would be that commands that can work (a merge only > needs to find the most recent common ancestor, etc) do work, and commands that > cannot ("log") emit sensible diagnostics. No it would not. A commit is a very small object which points (among others) to a tree object. A tree object corresponds to a directory (that is, it can point to a number of tree and blob objects). A blob object corresponds to a file (that is, git never parses its contents). If two separate revisions contain the same file (i.e. same contents), this is not duplicated, but the corresponding tree objects point to the same object. If you pull, upload-pack will think you have *every* object depending on every ref you have stored. Say you have three revisions, A -> B -> C, and A and C contain the same file bla.txt, and the client says it has B, the upstream upload-pack assumes you have bla.txt. > I know far too little about the internal workings for that, [...] I hope I clarified the important aspect. > > If you now rely on the grafts file to determine what was a cutoff, you may > > well end up with bogus cutoffs. > > Exactly that was my concern earlier; my database design gut feeling tells me > that information duplication is not good either, [...] You only have two choices: you proposed code duplication, and yours truly proposed data duplication. As is known from good database design: a few redundancies here and there are typically needed for good performance. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Feb 01 00:34:02 2006
This archive was generated by hypermail 2.1.8 : 2006-02-01 00:34:11 EST