View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012461CMakeCMakepublic2011-09-17 06:152012-04-02 10:10
ReporterValentin Rusu 
Assigned ToDavid Cole 
StatusclosedResolutionno change required 
PlatformIntelOSLinuxOS VersionopenSuSE 11.4
Product VersionCMake 2.8.5 
Target VersionCMake 2.8.7Fixed in VersionCMake 2.8.7 
Summary0012461: externalproject_add with GIT : fetch without merge
DescriptionUsing externalproject_add via KDE superbuild project.

First time it correctly clones GIT repositories.

Subsequent builds doing "git fetch". This updates GIT internal structures in the clone, but does not affect local sources, as the "git merge" step is not done.

Possible solutions:
- add "git merge" step,
- replace "git fetch" with "git pull".

TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to 0012445closedDavid Cole Do not use git.cmd in FindGit module 

-  Notes
Brad King (manager)
2011-09-19 10:00

Try using git.exe instead of git.cmd.
Brad King (manager)
2011-09-19 10:05

The update step uses multiple commands:

  git fetch ...
  git checkout ...

so that the update is not dependent on local tracking branch configuration.

However multiple commands does not work in VS generators because git.cmd the whole command sequence after the first command runs. See 0012445:0027375 for the proposed fix.

This is really happening to you in Linux too? What generator are you using?
Alex Neundorf (developer)
2011-11-16 15:12

Yes, I still have to manually do "git pull" or git merge afterwards.
git is

It looks like this:

[ 95%] Performing update step (git fetch) for 'kdeexamples'
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From git:// [^]
   bef0736..c210877 master -> origin/master
Already on 'master'
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.

The git checkout afterwards doesn't seem to do a lot, it simply stays at the branch it already is. git pull or merge updates the working tree:

kde_kdeexamples$ git checkout master
Already on 'master'
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
kde_kdeexamples$ git pull
Updating bef0736..c210877
 kdedemo/examples.xml | 1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Is this the intended behaviour ?
I'd like to be able to just get the sources updated to current git master.

Brad King (manager)
2011-11-17 13:09

Re 0012461:0027813: I'm not sure whether the current behavior is intended or desirable but you can follow the upstream master by using

  GIT_TAG origin/master

in the ExternalProject_Add call.
David Cole (manager)
2011-11-18 10:38

Just a note here, before we decide what the best fix is for this issue. I do not regard this as a high priority issue at all, for the following reasons:

The "vast majority use case" of connecting to a git repository with ExternalProject_Add is as follows (and all of these work right now):

Track an upstream branch, use "origin/" explicitly in GIT_TAG:

  GIT_TAG origin/master

Snap to a known tag or commit, never update, leave it static unless GIT_TAG changes:

  GIT_TAG v2.8.6


  GIT_TAG 46c70540ede37c5f2ebeeeba4178340abf92fadb
Alex Neundorf (developer)
2011-11-18 13:55
edited on: 2011-11-18 13:55

If I use origin/master, I get:

[ 0%] Performing download step (git clone) for 'extra-cmake-modules'
Cloning into kdesupport_extra-cmake-modules...
remote: Counting objects: 9541, done.
Resolving deltas: 100% (6307/6307), done.
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

This doesn't seem to be what we need.

The use case is the following:
with the transition from svn to git the situation for KDE has changed a lot.
Before, I could do svn co trunk/KDE/, and got all KDE modules (15 or so).

Now, with git, it's not only that every KDE developer who wants to access all (or multiple) "modules" would have to git clone those 15 git repositories, but the repositories are also being split into more modular repositories.
E.g. the kdegraphics module has been split into 14 git repositories holding one application each, and 4 git repositories holding one library each.
If I counted correctly, we have 192 git repositories currently.

Add to that that there are dependencies between some of them, this is unmanagable manually.

We have a python script kdesrc-build, which automates this.

I'm trying to write a SuperBuild CMakeLists.txt for KDE, adding one ExternalProject for each git repository.
So I can then select which subprojects I want, enable only those in this superbuild, and update them all at once: [^]

This is basically working, only that I cannot really update them because of the git fetch instead git pull (or the missing git merge).

So, I'd really like to get that working, and I can also work on this, if we agree how it should be done.

Brad King (manager)
2011-11-18 14:08

Ignore the "detached head" output. That is Git's explanation for newcomers that enter a command unintentionally entering that state. Using "origin/master" will do what you need. The resulting update sequence is

 git fetch # updates refs/remotes/origin/master
 git checkout origin/master # checks out updated version
 git submodule ... # brings contained submodules up to date

The reason we don't use "git pull" is because that cannot cleanly handle upstream branch rewrites.
Alex Neundorf (developer)
2011-11-18 14:20

Not completely, at least not directly.

When I try to push in this state, I get:

~/src/kde-git/KDESB2/src/kdesupport_extra-cmake-modules$ git push
fatal: You are not currently on a branch.

When I do then git checkout master, I can push again.
But doing the update via ExternalProject afterwards, takes me back to the detached HEAD.

Can I do something in my git setup to make this behave different ?

Or how about adding some switch or option to ExternalProject so that it does pull or merge or something ?
Brad King (manager)
2011-11-18 14:26

You can always use a custom UPDATE_COMMAND to work around this and make it "git pull".
David Cole (manager)
2011-11-18 14:39

ExternalProject was not intended for use with several checked out repositories where pushing back to origin is expected... If that's what you're intending, there may be other issues that crop up because we haven't thought that scenario would be a common one.

It's intended for convenience of building things you depend on, not as a git repository management system.
David Cole (manager)
2011-11-18 14:40

Sounds like what you want is simply:

  GIT_TAG master
Alex Neundorf (developer)
2011-11-18 15:39

Indeed, works.
Now that was simple :-)

I committed a patch to KDE superbuild, it should work now as expected.

Valentin, feel free to reopen this issue if it still doesn't work as expected.

David Cole (manager)
2011-11-18 15:41

Changing status to "resolved" so that Valentin can re-open if necessary...
David Cole (manager)
2012-04-02 10:10

Closing resolved issues that have not been updated in more than 4 months.

- Issue History
Date Modified Username Field Change
2011-09-17 06:15 Valentin Rusu New Issue
2011-09-19 10:00 Brad King Note Added: 0027447
2011-09-19 10:01 Brad King Relationship added related to 0012445
2011-09-19 10:05 Brad King Note Added: 0027448
2011-09-19 10:05 Brad King Assigned To => David Cole
2011-09-19 10:05 Brad King Status new => assigned
2011-10-25 21:51 David Cole Target Version => CMake 2.8.7
2011-11-16 15:12 Alex Neundorf Note Added: 0027813
2011-11-17 13:09 Brad King Note Added: 0027814
2011-11-18 10:38 David Cole Note Added: 0027819
2011-11-18 13:55 Alex Neundorf Note Added: 0027821
2011-11-18 13:55 Alex Neundorf Note Edited: 0027821 View Revisions
2011-11-18 14:08 Brad King Note Added: 0027822
2011-11-18 14:20 Alex Neundorf Note Added: 0027823
2011-11-18 14:26 Brad King Note Added: 0027824
2011-11-18 14:39 David Cole Note Added: 0027825
2011-11-18 14:40 David Cole Note Added: 0027826
2011-11-18 15:39 Alex Neundorf Note Added: 0027827
2011-11-18 15:39 Alex Neundorf Status assigned => closed
2011-11-18 15:39 Alex Neundorf Resolution open => no change required
2011-11-18 15:41 David Cole Note Added: 0027828
2011-11-18 15:41 David Cole Status closed => resolved
2011-11-18 15:41 David Cole Fixed in Version => CMake 2.8.7
2012-04-02 10:10 David Cole Note Added: 0029046
2012-04-02 10:10 David Cole Status resolved => closed

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker