Hmm, I haven't even thought about this. Might be worth trying.
On Fri, 12 Nov 2010 15:49:21 +0100, Steve Ebersole
wrote:
> Given your setup (separate clones) I am not sure merge, rebase or
> cherry-pick
> are going to work. Another idea I have been toying with is to link the 2
> clones (rem
Given your setup (separate clones) I am not sure merge, rebase or cherry-pick
are going to work. Another idea I have been toying with is to link the 2
clones (remote can be a file path). Really kind of orthogonal to the original
discussion, but has bearing.
On Friday, November 12, 2010, at 08
On Fri, 12 Nov 2010 15:02:55 +0100, Steve Ebersole
wrote:
>
> On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
>> On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
>> How does cherry picking solve the problem of the directory name changes?
>
> Well like I said before the co
On Friday, November 12, 2010, at 07:09 am, Hardy Ferentschik wrote:
> On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
> How does cherry picking solve the problem of the directory name changes?
Well like I said before the code in git that does merging understands the fact
that files are renam
On Fri, 12 Nov 2010 13:27:17 +0100, Steve Ebersole
wrote:
> A script is actually a great idea.
Right now it seems to be the way of least resistance.
> The other thought I had was to revert the module dir renames. Or to do
> it in 3.6 as well. Make them the same. Just not sure the kind of
The problem like you said in patching is that the dir renames are missed. The
problem in merge/rebase approches is that (due to git's common ancestor
approach) they want to pull in all the other changes back to 3.6 and there is
no way to adjust the base it uses to determine the diffs.
A script
