On Sun, Sep 1, 2013 at 9:34 AM, Niklas Johansson <sleeping.pil...@gmail.com> wrote: > There were two more places I had to add conditions before I could finish the > build. Sent in my changes for review. I hope that they are correct, at least > they build and pass make check. > > https://gerrit.libreoffice.org/#/c/5740 > > Hmm... I accidentally made it dependent on an earlier patch, is there a way > to remove that dependency somehow? The patches are completely unrelated.
Not that it matter for this particular case, since both have been merged, but: This is just _one_ way of doing it... I will create some local branch for the sake of clarity, some step could be 'optimized out' assuming you are currently on master, and that that 'maser' point to a commit that is in the remote origin master branch. git checkout -b my_local_b1 git fetch origin git fetch git://gerrit.libreoffice.org/core refs/changes/40/5740/2 git cherry-pick FETCH_HEAD #fix conflict + commit if any git push origin HEAD:refs/for/master so to put it in a single sentence: cherry pick the change onto a base commit that is already 'merged' in the repo and re-push it to gerrit. I have not actually verified that gerrit is not confused by the change of dependencies... in the odd case it would be. amend the commit message, remove the ChangeID and commit again. that should generate a new ChangeID... push again... and then mark the original as 'Abandoned' using gerrit's web interface... but I do not expect that to be necessary; just given for completeness sake. To avoid the dependencies problem, to start with, the 'rule' is make a single change, push it to gerrit... _then_ reposition yourselft to a commit that _is_ already committed in the repo, and do your next change (*)... you can create local branch to track each individual changes while they are under gerrit review, which make it easier to check them back out -- no need to do the git fetch long_url> dance --- or you can use a fire and forget approach by leaving the change under review as headless. I use both method depending on the kind of patch it is... for the one that I expect/anticipate some active review that could lead to multiple version, I tend to track them with local branches... for the more straigh-forward - house-keeping kind of patch I tend to use the fire and forget approach.... Norbert (*) it is a good idea to reposition on a point that you know build fine on your system... I tend to do a build of plain master after a pull -r... and then not pull for a while and use that known good master as a base for my gerrit work... then from time to time, as needed, git pull -r master, rince and repeat... On a slow machine, it may be usefull to look at http://tinderbox.libreoffice.org/MASTER/status.html to identify a likely 'good' master point, then pull -r and then manually force your local master back to that chosen good point (git reset --hard <good_sha>) _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice