First of all, lest you write in an embarrassed tone, I think the sequence of mistakes you made is close to universal. Using a DVCS is quite baffling if you have never
done so before; while a DVCS is fundamentally more “right”, moving from CVS/SVN to Git/Hg/Bzr is akin to listening to an friend try to explain special relativity in a
noisy bar. And Git in particular is not known for being particularly friendly—the terminology is odd, the commands and their options are sprawling and weirdly named,
error messages are often not helpful, etc. Once you get used to it you can do whatever you need but keep a Google search box at your right hand.
I will try to offer some generally useful advice but I am a relatively novice Git user myself; there are various ways you can automate these commands further, use
shortcuts, etc.
On 09/27/2012 03:49 PM, Erik Molekamp wrote:
- Clone the Jenkins repo
This is fine; no need to do differently before you want to make edits. (And generally you do not know if you are going to submit changes until you have at least played
with the original!)
- Build with Maven (unfortunately the build failed because some core tests fail
on Windows)
-DskipTests is your friend. (BTW if you use NetBeans there is a global option to pass this by default on non-test goals, which I find helpful: tests get run when you
intend to run tests, or are publishing releases, otherwise CI is there to guard your back.)
But do try to report (and if possible fix) known test failures on any
platform—as you did, thanks.
After reading some more GitHub help:
- Fork Jenkins
If you want to submit changes, yes click the Fork button on GitHub.
- Clone my fork
This is unnecessary. You can just do
$ git remote add fork [email protected]:molekamp/jenkins.git
Now ‘origin’ is the official project, and ‘fork’ is your stuff. ‘git remote -v’
summarizes.
- Make a change and push it to my fork
Slow down here. Before committing anything, preferably before even beginning
edits, pick a branch name to put your changes on (include the JIRA number if
one is filed):
$ git checkout -b XStreamDOMTest-win32
(If you had local modifications the above will still be OK. But if you already made commits on ‘master’ you have to run a horribly cryptic series of commands to
retroactively move them to a branch; Google it.)
Now you can commit in the IDE of your choice or from a shell. Then
$ git push fork
will fail but (for once!) will tell you what you need to run instead, so do
that.
Now from your fork’s GitHub page you can click on the button to create a pull request from this new branch and await comments. If you get any requests for changes, just
make your additional changes, commit, and
$ git push fork
again. The pull request's “Files” page will display the _aggregate_ diff after all your commits. If you directly addressed inline comments by rewriting the commented-on
code, they will get hidden automatically—neat.
If you want to go back to trunk sources, simply
$ git checkout master
If you want to work on your branch again,
$ git checkout XStreamDOMTest-win32
If you want to create a new branch for another pull request, check out ‘master‘
and then use the ‘checkout -b' command again as above.
If you are in trunk and want to update to latest sources:
$ git pull
If you then go to your branch and want to synchronize it with trunk:
$ git merge master
# if there are merge conflicts in a file, fix them up and then: git add file;
git commit
$ git push origin
There is no need to delete your branches if they get merged or rejected, but
‘git branch -d …’ can be used for that if you want.
If anything goes wrong, take a breather, use a graphical tool like gitg to
visualize repository history, and search for help.
