git-subtree: directory mismatch

Hi,

I've come across this weird behaviour using git-subtree: when updating a
directory created by git-subtree, the content of some (almost) random
neighbour directory gets replaced, instead of the directory specified by
"git-subtree --prefix".


mkdir /tmp/testrepo
cd /tmp/testrepo
git init .
mkdir -p modules/cognac/{manifests,files}
mkdir -p modules/cognac/manifests/{classes,definitions}
touch modules/cognac/README modules/cognac/manifests/classes/foo.pp
modules/cognac/manifests/definitions/bar.pp modules/cognac/files/blabla
git add modules/
git commit -m "test"

git remote add mapserver git://github.com/camptocamp/puppet-mapserver.git
git remote update
git-subtree add --prefix modules/mapserver 97f5985b # an older commit

# So far so good, I have 2 subdirectories in modules/ with completely
# different content.

# Then, the content of modules/cognac/ gets completely replaced by the
# content of HEAD from git://github.com/camptocamp/puppet-mapserver.git.
# modules/mapserver still contains the content of commit 97f5985b.

git-subtree pull --prefix modules/mapserver mapserver master

From git://github.com/camptocamp/puppet-mapserver

 * branch            master     -> FETCH_HEAD
Removing modules/cognac/files/blabla
Removing modules/cognac/manifests/classes/foo.pp
Removing modules/cognac/manifests/definitions/bar.pp
Merge made by subtree.
 modules/cognac/files/apt-preferences               |    3 +
 modules/cognac/files/epsg.C2C                      | 5445 ++++++++++++++++++++
 modules/cognac/files/epsg.legacy                   | 5445 ++++++++++++++++++++
 modules/cognac/files/epsg.minimal                  |   14 +
 modules/cognac/files/etc/apt/preferences-20070910  |    3 +
 modules/cognac/files/etc/apt/preferences-20080225  |   35 +
 modules/cognac/files/etc/apt/preferences-v5-2      |   35 +
 modules/cognac/manifests/classes/epsg.pp           |   21 +
 .../cognac/manifests/classes/mapserver-debian.pp   |   82 +
 modules/cognac/manifests/classes/v5.pp             |   46 +
 modules/cognac/manifests/init.pp                   |    8 +
 11 files changed, 11137 insertions(+), 0 deletions(-)
 create mode 100644 modules/cognac/files/apt-preferences
 delete mode 100644 modules/cognac/files/blabla
 create mode 100755 modules/cognac/files/epsg.C2C
 create mode 100755 modules/cognac/files/epsg.legacy
 create mode 100644 modules/cognac/files/epsg.minimal
 create mode 100644 modules/cognac/files/etc/apt/preferences-20070910
 create mode 100644 modules/cognac/files/etc/apt/preferences-20080225
 create mode 100644 modules/cognac/files/etc/apt/preferences-v5-2
 create mode 100644 modules/cognac/manifests/classes/epsg.pp
 delete mode 100644 modules/cognac/manifests/classes/foo.pp
 create mode 100644 modules/cognac/manifests/classes/mapserver-debian.pp
 create mode 100644 modules/cognac/manifests/classes/v5.pp
 delete mode 100644 modules/cognac/manifests/definitions/bar.pp
 create mode 100644 modules/cognac/manifests/init.pp

I was not able to reproduce this bug in any of the following cases:
 - if the README file wasn't empty
 - if modules/cognac is renamed to something else
 - if modules/cognac doesn't have the same sub-directories than
   modules/mapserver

This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
when git-subtree calls "git merge -s subtree".

Maybe something is broken in this puppet-mapserver.git repository I use ?
I've encountered the same problem with other directories too.

Any idea ?

Thanks !
Marc

On Tue, Nov 24, 2009 at 2:53 PM, Marc Fournier
[off-list ref] wrote:

I was not able to reproduce this bug in any of the following cases:
 - if the README file wasn't empty
 - if modules/cognac is renamed to something else
 - if modules/cognac doesn't have the same sub-directories than
  modules/mapserver

This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
when git-subtree calls "git merge -s subtree".

Yup.  This is basically a bug in "git merge -s subtree": it guesses
which subtree to merge into, rather than actually taking a prefix
parameter.  I've been meaning to either submit a patch for this, or
find a way to work around it.

This doesn't usually happen once your project is relatively mature
(ie. doesn't have blank or "default" template files in it) since then
the auto-guessing gets more reliable.  But there's no good reason to
do the auto-guessing, so it would be best to do this "properly."

Sorry that I haven't had time to fix it yet...

Avery

Quoting Avery Pennarun [off-list ref]

Yup.  This is basically a bug in "git merge -s subtree": it guesses
which subtree to merge into, rather than actually taking a prefix
parameter.  I've been meaning to either submit a patch for this, or
find a way to work around it.

Probably you can save time by using what was already done

http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021



-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

On Tue, Nov 24, 2009 at 04:48:26PM -0500, Avery Pennarun wrote:

On Tue, Nov 24, 2009 at 2:53 PM, Marc Fournier
[off-list ref] wrote:

quoted

I was not able to reproduce this bug in any of the following cases:
 - if the README file wasn't empty
 - if modules/cognac is renamed to something else
 - if modules/cognac doesn't have the same sub-directories than
  modules/mapserver

This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
when git-subtree calls "git merge -s subtree".

Yup.  This is basically a bug in "git merge -s subtree": it guesses
which subtree to merge into, rather than actually taking a prefix
parameter.  I've been meaning to either submit a patch for this, or
find a way to work around it.

I see. What sort of criteria does git-merge use to do this auto-guessing ?

I'm hoping to find a way to workaround this problem. I have a couple of
subtrees I'm completely unable to update. The best I found is:
"git rm -fr ..." followed by "git subtree add ..." again.

This doesn't usually happen once your project is relatively mature
(ie. doesn't have blank or "default" template files in it) since then
the auto-guessing gets more reliable.  But there's no good reason to
do the auto-guessing, so it would be best to do this "properly."

The thing is I use dozens of different "modules" in my project, all merged
into using git-subtree. All these modules have the same structure, and most
of them have quite minimal content and won't really evolve more. In my
case, evolution will mean adding even more modules.

If I understand the thread Nanako Shiraishi pointed us to, a patch
implementing a prefix to "git merge -s subtree" is available somewhere but
hasn't been added in any official release yet ?

Marc

On Tue, Nov 24, 2009 at 6:08 PM, Nanako Shiraishi [off-list ref] wrote:

Quoting Avery Pennarun [off-list ref]

quoted

Yup.  This is basically a bug in "git merge -s subtree": it guesses
which subtree to merge into, rather than actually taking a prefix
parameter.  I've been meaning to either submit a patch for this, or
find a way to work around it.

Probably you can save time by using what was already done

http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021

Hi Nanako,

I've read through the thread (I do remember skimming it awhile ago)
but can't find patches for the syntax actually under discussion.  I
found a patch that introduces "-s theirs", which was summarily shot
down in favour of adding -X support, but I can't find any actual patch
for this.  Moreover, git-merge seems to have been ported to C since
then, so I guess it wouldn't apply anyway.  And I can't find any
implementation at all for the discussed "-Xsubtree=" option, which I'm
guessing didn't actually ever get done.

Am I missing something?  It looks fairly easy to throw in anyway, but
it's even easier if someone has already done it :)

Thanks,

Avery