Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Microsoft swallows Github
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5122
Location: The Peanut Gallery

PostPosted: Fri Jun 29, 2018 11:22 pm    Post subject: Reply with quote

Quote:
Once you publish it, you can't pretend that you didn't
mv wrote:
Bad enough if e.g. somebody uploaded a file containing sensible information by mistake. But if a system forces him to keep this information readable online for everybody forever, something is wrong with that system. In my country such a system might be even against law. (Or you would have to keep backups of the repository to undo such mistakes and artificially rewrite history which completely defeats the purpose of a VCS).
So, you have code-reviews with at least 2 or 3 people, all bundling commits nicely so that "the history is clean", but you don't have separate release branches?

Further you can do a correct reversion, ie a patch that removes; but in general: yeah, don't publish crap to release. You have all those reviewers on code branches, after all.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1367

PostPosted: Sat Jun 30, 2018 4:03 am    Post subject: This truly is an evil thing to do Reply with quote

On big data
somewhere someone will analyse with neuronal network learning machines
how human developers do recognize hidden flaws in their software.
And as a next step howto write and inject long living trojan horses
into our every day software ...
_________________
fun2gen2
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6186

PostPosted: Sat Jun 30, 2018 6:50 am    Post subject: Reply with quote

steveL wrote:
So, you have code-reviews with at least 2 or 3 people, all bundling commits nicely so that "the history is clean", but you don't have separate release branches?

Not being able to rewrite history implies that for no branch one can rewrite history, so it doesn't matter (concerning undoing of mistakes) whether you publish several branches.
Anyway, even if the system such that it works only if 2-3 people are bundling commits nicely, then the VCS is only for special situations and not for everybody (where perhaps a simple project is maintained only by a single person who of course occasionally will make some mistake [which BTW can also happen if 2-3 people review first]).
Quote:
Further you can do a correct reversion, ie a patch that removes

That's different. Then you are able to change history.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5122
Location: The Peanut Gallery

PostPosted: Sat Jun 30, 2018 1:37 pm    Post subject: Reply with quote

steveL wrote:
So, you have code-reviews with at least 2 or 3 people, all bundling commits nicely so that "the history is clean", but you don't have separate release branches?
mv wrote:
Not being able to rewrite history implies that for no branch one can rewrite history, so it doesn't matter (concerning undoing of mistakes) whether you publish several branches.
No; we're not discussing any particular vcs here.
Quote:
Anyway, even if the system such that it works only if 2-3 people are bundling commits nicely, then the VCS is only for special situations and not for everybody
That's precisely the problem with git, as espoused in "best practice" such as the kernel: it tends to a situation where everyone is making up nice commits, instead of getting on with the actual work (since they can keep reworking them by a rebase.)
Please note that I don't have any issue with nice commits per se: just in chasing them, as if the product were the commit history, instead of the product.
Quote:
(where perhaps a simple project is maintained only by a single person who of course occasionally will make some mistake [which BTW can also happen if 2-3 people review first]).
You seem to think I am in favour of some sort of system where mistakes are never allowed, which is odd as that would defeat the entire purpose of revision-control.
steveL wrote:
Further you can do a correct reversion, ie a patch that removes
mv wrote:
That's different. Then you are able to change history.
Nonsense.
If I make a commit which removes some lines of code, and then push that, it still flows from the previous commits.

There is no change in what came before; only in what flows from here on in.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6186

PostPosted: Sat Jun 30, 2018 6:04 pm    Post subject: Reply with quote

steveL wrote:
No; we're not discussing any particular vcs here.

Then probably there was a misunderstanding for quite a while already. I thought you were talking about particular properties of fossil (which I am not familiar with).
Quote:
mv wrote:
That's different. Then you are able to change history.
Nonsense.

Apparently I misunderstood what you mean by "correct reversion". I had understood you mean by this something like git's reset (+git gc/repack), but now it seems that you really meant git's revert only which of course cannot solve the problem to remove sensible information (or a huge wrong file) from the repository.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5122
Location: The Peanut Gallery

PostPosted: Wed Jul 04, 2018 12:36 pm    Post subject: Reply with quote

Well, there is always the possibility of simply using an old clone, and then moving on from there.

So even in a system that forbids rewriting of history on published branches, there is always a way out.

The reason it matters, is for the ability to rely on something as part of infrastructure, used for reproducible builds.

You need a stable basis of collaboration, or things fall apart quickly.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6186

PostPosted: Wed Jul 04, 2018 1:57 pm    Post subject: Reply with quote

steveL wrote:
Well, there is always the possibility of simply using an old clone, and then moving on from there.
[...]
You need a stable basis of collaboration, or things fall apart quickly.

That's why many git projects have a policy of not allowing a non-force push. However, in excpetional cases some "administrator/main maintainer" might do a force push anyway.
There are 2 differences between the way you describe and the git way.
  1. whether you have to refer to independent backups or whether you can rely on the VCS itself for the backups, and
  2. whether e.g. in github or similar services the main administrator of the repository can do this or whether you have to ask github staff to do it.
For huge companies which have backup strategies and are completely self-hosting anyway, it does not matter. For small (e.g. essentially one-man) projects, I strongly prefer the git way.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5122
Location: The Peanut Gallery

PostPosted: Fri Jul 06, 2018 5:59 pm    Post subject: Reply with quote

mv wrote:
That's why many git projects have a policy of not allowing a non-force push. However, in excpetional cases some "administrator/main maintainer" might do a force push anyway.
Yes, that's how we ran things for update; and indeed at the beginning, I had to do a couple of forced-pushes.

The problem is that it took quite a bit of setup to get a somewhat secure arrangement; not that I had to do it.
Quote:
There are 2 differences between the way you describe and the git way.
TBH, I am not quite sure I am "describing" anything; there is no system at hand that I can point to and say: that's how you do it.
I am just chatting on downtime, not drawing up a specification, so forgive any laxity on my part (I am really knackered, after a few weeks of long coding, and looking forward to some cabbage-time this weekend. :)
Quote:
  1. whether you have to refer to independent backups or whether you can rely on the VCS itself for the backups, and
  2. whether e.g. in github or similar services the main administrator of the repository can do this or whether you have to ask github staff to do it.
For huge companies which have backup strategies and are completely self-hosting anyway, it does not matter. For small (e.g. essentially one-man) projects, I strongly prefer the git way.
Oh, my point is quite independent of how something is administered.
I strongly agree with you that the end-user must be able to walk away with their entire dataset at any point.

I don't think git is the last-word in version-control, that's all.
It is a significant step forward, without question; but it is not the end of the journey.

On the specific point of "changing history", the issue is that the admin has to setup a policy, and hooks, just to get something I see as pretty fundamental.
It should be the default, out of the box; that way, people are used to it, and don't question the basis.
They just have the essentials, and we all have a more stable infrastructure, by default.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum