Re: to git or not to git

2018-09-14 Thread Bjoern Schiessle
many of the other alternatives. You can click a button to fork a > project, you can start "watching" certain projects and get email > notifications, you can download the sources without needing Git, you > have an interface of markdown that every project adapts and the README > i

Innovation, funding and FS (was: to git or not to git)

2018-09-14 Thread Bernhard E. Reiter
Hi Andreas, Am Donnerstag 13 September 2018 17:05:41 schrieb Andreas Nilsson: > By the phrasing "leading provider" I assume that it means a company > that won't share the software innovations with the rest of the > community so that all can benefit. yes. > If this is the case then I would

Re: to git or not to git

2018-09-13 Thread Andreas Nilsson
s and get email notifications, you can download the sources without needing Git, you have an interface of markdown that every project adapts and the README is presented as if it were a web page. I am at a loss right now of suggestions or methods or ideas to counter Github but it sounds easy enough to

Re: to git or not to git

2018-09-11 Thread Stefano Maffulli
On Mon, Sep 10, 2018 at 2:25 AM Bernhard E. Reiter wrote: > The argument is about how to counter the network-effect that will makes it > easier and easier for a leading provider to get more ahead of others. > And it is about what is a more sustainable choice. One thing that I really

Re: to git or not to git

2018-09-11 Thread Michael Kesper
dies in a week long develop/rewrite cycle (did you consider that possibility?). Additionally you can use it to keep your repo in always-fast-forward state with linear, easy to follow history. Better explanation than I can do: https://sandofsky.com/blog/git-workflow.html My three pluses: + Review/Tests:

Re: to git or not to git

2018-09-10 Thread Bernhard E. Reiter
makes it easier and easier for a leading provider to get more ahead of others. And it is about what is a more sustainable choice. The money that Github is earning with helping to develop proprietary software, allows it to innovate fast and turn a user experience of git into a user experience of g

Re: to git or not to git

2018-09-10 Thread Paul Boddie
n upgrade and with Akonadi now playing around with my mail, hopefully not losing any, I sympathise with you in this situation. > Personally, I don't think we need to dive down into completely different > VCS software just because a VCS repository provider decided to go evil. > We can still use G

Re: to git or not to git

2018-09-08 Thread Adonay Felipe Nogueira
decided to go evil. We can still use Git but push people to not to use GitHub, not because of the recent Microsoft acquisition, but due to a problem we have been facing many months before that, which is even worse than the acquisition: non-free software being forced to the people who visit

Re: to git or not to git

2018-09-07 Thread Timothy Pearson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/07/2018 08:41 AM, evaggelos balaskas wrote: > Without derailing too much this wonderful discussion, I would like to make a > comment on lost commits/code. > > IMHO git is not a backup solution, its a version control system.

Re: to git or not to git

2018-09-07 Thread evaggelos balaskas
Without derailing too much this wonderful discussion, I would like to make a comment on lost commits/code. IMHO git is not a backup solution, its a version control system. sometimes we forgot this simple but important tiny thing so freq commits (even on a local cloned repo or branch

hg SCM, history rewriting (Re: to git or not to git)

2018-09-07 Thread Bernhard E. Reiter
Am Donnerstag 06 September 2018 22:40:49 schrieb Timothy Pearson: > > I think you could do something similar to git with Mercurial but it > > wouldn't be exactly the same. > As long as the general class of functionality is present, that's fine. https://www.mercuri

Re: to git or not to git

2018-09-06 Thread Timothy Pearson
control system. Of course, those people used to non-distributed > systems may be in the habit of batching their commits for several unrelated > issues because they are used to a centralised model where committing a change > involves sharing it with everyone else. > > I think you could do s

Re: to git or not to git

2018-09-06 Thread Timothy Pearson
side it looks like interactive >> rebases are not as easy as they are with git, and I really use them a >> lot (I write several features and test them all together, so I often >> squash my fixes in the original commit before pushing). > > Yes, I think there's a compromise between fle

Re: to git or not to git

2018-09-06 Thread David Boddie
d to non-distributed systems may be in the habit of batching their commits for several unrelated issues because they are used to a centralised model where committing a change involves sharing it with everyone else. I think you could do something similar to git with Mercu

Re: to git or not to git

2018-09-06 Thread David Boddie
On Wed Sep 5 19:44:20 UTC 2018, Alessandro Rubini wrote: > Today I read some (most?) documents on the project's site, and I see > that it's very similar, but on the flip side it looks like interactive > rebases are not as easy as they are with git, and I really use them a > lot (I w

pros for hg instead of git (was: to git or not to git)

2018-09-06 Thread Bernhard E. Reiter
xperience it is a sound option and comes with comparable power, if compared to git. > but on the flip side it looks like interactive > rebases are not as easy as they are with git, and I really use them a > lot (I write several features and test them all together, so I often > squash my fixes i

Re: to git or not to git

2018-09-05 Thread Alessandro Rubini
> Using Mercurial instead of git is also a bit like using another kernel > instead of Linux. It seems unnecessary to use something else when you already > have something that works, but it's useful to have working options in case > you find yourself using a device without

Re: to git or not to git

2018-08-31 Thread David Boddie
On Fri Aug 31 11:03:22 UTC 2018, Alessandro Rubini wrote: > > * Use hg or other trackers if you can. > > why? It's already oh so difficult to get people make decent commits to > git, where at least I can point to all the world doing that... Bernhard gave some good reasons

Re: to git or not to git

2018-08-31 Thread Bernhard E. Reiter
Am Freitag 31 August 2018 13:03:22 schrieb Alessandro Rubini: > > * Use hg or other trackers if you can. > > why? It's already oh so difficult to get people make decent commits to > git, where at least I can point to all the world doing that... * Because having a choice

Re: to git or not to git

2018-08-31 Thread Paul Boddie
On Friday 31. August 2018 13.03.22 Alessandro Rubini wrote: > > But I have a question for Berhnard, who says among other things I agree > with: > > * Use hg or other trackers if you can. > > why? It's already oh so difficult to get people make decent commits to > git, wh

Re: to git or not to git

2018-08-31 Thread Alessandro Rubini
and others, is try to self-host. As a second choice, get aware that nothing changed in github, which is not different from other providers, and use it as a data hosting facility (especially if we just use git and ignore the extra features). Also, using github (or gitlab, or both) as a back

Re: to git or not to git

2018-08-31 Thread Bernhard E. Reiter
Am Mittwoch 29 August 2018 07:04:05 schrieb Bastien: > https://www.gnu.org/software/repo-criteria-evaluation.html > https://www.gnu.org/software/repo-criteria.en.html Not taking new developments into account, though as the last evaluation came from 2016-04-13. -- FSFE -- Founding Member

Re: to git or not to git

2018-08-30 Thread Sandro Santilli
On Wed, Aug 29, 2018 at 07:04:05AM +0200, Bastien wrote: > Hi Alessandro, > > Alessandro Rubini writes: > > > How does the free software community feels in this respect? > > There is this: > > https://www.gnu.org/software/repo-criteria-evaluation.html >

Re: to git or not to git

2018-08-30 Thread Bastien
Hi Alessandro, Alessandro Rubini writes: > How does the free software community feels in this respect? There is this: https://www.gnu.org/software/repo-criteria-evaluation.html https://www.gnu.org/software/repo-criteria.en.html HTH, -- Bastien

Re: to git or not to git

2018-08-29 Thread Harald Welte
Hi Alessandro, On Mon, Aug 27, 2018 at 11:35:21PM +0200, Alessandro Rubini wrote: > So, besides self-hosting (unfeasible for whole-kernel repos) A remark for non-kernel-hackers: The linux.git tree is so large that you need a serious amount of RAM (and I/O bandwidth, and CPU) to host

Re: to git or not to git

2018-08-28 Thread Stefano Maffulli
On Mon, Aug 27, 2018 at 11:36 PM Alessandro Rubini wrote: > So, besides self-hosting (unfeasible for whole-kernel repos) I moved > to github. Well, not using it other than as a git repo why should I > care that the code (that I do not use) is not free? if you're not using the oth

Re: github and the like (Re: to git or not to git)

2018-08-28 Thread mray
throw in a relevant link to a project combining ActivityPub and git: https://github.com/forgefed/forgefed signature.asc Description: OpenPGP digital signature ___ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discu

github and the like (Re: to git or not to git)

2018-08-28 Thread Bernhard E. Reiter
gement product (git) So if we all want to have a good choice we need to work against those effects. Possible ways to act against some aspects * Go to the competition, e.g. Bitbucket (professional, proprietary, but offers hg), or Gitlab (neo-proprietary, no hg) * Pay for your service (so others ca

Re: to git or not to git

2018-08-27 Thread Duncan
With remote git repository hosting we have many options. You could self-host gogs or gitlab, or use many of the public instances of these, e.g. notabug.org or 0xacab.org. Or just host good old cgit somewhere safe. Or indeed keep using github as a place/mirror to put code. But with repository

to git or not to git

2018-08-27 Thread Alessandro Rubini
owners. Not nice. So, besides self-hosting (unfeasible for whole-kernel repos) I moved to github. Well, not using it other than as a git repo why should I care that the code (that I do not use) is not free? Maybe because I contribute visibility to that specific unfree provider, but they were