Re: First-time pushing a patch

[David Kastrup]

Ian Hulin <address@hidden> writes:

> I finally got my ssh access to savannah sorted yesterday, and I've got a
> small patch which has just gone in review and which James has marked as
> Patch-review.  Now *assuming* the patch stands up to review, it would be
> ready to push in the next few days.
>
> I normally like to work on a path in a branch on my local repository (in
> this case T2025).
>
> I'd just like to check what the correct process is as I don't want to
> screw up the first thing I push.  I presume the sequence would be
> something like this, once I've seen the Tracker status go to Push-patch:
>
> # make sure master branch and remote repo are in sync.
> git checkout master
> git pull --rebase --verbose

That means that if you have any patches of your own on your local
master, they will get rebased to be on top of the old master.

> #answer prompts for ssh pass-phrase etc. here
> .
> .
> .
> # merge branch into local repository master branch
> git merge T2025

Don't merge, that makes for messy histories.  I'd rather recommend the
following procedure:

Make sure that you fetch dev/staging.  I find it easiest to fetch all:
have something like the following in .git/config
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = ssh://git.sv.gnu.org/srv/git/lilypond.git

no other "fetch" lines should be needed.  Now do

git fetch


Now do

git rebase origin/master T2025

in case master has moved forward.  Rebasing your branch on origin/master
is a safe move since origin/master will not get rewritten.  I am
assuming that your patch actually applies to master and does not need
features only in dev/staging.

Now here for the trick:

git rebase origin/dev/staging T2025~0

This will check out your branch T2025 as a "detached HEAD" and rebase it
on dev/staging without touching your original T2025.  Why would you want
that?  Because the whole point of origin/dev/staging is that it is a
moving target: everything in it might get scrapped and rewritten, and
you would not want anything in it to make it into T2025 when it might
get scrapped and rewritten, since then git will attempt to _keep_ it
T2025.

Now use gitk and whatever else to check that HEAD looks _just_ like you
want it to become the new dev/staging.  If you find that anything looks
fishy, ask and abort.  Don't do any work of your own on the detached
HEAD or it will likely get lost: checkout a real branch for that first.

If it looks just like you want it to (this might involve testing!), do

git push origin HEAD:refs/heads/dev/staging

This is safe to do: it will refuse to do anything if this does not "fast
forward" dev/staging.  If you did the above rebase, the only way this
will fail if somebody else was faster and pushed something else to
dev/staging.

In that case, restart at the above rebase.

> If someone could confirm that won't screw up the main repository I'd be
> really grateful.

In order not to screw up the main repository, it is quite better to push
to dev/staging.  This will be given tests and committed regularly to
master.

[Diversion: by the way, Phil and Graham?  I have come to the conclusion
  that it is better if Patchy does not attempt any rebases or merges on
  its own.  Can you change that accordingly?  It should quite simplify
  Patchy and make its behavior more predictable: it would just try to
  push its tested version of dev/staging to master, and if that fails,
  it fails.
  
  In that way, we are sure that _only_ completely tested versions end up
  in master, and with identical structure to how people put them into
  dev/staging.

  A direct push to master bypassing dev/staging should be an emergency
  measure, and then Patchy can well wait until somebody manually rebased
  dev/staging.  Maybe we should rename the staging branch into just
  "staging" as the "dev/" is needlessly obscure. ]

-- 
David Kastrup