Carl Worth wrote: > On Fri, 5 May 2006 17:17:10 +1200, "Martin Langhoff" wrote: >> In that case, the server should apply the ignore rules. Except that >> later merges in the local repo would perhaps have to deal with missing >> part of the history. I suspect it should refuse to merge something we >> don't have all the merging parts for. > > Yeah, shallow clones can shake up the conventions a bit. It's > definitely common for a repository to only have a single parent-less > commit, such that there is always an identifiable merge base for any > pair of revisions. Shallow clones would make (effectively) parent-less > commits much more common. I wonder if it would be possible for git to: a) as for a fetch which would bring all the commits up to the merge base (and merge base has to be calculated on the server side I think), i.e. give command to use (for fetch or for force baseless merge) b) fetch the commits c) do merge d) optionally re-cauterize history again -- Jakub Narebski Warsaw, Poland - : 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