Git workflow discussion

[Luke Kanies]

Hi all,

James pointed me to this great discussion on workflow around git:

http://kerneltrap.org/Linux/Git_Management

I've been slowly arriving at Linus's conclusion -- development always
happens in topic branches, and that development makes its way to the
"main" branches (e.g., master and 0.24.x) by having the branch
maintainer do the merge.

Also, topic branches could and should rebase against their original
branch, but the branch maintainer should never rebase.

For instance, I recently did some provider refactoring in the 0.24.x
branch, which James now maintains. What I should have done is this:

* branch 0.24.x
* do my development in the new branch
* if the 0.24.x branch has changed in the meantime, pull 0.24.x from
James and rebase against it
* publish my new branch (but *don't* merge it into 0.24.x) and ask
James to pull
* when I see the code has been merged by James, delete my topic branch

This way patches always flow from developers to maintainers, and
largely, the only one ever doing a merge is the maintainer.

Anyone opposed to trying this out?

For most people, I expect the only real differences would be that you
would never publish your own 0.24.x branch except as a duplicate of
James's, and you would periodically need to rebase your topic branch
against whatever you originally branched.

--
Tradition is what you resort to when you don't have the time or the
money to do it right. -- Kurt Herbert Alder
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

[James Turnbull]

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

Luke Kanies wrote:
| Anyone opposed to trying this out?
|
| For most people, I expect the only real differences would be that you
| would never publish your own 0.24.x branch except as a duplicate of
| James's, and you would periodically need to rebase your topic branch
| against whatever you originally branched.

This is my preference - the less work for me the better. :)

Regards

James Turnbull

- --
James Turnbull (ja...@lovedthanlost.net)

Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIM4A69hTGvAxC30ARAn6CAKCTpoPzFoyGyB4BByUFu6X/wOcSlQCeIbyn
kPscQSJswu5e+dNVMiuETws=
=uh6B
-----END PGP SIGNATURE-----

[Paul Lathrop]

+1

I think by complete accident this is the way I've been doing things :-)

[AJ]

/agree, I've also been doing it this way (where applicable)

[David Lutterkort]

On Tue, 2008-05-20 at 20:40 -0500, Luke Kanies wrote:
> Hi all,
>
> James pointed me to this great discussion on workflow around git:
>
> http://kerneltrap.org/Linux/Git_Management
>
> I've been slowly arriving at Linus's conclusion -- development always
> happens in topic branches, and that development makes its way to the
> "main" branches (e.g., master and 0.24.x) by having the branch
> maintainer do the merge.

I think that makes a lot of sense. In a similar vein, I promised on the
dev call last week to send out something about posting patches to the
mailing list.

In an effort to increase visibility and awareness of proposed patches,
code changes, and what's going on in the code base in general, I suggest
that all patches are sent to the puppet-dev mailing list. That will also
help Luke and James vet those patches, since there's more eyeballs on
them. While patches are currently kept in trac, I feel that that doesn't
give it as much visibility as a 'send patches to puppet-dev' process.

The process I envision is
* every patch that you want Luke/James to merge gets sent to
puppet-dev
* once the patch gathers a number of ACK's (and no NAK), Luke or
James will merge it into their offical branch. How many ACK's to
require is a matter of taste, I think getting one should be
enough for starters
* we might still want to track some info in Trac, i.e., have a bug
report open and move it through a few states as the patch gets
ACK's and is finally merged

Maybe we should just start with requiring this process only for the
stable branch; that would help James a lot I think, since he wouldn't be
the only one responsible when a bad patch gets merged ;)

That leaves us with the mechanics of the whole patch submission process,
and how to make that reasonably easy for Luke and James to track. Since
I am about as far from a proficient git user as you can get, I've been
trying to find some decent resources on how to do that on the LazyWeb.
The instructions for coreutils[1] and gnulib[2] look like they might be
a good starting point; at the end of the day, it boils down to

* Patch submitter creates patch on topic branch; when ready,
create actual patch with 'git format-patch --stdout --signoff
HEAD~1 > DIFF'
* Email that to puppet-dev, best if the patch is inline in the
message, not an attachment. Alternatively, mention where that
patch can be pulled from if you have a public git repo.
* Luke or James apply the patch with git-am

David

[1]
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD
[2] http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11269

[Paul Lathrop]

I could get behind this. Basically, we want to give more people the
opportunity to eyeball patches before they are merged?

--Paul

[Peter Meier]

Hi

> I could get behind this. Basically, we want to give more people the
> opportunity to eyeball patches before they are merged?

yeah. i support this proposal. I really like it how it works on the
et-mgmt-tools list @ redhat. You can really follow the development on a
list an discuss right now changes. I somehow feel it a lot more
comfortable than visiting trac.
As I'm also quite happy to have at least the bug-mails back :)

greets pete

[AJ]

I don't feel that using email for patch distribution is a good idea,
especially with a tool like Github.

I know it works for larger projects (like the Linux kernel, etc) and
also allows the 'Signed-off-by: ' stuff to work, but I don't feel Puppet
has the required amount of developers for this to be required yet.

I'm of the opinion that if you *want* to eyeball patches, you SHOULD be
capable of clicking a link
http://github.com/fujin/puppet/commit/20fe9037b5de577c577230f5aab6be41caa594e8,
and obviously in the absense of a web browser you're familiar enough
with Git to clone and checkout a branch.

My slightly surly 2c :)

Regards,

AJ

[Luke Kanies]

On May 22, 2008, at 5:32 PM, Peter Meier wrote:
> As I'm also quite happy to have at least the bug-mails back :)

Me too (although that's a lot of emails this week).

--
He played the king as if afraid someone else would play the ace.
--John Mason Brown

[Brian Finney]

As a non active (hopefully active in the future)
contributer/developer, I would find emailed patches very useful for
visibility into the code base and where things are going, and as a
nice carrot hanging out in front of me to hopefully motivate me to
contribute. Of course the usability of actual contributers is more
important. Perhaps a merge mailing list that automatically gets
emailed patches when merges happen on major branches if this doesn't
go through? (github probably has something I could subscribe to
though, I'll have to look into it)

Thanks
Brian

[Luke Kanies]

On May 22, 2008, at 6:38 PM, AJ wrote:

> I don't feel that using email for patch distribution is a good idea,
> especially with a tool like Github.
>
> I know it works for larger projects (like the Linux kernel, etc) and
> also allows the 'Signed-off-by: ' stuff to work, but I don't feel
> Puppet
> has the required amount of developers for this to be required yet.
>
> I'm of the opinion that if you *want* to eyeball patches, you SHOULD
> be
> capable of clicking a link
> http://github.com/fujin/puppet/commit/20fe9037b5de577c577230f5aab6be41caa594e8
> ,
> and obviously in the absense of a web browser you're familiar enough
> with Git to clone and checkout a branch.

I'm kind of two minds about this.

On the one hand, I'm having a hard time seeing exactly how it would
work, at least in terms of using email to manage the patch queues.

On the other hand, David is clearly right that we need more people
looking at the code, and this might be a good way to do it. Further,
the -dev list is largely fallow, and this could go a long way toward
getting more conversation going on the list, and the conversation
might even -- crazy crazy! -- be about code.

I think we might as well try it. Even if it's not used to actually
approve patches, it would hopefully be a useful way to get more people
looking at the code and commenting on it.

--
All power corrupts, but we need the electricity.
-- Unknown

[James Turnbull]

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

Luke Kanies wrote:
>
> I'm kind of two minds about this.
>
> On the one hand, I'm having a hard time seeing exactly how it would
> work, at least in terms of using email to manage the patch queues.
>
> On the other hand, David is clearly right that we need more people
> looking at the code, and this might be a good way to do it. Further,
> the -dev list is largely fallow, and this could go a long way toward
> getting more conversation going on the list, and the conversation
> might even -- crazy crazy! -- be about code.
>
> I think we might as well try it. Even if it's not used to actually
> approve patches, it would hopefully be a useful way to get more people
> looking at the code and commenting on it.
>

I like the idea personally - mostly because I want to feel somewhat
confident that patches - some of which I don't understand as well as I
could or pertain to type/providers that I don't use - are at least
partially reviewed. I find having the patch in your face in your email
seems to make people look more closely.

Obviously there are some issues here with work flow that I am going to
try to work through shortly and document.

One issue is of course that Trac relies on local repositories and my
primary is currently GitHub. We might need to rethink that.

Cheers

James

- --
James Turnbull (ja...@lovedthanlost.net)
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINo0P9hTGvAxC30ARAu8wAKCA1zKnoARrEBHq3MMByUAZZc4rdQCgiDlT
Sfpo0uRYQUgptfIB8tjoABQ=
=vwVl
-----END PGP SIGNATURE-----

[Ramon van Alteren]

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

James Turnbull wrote:
| One issue is of course that Trac relies on local repositories and my
| primary is currently GitHub. We might need to rethink that.

What is the problem ?
Syncing a local git against github is fairly trivial, git being
distributed ensures you have full information on trac wrt branches etc.

Since trac | gitplugin doesn't support multiple repositories, you'd need
to pick a single git repository for the trac-integration anyway.

Or is the issue somewhere else ?

Ramon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg2oywACgkQwiVM6CtDHQ25IACfVw70EgHqqP2g/DiLbuZjDs34
XBoAniqEU6Kz7nJZSUsVRKSHd3Nih7E4
=boZQ
-----END PGP SIGNATURE-----

[James Turnbull]

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

Ramon van Alteren wrote:
> James Turnbull wrote:
> | One issue is of course that Trac relies on local repositories and my
> | primary is currently GitHub. We might need to rethink that.
>
> What is the problem ?
> Syncing a local git against github is fairly trivial, git being
> distributed ensures you have full information on trac wrt branches etc.
>
> Since trac | gitplugin doesn't support multiple repositories, you'd need
> to pick a single git repository for the trac-integration anyway.
>
> Or is the issue somewhere else ?

I don't like the risk of sync issues to be honest - but this might be
reaction to recent events - which again might be triggered by a lack of
knowledge about where the repo is located. My comment was more that it
might be better for me to push to the master repo at madstop.com rather
than a github repo.

Regards

James Turnbull

- --
James Turnbull (ja...@lovedthanlost.net)
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINqUF9hTGvAxC30ARAlmhAKCeateRq/lHAdQZNTrGZPl2GhNPWgCfY2Te
qyeAEFjoDc0JrkI2Awi0fsY=
=ztp5
-----END PGP SIGNATURE-----

[David Schmitt]

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

On Friday 23 May 2008, James Turnbull wrote:
> > I think we might as well try it. Even if it's not used to actually
> > approve patches, it would hopefully be a useful way to get more people
> > looking at the code and commenting on it.
>
> I like the idea personally - mostly because I want to feel somewhat
> confident that patches - some of which I don't understand as well as I
> could or pertain to type/providers that I don't use - are at least
> partially reviewed. I find having the patch in your face in your email
> seems to make people look more closely.

+1

Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINrS6/Pp1N6Uzh0URAnRxAJsEEB0MyPP7jBD45Lu9xPBWWkPLyQCfWru8
6LVMmVcE6ikrlN5ohcPNYBw=
=50H7
-----END PGP SIGNATURE-----

[David Schmitt]

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

On Friday 23 May 2008, James Turnbull wrote:

> I don't like the risk of sync issues to be honest - but this might be
> reaction to recent events - which again might be triggered by a lack of
> knowledge about where the repo is located. My comment was more that it
> might be better for me to push to the master repo at madstop.com rather
> than a github repo.

Without knowing the details of this "recent event", my understanding of the
git basics is that you should be always able to push to a branch as long as
it has not changed since you last pulled from there. So I presume, iff the
trac repo is push-only and each branch has a single maintainer there should
be no _technical_ problems ...

Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINrV7/Pp1N6Uzh0URAvb6AKCMsG+/k3mKmpzDdhXtSR6GAU53JwCfX6BP
lqywvTthFE4zblaEiXYsWkc=
=5Ztq
-----END PGP SIGNATURE-----

[The Anarcat]

On Thu, May 22, 2008 at 06:38:12PM -0700, Brian Finney wrote:
>
> As a non active (hopefully active in the future)
> contributer/developer, I would find emailed patches very useful for
> visibility into the code base and where things are going, and as a
> nice carrot hanging out in front of me to hopefully motivate me to
> contribute. Of course the usability of actual contributers is more
> important. Perhaps a merge mailing list that automatically gets
> emailed patches when merges happen on major branches if this doesn't
> go through? (github probably has something I could subscribe to
> though, I'll have to look into it)

For me that's the best solution: having a -commits mailing list that
gets all the commits done on the master branches will ensure maximum
peer review of the actual master code, the one that matters.

Branch maintainers still have the duty to actually review the topical
branches before they merge so I'm not sure it's relevant to share those
"proposed patches" with everyone, unless we want to distribute the task
of reviewing proposed patches to the master branches.

In the case, the same process could be follow: hooks in topical
repositories would send mail to -commit@ on push.

In general, it would be important to have tags in the commitmail saying
what the patch applies to: a topical branch (and which(, a "stable" master branch,
the "next release" master branch, etc.

A.

--
Information is not knowledge
Knowledge is not wisdom
Wisdom is not truth
- Frank Zappa

[Luke Kanies]

That's a good point -- another option is to just extend the -commits
list so that everyone posts their commits to it, rather than just the
commits sent to the master repo.

Anyone want to set up a commit hook for github that would make this
easy?

--
To my embarrassment I was born in bed with a lady.
--Wilson Mizner

[Adam Jacob]

I'm on this.

Adam

--
HJK Solutions - We Launch Startups - http://www.hjksolutions.com
Adam Jacob, Senior Partner
T: (206) 508-4759 E: ad...@hjksolutions.com

[James Turnbull]

Luke Kanies wrote:
> On May 23, 2008, at 7:42 AM, The Anarcat wrote:
>
>> Branch maintainers still have the duty to actually review the topical
>> branches before they merge so I'm not sure it's relevant to share
>> those
>> "proposed patches" with everyone, unless we want to distribute the
>> task
>> of reviewing proposed patches to the master branches.

I think we want broad ranging feedback - especially given the
multi-platform nature of Puppet. Obviously not every patch is going get
comment and ultimate accountability for this rests with Luke and/or me
but I think it's a good model. It at least makes the development
process somewhat more transparent and hopefully encourages discussion
and debate.

>> In the case, the same process could be follow: hooks in topical
>> repositories would send mail to -commit@ on push.
>>
>> In general, it would be important to have tags in the commitmail
>> saying
>> what the patch applies to: a topical branch (and which(, a "stable"
>> master branch,
>> the "next release" master branch, etc.

+1

> That's a good point -- another option is to just extend the -commits
> list so that everyone posts their commits to it, rather than just the
> commits sent to the master repo.
>
> Anyone want to set up a commit hook for github that would make this
> easy?

This would be my preferred approach.

Again - I will document this workflow with some pretty pictures sometime
today and post a link here.

Regards

James Turnbull

[Adam Jacob]

On Fri, May 23, 2008 at 3:54 PM, James Turnbull <ja...@lovedthanlost.net> wrote:
> This would be my preferred approach.
>
> Again - I will document this workflow with some pretty pictures sometime
> today and post a link here.

Let me know if you would like more functionality out of the email
commit bot. I talked with the #github folks, and learned how to get
the raw diffs from the commit URLs. If you want them as patches, or
inline, either are pretty trivial.

Adam

[James Turnbull]

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

Adam Jacob wrote:
> On Fri, May 23, 2008 at 3:54 PM, James Turnbull <ja...@lovedthanlost.net> wrote:
>> This would be my preferred approach.
>>
>> Again - I will document this workflow with some pretty pictures sometime
>> today and post a link here.
>
> Let me know if you would like more functionality out of the email
> commit bot. I talked with the #github folks, and learned how to get
> the raw diffs from the commit URLs. If you want them as patches, or
> inline, either are pretty trivial.

Hmmm let's try inline.

Regards

James Turnbull

- --

James Turnbull (ja...@lovedthanlost.net)
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIN7Yi9hTGvAxC30ARArVYAJ9m5l2Z+HHEuwslJeHyO/+VoepDRgCgxaHD
SoD/t1AVY6r88a/FjONd/zI=
=ep2/
-----END PGP SIGNATURE-----

[Peter Meier]

Hi

>>> Again - I will document this workflow with some pretty pictures sometime
>>> today and post a link here.
>> Let me know if you would like more functionality out of the email
>> commit bot. I talked with the #github folks, and learned how to get
>> the raw diffs from the commit URLs. If you want them as patches, or
>> inline, either are pretty trivial.
>
> Hmmm let's try inline.

+1

thanks a lot for your work!

greets pete

[Luke Kanies]

On May 24, 2008, at 1:06 AM, Adam Jacob wrote:

>
> On Fri, May 23, 2008 at 3:54 PM, James Turnbull <ja...@lovedthanlost.net
> > wrote:
>> This would be my preferred approach.
>>
>> Again - I will document this workflow with some pretty pictures
>> sometime
>> today and post a link here.
>
> Let me know if you would like more functionality out of the email
> commit bot. I talked with the #github folks, and learned how to get
> the raw diffs from the commit URLs. If you want them as patches, or
> inline, either are pretty trivial.

I agree with James, I'd like them inline, and as my other email said,
I'd prefer the subject of the email be the first line of the commit log.

Git seems to consistently use the first line of a commit log as a
summary of the commit, so I've been trying to consistently provide a
short, helpful first line, and then a more detailed log below if
necessary.

Thanks for setting this up.

--
The easiest way to figure the cost of living is to take your income and
add ten percent.

[Adam Jacob]

On Sat, May 24, 2008 at 10:41 AM, Luke Kanies <lu...@madstop.com> wrote:
> I agree with James, I'd like them inline, and as my other email said,
> I'd prefer the subject of the email be the first line of the commit log.

Done and done.

> Git seems to consistently use the first line of a commit log as a
> summary of the commit, so I've been trying to consistently provide a
> short, helpful first line, and then a more detailed log below if
> necessary.
>
> Thanks for setting this up.

No problem.

[David Lutterkort]

On Fri, 2008-05-23 at 08:42 -0400, The Anarcat wrote:
> In the case, the same process could be follow: hooks in topical
> repositories would send mail to -commit@ on push.

I don't believe that that will achieve much .. it won't increase
discussions around the code. People will just look at that list as a
FYI, and then go on there merry way. I'd wager money that there won't be
more than two non-commit mails per month on that list. Of course,
there's nothing wrong with a commit list.

Sending patches to the dev list and requiring ACK's on the list _before_
commit gives you much more active participation. Part of what I was
suggesting was to have livelier discussions around the actual code,
which isn't happening right now.

David

[James Turnbull]

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

What David said - I'd be happy to see it go to both. Though on the
ACK's I am going to assume that if people don't ACK within x timeframe
that indicates they accept the patch.

Regards

James Turnbull

- --
James Turnbull (ja...@lovedthanlost.net)
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIOQ9z9hTGvAxC30ARAvNNAKC9dYRugc1lq5toANebeIb67BBVAwCgpViH
nTyJqpMG6YQK9VK/fE8YYww=
=J8+H
-----END PGP SIGNATURE-----

[Luke Kanies]

On May 25, 2008, at 2:04 AM, James Turnbull wrote:
>
> David Lutterkort wrote:
>>
>> On Fri, 2008-05-23 at 08:42 -0400, The Anarcat wrote:
>>> In the case, the same process could be follow: hooks in topical
>>> repositories would send mail to -commit@ on push.
>>
>> I don't believe that that will achieve much .. it won't increase
>> discussions around the code. People will just look at that list as a
>> FYI, and then go on there merry way. I'd wager money that there
>> won't be
>> more than two non-commit mails per month on that list. Of course,
>> there's nothing wrong with a commit list.
>>
>> Sending patches to the dev list and requiring ACK's on the list
>> _before_
>> commit gives you much more active participation. Part of what I was
>> suggesting was to have livelier discussions around the actual code,
>> which isn't happening right now.
>
> What David said - I'd be happy to see it go to both. Though on the
> ACK's I am going to assume that if people don't ACK within x timeframe
> that indicates they accept the patch.

There's also a difference between commits to personal repositories and
commits to the master repos.

I like having commit notices for all repositories, but I agree with
David that they won't automatically result in conversation about the
patches.

At this point, I'd prefer to stick with everyone setting up commits
for their personal repositories, but then when a commit is being
considered for merging, it should be sent to -dev.

I'm still a bit unclear on what the actual development process will
look like, WRT people sending patches to -dev, but I guess we'll just
have to sort it out as we go.

--
The big thieves hang the little ones. -- Czech Proverb

[Peter Meier]

Hi

> At this point, I'd prefer to stick with everyone setting up commits
> for their personal repositories, but then when a commit is being
> considered for merging, it should be sent to -dev.

I like this idea. So everybody who wants to get the important changes
won't have the noice on the -commit list. As well it might get more
discussed there.

greets pete

[hajd...@gmail.com]

Apologies for bringing up this old thread but being rather new to git
and this community, I don't want to step on any toes - but does anyone
have a solid example of their typical git workflow?

My typical workflow and setup ( for facter ) at the moment is:

Setup -
- Clone lak's git repo of facter
- Branch to my own dev branch

Reoccuring:
- Checkout my branch. Branch from my branch into appropriate topic
branch (facter_ver/ticket_####) and check that out.
- Work on ticket, test, commit to topic branch
- Merge ticket back into my dev branch
- Rebase my dev branch
- Push my dev branch up to github

Is this preferrable? Or should I just skip the part of having my own
dev branch, branch off the master for each topic branch and then push
each topic branch up to my github repo for the maintainer's to pull
from?

I've just been testing this out, so I haven't setup the commit hooks,
emails and such, but any peeks into what other developers' workflows
look like would be appreciated.

Thanks -

-
sh

[Luke Kanies]

On Jun 16, 2008, at 4:12 PM, hajd...@gmail.com wrote:

>
> Apologies for bringing up this old thread but being rather new to git
> and this community, I don't want to step on any toes - but does anyone
> have a solid example of their typical git workflow?
>
> My typical workflow and setup ( for facter ) at the moment is:
>
> Setup -
> - Clone lak's git repo of facter
> - Branch to my own dev branch
>
> Reoccuring:
> - Checkout my branch. Branch from my branch into appropriate topic
> branch (facter_ver/ticket_####) and check that out.
> - Work on ticket, test, commit to topic branch
> - Merge ticket back into my dev branch
> - Rebase my dev branch
> - Push my dev branch up to github
>
> Is this preferrable? Or should I just skip the part of having my own
> dev branch, branch off the master for each topic branch and then push
> each topic branch up to my github repo for the maintainer's to pull
> from?

I recommend directly branching off of the main branch each time,
either master or 0.24.x depending on what you're working on.

Then you're only pushing individual topic branches, so we can assess
each commit set separately. It might be that some of your commits
need further work while others are directly mergeable; in that case,
we need to be able to pick and choose, and if you publish them all in
one piece, all we can do is cherry-pick.

That's basically what my workflow looks like. If I know what I'm
doing when I start (e.g., fixing bug #1232), I do this:

$ git checkout 0.24.x
$ git checkout -b tickets/0.24.x/1232
... do work ...
... run tests ...
$ git commit -a
$ git push luke tickets/0.24.x/1232
$ git-format-patch -C -M -s -n 0.24.x..HEAD
$ git send-email --no-chain-reply-to --no-signed-off-by-cc --suppress-
from --no-thread --to puppe...@googlegroups.com 00*.patch
$ rm 00*

If I don't know what I'm doing yet, then I skip the separate branch
until I do. I'll just directly edit stuff until I have enough to make
a ticket or know whether I'm making a new feature or whatever; then I
branch et al.

One great thing about git is that as you switch branches (e.g., from
0.24.x to your new topic branch) it will apply your uncommitted
changes to the next branch, so you can safely edit in the main branch,
as long as you don't commit there.

Another useful trick is 'git reset' -- I have recently been using it
to make temporary commits (essentially long-lived versions of 'git
stash'), with something like 'REVERT THIS' in the commit msg. Then,
when I go back to work on that banch, I just do 'git reset ^HEAD' (or,
if necessary, reset to the specific previous commit). This makes it
easy to store state in a branch and get back to it later. A similar
technique makes it easy to commit, then branch, and then rewind the
csource branch.

I'm glad to elaborate if you're interested.

--
The remarkable thing about Shakespeare is that he really is very good,
in spite of all the people who say he is very good. -- Robert Graves

[Andrew Shafer]

I like pictures.
http://osteele.com/archives/2008/05/my-git-workflow
http://osteele.com/archives/2008/05/commit-policies

I've only been using git for about 6 months and really only for about 3.
I thought these two articles gave me the reference point I needed to
map out more of how the git thing works in my mind.

Might be useful for you.

[Luke Kanies]

On Jun 16, 2008, at 5:15 PM, Luke Kanies wrote:

> That's basically what my workflow looks like. If I know what I'm
> doing when I start (e.g., fixing bug #1232), I do this:
>
> $ git checkout 0.24.x
> $ git checkout -b tickets/0.24.x/1232
> ... do work ...
> ... run tests ...
> $ git commit -a
> $ git push luke tickets/0.24.x/1232
> $ git-format-patch -C -M -s -n 0.24.x..HEAD
> $ git send-email --no-chain-reply-to --no-signed-off-by-cc --
> suppress-from --no-thread --to puppe...@googlegroups.com 00*.patch
> $ rm 00*

The only bits I forgot are what I do when the branch has been merged:

$ git checkout 0.24.x
$ # pull latest from James
$ git pull # I've got 0.24.x set up as a tracking branch of James's
branch
$ # Delete my local branch
$ git branch -d tickets/0.24.x/1232
$ # Delete the local branch

$ git push luke :tickets/0.24.x/1232

Note that you should *always* use '-d' here (rather than '-D'), and I
recommend always deleting the local branch first. 'git branch -d'
will fail unless the branch you're deleting has been merged into the
current branch, so it's an easy way to figure out whether it's safe to
delete that branch.

Note also the ':' in the push statement above -- that's what removes
the remote branch.

--
There are three kinds of death in this world. There's heart death,
there's brain death, and there's being off the network. -- Guy Almes