octave-maintainers
[Top][All Lists]
Advanced

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

Re: GSL in octave


From: Julien Bect
Subject: Re: GSL in octave
Date: Wed, 20 Jul 2016 13:53:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0

Le 20/07/2016 à 10:16, Susi Lehtola a écrit :
Since my previous email, I have pushed all your recent changesets and
added a few of my own.

I again had to fold some of your changesets for clarity.  When you have
several consecutive changesets that address the same logical change
(typically, you realize that you forgot to commit something, or you
discover that you made a typo) please don't leave them like them.
Instead, fold them using hg's mq extension.  Of course, you have to do
that *before* you push to the public repo (i.e., the changesets must be
in "draft" phase).

Well, I guess I'm used to project specific repos, whereas your policies seem to stem from octave-forge being managed as one huge consolidation. It's also a bit confusing having to work on different version control systems and try to learn each of their quirks. I thought pull requests might result in just a single commit message.

Sorry if I wasn't clear : this *is* a project-specific repository, and octave forge is *not* managed as one huge project (it was some time ago, but as you can see now each package has its own repo).

Folding changes, i.e., squashing them into one single commit, is not specific to Mercurial, people do that with git as well.  Of course, the way to achieve it is different (for instance, I use the mq extension in hg, and git rebase in git).  I recommend you to use TortoiseHg (thg) if you can: then you simply have to activate the mq extension in the preferences, and the mq commands will become easily available from the context menu.

Folding changes is not usually *required*, if you have well separated changesets.  And there is no general "policy" about that is Octave Forge.

But when you have a series of commits with titles such "Trying something about feature XXXX", and then "Changing my mind about feature XXXX", and again "Oooops I forgot to push some patches concerning feature XXXX", it becomes difficult and time-consuming for other people to review your changes.  And if nobody can review your changes, it is very unlikely that they will end up in the official package repo.

Please don't be mistaken: I think you did a great job recently on the gsl package, and we probably are very close to being able to make a release.  It's cool ;-)


reply via email to

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