On Mon, Apr 18, 2005 at 08:38:25AM -0700, Linus Torvalds wrote: > On Mon, 18 Apr 2005, David Roundy wrote: > > .... In particular, it would make life (that is, life interacting back > > and forth with git) easier if we were to embed darcs patches in their > > entirety in the git comment block. > > Hell no.
I was afraid that would be the response... > The commit _does_ specify the patch uniquely and exactly, so I really > don't see the point. You can always get the patch by just doing a > > git diff $parent_tree $thistree > > so putting the patch in the comment is not an option. The issue is that in darcs the parent and child trees *don't* uniquely or exactly specify the patch. In fact, even the output of git diff will depend on what version of diff you're using (e.g. if someone were to use BSD diff rather than GNU diff). > > As I say, it's a bit ugly, and before we explore the idea further, it would > > be nice to know if this would cause Linus to vomit in disgust and/or refuse > > patches from darcs users. > > That's definitely the case. I will _not_ be taking random files etc just > to keep other peoples stuff straightened up. Okay. > > Another slightly less noxious possibility would be to store the darcs > > patch as a "hidden" file, if git were given the concept of > > commit-specific files. > > No, git will not track commit-specific files. There's the comment > section, and that _is_ the commit-specific file. But I will refuse to > take any comments that aren't just human-readable explanations, together > with maybe one extra line of > > # Darcs ID: 780c057447d4feef015a905aaf6c87db894ff58c > > (others will want to track _their_ PR numbers etc) and that's it. The > actual darcs data that that ID refers to can obviously be maintained in > _another_ git archive, but it's not one I'm going to carry about. The trouble is that the philosophy of darcs and git are about as orthogonal as one can come. Git treats the content as fundamental, where in darcs the changes are fundamental. Since in darcs there can be different changes that lead from the same parent to the same child--and these differences are meaningful when merges happen---when interacting with git, we either need to restrict darcs to only describe changes in a way that can be uniquely determined by a parent and child, or we need to have extra metadata somewhere. For bidirectional functionality, we either need to avoid the use of advanced darcs features, or we need to include that information in git somehow, or we need to keep a parallel darcs archive holding that information. Would a small amount of human-readable change information be acceptable in the free-form comment area? In the rename thread I got the impression this would be okay for renames. For example, rename foo bar or (this is less important, but you might consider it to be a useful human-readable comment) replace [_a-zA-Z0-9] old_variable new_variable file/path Currently these two patch types account for almost the sum total of the cases where different patches lead to the same resulting trees. -- David Roundy - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
