At Sun, 21 Jun 2020 17:45:44 +0200, Johnny Billquist wrote:
Subject: Re: cvs better than git?
>
> Something done on your local repository is not truly committed to
> start with. And it should be run through unit tests and so on, on the
> central repository, before being committed to the central
On Sun, Jun 21, 2020 at 06:48:54PM +0100, Sad Clouds wrote:
> On Sun, 21 Jun 2020 18:26:48 +0200
> Johnny Billquist wrote:
>
> > I hear what you say, but it's still a fact that even good people make
> > errors all the time. So it's not really that much about "trust" as
> > about in the end
On Sun, 21 Jun 2020 17:36:23 +0200
Andreas Krey wrote:
> > Even when you have unit tests (which you should), there are still plenty
> > of errors not caught by that. However, automatically running unit tests
> > on all code to be committed, *before* it is committed, is also very
> > valuable.
On Sun, Jun 21, 2020 at 12:36 PM Mayuresh wrote:
>
> On Sun, Jun 21, 2020 at 11:56:20AM -0400, matthew sporleder wrote:
> > >
> > > the way git works (tracking whole trees at a time, never single files),
> > > that ends up being very painful, because it's an "all or nothing"
> > > approach.
> >
On Sun, 21 Jun 2020 18:26:48 +0200
Johnny Billquist wrote:
> I hear what you say, but it's still a fact that even good people make
> errors all the time. So it's not really that much about "trust" as
> about in the end getting the damn thing right. Prestige have no place
> there. If you think
On 2020-06-21 18:49, Andreas Krey wrote:
On Sun, 21 Jun 2020 18:34:30 +, Johnny Billquist wrote:
...
That is what literally the word "commit" means. Until that point, you
are not committed.
Please excuse me for not getting that, with 'committing', you don't
mean creating git commits in
On Sun, 21 Jun 2020 18:34:30 +, Johnny Billquist wrote:
...
> That is what literally the word "commit" means. Until that point, you
> are not committed.
Please excuse me for not getting that, with 'committing', you don't
mean creating git commits in the context of talking about git.
I mean,
Hi All,
Thanks Greg and Martin for the hints! I had to fix them manually but managed to
get it done so postinstall does not complain when I let them checked.
Today when I started up the system I got in dmesg this stuff but I haven't seen
that after reboot:
[ 1686,631400] kern error:
On 2020-06-21 18:17, Andreas Krey wrote:
On Sun, 21 Jun 2020 17:59:59 +, Johnny Billquist wrote:
...
You're a bit hung up on the word 'commit', and the finality of commits
in some VCSes, it seems.
So are obviously everyone using git in combination with gerrit...
What? The gerrit model
On Sun, Jun 21, 2020 at 11:56:20AM -0400, matthew sporleder wrote:
> >
> > the way git works (tracking whole trees at a time, never single files),
> > that ends up being very painful, because it's an "all or nothing"
> > approach.
> >
> > So I'm hoping that if you guys are seriously considering
On 2020-06-21 18:17, Sad Clouds wrote:
On Sun, 21 Jun 2020 17:15:44 +0200
Johnny Billquist wrote:
Not talking about a specific tool, but the process then.
There are multiple advantages by having code reviewed.
First of all, noone is perfect. People make mistakes all the time,
and having two
On Sun, 21 Jun 2020 17:15:44 +0200
Johnny Billquist wrote:
> Not talking about a specific tool, but the process then.
>
> There are multiple advantages by having code reviewed.
> First of all, noone is perfect. People make mistakes all the time,
> and having two people look at it already reduce
On Sun, 21 Jun 2020 17:59:59 +, Johnny Billquist wrote:
...
> >You're a bit hung up on the word 'commit', and the finality of commits
> >in some VCSes, it seems.
>
> So are obviously everyone using git in combination with gerrit...
What? The gerrit model is exactly that: Make commits to be
On 2020-06-21 18:02, Andreas Krey wrote:
On Sun, 21 Jun 2020 17:45:44 +, Johnny Billquist wrote:
...
Something done on your local repository is not truly committed to start
with. And it should be run through unit tests and so on, on the central
repository, before being committed to the
On Sun, 21 Jun 2020 17:45:44 +, Johnny Billquist wrote:
...
> Something done on your local repository is not truly committed to start
> with. And it should be run through unit tests and so on, on the central
> repository, before being committed to the central repository.
When you try to
On 2020-06-21 17:55, Andreas Krey wrote:
On Sun, 21 Jun 2020 17:26:05 +, Johnny Billquist wrote:
...
What? I can't believe you are ignorant enough to not know that each file
in cvs have a version number for each commit on it.
ETOOLONGAGO; this is starting to slip my mind.
Yes, files have
On Sun, Jun 21, 2020 at 11:33 AM Mayuresh wrote:
>
> On Sat, Jun 20, 2020 at 11:35:53AM +0530, Mayuresh wrote:
> > On Fri, Jun 19, 2020 at 10:01:35PM -0700, Greg A. Woods wrote:
> > > (c) modern change tracking tools try to track changes to whole sets of
> > > files at once, so if you have
On Sun, 21 Jun 2020 17:26:05 +, Johnny Billquist wrote:
...
> What? I can't believe you are ignorant enough to not know that each file
> in cvs have a version number for each commit on it.
ETOOLONGAGO; this is starting to slip my mind.
Yes, files have revision numbers. But they are nearly
On 2020-06-21 17:36, Andreas Krey wrote:
On Sun, 21 Jun 2020 17:15:44 +, Johnny Billquist wrote:
...
Even when you have unit tests (which you should), there are still plenty
of errors not caught by that. However, automatically running unit tests
on all code to be committed, *before* it is
On Sun, 21 Jun 2020 17:15:44 +, Johnny Billquist wrote:
...
> Even when you have unit tests (which you should), there are still plenty
> of errors not caught by that. However, automatically running unit tests
> on all code to be committed, *before* it is committed, is also very
> valuable.
On Sat, Jun 20, 2020 at 11:35:53AM +0530, Mayuresh wrote:
> On Fri, Jun 19, 2020 at 10:01:35PM -0700, Greg A. Woods wrote:
> > (c) modern change tracking tools try to track changes to whole sets of
> > files at once, so if you have lots of files, and lots of history,
> > this combinatorial
On 2020-06-21 17:20, Andreas Krey wrote:
On Sun, 21 Jun 2020 15:20:39 +, Johnny Billquist wrote:
...
40. And you can abbreviate as far as they stay unambiguous.
And it's still not anything you would want to type at all.
Yes, but. There are lots of ways to reference commits, like
'two
On Sun, 21 Jun 2020 15:20:39 +, Johnny Billquist wrote:
...
> >40. And you can abbreviate as far as they stay unambiguous.
>
> And it's still not anything you would want to type at all.
Yes, but. There are lots of ways to reference commits, like
'two before the current commit on this
On 2020-06-21 17:07, Sad Clouds wrote:
On Sun, 21 Jun 2020 10:32:32 -0400
g...@duzan.org wrote:
On 2020-06-21 16:07, Rhialto wrote:
On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
I am still curious about how to manage well in git the scenario
where you do
have a central
On Sun, 21 Jun 2020 10:32:32 -0400
g...@duzan.org wrote:
> > On 2020-06-21 16:07, Rhialto wrote:
> >> On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
> >>> I am still curious about how to manage well in git the scenario
> >>> where you do
> >>> have a central repository that holds
> On Jun 21, 2020, at 10:32 AM, g...@duzan.org wrote:
>
>
>>
>>> On 2020-06-21 16:07, Rhialto wrote:
>>> On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
I am still curious about how to manage well in git the scenario where
you do
have a central repository that
> On 2020-06-21 16:07, Rhialto wrote:
>> On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
>>> I am still curious about how to manage well in git the scenario where
>>> you do
>>> have a central repository that holds the actual source of truth, and
>>> where
>>> you want to review and
On 2020-06-21 16:07, Rhialto wrote:
On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
I am still curious about how to manage well in git the scenario where you do
have a central repository that holds the actual source of truth, and where
you want to review and approve anything that
On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:
> I am still curious about how to manage well in git the scenario where you do
> have a central repository that holds the actual source of truth, and where
> you want to review and approve anything that gets committed.
Let me point you
On 2020-06-21 14:27, Andreas Krey wrote:
On Sun, 21 Jun 2020 12:07:00 +, Johnny Billquist wrote:
...
simple operations, and yet I waste a day or two on git instead of just
getting work done. For me a clear sign that the tool is wrong.
'one or two days' has a bit of a smell to it.
It is
On Sun, 21 Jun 2020 12:07:00 +, Johnny Billquist wrote:
...
> simple operations, and yet I waste a day or two on git instead of just
> getting work done. For me a clear sign that the tool is wrong.
'one or two days' has a bit of a smell to it.
...
> obviously not meant for people to use on
On 2020-06-21 10:57, Andreas Krey wrote:
On Sun, 21 Jun 2020 00:03:54 +, Johnny Billquist wrote:
...
Except when git refuses to do that, which I have had happen to me
several times. git stash refuses (I can't even remember the error
message right now, but something weird).
I can't think
On Sun, 21 Jun 2020 11:05:51 +0200
Andreas Krey wrote:
> But I take objection at the 'seems'. You're arguing
> that some - few - projects are too big for git, and
> hence everybody should stay away from is. Even though
> MS implemented VFS exactly to be able *use* git.
>
Absolutely not. There
On Sat, 20 Jun 2020 16:52:16 +, Sad Clouds wrote:
...
> Because let's face it, breaking up codebase into gazillions of smaller
> repos is daft and not very user friendly.
Neither is throwing unrelated things into a single repo. It's not
easy to decide where to draw the line - what you do
On Sun, 21 Jun 2020 00:03:54 +, Johnny Billquist wrote:
...
> Except when git refuses to do that, which I have had happen to me
> several times. git stash refuses (I can't even remember the error
> message right now, but something weird).
I can't think of any nonobvious (like being in a
35 matches
Mail list logo
