On 16 February 2016 3:35:55 PM NZDT, Steve Litt <[email protected]> wrote: >On Mon, 15 Feb 2016 14:00:46 +0000 >KatolaZ <[email protected]> wrote: > >> On Mon, Feb 15, 2016 at 01:05:25PM +0000, Rainer Weikusat wrote: >> > Edward Bartolo <[email protected]> writes: >> > > I need to avoid having to "git commit -m ..." every time I >> > > add/modify code. I need to 'git buildpackage' without committing >> > > changes. The reason is to make sure new code works before >> > > committing. >> > >> > In my opinion, that's an unfortunate way to use a SCM because it's >> > than not used as a change management system but more like a release >> > tracking system. I usually commit every somewhat self-contained >> > unit of work, eg, every new function or signficant change to an >> > existing function without even knowing if the code compiles, let >> > alone works (this requires private branches if more than one person >> > works on a codebase). This means I get a detailed and commented >> > history of all changes I made which makes it easy to determine why >> > something was changed/ written in a particular way and also means >> > that I can always throw the current working files away (instead of >> > trying to reconstruct them after an ill-advised change, be it some >> > idea which just didn't work out or accidentally damaging a file) >> > without losing a lot of work. >> >> +1 >> >> Try to use git for what it was conceived: revision management. And a >> revision is not a release. The strategy suggested by Rainer, >> i.e. maintaining personal branches where every consistent set of >> changes is fixed into a commit, is usually the easiest way out. >> >> Commit often. Branch whenever needed needed. Merge when it >> works. Release when "perfect" (the last one should be really >> considered with a pinch of salt :P). > >When a version is a release, don't you just give it a tag? > Yes. But that is no excuse for not using private branches to develop on. If you have to revert a commit your probably doing it wrong. Please keep master branches for merging tested and release ready branches only.
For Devuan packaging projects, devuan/<release> branches should be marked protected and changes proposed via merge requests. And the owners/masters should be the only ones to merge changes and set release tags. Daniel
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
