lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CG manual, pushing to staging


From: James Lowe
Subject: Re: CG manual, pushing to staging
Date: Sun, 19 Jul 2015 08:29:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18/07/15 18:05, Federico Bruni wrote:
> Il giorno sab 18 lug 2015 alle 18:33, Benkő Pál
> <address@hidden> ha scritto:
>>> 3. I don't like much the `git merge` approach suggested for
>>> those who work with local branches, as the git log is a bit
>>> messed up (a merge commit is added, often faraway from the
>>> commit containing the real changes). I'd rather suggest using
>>> format-patch and git am even in this case.
>> 
>> I prefer working with local branches, using rebase instead of
>> merge like
>> 
>> $ git checkout my_branch_name $ git fetch $ git rebase
>> origin/staging [fix conflicts, run all checks, repeat from fetch,
>> etc.] $ git push origin HEAD:staging
> 
> That's probably how I would like to work (so I don't need the patch
> file). `git fetch` fetches implicitly from a particular branch?
> 
> What's the purpose of HEAD:staging?

- From the man page :)

- --snip--

 git push origin :
           Push "matching" branches to origin. See <refspec> in the
OPTIONS section above for a description of "matching" branches.

       git push origin master
           Find a ref that matches master in the source repository
(most likely, it would find refs/heads/master), and update the same
ref (e.g.
           refs/heads/master) in origin repository with it. If master
did not exist remotely, it would be created.

       git push origin HEAD
           A handy way to push the current branch to the same name on
the remote.

...

 git push origin HEAD:master
           Push the current branch to the remote ref matching master
in the origin repository. This form is convenient to push the current
branch
           without thinking about its local name.



- --snip--

Thus I assume that as long as you have merged you local branches with
staging (as I do when using lily-git.tcl) I don't have to worry about
what the local branch is (dev/local_working) compared to the remote
branch's name.

At least that is how I read it with my very simplistic day-to-day use
of git.

James
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVq1HNAAoJEP8yVoKoS9i+PK4QALtRO6jcZK60aq8Wfx6jhqCd
cftijKM9b07hvoeIuh8LrJBtSyj/PZ4kriPI19cocpUuoXAkHSHpsr7Fizk0PaaH
4yfHnOvPN2VE+6EpG1e8r+bkxDyrrxjy26PRahGd6+2Quc/86ReFYIVHuchqxSKC
TOQnF4oqjsZUR5nsSjOkB2XHiEDqopSdYVsS4+/4PGUsEE4urO/7fbHveB1aUp0Q
Y4TvsG80JS5HluS5B+1KiOGsNHrGxfB/adTvfNth++pfpOu7RZshv9GqLM9feZKl
EPW5ZW0fYibMQUsz+GS5rXEcZvEQNv4sDT62+pQPl7Y1ixKUUU8zupdn0hFpj/Hr
/isFJ2ldNIkG7HT9IagYGHglNfjp1G7AjAoDJlLXDD1lVfsfvu4DzmTmjqzSYfCO
fFF1zWZ0SSs1OxKyeCDjIOFNAKnInEe4lZNu3rJvyt2UreCRCItkVCOq6slIWIAr
0JG5V5nZQqoJI6VS1Wp+ZAeZtvtzl7O62wLbEMbLwlcyIIZ/n8LP15ETkgpEraY+
4CSSNlRN8ZVohX5+sgldHWEKEHZVXG/3y7GBwWZp4YzIlxrFcdRhrzdvvRBFqVrb
T3eI0cukvRITEvUigvrdvGQenVvR9Y3K9fzJIktocStzjRnouk/urqKiJjNQHUIb
7guhB3h0zjpT6gpUlRog
=s5uK
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]