Is it my fault that git was so badly designed it requires perfect humans to
use "properly"? Clearly a lot more thought about its usability should have been
gone into the design of branches. They are a really useful concept but
something about them has turned them into unusable hairballs. Even freaking
saws that nobody works on has 40 branches at bitbucket while petsc has 99+
(what does the + means, it might have 400?)*. But bitbucket shows them in a
dinky window that can display 7 at at time with the only information displayed
is their name: how about displaying their current status in some reasonable
way. This is absurd, git/bitbucket/something needs some far better mechanism to
track and mange branches then just having a big freaking list of (mostly)
meaningless crap plus some useful stuff that is lost in the mass.
branches have purposes but there doesn't seem to be a way to properly
indicate this. When created each branch should at a minimum know where it came
from, have a purpose the user can type in and a plan for where it is intended
and if it is intended as a one time fix etc and that should not all be encoded
in the branch name.
For example:
root branch purpose intended
destination planned lifetime
Current status
maint fix error in spelling of Jed's name maint, next,
master until put into maint and master
merged into next
master add cool new feature next, master
keep around for bug fixes since Barry is a crappy coder
previous cut merged into next, new stuff added not yet merged into next
barry/saws try a new feature with saws barry/saws
until put into barry/saws
new stuff in there not merged into barry/saws.
Barry
* and don't say, this is just because you haven't cleaned them up recently and
go "clean them up". They should be managed properly by the system and not
require "cleaning up" by a git guru.
On Oct 6, 2013, at 9:06 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes:
>> If someone "fixed" a branch like this why won't they merge it into
>> master or next? Likely because they "forgot" that step? If this is
>> the case then I will point out yet again this is a flaw with the
>> tool, not the person. Any software that assumes and requires the
>> user do the right thing every time is crap software. If a branch is
>> already merged into next or master is there some way when a person
>> does a commit on the branch in the future it asks or reminds them
>> if they want to merge into next or master, i.e. reminds them right
>> there and then what they should do?
>
> How do we decide this programmatically? That is, how do we distinguish
> between a new branch starting from 'master' and one that has already
> been merged?
>
> If "git merge-base master HEAD" is not a first-parent ancestor of
> 'master', then something in our history was merged back to 'master'.
> This does not distinguish:
>
> 1. 'alice/prereq' starts from 'master' and merges into 'next'
> 2. 'bob/enhancement' starts from 'alice/prereq'
> 3. 'alice/prereq' graduates to 'master'
> 4. Is Bob's next commit a "bug-fix" or just unmerged work?
>
