8 Commits (835a87aed2478ee441f2dbfab15124315ddd880a)

Author	SHA1	Message	Date
Zach Loafman	e4b613b514	Infer the URL from the existing git setup. (I don't push via ssh) ... Also document using the recursive/ours merge strategy, because it's almost certainly what we want to do in this case.	2015-04-02 10:15:18 -07:00
Eric Paris	e9d2c49fd4	Instructions to back-merge release branches into master ... This allows us to continue on branched like v0.14.1, v0.14.2, and tag on that branch. But it will merge those tags into master so git describe picks up the changes.	2015-03-30 17:31:15 -04:00
Eric Paris	a5732697fd	update instructions to make it clear to get review	2015-03-30 15:10:34 -04:00
Eric Paris	329f9a0e99	Do not allow minor release which is not a decendant of the release branch ... This does some git magic to make sure you do not tag a branch with v0.13.3 unless that branch is a decendant of the release-0.13 branch upstream. Don't allow v0.13.4 if v0.13.3 doesn't exit Don't allow v0.13.3 if v0.13.3 already exits	2015-03-27 21:24:10 -04:00
Eric Paris	cbefaf5d65	output current_branch name instead of HEAD in help messages	2015-03-27 19:03:42 -04:00
Eric Paris	2b941f4954	anchor version regex ... Also create a GIT_MINOR variable for a touch of readability....	2015-03-27 18:54:36 -04:00
Eric Paris	3919a38ad6	make mark-new-release.sh do branching and tell you exactly what to do next ... We keep getting tags and branches wonky. This will land v0.14.0 as an ancestor of master v0.14.1 will NOT be an ancestor of master I can do the later, it only a touch of git gymnastics, not really hard, but we only occasionably do that today. (0.13.1 is an ancestor of master, but 0.13.2 is not)	2015-03-27 17:01:56 -05:00
Joe Beda	35313c605c	Script to help mark new versions	2014-11-24 12:24:29 -08:00