[OPEN-ILS-DEV] commiting documentation changes from the branches of others into Evergreen repo

[Soulliere, Robert]

Hi Dan,

I did try to follow the instructions and using "git cherry-pick -s <commit-hash>". However, when I got to the point of pushing the changes, I received a git error regarding non fast-forward commits and requiring a merge.. Thus, I merged and could push. Did I miss a step or is there a good way to get around this error without merging? I did pull for the latest changes just before pushing.

I will keep in line related to branch naming in the future.

I was wondering if I could delete the old 1.6 folder under docs? This is an old directory used in the early days of DocBook testing. Seems like it could be confusing and is non useful at this point in time.
http://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=docs/1.6;h=ee59c7ad272d9262a5034d854511290a4d4d4cd8;hb=master

Thanks,
Robert













Robert Soulliere, BA (Hons), MLIS
Systems Librarian
Mohawk College Library
robert.soulliere at mohawkcollege.ca
Telephone: 905 575 1212 x3936
Fax: 905 575 2011
________________________________________
From: open-ils-dev-bounces at list.georgialibraries.org [open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Dan Scott [dan at coffeecode.net]
Sent: June 12, 2012 4:49 PM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] commiting documentation changes from the branches of others into Evergreen repo

On Mon, Jun 11, 2012 at 01:49:04PM -0400, Soulliere, Robert wrote:
> Hi Developers,
>
> I have tested committing a change for the docs folder in the code
> repository. However I am a bit fuzzy on committing changes from the
> branches of other into the main repo. For example, bshum made did some
> asciidoc cleanup here:
>
> http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=af19fa6419e5328058338cada40b42a44b0522de
>
> and I want to merge the changes into the repo. I don't think the
> changes have been merged yet?

Actually, I think they were pushed to master, based on the shortlog at
http://git.evergreen-ils.org/?p=Evergreen.git;a=summary (or running "git
log" against a current copy of master).

It looks like you used "git merge" to merge Ben's branch into your copy
of the master repository, then committed the merge of that branch with
your own commit message of "Merge remote branch 'origin' into
documentation_test", then pushed your documentation_test branch to
master.

> What appropriate steps are used to make
> that happen? Do I need to set up my own working branch, merge bshum's
> changes into my branch and then merge my branch into the master repo,
> or can I merge bshum's branch directly into the master branch?

Generally, the process that we've been following for the code is to use
"git cherry-pick" to sign-off on each commit that we want to bring into
the master branch, rather than "git merge". As documented at
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git#guidelines_for_contributors
under the "Signing off on one or more commits" section, the process is
basically:

1. git checkout -b new_branch origin/master
2. git cherry-pick -s <commit-hash>
3. <test the changes to ensure docs still build>
4. git push origin new_branch:master

The main difference to note is the push to "origin" instead of
"working"; "origin" is where the canonical set of code lives. If you
want to push your branch out to the working repository so that others
can check your efforts first for things like proper sign-offs / comments
/ everything works, then you push to the "working" repo in your own user
directory -- e.g.

git push working new_branch:user/rsoulliere/new_branch

Also note that "new_branch" should be something meaningful, like
"dos_to_unix_linefeeds", so that a few months later if you're wondering
what the branch was for you don't have to wade through a bunch of
"quick_test" "fix_bug" generic branch names (speaking from experience
here!)

Also also note that when the docs get merged into the rel_2_2 branch, to
apply changes there you would checkout the new branch against
"origin/rel_2_2" instead of "origin/master" in step 1.

If you're ever feeling unsure about any of these steps, feel free to
throw questions at #evergreen - there's plenty of us who will be happy
to help you out!

> Also, I am concerned about keeping track of these branched changes to
> ensure that they do not slip through the cracks as we get more
> contributors. Is there a recommended strategy for keeping up with
> contribution branches.

I think this was mentioned elsewhere, but the best practice (again,
keeping in sync with what we're doing for code) is probably to file a
bug at http://bugs.launchpad.net/evergreen and tag it "documentation" so
that you can generate lists of doc bugs that have not yet made it to
"Fix committed" or "Fix released" status.

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message.  If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited.  If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.