Here's the way I have been doing it ... Branches other than "master" and "unstable" are development branches, personal versions, experimental versions or whatever. In that sense, all are welcome.
When a branch is ready for merge, I do these steps. First, I rebase to the current unstable. This pushes the branch history to the top, so I can see it relative to what is in master or unstable now. In some cases, it won't rebase, so I try to fix it. Note that this is "rebase", not "merge". Merge leaves history scattered and hard to trace. Rebase puts the branch history all together. After rebase, git won't allow a commit back to the same branch. It's "not an ancestor", so I make a new one. That's what the -1, -2. -3 .. branches are. Git would merge after a pull, but then history is there twice, and mingled again, so I don't do that. Then it's test, test, test .. possibly fix stuff. When ready to merge .. It must be able to qualify for a "fast-forward" merge into unstable, but I merge it with "--no-ff" to make a hierarchical log entry. This way, I can see either a consolidated or detailed history. Then it sits in unstable a few weeks waiting for complaints, and other merges that may follow in short time. Then, if it's good, it goes to "master" and gets a date tag. So this can be "considered stable" and is the version most people should use. One git issue that still needs a fix is updating the $Id$ tag in files. I have been doing it manually, and forgetting sometimes. When Gnucap was using RCS instead of GIT, RCS took care of that automatically. I still miss that feature of RCS, but there is no going back. Also ... "make checkin" updates patchlev.h then does "git commit", so the checked in version will identify itself on signon. There's also "make date" that updates patchlev.h. The file name patchlev.h goes back to the days "shar" and "patch" files on news groups like comp.sources.unix and alt.sources. Back in the day, that's how free software was distributed. A lot has changed since then, but we still keep some of the legacy. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
