[petsc-dev] v3.5 release schedule

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131006/6251a5b7/attachment.sig>