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"?



[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/

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to