On 17/02/16 13:38, Simon Wise wrote:
On 17/02/16 03:38, Steve Litt wrote:
Where would you suggest I find out more about the practicalities of
git? I use it for my own stuff quite a bit, but don't know how to do
branches and all that.
look at:
man gitworkflows
that one is more about collabor
On 17/02/16 03:38, Steve Litt wrote:
Where would you suggest I find out more about the practicalities of
git? I use it for my own stuff quite a bit, but don't know how to do
branches and all that.
look at:
man gitworkflows
that one is more about collaboration and a wider group of developers
On Tue, 16 Feb 2016 19:47:37 +1300
Daniel Reurich wrote:
> On 16 February 2016 3:35:55 PM NZDT, Steve Litt
> wrote:
> >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 y
On Tue, 16 Feb 2016 10:06:35 +
KatolaZ wrote:
> On Mon, Feb 15, 2016 at 09:35:55PM -0500, Steve Litt wrote:
>
> [cut]
>
> > >
> > > Commit often. Branch whenever needed needed. Merge when it
> > > works. Release when "perfect" (the last one should be really
> > > considered with a pinch of
On Mon, Feb 15, 2016 at 09:35:55PM -0500, Steve Litt wrote:
[cut]
> >
> > 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
Hi Steve,
On 02/16/2016 07:47 AM, dng-requ...@lists.dyne.org wrote:
When a version is a release, don't you just give it a tag?
SteveT
Yes, but you can also give a tag to a concrete commit[*], for example:
$ git tag -a 0.1.1-9928033
You can recover it checking out the tag:
$ git checkout 0.
On 16 February 2016 3:35:55 PM NZDT, Steve Litt
wrote:
>On Mon, 15 Feb 2016 14:00:46 +
>KatolaZ wrote:
>
>> On Mon, Feb 15, 2016 at 01:05:25PM +, Rainer Weikusat wrote:
>> > Edward Bartolo writes:
>> > > I need to avoid having to "git commit -m ..." every time I
>> > > add/modify co
On Mon, 15 Feb 2016 14:00:46 +
KatolaZ wrote:
> On Mon, Feb 15, 2016 at 01:05:25PM +, Rainer Weikusat wrote:
> > Edward Bartolo writes:
> > > I need to avoid having to "git commit -m ..." every time I
> > > add/modify code. I need to 'git buildpackage' without committing
> > > changes.
On Mon, Feb 15, 2016 at 02:00:46PM +, KatolaZ wrote:
> 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 usua
On Mon, Feb 15, 2016 at 01:05:25PM +, Rainer Weikusat wrote:
> Edward Bartolo 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.
>
Edward Bartolo 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
no
Hi,
Do not reply to this: I used --git-ignore-changes. It works as I need it.
Edward
On 15/02/2016, Edward Bartolo wrote:
> Hi,
>
> 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
Hi,
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. This also
makes commits more meaningful.
So, in short, I need this:
1) edit / modify code
2) build
13 matches
Mail list logo