Re: [RFD] Deepen the git directory structure a bit.

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2010, 01:28 UTC
Message-ID: <7vzl2va2lo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B8657EC.8060302@googlemail.com>

Fabian Kössel <mok4sin@googlemail.com> writes:

Show 9 quoted lines

> On 22.02.2010 23:32, Junio C Hamano wrote:
>> I'll queue with a trivial addition of "rm builtin/*.o" to the "make
> clean"
>> target.  I am not looking forward to merging the result of this with
> other
>> topics, though... X-<.
>
> Just out of curiosity, how do you actually merge such a relatively big
> rename with other branches?

For git.git, existing files are not so troublesome. merge-recursive knows how to handle renames, so does "am -3", but the latter is tricky when the contributor based a patch on some unknown vintage of the source.

A topic with a new builtin command is a bit problematic and no mechanical merge would help. I suspect that no other SCM would be able to either.

 - A topic that adds builtin-frotz.c has an entry that describes how to
   build builtin-frotz.o in Makefile, somewhere near Linus's topic changes
   an existing builtin-nitfol.o to builtin/nitfol.o.  The topic would have
   added the new target already, and then we are merging Linus's topic.
   The merge will conflict.  Every time I rebuild 'pu', this conflict will
   reappear over and over.

   But once the conflict is resolved, rerere will remember it for me, so
   this is not a big problem.

 - A new builtin-frotz.c file in such a topic is more problematic.
   Linus's patch does not know anything about it, so it will merge
   cleanly, but the merge will not move it to builtin/frotz.c; this needs
   to be fixed manually as an evil merge.

   I have automated such an evil merge so that I can rebuild 'pu' without
   manual intervention.