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

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-<.

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?

I haven't found a pleasant way yet to merge rename+modification in one
branch and modification on an old path in another branch.


There is git file-merge theirs base ours . But it only seems to take
filenames and no git object specifications. It would be very handy if
something like

git file-merge bfile HEAD^:afile afile

would be possible.


For clearification, here an example


echo "First line" > afile

git add .
git commit -m "First commit in master"

git checkout -b mybranch

echo "Second line in mybranch" >> afile
git mv afile bfile

git commit -a -m "Change and rename in mybranch"

git checkout master

echo "Changed first line in master" > afile

git commit -a -m "changed afile"

git merge mybranch


Regards

Fabian

Fabian Kössel [off-list ref] writes:

On 22.02.2010 23:32, Junio C Hamano wrote:

quoted

I'll queue with a trivial addition of "rm builtin/*.o" to the "make

clean"

quoted

target.  I am not looking forward to merging the result of this with

other

quoted

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.