| View previous topic :: View next topic |
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Fri Jun 29, 2018 11:22 pm Post subject: |
 |
|
| 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 |
|
 |
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Sat Jun 30, 2018 4:03 am Post subject: This truly is an evil thing to do |
|
|
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 ... |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Jun 30, 2018 6:50 am Post subject: |
|
|
| 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 |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jun 30, 2018 1:37 pm Post subject: |
|
|
| 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Jun 30, 2018 6:04 pm Post subject: |
|
|
| 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 |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jul 04, 2018 12:36 pm Post subject: |
|
|
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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Jul 04, 2018 1:57 pm Post subject: |
|
|
| 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.
- whether you have to refer to independent backups or whether you can rely on the VCS itself for the backups, and
- 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 |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jul 06, 2018 5:59 pm Post subject: |
|
|
| 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: | - whether you have to refer to independent backups or whether you can rely on the VCS itself for the backups, and
- 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 |
|
|
yathish
n00b
Joined: 06 Sep 2019
Posts: 1
|
| Posted: Fri Sep 06, 2019 12:09 pm Post subject: |
|
|
| Git is platform and service provider |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sat Sep 07, 2019 1:37 am Post subject: |
|
|
Nice spam necrobump... 
When the acquisition happened, I moved over to cgit and haven't looked back. It does everything it needs to.
A year later, I'm still somewhat concerned about the future availability of GitHub to anonymous users. If I'm forced to have an account to pull or clone, then I guess I won't be cloning a bunch of stuff, haha.. ha...
Part of the problem is our tendency to centralize development resources, when git was meant to be used more or less ad hoc. The key is making this sort of workflow more accessible. Blocked ports can be a problem, but generally all you need is someone's IP and a repo path to clone or pull. Self-hosters tend to already have a domain to host it on, so direct communication can still work.
When used in a distributed fashion, Git is resilient to stuff like the MS acquisition. The other part of the problem is, for most people, convenience wins over quality or philosophy. I doubt that will change. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22719
|
| Posted: Sat Sep 07, 2019 3:47 pm Post subject: |
|
|
| spork_kitty wrote: | | A year later, I'm still somewhat concerned about the future availability of GitHub to anonymous users. If I'm forced to have an account to pull or clone, then I guess I won't be cloning a bunch of stuff, haha.. ha... |
It looks to me like Github allows anonymous cloning over https. Could you point to a publicly browseable repository where this is not the case? |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sat Sep 07, 2019 4:06 pm Post subject: |
|
|
| Hu wrote: | | spork_kitty wrote: | | A year later, I'm still somewhat concerned about the future availability of GitHub to anonymous users. If I'm forced to have an account to pull or clone, then I guess I won't be cloning a bunch of stuff, haha.. ha... |
It looks to me like Github allows anonymous cloning over https. Could you point to a publicly browseable repository where this is not the case? |
Yes, it does allow that. For now.
I wrote that I am concerned over the future, not the present. When the belt tightens and MS starts looking for a return on their investment, I don't expect anonymous access to remain. It's a pattern that many corporate websites follow, because hoarding data is currently profitable and laws on protecting its handling are weak at best. Anonymous users who protect themselves don't produce as much data, and thus lead to less revenue than registered users. One of the first ways to cut a website's costs is to reduce its bandwidth usage. You do the math. |
|
| Back to top |
|
|
Morality124
Tux's lil' helper
Joined: 20 Feb 2018
Posts: 102
|
| Posted: Sat Sep 07, 2019 5:47 pm Post subject: |
|
|
| Hu wrote: | | spork_kitty wrote: | | A year later, I'm still somewhat concerned about the future availability of GitHub to anonymous users. If I'm forced to have an account to pull or clone, then I guess I won't be cloning a bunch of stuff, haha.. ha... |
It looks to me like Github allows anonymous cloning over https. Could you point to a publicly browseable repository where this is not the case? |
Not exactly what you asked... but concerning nonetheless:
https://www.techdirt.com/articles/20190731/01564742686/what-happens-when-us-government-tries-to-take-open-source-community.shtml
| Quote: | Last year, Microsoft bought the popular code repository GitHub. As Techdirt wrote at the time, many people were concerned by this takeover of a key open source resource by a corporate giant that has frequently proved unfriendly to free software. In the event, nothing worrying has happened -- until this:
GitHub this week told Anatoliy Kashkin, a 21-year-old Russian citizen who lives in Crimea, that it had "restricted" his GitHub account "due to US trade controls". |
|
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3738
Location: Rasi, Finland
|
| Posted: Sat Sep 07, 2019 6:33 pm Post subject: |
|
|
I have set up a gitlab account in case Microsoft starts being the old itself.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
