Maybe somebody around here is more familiar with git than myself. Gump's git support is built the same way as all the other SCM modules, we have a command to initialize a working copy and one to update an existing working copy.
During a Gump run the working copy is created or updated and then synced to a different workspace directory where the actual build happens. Nothing done by Gump should alter the working copy except for the "update" command itself. To create a working copy Gump uses git clone --quiet URL directory-of-working-copy and to update an existing working copy git pull --quiet [since a few minutes ago trunk uses use 'git pull --quiet origin'] from within the directory holding the working copy. For JUnit this currently fails because git claims there'd be uncommitted changes in the working copy[1]. This shouldn't really be possible since Gump never modifies anything in the directory, only "git pull" does. While trying to investigate this I manually updated my local JUnit working copy which was sort of stale (not touched in months). The first "git pull" resulted in some merge conflicts (one in acknowledgements.txt IIRC) and subsequent "git pull"s looked exactly the same as the ones I see in Gump[2]. So it may be something in the way the JUnit folks are working with their git master, I don't know. Does anybody know what might be causing those merge conflicts or "unmerged files"? Is this something Gump could detect before performing "git pull"? Stefan [1] http://vmgump.apache.org/gump/public/junit/gump_work/update_junit.html [2] This is the tail of "git info" in my working copy # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: acknowledgements.txt # both modified: src/main/java/org/junit/runners/Parameterized.java # --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
