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
On 06/12/2013 10:45 PM, David Medinets wrote:
> It troubles me that we are referring to the master branch as unstable.
> While we are not following the dictums of Agile methodology it is clear to
> me that the master branch should always be potentially releasable. It is
> not a dumping ground for untested features or half-complete code.
This is a matter of opinion on what the contents of master should be.
The (public) opinion up until this point has been to just keep master
unstable. TBH, I could go either way.
> If something is incomplete, leave it in a branch. If you want to
> collaborate, create a github project and form a team. Only when the code is
> fully baked, merge it into the master.
> The SHA1 value of a change tracks it across all branches. No need to
> perform no-op merges. Simply check the branch history to see it contains
> the SHA1 hash you're interested in.
That... isn't really how Git is meant to work. The parent of a commit is
important and uniquely identifies a commit. In other words, the tree in
which a commit falls identifies the changes which that commit
introduces. Things break down when you try to circumvent this. See also
my other comment about how we currently perform SVN merges (`cd
accumulo-1.y && svn merge -r 1:HEAD 1.x .`)
> I found the 'git show-graph' alias at
> http://gitready.com/intermediate/2009/01/26/text-based-graph.html to be
> helpful. Simply 'git show-graph | grep <sha1>' to easily find out if one
> change is included in a branch.
See also, `git branch --contains SHA1`
> If managing the releases inside one git repository seems prone to
> complications, create a separate repository for each release. After all,
> post-release there really should be only bug fixes.
Forcing separate repositories for each release sounds like a terrible
idea. You'd be segmenting every single Accumulo release into its own
series of disjoint changes. 1.4.3 would have no common parent to 1.4.2,
which would have no common parent to 1.4.1. This would destroy the
linear progress that, over time, any actively developed software project

Am I misinterpreting what you're saying?