gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] git usage, branches and how things finally make it into t


From: al davis
Subject: [Gnucap-devel] git usage, branches and how things finally make it into the master.
Date: Fri, 12 Aug 2016 19:23:15 -0400

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]