Zsh Mailing List Archive
Messages sorted by:
Re: Next release
Peter Stephenson wrote:
> Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
> That message seems to be mostly about branch structure which isn't
> really relevant to us; our case is much simpler. Obviously the ease of
> people having their own private areas without reference to the main
> repository is a big gain, but that's up to them.
FVWM is pretty much in maintenance-only mode for a while now, so that
mail was merely to show possible development models, which might be a
helpful insight given that not everybody uses git regularly.
>> Thomas later followed up on himself with the following mail regarding the
>> ChangeLog file:
>> ...and I couldn't agree more.
> I'd prefer to have the ChangeLog, at least to begin with. I find it
> much more visible;
Really? I find manual ChangeLog updates (even with the help of emacs'
`add-change-log-entry') to be the single most annoying thing about CVS
from a mere user's perspective, because it doesn't work with changesets.
It also makes merging different changes virtually impossible, because
there will always be a conflict at the top of the ChangeLog file
(although I hear people have automatic merge drivers for that now¹).
> I'm planning to spend as little time as I can playing
> with source control, whose job is to stay in the background while I look
> at the files (and I find git infuriatingly geeky). If we get rid of it
> on a day-to-day basis, we would need to get into the habit of including
> all the same information in commits --- which is a perfectly reasonable
> aim, particularly when the notion of changesets becomes meaningful.
> Generating it at the time of a release rather than immediately might be
> something to aim at. If we get to the point where we have a simple
> utility (i.e. doesn't demand detailed knowledge of git) that can
> generate a readable one, that becomes possible.
Yes, ChangeLog conversion could be automated from the output of "git
log". A one line approach might be as "easy" as this:
git --no-pager log --format="%ai %aN %n%n%x09* %s%d%n" $(git describe --abbrev=0)..
...which would make for a nice alias in ~/.gitconfig. But the result
could be better. And people have done better. That's not rocket science.
Either we use an existing script from someone else, or we cook up one of
>> I don't know if dropping the stable- vs development versions, is something
>> that would work for zsh (although I think it could - everybody uses 4.3.x
> We've only had separate development branches when needed for long term
> work on particular features, first ZLE widgets and then multibyte
Agreed. And even if we'd need a feature branch for stuff like that, it's
extremely easy to one such branch in git (as Thomas from FVWM outlined
in his mail).
> Feel free to bring up anything you think is relevant --- other than the
> basic move I didn't see much that seemed to affect our much simpler case
> --- but obviously anything that makes administration more complicated is
> out (there's no reason moving to git should generally have that effect,
Yes. Git can be used with an CVS-like workflow to a central server just
fine. And almost exactly the same way as with CVS (except that you make
a commit locally first and push the complete commit over to the server
It's absolutely up to the individual developer to decide how much of
git's feature-set he/she wants to use locally.
I also think that there are quite a number of apt git users on -workers,
who should be able to assist if something odd comes up (which may or may
As for the actual move to git: Wayne is keeping the CVS repository in
sync pretty darn well and I guess it's just a setting somewhere in the
sourceforge configuration to turn off CVS commits and enable commit
pushing into the git repository. I don't know the sourceforge admin
interface, but I'm sure Wayne will have a pretty good idea on how to do
that final switch-over.
¹ <http://gcc.gnu.org/wiki/GitMirror#git-merge-changelog> (I didn't try
Messages sorted by: