Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - [git] Documentation and Plan of Action


Copy link to this message
-
Re: [git] Documentation and Plan of Action
Corey Nolet 2013-06-13, 20:26
I finally got a chance to read this as well. Thanks again Josh for
writing/maintaining this!

For the contributor workflow, I've always tried to avoid using "commit -a"
but instead use "git status" and separately stage files for commit with
"git add <directory> or <file>". I've seen people commit strange things by
accident and not notice until its too late. It's also easy to unstage items
before the commit is made so I may just be being picky.

In reference to the master being "stable". I've often seen projects use a
"master" and "next" branches where master is considered stable and "next"
is the unstable next-gen development branch. I've also seen groups do the
opposite and use "stable" and "master" where master is the unstable
next-gen development branch. As Chris pointed out, it seems like a semantic
argument and I'm partial to either one.

To John's point, I assumed since we were using the jira git plugin that
we'd be able to mark the ticket in the commit but it would be nice to note
this in the workflow somewhere.

On Thu, Jun 13, 2013 at 1:55 PM, John Vines <[EMAIL PROTECTED]> wrote:

> In my git work, there's git integration and we ref tickets in commits. Just
> starting with ticket-number and then I can do #comment to add comments, as
> well as #resolve to automatically resolve the issue, etc. But I think that
> latter one isn't as important since it sounds like there will be a lot of
> merging going on
>
>
> On Thu, Jun 13, 2013 at 1:49 PM, Christopher <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jun 13, 2013 at 1:36 PM, John Vines <[EMAIL PROTECTED]> wrote:
> > > Finally read through all of this.
> > > First of all, great work Josh.
> >
> > +42
> >
> > [snip]
> > > I'm happy with the email subject. I'm assuming we're sticking with all
> > > commits reffing a ticket? Or at least all commits to the main
> branch(es).
> > [snip]
> >
> > If you're going to squash them, it would just be the squashed commit
> > where this would be needed, I would think.
> >
> > This also raises an interesting question: how does the JIRA
> > integration work for git? Would it just add comments corresponding to
> > commits pushed to master? Or would it track all commits pushed to any
> > branch? If it tracks all commits pushed to any branch, you may want to
> > reference the JIRA issue in every commit... unless you don't want/need
> > that much verbosity on the ticket. Then, I suppose you could just do
> > one reference when you merge/squash.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>