[quagga-dev 11716] Re: [PATCH 1/6] Buggy Unlock in ospfd/ospf_opaque.c
gdt at ir.bbn.com
Mon Nov 3 00:29:04 GMT 2014
Olivier Dugeon <olivier.dugeon at orange.com> writes:
> First, I clone Quagga with 'bare' option with the command like
> explain on GitHub help page.
> git clone --bare http://git.savannah.gnu.org/r/quagga.git
> And them push it on GitHub with the 'mirror' option with the command
> git push --mirror https://github.com/Orange-OpenSource/
I see, so you do have the entire history.
> Once the repo is online, I apply my TE modification, but as a
> monolithic patch and submit this first version to Quagga mailing
> list. As suggested by Feng Lu, I split this monolithic patch into 6
> patches. But, this time, loose the detail on my repo on GitHub.
My preference (but I'm not really the one with time to review and merge)
is that the commits for your work be similar in style to what you would
commit to master if you had commit access. The great thing about git is
that it separates ability to prepare changes with authority to push the
I really don't understand "lose the detail".
> So, now, as suggested by David, I will restart all the process once
> removing my Quagga-TE repository on GitHub. Now, my question concern
> the first steps as I see different options:
> 1/ Make a full 'bare' clone of Quagga repo like I did previously,
> but I don't need all details of original Quagga repo (like the
> different branch)
I don't think it matters if the other branches are there. But I don't
see why you would try to avoid it.
> 2/ Make a simple clone of Quagga master branch only
> And, once my Quagga-TE repo will be setup, do I apply my TE patches
> 3/ master branch
> 4/ on a dedicated branch
My view on best practices is that each logical group of changes is on a
separate branch, as they would be if everyone were working in a single
shared repo and pushing work in progress prior to actually merging. In
a project I worked on with 20 people, all of whom had the *ability* (but
not permission) to write to master, the convention was that feature
branches based on master would be prepared, and after code review and
merge approval actually merged.
Part of the reason I suggest a separate branch is that I find it really
helpful to reduce confusion if people's clones of the repo has their
master equal to the official master. Also, if you update and your
master is behind, then you can update it, and then rebase and force push
your feature branch.
Sorry if this is too much git process flamage....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 180 bytes
Desc: not available
More information about the Quagga-dev