accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [git] Documentation and Plan of Action
Date Thu, 13 Jun 2013 02:59:17 GMT
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
> 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?

View raw message