Unable to build master with Visual Studio Express since last weekend

[Norbert Thiebaud]

On Sun, Sep 1, 2013 at 9:34 AM, Niklas Johansson
<sleeping.pillow at 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>)