lilypond-devel
[Top][All Lists]
Advanced

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

Re: Contributor Guide "volunteers" needed


From: Graham Percival
Subject: Re: Contributor Guide "volunteers" needed
Date: Mon, 19 Jan 2009 00:58:17 +0800
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Jan 18, 2009 at 04:27:00PM +0100, Maximilian Albert wrote:
> 2009/1/18 Graham Percival <address@hidden>:
> > By "work fine", I also want to know that:
> > - future pulls work with simply "git pull" or "git pull origin"
> >  (whatever is listed in that section)
> > - creating patches works with whatever the command is
> >  (whether that's "git-format-patch HEAD or MASTER or whatever)
> 
> Should this take the possibility into account that people are able to
> create their own branches?

No.

> Or would it be OK to assume they work on
> master (because if they know how to create branches they also know how
> to use these commands)?

Yes.

The target audience is this:
"Hi guys, I have OSX and I noticed a few typos in the docs.  I'd
like to fix them, but there's a lot of mistakes so I don't want to
type them all in an email.  I've never used git before, but I have
macports set up and have run port install git."

Then we say "read CG 1 to get started with git, and CG 2 to find
otu what file(s) to edit to fix the typos".  $helpful_user then
looks at CG 1, does a copy&paste to get the source, edits the
files, does more copy&paste to update git, commit the files, and
produce a patch.

> Anyway, when I "reset --hard" the master branch to a previous commit
> (so that it differs from remotes/origin/master and I don't have to
> wait for any of the developers to commit something to the remote
> branch) then both "git pull" and "git pull origin" work fine to
> synchronize master and remotes/origin/master again.

I've had problems with just "git pull"...

> This only applies if there are no local changes, though.

... ah, for precisely for this reason.  :)

> In case there are, then issuing
> either command produces a merge commit so that the commit graph now
> looks like this:
> 
>   * master after merging
>   |\
>   | \
>   |  \
>   * * remotes/origin/master (on the right)
>    \ |
>     \|
>      *
>      |
> 
> I'm not sure if this constellation can cause problems when producing
> patches. It seems that the command "git-format-patch origin" works
> fine, though (Rainer, thanks for pointing out that this should be the
> correct command).

See, I've been using git for a few years now, and I only barely
understand what you're talking about.  (not because I'm an idiot;
just because I've never been willing to put any time or effort
towards learning any git theory.  If I can use it like cvs --
checkout, add, commit, update -- then I'm happy)

> I personally prefer to checkout the remote branch before pulling and
> then doing a rebase:
> 
>    git-checkout remotes/origin/master
>    git-pull
>    git-rebase remotes/origin/master master
> 
> This produces a linear history, which I personally find "cleaner". :-)
> But I suppose that "git-format-patch origin" does the right thing in
> both situations. I don't know what you prefer to be included in the
> CG.

Mao.  I'm totally lost now.

Git people, please discuss and modify the CG accordingly.  I
promise to read the non-theory parts of the CG in a week or two,
and will use whatever commands are there.  In the copy&paste
sections.  I still plan on ignoring any paragraph which has more
than three sentences, or any section which contains more than
three paragraphs.  :)

Cheers,
- Graham




reply via email to

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