Branching and submitting a bugfix to Bitbucket

[James Perrin]

Hi,

I've outlined the steps (and commands) that as far as I understand are
necessary to submit a bug fix. For now I'm just focused on the applying
stuff to the 1.4.1 branch. Hopefully those you are wiser in these things
than me will point out any errors and we can use this as basis to get
committers committing again.


1. Local: Clone repo
git clone g...@bitbucket.org:opencast-community/matterhorn.git
cd matterhorn

2. Local: Create branch and swap to it
git checkout -b b/MH-1234-short-descrip r/1.4.1

3. Local: Fix problem and commit code to local branch
git add foo/bar.java
git commit -m "MH-1234, fixed typo" foo/bar.java

4. Local: Push branch to Bitbucket
git push -u origin b/MH-1234-short-descrip

* You can do this before you have any code committed but it doesn't show
up in Bitbucket until you do

5. Local: Optional commit and push further changes to the branch
git add foo/bar2.java
git commit -m "MH-1234, fixed yet another typo" foo/bar2.java
git push

6. Bitbucket: Create pull request
https://bitbucket.org/opencast-community/matterhorn
Top right "Branch" button

Select b/MH-1234-short-descrip branch on the left and the r/1.4.1 on the
right

Add title: "MH-1234, fixed all the typos"

Reviewers: Greg Logan (for some reason it searches every bitbucket user
not just those in the Team)

Close branch?

7 JIRA: Add the pull request to the ticket MH-1234:

https://bitbucket.org/opencast-community/matterhorn/pull-request/1234/mh-1234-fixed-yet-another-typo

Resolve as Fixed Needs Review and assign to Greg Logan.



Regards
James


--
------------------------------------------------------------------------
James S. Perrin

Media Technologies Team
Devonshire House, University Precinct
The University of Manchester
Oxford Road, Manchester, M13 9PL

t: +44 (0) 161 275 6945
e: james....@manchester.ac.uk
w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
"The test of intellect is the refusal to belabour the obvious"
- Alfred Bester
------------------------------------------------------------------------

[Logan, Greg]

While I am by no means a git master, I think you are on the right track. My impression was that the prefix for tickets was t, so t/MH-1234-short-descrip, but that is very minor. Closing the branch is something I think I have to do, since the changes need to be merged in before you can close it. I am fine doing that, or assuming the initial author will do it when I resolve the ticket as fixed and reviewed.

In terms of repos, I assumed that we were to fork the mainline repo and then work in there. I already have a number of branches in progress in my fork (mainly old patchsets). We should perhaps decide what we as a project-wide policy in the near future :)

Otherwise, your commands and workflow look just right to me!

G
________________________________________
From: James Perrin [james.s...@manchester.ac.uk]
Sent: Wednesday, October 23, 2013 5:05 AM
To: Matterhorn Dev
Subject: [Matterhorn] Branching and submitting a bugfix to Bitbucket

--
You received this message because you are subscribed to the Google Groups "Matterhorn" group.
To unsubscribe from this group and stop receiving emails from it, send an email to matterhorn+...@opencast.org.
To post to this group, send email to matte...@opencast.org.
Visit this group at http://groups.google.com/a/opencast.org/group/matterhorn/.

[James S Perrin]

Hi,

Thanks for the feedback Greg. I looked at Lars' branches as assumed they
were for tasks as I've still not found where the pattern was initially
suggested

When you create a pull request there is an option to close the branch
once the it has been merged so in theory bitbucket will do it
automatically for you.

The main reason to fork a repo is if "you" don't have write permissions
on the main repo and want to make your changes public. Cloning should be
fine especially for bug fixing but it may be done to an individual's
preferred work flow. Anyway both seem to work.

I would recommend people create their own test repo (or fork mh) and
play around with it as you can screw it up without fear and also see the
see what happens after you make a pull request.

Regards
James

[Benjamin Wulff]

Hi Greg,

On 23.10.2013 19:51, Logan, Greg wrote:
> We should perhaps decide what we as a project-wide policy in the near future :)
>

you are so right. So, let's get to it.

I've put up a repo on BB that maily has a Wiki in which we can write
those processes down. I intent to track the discussions about Git and BB
and collect the results in this Wiki. It is called 'Opencast Developer's
Corner'

https://bitbucket.org/opencast-community/opencast-developers-corner

There are sections for different groups of people (committers, release
manager, contributors etc.) that provide a list of how-to-like items
(first three of them already have some content) that will explain
shortly how to achieve a certain goal and that should, in every chase,
provide examples.

I'm working on filling the existing topics with content will care for
keeping the Wiki updated. However, everyone that is in on our BitBucket
account can edit the Wiki and is invited to do so. Also the repo itself
is open for everybody on our BB team account. It is intended to be used
as a sandbox for providing examples and experimenting with Git so feel
free to try anything.

Regards,
Ben

PS: I didn't start this as a section in the Opencast Wiki because I
wanted to have all people that are currently working with our team
account to have write access to the Wiki. We can import the pages later
into Confluence.