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?
pgp8ZJ6O2vRgE.pgp
Description: PGP signature
