| View previous topic :: View next topic |
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Mon Jun 11, 2018 12:13 pm Post subject: |
 |
|
| Yamakuzure wrote: | | Well, we'll see what happens. Microsoft either screws GitHub, and force most of their users to move their projects to the more than enough alternatives, or they really have changed as much as they say they have. |
That's a false dichotomy.
It seems far more likely that they will "extend" the protocol to allow for proprietary "features", which do not stop the base usage, but make it awkward to use other platforms, for precisely the kind of things that github has already invested in to differentiate itself from self-hosting.
Quite hard to argue with that, when you have people lining up to say how useful github is (without ever discussing why we can't just do that kind of thing as a community.) | Quote: | | No need to panic (, yet), but if they screw up, the world will continue spinning. |
Sure it will. It will also keep spinning when all the humans have finally died out.
Not sure I see the point you're making here; though I guess it's nice you want everyone just to get along. |
|
| Back to top |
|
 |
mir3x
Guru
Joined: 02 Jun 2012
Posts: 455
|
| Posted: Fri Jun 15, 2018 6:20 am Post subject: |
|
|
So are there any official numbers how much projects left github ? I couldnt google any new numbers.
Earlier I saw only 100k left to gitlab - so nothing compared to 85M projects on github.
_________________
Sent from Windows |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Jun 15, 2018 2:23 pm Post subject: |
|
|
It's fresh news. For some they probably haven't noticed yet, and for bigger projects it takes time to plan everything out.
And then there will be the vast majority who do not care enough to move. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Jun 15, 2018 11:01 pm Post subject: |
|
|
| mir3x wrote: | So are there any official numbers how much projects left github ? I couldnt google any new numbers.
Earlier I saw only 100k left to gitlab - so nothing compared to 85M projects on github. |
A lot of the projects on github are spam, schoolwork, or clueless computer-illiterate people who've somehow dumbed their way into signing up and hitting the green button.
This is an enlightening list if you think github's activity numbers are all above-board. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Jun 15, 2018 11:56 pm Post subject: |
|
|
| Ant P. wrote: | | mir3x wrote: | So are there any official numbers how much projects left github ? I couldnt google any new numbers.
Earlier I saw only 100k left to gitlab - so nothing compared to 85M projects on github. |
A lot of the projects on github are spam, schoolwork, or clueless computer-illiterate people who've somehow dumbed their way into signing up and hitting the green button.
This is an enlightening list if you think github's activity numbers are all above-board. |
What do you mean by above board?
There are also people who have github accounts but don't post directly to them. We instead have admin or write access to an organizational account, and post directly to that. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Jun 16, 2018 5:41 am Post subject: |
|
|
| 1clue wrote: | | What do you mean by above board? |
Whether "85M users can't be wrong!" means anything whatsoever.
After all, an entire planetary populace can be wrong; it's happened before. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2297
Location: Adendorf, Germany
|
| Posted: Tue Jun 19, 2018 11:23 am Post subject: |
|
|
On a side note, SourceForge has started advertising their GitHub Importer. 
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
bunder
Bodhisattva
Joined: 10 Apr 2004
Posts: 5937
|
| Posted: Tue Jun 19, 2018 12:35 pm Post subject: |
|
|
sourceforge is a horrendous website to use, i can't imagine why anyone would want to use them, aside from the bandwidth.
has microsoft done anything to bork up github yet? i never moved my repo and haven't seen an urgent need to... the mass exodus seems to have been kneejerk. 
_________________
| Neddyseagoon wrote: | | The problem with leaving is that you can only do it once and it reduces your influence. |
banned from #gentoo since sept 2017 |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Tue Jun 19, 2018 1:51 pm Post subject: |
|
|
| WTF is a github importer? It's git. When you do a clone from a remote, you get a complete copy of that remote's repository. An ftp server could be a github importer. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2297
Location: Adendorf, Germany
|
| Posted: Tue Jun 19, 2018 2:29 pm Post subject: |
|
|
| 1clue wrote: | | WTF is a github importer? It's git. When you do a clone from a remote, you get a complete copy of that remote's repository. An ftp server could be a github importer. |
*coughcough* Issues? Wiki? Releases? Metadata? GitHub holds a lot more than just git repos.
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Tue Jun 19, 2018 3:33 pm Post subject: |
|
|
| Yamakuzure wrote: | | 1clue wrote: | | WTF is a github importer? It's git. When you do a clone from a remote, you get a complete copy of that remote's repository. An ftp server could be a github importer. |
*coughcough* Issues? Wiki? Releases? Metadata? GitHub holds a lot more than just git repos. |
I guess I made that point earlier in the thread. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jun 22, 2018 2:25 pm Post subject: |
|
|
| Yamakuzure wrote: | | *coughcough* Issues? Wiki? Releases? Metadata? GitHub holds a lot more than just git repos. |
That's one of the things I like about fossil; that your issue tracker is part of the repo.
I like that there is no such thing as "rewriting history", even more.
Issue tracking as part of the repo feels a bit gacky, tbh; I just like the idea of bundling two repos, or w/e, which would need to be strictly data-only wrt issue-tracking, so any "website engine" can present an interface. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2297
Location: Adendorf, Germany
|
| Posted: Mon Jun 25, 2018 7:25 am Post subject: |
|
|
| steveL wrote: | | Yamakuzure wrote: | | *coughcough* Issues? Wiki? Releases? Metadata? GitHub holds a lot more than just git repos. |
That's one of the things I like about fossil; that your issue tracker is part of the repo.
I like that there is no such thing as "rewriting history", even more.
Issue tracking as part of the repo feels a bit gacky, tbh; I just like the idea of bundling two repos, or w/e, which would need to be strictly data-only wrt issue-tracking, so any "website engine" can present an interface. |
From their frontpage on fossil-scm.org it looks like an all-in-one attempt.
Looks interesting so far, but why did they rename "Commit" to "Check-Ins"? Looks odd...
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Jun 25, 2018 8:57 am Post subject: |
|
|
| Yamakuzure wrote: | | but why did they rename "Commit" to "Check-Ins"? Looks odd... |
Actually, git has renamed check-in into commit... |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Jun 25, 2018 9:05 am Post subject: |
|
|
| steveL wrote: | | I like that there is no such thing as "rewriting history", even more. |
This is horrible: Once you made a mistake you cannot undo it anymore?
E.g. committing the wrong patch (hence completely wrong description of the check-in), adding by accident an output of a test-run (which might not only be huge but perhaps even contains sensible information), or similar mistakes which can (and do) happen... |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2297
Location: Adendorf, Germany
|
| Posted: Mon Jun 25, 2018 11:13 am Post subject: |
|
|
| mv wrote: | | Yamakuzure wrote: | | but why did they rename "Commit" to "Check-Ins"? Looks odd... |
Actually, git has renamed check-in into commit... |
What about CVS, Subversion, Bazaar, Mercurial and so on? Oddly enough the short form of 'svn commit' is 'ci', which means 'check in'...
I guess it doesn't matter anyway... 
| mv wrote: | | steveL wrote: | | I like that there is no such thing as "rewriting history", even more. |
This is horrible: Once you made a mistake you cannot undo it anymore?
E.g. committing the wrong patch (hence completely wrong description of the check-in), adding by accident an output of a test-run (which might not only be huge but perhaps even contains sensible information), or similar mistakes which can (and do) happen... |
In those cases a revert wouldn't be enough, right?
So if you accidentally pushed such a commit, you'd be screwed? Uh-oh...
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Jun 25, 2018 4:24 pm Post subject: |
|
|
| Yamakuzure wrote: | | What about CVS, Subversion, Bazaar, Mercurial and so on? |
rcs: ci (rcs is the father of all VCS)
cvs, svn: ci (yes, meanwhile also commit, but who used that?)
bzr, mercurial, monotone are about the same age as git; I forgot what they use.
| Quote: | | In those cases a revert wouldn't be enough, right? |
No. The repository would still be huge and/or contain sensible information. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Mon Jun 25, 2018 4:54 pm Post subject: |
|
|
| mv wrote: | | Yamakuzure wrote: | | What about CVS, Subversion, Bazaar, Mercurial and so on? |
rcs: ci (rcs is the father of all VCS)
cvs, svn: ci (yes, meanwhile also commit, but who used that?)
bzr, mercurial, monotone are about the same age as git; I forgot what they use.
| Quote: | | In those cases a revert wouldn't be enough, right? |
No. The repository would still be huge and/or contain sensible information. |
On git, if you commit something in error on a branch and then revert, and nothing (no tags, no other commits, etc) references that commit for a few weeks it will eventually be cleaned out and be gone forever. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22697
|
| Posted: Tue Jun 26, 2018 2:05 am Post subject: |
|
|
| 1clue wrote: | | On git, if you commit something in error on a branch and then revert, and nothing (no tags, no other commits, etc) references that commit for a few weeks it will eventually be cleaned out and be gone forever. |
That first part is not quite correct (perhaps you meant reset, not revert?). Unreferenced blobs are eventually deleted, yes. However, if you commit a file, then revert the commit that added it, the file remains referenced by the historical commit. Anyone who browses history can see your revert and your preceding add, and can retrieve the contents of the tree at either of those times. While the blob is referenced, even if only by historical commits, it cannot be deleted. (If it were otherwise, how could you ever check out old versions of the project, since many of those files have since become "unreferenced" in tip because they were superseded by more recent changes?)
The only way to make a file be completely unreferenced is to make the commit which references the file be itself unreferenced. That commit will be referenced as long as any branch points to it as a tip or to any commit descended from the offending commit. Therefore, a full discard needs the administrator to delete every branch which refers to the commit, and every branch which refers to any commit descended from the bad commit, and every tag which refers to any commit descended from the bad commit. As you say, once nothing references it, then it can finally be purged. The problem is that Git has a very cautious idea of "nothing" because it's not supposed to lose data unless the user goes out of his way to make that happen. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Jun 26, 2018 12:47 pm Post subject: |
|
|
| steveL wrote: | | I like that there is no such thing as "rewriting history", even more. |
| mv wrote: | This is horrible: Once you made a mistake you cannot undo it anymore?
E.g. committing the wrong patch (hence completely wrong description of the check-in), adding by accident an output of a test-run (which might not only be huge but perhaps even contains sensible information), or similar mistakes which can (and do) happen... |
Once you publish it, you can't pretend that you didn't.
Well, that's what I prefer; whether fossil does that or not, or precisely how, is another matter.
My point being, not that you can't make mistakes in a local checkout; but that there is a process, part of which is publishing, beyond building a changeset. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Tue Jun 26, 2018 3:04 pm Post subject: |
|
|
| Hu wrote: | | 1clue wrote: | | On git, if you commit something in error on a branch and then revert, and nothing (no tags, no other commits, etc) references that commit for a few weeks it will eventually be cleaned out and be gone forever. |
That first part is not quite correct (perhaps you meant reset, not revert?). Unreferenced blobs are eventually deleted, yes.
|
Yes, in git speak it's reset. With everyone talking about multiple RCS apps, I used the word that most of the ones I know use, and the word that in English means what it actually does.
| Quote: |
However, if you commit a file, then revert the commit that added it, the file remains referenced by the historical commit. Anyone who browses history can see your revert and your preceding add, and can retrieve the contents of the tree at either of those times. While the blob is referenced, even if only by historical commits, it cannot be deleted. (If it were otherwise, how could you ever check out old versions of the project, since many of those files have since become "unreferenced" in tip because they were superseded by more recent changes?)
The only way to make a file be completely unreferenced is to make the commit which references the file be itself unreferenced. That commit will be referenced as long as any branch points to it as a tip or to any commit descended from the offending commit. Therefore, a full discard needs the administrator to delete every branch which refers to the commit, and every branch which refers to any commit descended from the bad commit, and every tag which refers to any commit descended from the bad commit. As you say, once nothing references it, then it can finally be purged. The problem is that Git has a very cautious idea of "nothing" because it's not supposed to lose data unless the user goes out of his way to make that happen. |
I remember seeing a video about that, it's a huge PITA. Never had to try it. Didn't know that the file exists anyway, which makes mistakes like accidentally adding binary build products problematic. This explains why some of our older repositories are so huge. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22697
|
| Posted: Wed Jun 27, 2018 1:17 am Post subject: |
|
|
| steveL wrote: | | Once you publish it, you can't pretend that you didn't. |
I think mv's concern was that fossil treats every commit as "publish", even those that you have not yet published to anyone. For some Git-based projects, I may want to git commit -a -m 'Checkpoint changes' as a safety measure. Once I'm satisfied that later work didn't break anything, I reset that commit out of existence and commit with a good message and a more maintainer-friendly patch sequence. No one needs to see all my checkpoint commits, and I intentionally don't publish them even to other project members. From the description above, it sounded as if Fossil wouldn't allow this workflow, even though it hurts no one and is arguably better than the alternative. If my patch sequence needs to be clean, and I must get it right on the first try, I'll either be leaving everything uncommitted until I'm done, which deprives me of useful internal checkpoints, or I'll invent some elaborate workflow around checkpointing in some other VCS and only showing the finished work to Fossil.
| 1clue wrote: | | I remember seeing a video about that, it's a huge PITA. Never had to try it. Didn't know that the file exists anyway, which makes mistakes like accidentally adding binary build products problematic. This explains why some of our older repositories are so huge. |
As I understand it, the huge pain is by design. It's supposed to be very hard to lose work and to be very hard to quietly change history. Yes, this is inconvenient for projects which pick up pollution. Most projects that worry about this set up some sort of commit hook to prevent publishing polluted history into the master copy. If caught before publication, cleaning it is much easier. You only need to change the history of the person(s) who have polluted branches, and if that can be isolated to the initial polluter and possibly an upstream maintainer, that's far less trouble than changing the history that everyone has copied. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Wed Jun 27, 2018 3:07 am Post subject: |
|
|
I use git. I am skeptical that fossil is any better, or that anything else is better for my needs. I don't really see a huge difficulty with git command line, and even so there is google, and for the rare times I need something more sophisticated than the command line there are plenty of gui tools. I think I've opened a git gui maybe once in the last 3 years or so, for history browsing.
Whether I use github or not, or whether I use any other site, is another discussion. Git does not require a server, and does not lack features I think I need.
Edit: This whole thread is about paranoia with respect to Microsoft owning github. While I agree with a good share of that paranoia, and while I have a github account, I am not particularly bothered by the prospect of moving. Git itself is fine, healthy and every bit as flaky, temperamental and lovable as it has ever been. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2297
Location: Adendorf, Germany
|
| Posted: Wed Jun 27, 2018 7:08 am Post subject: |
|
|
| Hu wrote: | | I think mv's concern was that fossil treats every commit as "publish", even those that you have not yet published to anyone. |
I just wanted to add that one of the strongest reasons to migrate from Subversion to Git was exactly that.
If Fossil does a direct "push" / "publish" with every "commit" / "check-in", then it is off the table forever. This idiocy from SVN lead to so much garbage and huge amounts of problems in so many repositories I had to work with, I'd never want that back.
However, I remember having read something about a "sync mode" or something like that. Like this behavior was configurable in Fossil, meaning it can do both, right?
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Jun 27, 2018 8:18 pm Post subject: |
|
|
| Hu wrote: | | I think mv's concern was that fossil treats every commit as "publish" |
No. Mistakes can and do always happen. It is quite unusual that even on an experimental branch (which you do not want to keep only locally) it is necessary to have a careful review by 2-3 persons for every upload. And even they could easily miss e.g. an adding of an unintended file. In any case, it seems then that this project is then only for huge companies who can afford such a costly work-flow.
| Quote: | | Once you publish it, you can't pretend that you didn't |
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). |
|
| 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
