Re: [ros-dev] Microsoft switched to Git (status?)

[Neo Love]

At the risk of flogging a dead horse,
I found the following assessment rather interesting:

https://svnvsgit.com/

Are we leaving old reliable SVN because some big-shots did?
What's the verdict?

WBR // L.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

LOL!

Didn't the chromium people did just that earlier?

On 25 February 2017 at 02:12, Alex Ionescu <ion...@videotron.ca> wrote:

> I think I'm going to upload two PDF files to prove my point.
>
> On Thu, Feb 16, 2017 at 11:25 PM Hermès BÉLUSCA-MAÏTO <
> hermes.belu...@sfr.fr> wrote:
>
>> Hi ! Here are some thoughts as an answer to Ziliang's mail:
>>
>> > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de
>> Zachary Gorden
>> > Envoyé : jeudi 16 février 2017 23:03
>> > À : ReactOS Development List
>> > Objet : Re: [ros-dev] Microsoft switched to Git
>>
>> > The fact that git has problems maintain a large history is ONE of the
>> limitations that prompted them to develop GVFS. There are several comments
>> on the first page in the discussion of the ars technica article on GVFS
>> that talk about git's issues with long histories:
>> > https://arstechnica.com/information-technology/2017/
>> 02/microsoft-hosts-the-windows-source-in-a-monstrous-
>> 300gb-git-repository/?comments=1
>> > I can't link directly to the comments, but if you search by user name
>> you jump right to them. Two especially relevant ones are by smengler and
>> zaqzlea. The one by zaqzlea is also rather interesting if Linux itself has
>> truncated its own commit history, which is more than a bit disturbing from
>> > my perspective.
>>
>> I guess that this 'truncated history' story happened when Linus switched
>> to his newly-created Git the 16. April, 2005 :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/
>> linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> because, if one believes what's written inside
>> https://git.wiki.kernel.org/index.php/GraftPoint , "When Linus started
>> using git for maintaining his kernel tree there didn't exist any tools to
>> convert the old kernel history." Later on, when new features have been
>> added to Git, people were able to create Git repositories of Linux' code
>> before the 16/04/2005 Git transition, and then, to be able to see the whole
>> Linux history, you need to use the so-called graft points. Examples are
>> given here:
>> http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-
>> repository-with-full-history
>> https://archive.org/details/git-history-of-linux
>>
>>
>> > We also see a few remarks by a guy calling himself scuttle22 who claims
>> that truncating history and dropping it is "common practice" and
>> acceptable. His original posts have all been downvoted to oblivion,
>> presumably because others take a less lackadaisical perspective
>> > on preserving history for purposes of documentation and accountability.
>>
>> This is possibly "common practice", maybe in order to reduce the git
>> repos... In there: http://stackoverflow.com/questions/4515580/how-do-i-
>> remove-the-old-history-from-a-git-repository , someone ask for example
>> how to trim the history before a certain date, while the complete copy of
>> history is kept in an archive repository
>>
>>
>> I also take the occasion to mention the peculiar possibility, with Git,
>> to have a repository having multiple roots ("initial commits"): for
>> example, someone did the error once in the linux kernel repo:
>> http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01926.html .
>>
>> Best,
>> Hermès
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> Best regards,
> Alex Ionescu
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Alex Ionescu]

I think I'm going to upload two PDF files to prove my point.

On Thu, Feb 16, 2017 at 11:25 PM Hermès BÉLUSCA-MAÏTO <hermes.belu...@sfr.fr>
wrote:

> Hi ! Here are some thoughts as an answer to Ziliang's mail:
>
> > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Zachary
> Gorden
> > Envoyé : jeudi 16 février 2017 23:03
> > À : ReactOS Development List
> > Objet : Re: [ros-dev] Microsoft switched to Git
>
> > The fact that git has problems maintain a large history is ONE of the
> limitations that prompted them to develop GVFS. There are several comments
> on the first page in the discussion of the ars technica article on GVFS
> that talk about git's issues with long histories:
> >
> https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-windows-source-in-a-monstrous-300gb-git-repository/?comments=1
> > I can't link directly to the comments, but if you search by user name
> you jump right to them. Two especially relevant ones are by smengler and
> zaqzlea. The one by zaqzlea is also rather interesting if Linux itself has
> truncated its own commit history, which is more than a bit disturbing from
> > my perspective.
>
> I guess that this 'truncated history' story happened when Linus switched
> to his newly-created Git the 16. April, 2005 :
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> because, if one believes what's written inside
> https://git.wiki.kernel.org/index.php/GraftPoint , "When Linus started
> using git for maintaining his kernel tree there didn't exist any tools to
> convert the old kernel history." Later on, when new features have been
> added to Git, people were able to create Git repositories of Linux' code
> before the 16/04/2005 Git transition, and then, to be able to see the whole
> Linux history, you need to use the so-called graft points. Examples are
> given here:
>
> http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repository-with-full-history
> https://archive.org/details/git-history-of-linux
>
>
> > We also see a few remarks by a guy calling himself scuttle22 who claims
> that truncating history and dropping it is "common practice" and
> acceptable. His original posts have all been downvoted to oblivion,
> presumably because others take a less lackadaisical perspective
> > on preserving history for purposes of documentation and accountability.
>
> This is possibly "common practice", maybe in order to reduce the git
> repos... In there:
> http://stackoverflow.com/questions/4515580/how-do-i-remove-the-old-history-from-a-git-repository
> , someone ask for example how to trim the history before a certain date,
> while the complete copy of history is kept in an archive repository
>
>
> I also take the occasion to mention the peculiar possibility, with Git, to
> have a repository having multiple roots ("initial commits"): for example,
> someone did the error once in the linux kernel repo:
> http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01926.html .
>
> Best,
> Hermès
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

-- 
Best regards,
Alex Ionescu
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Zachary Gorden]

The fact that git has problems maintain a large history is ONE of the
limitations that prompted them to develop GVFS. There are several comments
on the first page in the discussion of the ars technica article on GVFS
that talk about git's issues with long histories:
https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-windows-source-in-a-monstrous-300gb-git-repository/?comments=1

I can't link directly to the comments, but if you search by user name you
jump right to them. Two especially relevant ones are by smengler and
zaqzlea. The one by zaqzlea is also rather interesting if Linux itself has
truncated its own commit history, which is more than a bit disturbing from
my perspective. We also see a few remarks by a guy calling himself
scuttle22 who claims that truncating history and dropping it is "common
practice" and acceptable. His original posts have all been downvoted to
oblivion, presumably because others take a less lackadaisical perspective
on preserving history for purposes of documentation and accountability.

The patches have apparently been submitted upstream. I do not know what
state they are in the review process for acceptance. I also don't know what
support for Linux is with the current patchset. If all of you are dead set
on migrating to git, that is ultimately your choice, but frankly there are
several things that you need to keep in mind and develop policies about to
keep the git repo from becoming useless for things like tracking history
and cross-referencing things between what different developers do.

On Thu, Feb 16, 2017 at 3:38 PM, Alex Ionescu  wrote:

>  which have nothing to do with history. And which have now been
> publically made available/fixed.
> Best regards,
> Alex Ionescu
>
>
> On Thu, Feb 16, 2017 at 12:14 PM, Zachary Gorden
>  wrote:
> > It was not zero problems. Their entire creation of the git virtual file
> > system was to overcome git's limitations.
> >
> > On Thu, Feb 16, 2017 at 2:07 PM, Alex Ionescu 
> wrote:
> >>
> >> Sounds like a bug in their migration/etc tool. MS has history going
> >> back to 1984 and migrated everything to Git with zero problems.
> >>
> >> At some point you should apply Ionescu's Razor: "Hmmm, a company of
> >> 150,000 developers and the most complicated and oldest series of
> >> repositories in the world, was able to move to Git, including while
> >> employing people who have been there for 30 years and used to other,
> >> older systems but 30 open source developers can't make that change
> >> because X". It follows from this that X is bullshit.
> >>
> >> On the polluting history, again, just read commits that have [FOOBAR]
> >> in them, and ignore others. Write a post-commit hook to rewrite/squash
> >> them.
> >> Best regards,
> >> Alex Ionescu
> >>
> >>
> >> On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden
> >>  wrote:
> >> > The project that I worked with using git has history going back to
> 1988.
> >> > They certainly didn't start with git, nor did they necessarily start
> >> > with
> >> > any revision control at the beginning, but after they migrated to it
> >> > they
> >> > discovered the history problem.
> >> >
> >> > On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck 
> wrote:
> >> >>
> >> >> Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
> >> >> > That being said, that type of "dirty history" only happens if you
> >> >> > heavily work with branches. That's not how reactos developers work
> --
> >> >> > we
> >> >> > don't open PRs and separate branches for every checkin.
> >> >> >
> >> >> > These ALL sound like manufactured problems or poor/strange use of
> >> >> > git.
> >> >>
> >> >> That merge hell is easily reproducible using my default Git setup:
> >> >>
> >> >> 1) Change something in your clone of master and do a "git commit".
> >> >> 2) Let someone else change something in his clone of master and let
> him
> >> >> "git commit" and "git push" it.
> >> >> 3) Try to "git push" your commit, won't work because of the commit of
> >> >> the other person.
> >> >> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
> >> >> automatic merge of both masters and pollute your history.
> >> >>
> >> >> You see, not a single extra branch is involved and yet we get two
> >> >> parallel streams of history.
> >> >>
> >> >> Rafal's mentioned "pull.rebase" option sounds promising, but can we
> >> >> enforce that somehow?
> >> >>
> >> >>
> >> >> - Colin
> >> >>
> >> >> ___
> >> >> Ros-dev mailing list
> >> >> Ros-dev@reactos.org
> >> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >> >
> >> >
> >> >
> >> > ___
> >> > Ros-dev mailing list
> >> > Ros-dev@reactos.org
> >> > http://www.reactos.org/mailman/listinfo/ros-dev
> >> >
> >>
> >> ___
> >> Ros-dev mailing 

Re: [ros-dev] Microsoft switched to Git

[Zachary Gorden]

It was not zero problems. Their entire creation of the git virtual file
system was to overcome git's limitations.

On Thu, Feb 16, 2017 at 2:07 PM, Alex Ionescu  wrote:

> Sounds like a bug in their migration/etc tool. MS has history going
> back to 1984 and migrated everything to Git with zero problems.
>
> At some point you should apply Ionescu's Razor: "Hmmm, a company of
> 150,000 developers and the most complicated and oldest series of
> repositories in the world, was able to move to Git, including while
> employing people who have been there for 30 years and used to other,
> older systems but 30 open source developers can't make that change
> because X". It follows from this that X is bullshit.
>
> On the polluting history, again, just read commits that have [FOOBAR]
> in them, and ignore others. Write a post-commit hook to rewrite/squash
> them.
> Best regards,
> Alex Ionescu
>
>
> On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden
>  wrote:
> > The project that I worked with using git has history going back to 1988.
> > They certainly didn't start with git, nor did they necessarily start with
> > any revision control at the beginning, but after they migrated to it they
> > discovered the history problem.
> >
> > On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck  wrote:
> >>
> >> Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
> >> > That being said, that type of "dirty history" only happens if you
> >> > heavily work with branches. That's not how reactos developers work --
> we
> >> > don't open PRs and separate branches for every checkin.
> >> >
> >> > These ALL sound like manufactured problems or poor/strange use of git.
> >>
> >> That merge hell is easily reproducible using my default Git setup:
> >>
> >> 1) Change something in your clone of master and do a "git commit".
> >> 2) Let someone else change something in his clone of master and let him
> >> "git commit" and "git push" it.
> >> 3) Try to "git push" your commit, won't work because of the commit of
> >> the other person.
> >> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
> >> automatic merge of both masters and pollute your history.
> >>
> >> You see, not a single extra branch is involved and yet we get two
> >> parallel streams of history.
> >>
> >> Rafal's mentioned "pull.rebase" option sounds promising, but can we
> >> enforce that somehow?
> >>
> >>
> >> - Colin
> >>
> >> ___
> >> Ros-dev mailing list
> >> Ros-dev@reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Alex Ionescu]

Sounds like a bug in their migration/etc tool. MS has history going
back to 1984 and migrated everything to Git with zero problems.

At some point you should apply Ionescu's Razor: "Hmmm, a company of
150,000 developers and the most complicated and oldest series of
repositories in the world, was able to move to Git, including while
employing people who have been there for 30 years and used to other,
older systems but 30 open source developers can't make that change
because X". It follows from this that X is bullshit.

On the polluting history, again, just read commits that have [FOOBAR]
in them, and ignore others. Write a post-commit hook to rewrite/squash
them.
Best regards,
Alex Ionescu


On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden
 wrote:
> The project that I worked with using git has history going back to 1988.
> They certainly didn't start with git, nor did they necessarily start with
> any revision control at the beginning, but after they migrated to it they
> discovered the history problem.
>
> On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck  wrote:
>>
>> Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
>> > That being said, that type of "dirty history" only happens if you
>> > heavily work with branches. That's not how reactos developers work -- we
>> > don't open PRs and separate branches for every checkin.
>> >
>> > These ALL sound like manufactured problems or poor/strange use of git.
>>
>> That merge hell is easily reproducible using my default Git setup:
>>
>> 1) Change something in your clone of master and do a "git commit".
>> 2) Let someone else change something in his clone of master and let him
>> "git commit" and "git push" it.
>> 3) Try to "git push" your commit, won't work because of the commit of
>> the other person.
>> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
>> automatic merge of both masters and pollute your history.
>>
>> You see, not a single extra branch is involved and yet we get two
>> parallel streams of history.
>>
>> Rafal's mentioned "pull.rebase" option sounds promising, but can we
>> enforce that somehow?
>>
>>
>> - Colin
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Magnus Johnsson]

You could enforce it via.. uh.. communication? :) (not trying to be snarky,
just thinking out loud)

Like, maintainers are the only ones getting push access to the master,
right? So you make sure anyone getting access to push things to the master
has that option used. Anyone not having access to it can only submit pull
requests, and you can easily see in the pull request if it will pollute the
history? It feels about right.
On github you have a setting on a repo, that lets you set a template for
pull request descriptions. In it, you can ask people to verify that they
have rebased. :).
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Zachary Gorden]

The project that I worked with using git has history going back to 1988.
They certainly didn't start with git, nor did they necessarily start with
any revision control at the beginning, but after they migrated to it they
discovered the history problem.

On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck  wrote:

> Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
> > That being said, that type of "dirty history" only happens if you
> > heavily work with branches. That's not how reactos developers work -- we
> > don't open PRs and separate branches for every checkin.
> >
> > These ALL sound like manufactured problems or poor/strange use of git.
>
> That merge hell is easily reproducible using my default Git setup:
>
> 1) Change something in your clone of master and do a "git commit".
> 2) Let someone else change something in his clone of master and let him
> "git commit" and "git push" it.
> 3) Try to "git push" your commit, won't work because of the commit of
> the other person.
> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
> automatic merge of both masters and pollute your history.
>
> You see, not a single extra branch is involved and yet we get two
> parallel streams of history.
>
> Rafal's mentioned "pull.rebase" option sounds promising, but can we
> enforce that somehow?
>
>
> - Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Colin Finck]

Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
> That being said, that type of "dirty history" only happens if you
> heavily work with branches. That's not how reactos developers work -- we
> don't open PRs and separate branches for every checkin.
> 
> These ALL sound like manufactured problems or poor/strange use of git.

That merge hell is easily reproducible using my default Git setup:

1) Change something in your clone of master and do a "git commit".
2) Let someone else change something in his clone of master and let him
"git commit" and "git push" it.
3) Try to "git push" your commit, won't work because of the commit of
the other person.
4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
automatic merge of both masters and pollute your history.

You see, not a single extra branch is involved and yet we get two
parallel streams of history.

Rafal's mentioned "pull.rebase" option sounds promising, but can we
enforce that somehow?


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Alex Ionescu]

I too have no idea where this "history limit" comes into play. I work on
and have repos spaning 50-100 developers working on dozens of thousands of
branches over two dozen repos with almost 8 years of history. Some people
rebase, but most people don't.

It is extremely easy to have a clean history due to the fact we enforce the
"[COMPONENT] Description" commit message (and can use a git hook to make
sure it looks this way). It is then trivial to write a script that only
looks for those commits. Heck you can even auto-squash/rebase anything that
doesn't match.

That being said, that type of "dirty history" only happens if you heavily
work with branches. That's not how reactos developers work -- we don't open
PRs and separate branches for every checkin.

These ALL sound like manufactured problems or poor/strange use of git.

On Thu, Feb 16, 2017 at 12:02 AM David Quintana (gigaherz) <
gigah...@gmail.com> wrote:

> If git has an upper limit on history, it's the first time I hear about it,
> and it would be an issue I was simply not aware of. So far as I was aware,
> git just keeps a parent hash on each commit, and the GC just deletes
> commits without any reference. In fact, we use Git at my current job, and
> the history goes back many years, and it seems perfectly capable of
> tracking it. And no, we don't rebase or squash, ever. We are not allowed to
> do any operation that changes commit history. So it's quite a mess of merge
> commits, but even then it's manageable.
>
> I disagree on needing a single person responsible for merges. The the PR
> workflow we have at my current job is that the developer submits a PR for
> review, and adds to the PR two other developers, who have to approve the
> changes or request fixes. Once it's approved, the original developer can
> click the merge button themselves. For external PRs done by contributors,
> then one of the reviewers is the responsible for clicking the merge button.
>
> And even if you do choose to require a commit-master, with the way
> github's merge button works, you can choose to have a merge commit, or to
> squash & rebase implicitly, and the history ends up with one single commit
> attributed to all the developers that were involved in the merge. As an
> example, I have a hobby writing Minecraft mods, and they use Forge to work:
> https://github.com/MinecraftForge/MinecraftForge/commits/1.11.x -- you'll
> see many " commited with LexManos". That's because there's an
> author, and a commiter, in the git info.
>
> I do agree, git history can get messy, and ugly, and hard to track -- if
> you abuse merge commits. I, unlike Alex, am a fan of manual rebases, and
> leaving a clean history before you submit the changes for review. But I
> understand that constantly rewriting history means you end up with a
> fabricated history at the end. So the policy choices should probably either
> be no merges at all, or no rebasing at all. But that's where "git blame"
> comes in. With a proper tool, you can see exactly who changed a file, and
> when, and you can use it to track back the history of that file, or that
> specific line of code.
>
>
>
> On 16 February 2017 at 03:45, Zachary Gorden 
> wrote:
>
> I've used both git and svn in work environments. If all you do is git pull
> and git push, you end up with lots of noise in the commit log with git
> tracking every single merge because you don't rebase. Combined with the
> fact that git has an upper limit on how much history it can track and the
> solution literally being to purge history, I'm not exactly sure why all of
> you are so enthused about it. Unless the team wants to adopt having a
> single person being responsible for all commits going into the canonical
> master repo to avoid all of the problems with how git tracks history, the
> commit log is going to be next to useless for actual tracking of history.
> If you don't care about the commit history, then sure, go ahead, but I
> personally would like to be able to easily track changes back cleanly. We
> get that basically for free with svn right now. With git, the usage
> patterns that those of you pushing for git are promoting actively works
> against keeping a clean history.
>
> On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu  wrote:
>
> Sure, I didn't count git add because you can do it with git commit -a.
> git status/log are the same as the svn equivalents. just like git
> diff/svn diff. I was mainly referring to regular workflow.
>
> In fact, I think outside of stash (which is an optional, but awesome,
> feature) fetch and rebase (which I refuse to learn), all commands map
> 1:1 with svn. That's why I don't get this whole "it takes way more
> commands/steps in git".
>
> git commit -a -m "[BOOTLIB] Fix yet another bug]"
> git push
>
> Done.
>
> Best regards,
> Alex Ionescu
>
>
> On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
>  wrote:
> > My command set is a bit more 

Re: [ros-dev] Microsoft switched to Git

[Rafał Harabień]

You can change one config entry and you can forget about merging strategy:

|git config --globalpull.rebase true |

||You just have to force everyone to using it. Then simple git pull
automatically rebases. We use it in work for all projects and history is
linear.
||

W dniu 16.02.2017 o 09:37, Colin Finck pisze:
> Am 16.02.2017 um 03:45 schrieb Zachary Gorden:
>> I've used both git and svn in work environments. If all you do is git
>> pull and git push, you end up with lots of noise in the commit log with
>> git tracking every single merge because you don't rebase.
> To give a picture of what he is talking about:
>
>   http://fs5.directupload.net/images/170216/tfchxvni.png
>   (random example repo on GitHub)
>
> You see how parallel streams of history emerge with every new committer
> when just using git commit, git pull and git push. Commits in the list
> are not even in chronological order anymore.
>
> Now what is the least painful way to avoid these automatic merges?
> We don't want to make life harder for any Git user..
>
>
> - Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev




---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie 
antywirusowe Avast.
https://www.avast.com/antivirus
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Colin Finck]

Am 16.02.2017 um 03:45 schrieb Zachary Gorden:
> I've used both git and svn in work environments. If all you do is git
> pull and git push, you end up with lots of noise in the commit log with
> git tracking every single merge because you don't rebase.

To give a picture of what he is talking about:

  http://fs5.directupload.net/images/170216/tfchxvni.png
  (random example repo on GitHub)

You see how parallel streams of history emerge with every new committer
when just using git commit, git pull and git push. Commits in the list
are not even in chronological order anymore.

Now what is the least painful way to avoid these automatic merges?
We don't want to make life harder for any Git user..


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

If git has an upper limit on history, it's the first time I hear about it,
and it would be an issue I was simply not aware of. So far as I was aware,
git just keeps a parent hash on each commit, and the GC just deletes
commits without any reference. In fact, we use Git at my current job, and
the history goes back many years, and it seems perfectly capable of
tracking it. And no, we don't rebase or squash, ever. We are not allowed to
do any operation that changes commit history. So it's quite a mess of merge
commits, but even then it's manageable.

I disagree on needing a single person responsible for merges. The the PR
workflow we have at my current job is that the developer submits a PR for
review, and adds to the PR two other developers, who have to approve the
changes or request fixes. Once it's approved, the original developer can
click the merge button themselves. For external PRs done by contributors,
then one of the reviewers is the responsible for clicking the merge button.

And even if you do choose to require a commit-master, with the way github's
merge button works, you can choose to have a merge commit, or to squash &
rebase implicitly, and the history ends up with one single commit
attributed to all the developers that were involved in the merge. As an
example, I have a hobby writing Minecraft mods, and they use Forge to work:
https://github.com/MinecraftForge/MinecraftForge/commits/1.11.x -- you'll
see many " commited with LexManos". That's because there's an
author, and a commiter, in the git info.

I do agree, git history can get messy, and ugly, and hard to track -- if
you abuse merge commits. I, unlike Alex, am a fan of manual rebases, and
leaving a clean history before you submit the changes for review. But I
understand that constantly rewriting history means you end up with a
fabricated history at the end. So the policy choices should probably either
be no merges at all, or no rebasing at all. But that's where "git blame"
comes in. With a proper tool, you can see exactly who changed a file, and
when, and you can use it to track back the history of that file, or that
specific line of code.



On 16 February 2017 at 03:45, Zachary Gorden 
wrote:

> I've used both git and svn in work environments. If all you do is git pull
> and git push, you end up with lots of noise in the commit log with git
> tracking every single merge because you don't rebase. Combined with the
> fact that git has an upper limit on how much history it can track and the
> solution literally being to purge history, I'm not exactly sure why all of
> you are so enthused about it. Unless the team wants to adopt having a
> single person being responsible for all commits going into the canonical
> master repo to avoid all of the problems with how git tracks history, the
> commit log is going to be next to useless for actual tracking of history.
> If you don't care about the commit history, then sure, go ahead, but I
> personally would like to be able to easily track changes back cleanly. We
> get that basically for free with svn right now. With git, the usage
> patterns that those of you pushing for git are promoting actively works
> against keeping a clean history.
>
> On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu  wrote:
>
>> Sure, I didn't count git add because you can do it with git commit -a.
>> git status/log are the same as the svn equivalents. just like git
>> diff/svn diff. I was mainly referring to regular workflow.
>>
>> In fact, I think outside of stash (which is an optional, but awesome,
>> feature) fetch and rebase (which I refuse to learn), all commands map
>> 1:1 with svn. That's why I don't get this whole "it takes way more
>> commands/steps in git".
>>
>> git commit -a -m "[BOOTLIB] Fix yet another bug]"
>> git push
>>
>> Done.
>>
>> Best regards,
>> Alex Ionescu
>>
>>
>> On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
>>  wrote:
>> > My command set is a bit more extended:
>> >
>> > git clone -- similar to svn checkout into a new folder
>> > git checkout -- for changing the current branch
>> > git pull -- effectively the same as "svn update", xcept it gets the
>> entire
>> > change history, not just the latest commit data
>> > git push [--force] -- for sending changes into the repository
>> > git fetch -- downloads stuff but doesn't apply it to the checkout copy
>> > git merge -- can be used to merge the remote data (in which case it's
>> like
>> > svn update), or to merge from another branch
>> > git branch
>> > git add
>> > git commit
>> > git stash save/pop -- can be used to temporarily undo some changes, and
>> be
>> > able to recover them afterward
>> > git status, git log, ... -- for getting info about the state of the
>> > repository and the uncommited changes
>> > ... and more I that I use less often
>> >
>> > I do agree that it is a bit annoying that git has so much trouble
>> pulling
>> > with local changes, and that 

Re: [ros-dev] Microsoft switched to Git

[Zachary Gorden]

I've used both git and svn in work environments. If all you do is git pull
and git push, you end up with lots of noise in the commit log with git
tracking every single merge because you don't rebase. Combined with the
fact that git has an upper limit on how much history it can track and the
solution literally being to purge history, I'm not exactly sure why all of
you are so enthused about it. Unless the team wants to adopt having a
single person being responsible for all commits going into the canonical
master repo to avoid all of the problems with how git tracks history, the
commit log is going to be next to useless for actual tracking of history.
If you don't care about the commit history, then sure, go ahead, but I
personally would like to be able to easily track changes back cleanly. We
get that basically for free with svn right now. With git, the usage
patterns that those of you pushing for git are promoting actively works
against keeping a clean history.

On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu  wrote:

> Sure, I didn't count git add because you can do it with git commit -a.
> git status/log are the same as the svn equivalents. just like git
> diff/svn diff. I was mainly referring to regular workflow.
>
> In fact, I think outside of stash (which is an optional, but awesome,
> feature) fetch and rebase (which I refuse to learn), all commands map
> 1:1 with svn. That's why I don't get this whole "it takes way more
> commands/steps in git".
>
> git commit -a -m "[BOOTLIB] Fix yet another bug]"
> git push
>
> Done.
>
> Best regards,
> Alex Ionescu
>
>
> On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
>  wrote:
> > My command set is a bit more extended:
> >
> > git clone -- similar to svn checkout into a new folder
> > git checkout -- for changing the current branch
> > git pull -- effectively the same as "svn update", xcept it gets the
> entire
> > change history, not just the latest commit data
> > git push [--force] -- for sending changes into the repository
> > git fetch -- downloads stuff but doesn't apply it to the checkout copy
> > git merge -- can be used to merge the remote data (in which case it's
> like
> > svn update), or to merge from another branch
> > git branch
> > git add
> > git commit
> > git stash save/pop -- can be used to temporarily undo some changes, and
> be
> > able to recover them afterward
> > git status, git log, ... -- for getting info about the state of the
> > repository and the uncommited changes
> > ... and more I that I use less often
> >
> > I do agree that it is a bit annoying that git has so much trouble pulling
> > with local changes, and that is the one area where svn just simply works
> > better. In every other aspect, I have come to like the "git way" more.
> >
> > That said, I avoid commandline git as much as possible. I prefer to use
> > TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a
> > mac, and SourceTree is probably the least shitty frontend for git).
> >
> > I like to say, that for someone who knows Subversion, learning git
> starts by
> > realizing that all the usual svn concepts, apply to git, just NOT with
> the
> > remote repository. The svn-like commands work with the local repository
> > clone, and then it has a separate command set for interacting with
> remotes.
> > Of course it's not a 1:1 match, but it's a good starting point. If you
> are
> > able to "catch" that, then learning how to work with git becomes a LOT
> > easier.
> >
> >
> >
> > On 16 February 2017 at 00:31, Alex Ionescu  wrote:
> >>
> >> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
> >>  wrote:
> >> > Why is there a need for anything beyond "git commit" or "git push" or
> >> > "git
> >> > pull" to do anything?
> >>
> >> Good question. I've never used any other git command other than those
> >> (except git checkout). Oh, that's lie, I've also used "git branch",
> >> just like on svn, to create a branch.
> >>
> >> Sounds like you've never actually used git? I've never rebased in my
> >> life, and I don't know what other commands even exist.
> >>
> >> Best regards,
> >> Alex Ionescu
> >>
> >> ___
> >> Ros-dev mailing list
> >> Ros-dev@reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Alex Ionescu]

Sure, I didn't count git add because you can do it with git commit -a.
git status/log are the same as the svn equivalents. just like git
diff/svn diff. I was mainly referring to regular workflow.

In fact, I think outside of stash (which is an optional, but awesome,
feature) fetch and rebase (which I refuse to learn), all commands map
1:1 with svn. That's why I don't get this whole "it takes way more
commands/steps in git".

git commit -a -m "[BOOTLIB] Fix yet another bug]"
git push

Done.

Best regards,
Alex Ionescu


On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
 wrote:
> My command set is a bit more extended:
>
> git clone -- similar to svn checkout into a new folder
> git checkout -- for changing the current branch
> git pull -- effectively the same as "svn update", xcept it gets the entire
> change history, not just the latest commit data
> git push [--force] -- for sending changes into the repository
> git fetch -- downloads stuff but doesn't apply it to the checkout copy
> git merge -- can be used to merge the remote data (in which case it's like
> svn update), or to merge from another branch
> git branch
> git add
> git commit
> git stash save/pop -- can be used to temporarily undo some changes, and be
> able to recover them afterward
> git status, git log, ... -- for getting info about the state of the
> repository and the uncommited changes
> ... and more I that I use less often
>
> I do agree that it is a bit annoying that git has so much trouble pulling
> with local changes, and that is the one area where svn just simply works
> better. In every other aspect, I have come to like the "git way" more.
>
> That said, I avoid commandline git as much as possible. I prefer to use
> TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a
> mac, and SourceTree is probably the least shitty frontend for git).
>
> I like to say, that for someone who knows Subversion, learning git starts by
> realizing that all the usual svn concepts, apply to git, just NOT with the
> remote repository. The svn-like commands work with the local repository
> clone, and then it has a separate command set for interacting with remotes.
> Of course it's not a 1:1 match, but it's a good starting point. If you are
> able to "catch" that, then learning how to work with git becomes a LOT
> easier.
>
>
>
> On 16 February 2017 at 00:31, Alex Ionescu  wrote:
>>
>> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
>>  wrote:
>> > Why is there a need for anything beyond "git commit" or "git push" or
>> > "git
>> > pull" to do anything?
>>
>> Good question. I've never used any other git command other than those
>> (except git checkout). Oh, that's lie, I've also used "git branch",
>> just like on svn, to create a branch.
>>
>> Sounds like you've never actually used git? I've never rebased in my
>> life, and I don't know what other commands even exist.
>>
>> Best regards,
>> Alex Ionescu
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

My command set is a bit more extended:

   - git clone -- similar to svn checkout into a new folder
   - git checkout -- for changing the current branch
   - git pull -- effectively the same as "svn update", xcept it gets the
   entire change history, not just the latest commit data
   - git push [--force] -- for sending changes into the repository
   - git fetch -- downloads stuff but doesn't apply it to the checkout copy
   - git merge -- can be used to merge the remote data (in which case it's
   like svn update), or to merge from another branch
   - git branch
   - git add
   - git commit
   - git stash save/pop -- can be used to temporarily undo some changes,
   and be able to recover them afterward
   - git status, git log, ... -- for getting info about the state of the
   repository and the uncommited changes
   - ... and more I that I use less often

I do agree that it is a bit annoying that git has so much trouble pulling
with local changes, and that is the one area where svn just simply works
better. In every other aspect, I have come to like the "git way" more.

That said, I avoid commandline git as much as possible. I prefer to use
TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a
mac, and SourceTree is probably the least shitty frontend for git).

I like to say, that for someone who knows Subversion, learning git starts
by realizing that all the usual svn concepts, apply to git, just NOT with
the remote repository. The svn-like commands work with the local repository
clone, and then it has a separate command set for interacting with remotes.
Of course it's not a 1:1 match, but it's a good starting point. If you are
able to "catch" that, then learning how to work with git becomes a LOT
easier.



On 16 February 2017 at 00:31, Alex Ionescu  wrote:

> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
>  wrote:
> > Why is there a need for anything beyond "git commit" or "git push" or
> "git
> > pull" to do anything?
>
> Good question. I've never used any other git command other than those
> (except git checkout). Oh, that's lie, I've also used "git branch",
> just like on svn, to create a branch.
>
> Sounds like you've never actually used git? I've never rebased in my
> life, and I don't know what other commands even exist.
>
> Best regards,
> Alex Ionescu
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Alex Ionescu]

On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
 wrote:
> Why is there a need for anything beyond "git commit" or "git push" or "git
> pull" to do anything?

Good question. I've never used any other git command other than those
(except git checkout). Oh, that's lie, I've also used "git branch",
just like on svn, to create a branch.

Sounds like you've never actually used git? I've never rebased in my
life, and I don't know what other commands even exist.

Best regards,
Alex Ionescu

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Giannis Adamopoulos]

I have worked with Github in the past using the rebase-only no-merge workflow 
and had no problem with GitHub Pull Requests.

ReactOS Development List  wrote on Wed, February 15th, 
2017, 12:28 PM:
> Am 15.02.2017 um 12:04 schrieb Ged Murphy:
> > That would allow devs that prefer SVN to mostly continue working as before, 
> > and give the devs who want to use git in a more traditional way the ability 
> > to branch off and work in a git style manner, then sync their changes back 
> > into 'trunk'.
> 
> Question is how is this "sync" going to happen?
> When multiple developers work on Git "trunk" at the same time without
> pulling before every commit, parallel history will be generated, which
> is later merged automatically. This soon looks messy in Git history and
> makes it hard to follow the chronologic stream of commits.
> 
> A strict rebase-only no-merge workflow would guarantee linear history
> like before, but breaks many of the cool Git features. We may not even
> be able to make use of GitHub Pull Requests..
> 
> Our situation is not really comparable to projects like Linux or WINE,
> because they only have a single person sitting at the "trunk" to commit
> patches, so parallel history cannot happen.
> 
> 
> - Colin
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Andreas Bjerkeholt]

If ReactOS at some point decides to actually move to Git, it would be nice
if Github is considered for hosting. It might lower the barrier of entry
for developers new to ReactOS, if they can look at the code, send PRs etc
like they're used to for other projects.
Github issues can of course be disabled in favour of continuing to use JIRA.

2017-02-15 18:01 GMT+01:00 Zachary Gorden :

> Why is there a need for anything beyond "git commit" or "git push" or "git
> pull" to do anything? Why should I, as a developer, be required to
> micromanage the revision control mechanism? That's the fundamental point of
> my previous message. If I have to spend more time getting a commit through
> to the canonical repo than I do making a change to the code, that suggests
> to me whatever tool I'm using for revision control is not fit for purpose.
> If dealing with the common case, of someone committing before you, cannot
> be automated cleanly by git out of the box, how is it a better tool than
> the likes of svn?
>
> On Wed, Feb 15, 2017 at 10:46 AM, Magnus Johnsson 
> wrote:
>
>> Zachary, that is some seriously valuable input :). I was going to write a
>> longer answer, with super simple answers, but I found that the super simple
>> solutions to these are all the top results on google, stackoverflow. Seems
>> like the situation has cleared up to be a *lot* simpler these days, like 2
>> to 3 commands copy paste, with helpfull comments on the what and why's :).
>> Check it out?
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Magnus Johnsson]

Zachary, that is some seriously valuable input :). I was going to write a
longer answer, with super simple answers, but I found that the super simple
solutions to these are all the top results on google, stackoverflow. Seems
like the situation has cleared up to be a *lot* simpler these days, like 2
to 3 commands copy paste, with helpfull comments on the what and why's :).
Check it out?
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Zachary Gorden]

Until the following clumsiness in git get resolved, it remains in my
opinion an inferior revision control system to svn.

1) Attempts to push changes should not require any intervention on the part
of the user to pull and rebase if someone else got in a commit ahead of
time, this should be done automatically. I don't care that someone else
might have gotten a commit in first, especially if they're working on an
entirely different part of the repo. The only case where it should require
manual intervention is if a merge fails because we touched the same block
of code in the same file. Anything else, including touching different parts
of the same file, should be transparent.

2) Attempts to pull in general should not stumble because I've made changes
to a file and not added it. Git should be tracking changes automatically
and only require user intervention if, again, the pulled changes outright
conflicts with a local change, regardless of whether it's "added" or not.

3) If I commit multiple files at once, I should be able to roll back any
arbitrary number of those files instead of having to revert the entire
commit.

As a user, I should not need to have to fight with the revision control
software every time I need to make a change, nor should I need to tell the
revision control software what to track and how to track it. It's its
bloody job to do that, why should I suddenly have to take on additional
management responsibilities when I gain nothing of benefit in return? I
should not need to care about what anyone else is doing UNLESS we happen to
be trying to do the same thing. Considering every project wherein I've used
git the quickest solution to deal with git's merge cockups is to do a clean
checkout, I am unsure why everyone seems so enthusiastic about it. Are all
of you expecting to work in complete isolation from each other and never
have to deal with the inevitable when you try to commit? Cause avoiding
these sorts of problems in git requires a discipline and level of
coordination that this project has historically not demonstrated, whereas
our usage of svn has basically kept people relatively insulated from these
issues by virtue of the fact that svn handles most of them for you.

On Wed, Feb 15, 2017 at 9:11 AM, Magnus Johnsson 
wrote:

> Why use a hammer as a screwdriver just because it has worked before?
>
> 2017-02-15 16:04 GMT+01:00 Javier Agustìn Fernàndez Arroyo <
> elh...@gmail.com>:
>
>> why change a working solution?
>>
>> its a questin i have done myself many times :P
>>
>>
>>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Hermès BÉLUSCA-MAÏTO]

Because a « working solution » does not mean it is still optimal / efficient…

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : mercredi 15 février 2017 16:04
À : ReactOS Development List
Objet : Re: [ros-dev] Microsoft switched to Git

 

why change a working solution?

its a questin i have done myself many times :P

 

On Wed, Feb 15, 2017 at 3:18 PM, Brandin L Claar <bran...@remodulate.com> wrote:

Just move everything to GitHub:

 

https://github.com/blog/966-improved-subversion-client-support

-brandin


On Feb 15, 2017, at 06:32, ros-dev-requ...@reactos.org wrote:

Send Ros-dev mailing list submissions to
   ros-dev@reactos.org

To subscribe or unsubscribe via the World Wide Web, visit
   http://www.reactos.org/mailman/listinfo/ros-dev
or, via email, send a message with subject or body 'help' to
   ros-dev-requ...@reactos.org

You can reach the person managing the list at
   ros-dev-ow...@reactos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ros-dev digest..."


Today's Topics:

  1. Re: Microsoft switched to Git (Ged Murphy)
  2. Re: Microsoft switched to Git (David Quintana (gigaherz))
  3. Re: Microsoft switched to Git (Colin Finck)
  4. Re: Microsoft switched to Git (David Quintana (gigaherz))
  5. Re: Microsoft switched to Git (Colin Finck)


--

Message: 1
Date: Wed, 15 Feb 2017 11:04:52 -
From: "Ged Murphy" <gedmurphy.mailli...@gmail.com>
To: "'ReactOS Development List'" <ros-dev@reactos.org>
Subject: Re: [ros-dev] Microsoft switched to Git
Message-ID: <004701d2877b$55983010$00c89030$@gmail.com>
Content-Type: text/plain;charset="utf-8"

I think the easiest path is to switch to a centralized style model using git.
That is, we have a master copy (aka trunk) that gives the feel of our existing 
model. That would allow devs that prefer SVN to mostly continue working as 
before, and give the devs who want to use git in a more traditional way the 
ability to branch off and work in a git style manner, then sync their changes 
back into 'trunk'.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: 15 February 2017 10:53
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Microsoft switched to Git

Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):



The number doesn't matter. The ReactOS project can't afford to lost 

any long-time members. Git would be a benefit for all of us, but it 

has to be a benefit for ALL of us.


Let's not forget:

- Part of the reasons developers had against Git may have been resolved by now.
- Part of the problem may be that "Git is so different" to some devs, but I 
think this can be resolved by a detailed Wiki article showing how to do the 
same thing in SVN and Git. We already wrote such articles for TortoiseSVN after 
all!
- And finally, we first need a plan for a Git move that doesn't suck. We tried 
SubGit and it failed for us. Then there is the "Merge workflow", which is 
supported very well by all tools, but creates a lot of parallel history. The 
"Rebase workflow" is more like what SVN does (keeping a linear history), but no 
idea how to enforce that with TortoiseGit.

I think if a team could look after these things and help moving each and every 
developer towards Git, it may even be doable for us.

Cheers,

Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




--

Message: 2
Date: Wed, 15 Feb 2017 12:18:40 +0100
From: "David Quintana (gigaherz)" <gigah...@gmail.com>
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] Microsoft switched to Git
Message-ID:
   <cadd3+ruo18pqos1qo+jchg5v2-hyrrjsz7va1pfgm+tprdb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

My belief is that the best path would be:

Phase 0: This is how we are now. We have SVN master (trunk), and a
read-only git mirror, and a semi-updated github mirror for when a
contributor really wants to submit git PRs.

Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
system is really really nice these days, but other solutions exist). Setup
a SVN mirror "bot" that creates one svn commit for each push/merge detected
in the master branch, and allows the buildbots to continue working as they
do now.

This would allow the existing svn-patch workflow to continue working, but
commits on svn wouldn't be allowed anymore. Developers are expected to at
least TRY to learn to use git (it's not that hard! I promise!).

Phase 2: We switch the buildbots and testbots to pull from git, enable
testbot access for git PRs (such as with a github bot that responds to
&

Re: [ros-dev] Microsoft switched to Git

[Javier Agustìn Fernàndez Arroyo]

why change a working solution?

its a questin i have done myself many times :P

On Wed, Feb 15, 2017 at 3:18 PM, Brandin L Claar <bran...@remodulate.com>
wrote:

> Just move everything to GitHub:
>
> https://github.com/blog/966-improved-subversion-client-support
>
> -brandin
>
> On Feb 15, 2017, at 06:32, ros-dev-requ...@reactos.org wrote:
>
> Send Ros-dev mailing list submissions to
>ros-dev@reactos.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
>ros-dev-requ...@reactos.org
>
> You can reach the person managing the list at
>ros-dev-ow...@reactos.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: Microsoft switched to Git (Ged Murphy)
>   2. Re: Microsoft switched to Git (David Quintana (gigaherz))
>   3. Re: Microsoft switched to Git (Colin Finck)
>   4. Re: Microsoft switched to Git (David Quintana (gigaherz))
>   5. Re: Microsoft switched to Git (Colin Finck)
>
>
> --
>
> Message: 1
> Date: Wed, 15 Feb 2017 11:04:52 -0000
> From: "Ged Murphy" <gedmurphy.mailli...@gmail.com>
> To: "'ReactOS Development List'" <ros-dev@reactos.org>
> Subject: Re: [ros-dev] Microsoft switched to Git
> Message-ID: <004701d2877b$55983010$00c89030$@gmail.com>
> Content-Type: text/plain;charset="utf-8"
>
> I think the easiest path is to switch to a centralized style model using
> git.
> That is, we have a master copy (aka trunk) that gives the feel of our
> existing model. That would allow devs that prefer SVN to mostly continue
> working as before, and give the devs who want to use git in a more
> traditional way the ability to branch off and work in a git style manner,
> then sync their changes back into 'trunk'.
>
>
> -Original Message-----
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org
> <ros-dev-boun...@reactos.org>] On Behalf Of Colin Finck
> Sent: 15 February 2017 10:53
> To: ros-dev@reactos.org
> Subject: Re: [ros-dev] Microsoft switched to Git
>
> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
>
> The number doesn't matter. The ReactOS project can't afford to lost
>
> any long-time members. Git would be a benefit for all of us, but it
>
> has to be a benefit for ALL of us.
>
>
> Let's not forget:
>
> - Part of the reasons developers had against Git may have been resolved by
> now.
> - Part of the problem may be that "Git is so different" to some devs, but
> I think this can be resolved by a detailed Wiki article showing how to do
> the same thing in SVN and Git. We already wrote such articles for
> TortoiseSVN after all!
> - And finally, we first need a plan for a Git move that doesn't suck. We
> tried SubGit and it failed for us. Then there is the "Merge workflow",
> which is supported very well by all tools, but creates a lot of parallel
> history. The "Rebase workflow" is more like what SVN does (keeping a linear
> history), but no idea how to enforce that with TortoiseGit.
>
> I think if a team could look after these things and help moving each and
> every developer towards Git, it may even be doable for us.
>
> Cheers,
>
> Colin
>
> _______________
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>
> --
>
> Message: 2
> Date: Wed, 15 Feb 2017 12:18:40 +0100
> From: "David Quintana (gigaherz)" <gigah...@gmail.com>
> To: ReactOS Development List <ros-dev@reactos.org>
> Subject: Re: [ros-dev] Microsoft switched to Git
> Message-ID:
><cadd3+ruo18pqos1qo+jchg5v2-hyrrjsz7va1pfgm+tprdb...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> My belief is that the best path would be:
>
> Phase 0: This is how we are now. We have SVN master (trunk), and a
> read-only git mirror, and a semi-updated github mirror for when a
> contributor really wants to submit git PRs.
>
> Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
> system is really really nice these days, but other solutions exist). Setup
> a SVN mirror "bot" that creates one svn commit for each push/merge detected
> in the master branch, and allows the buildbots to continue working as they
> do now.
>
> This would allow the existing svn-patch workflow to continue working, but

Re: [ros-dev] Microsoft switched to Git

[Brandin L Claar]

Just move everything to GitHub:

https://github.com/blog/966-improved-subversion-client-support

-brandin

> On Feb 15, 2017, at 06:32, ros-dev-requ...@reactos.org wrote:
> 
> Send Ros-dev mailing list submissions to
>ros-dev@reactos.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
>ros-dev-requ...@reactos.org
> 
> You can reach the person managing the list at
>ros-dev-ow...@reactos.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Microsoft switched to Git (Ged Murphy)
>   2. Re: Microsoft switched to Git (David Quintana (gigaherz))
>   3. Re: Microsoft switched to Git (Colin Finck)
>   4. Re: Microsoft switched to Git (David Quintana (gigaherz))
>   5. Re: Microsoft switched to Git (Colin Finck)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 15 Feb 2017 11:04:52 -
> From: "Ged Murphy" <gedmurphy.mailli...@gmail.com>
> To: "'ReactOS Development List'" <ros-dev@reactos.org>
> Subject: Re: [ros-dev] Microsoft switched to Git
> Message-ID: <004701d2877b$55983010$00c89030$@gmail.com>
> Content-Type: text/plain;charset="utf-8"
> 
> I think the easiest path is to switch to a centralized style model using git.
> That is, we have a master copy (aka trunk) that gives the feel of our 
> existing model. That would allow devs that prefer SVN to mostly continue 
> working as before, and give the devs who want to use git in a more 
> traditional way the ability to branch off and work in a git style manner, 
> then sync their changes back into 'trunk'.
> 
> 
> -----Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
> Sent: 15 February 2017 10:53
> To: ros-dev@reactos.org
> Subject: Re: [ros-dev] Microsoft switched to Git
> 
>> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
>> The number doesn't matter. The ReactOS project can't afford to lost 
>> any long-time members. Git would be a benefit for all of us, but it 
>> has to be a benefit for ALL of us.
> 
> Let's not forget:
> 
> - Part of the reasons developers had against Git may have been resolved by 
> now.
> - Part of the problem may be that "Git is so different" to some devs, but I 
> think this can be resolved by a detailed Wiki article showing how to do the 
> same thing in SVN and Git. We already wrote such articles for TortoiseSVN 
> after all!
> - And finally, we first need a plan for a Git move that doesn't suck. We 
> tried SubGit and it failed for us. Then there is the "Merge workflow", which 
> is supported very well by all tools, but creates a lot of parallel history. 
> The "Rebase workflow" is more like what SVN does (keeping a linear history), 
> but no idea how to enforce that with TortoiseGit.
> 
> I think if a team could look after these things and help moving each and 
> every developer towards Git, it may even be doable for us.
> 
> Cheers,
> 
> Colin
> 
> _______________
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
> 
> 
> 
> 
> --
> 
> Message: 2
> Date: Wed, 15 Feb 2017 12:18:40 +0100
> From: "David Quintana (gigaherz)" <gigah...@gmail.com>
> To: ReactOS Development List <ros-dev@reactos.org>
> Subject: Re: [ros-dev] Microsoft switched to Git
> Message-ID:
><cadd3+ruo18pqos1qo+jchg5v2-hyrrjsz7va1pfgm+tprdb...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> My belief is that the best path would be:
> 
> Phase 0: This is how we are now. We have SVN master (trunk), and a
> read-only git mirror, and a semi-updated github mirror for when a
> contributor really wants to submit git PRs.
> 
> Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
> system is really really nice these days, but other solutions exist). Setup
> a SVN mirror "bot" that creates one svn commit for each push/merge detected
> in the master branch, and allows the buildbots to continue working as they
> do now.
> 
> This would allow the existing svn-patch workflow to continue working, but
> commits on svn wouldn't be allowed anymore. Developers are expected to at
> least TRY to learn to use git (it's not that hard! I promise!).
> 
> Phase 2: We switch the buildbots and testbots to

Re: [ros-dev] Microsoft switched to Git

[Alex Ionescu]

How about I leave if we DON'T switch to Git? I fucking hate SVN now
(read my e-mail from 8 years ago on this topic, lol!).
Best regards,
Alex Ionescu


On Wed, Feb 15, 2017 at 3:32 AM, Colin Finck  wrote:
> Am 15.02.2017 um 12:18 schrieb David Quintana (gigaherz):
>> Setup a SVN mirror "bot" that creates one svn commit for each push/merge
>> detected in the master branch, and allows the buildbots to continue
>> working as they do now.
>
> Let's not have a Git repository with a parallel SVN mirror again. SubGit
> tried to accomplish this as a professional solution and it failed for us.
>
> There is no reason to take extra care of the Buildslaves at all.
> The same infra people, who would do the switch to Git, could also change
> the Buildslaves to use Git instead of SVN in the course of that.
>
>
> - Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Colin Finck]

Am 15.02.2017 um 12:18 schrieb David Quintana (gigaherz):
> Setup a SVN mirror "bot" that creates one svn commit for each push/merge
> detected in the master branch, and allows the buildbots to continue
> working as they do now.

Let's not have a Git repository with a parallel SVN mirror again. SubGit
tried to accomplish this as a professional solution and it failed for us.

There is no reason to take extra care of the Buildslaves at all.
The same infra people, who would do the switch to Git, could also change
the Buildslaves to use Git instead of SVN in the course of that.


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Colin Finck]

Am 15.02.2017 um 12:04 schrieb Ged Murphy:
> That would allow devs that prefer SVN to mostly continue working as before, 
> and give the devs who want to use git in a more traditional way the ability 
> to branch off and work in a git style manner, then sync their changes back 
> into 'trunk'.

Question is how is this "sync" going to happen?
When multiple developers work on Git "trunk" at the same time without
pulling before every commit, parallel history will be generated, which
is later merged automatically. This soon looks messy in Git history and
makes it hard to follow the chronologic stream of commits.

A strict rebase-only no-merge workflow would guarantee linear history
like before, but breaks many of the cool Git features. We may not even
be able to make use of GitHub Pull Requests..

Our situation is not really comparable to projects like Linux or WINE,
because they only have a single person sitting at the "trunk" to commit
patches, so parallel history cannot happen.


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

My belief is that the best path would be:

Phase 0: This is how we are now. We have SVN master (trunk), and a
read-only git mirror, and a semi-updated github mirror for when a
contributor really wants to submit git PRs.

Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
system is really really nice these days, but other solutions exist). Setup
a SVN mirror "bot" that creates one svn commit for each push/merge detected
in the master branch, and allows the buildbots to continue working as they
do now.

This would allow the existing svn-patch workflow to continue working, but
commits on svn wouldn't be allowed anymore. Developers are expected to at
least TRY to learn to use git (it's not that hard! I promise!).

Phase 2: We switch the buildbots and testbots to pull from git, enable
testbot access for git PRs (such as with a github bot that responds to
"@rosbot runtest" or similar). The SVN mirror remains, for archival
purposes, but git commits aren't merged so regularly. Release tags/branches
can still be published through SVN, for ease of access.

Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no
longer worth the effort.

Of course, anything like this will only happen if the entire team agrees to
it.

On 15 February 2017 at 12:04, Ged Murphy <gedmurphy.mailli...@gmail.com>
wrote:

> I think the easiest path is to switch to a centralized style model using
> git.
> That is, we have a master copy (aka trunk) that gives the feel of our
> existing model. That would allow devs that prefer SVN to mostly continue
> working as before, and give the devs who want to use git in a more
> traditional way the ability to branch off and work in a git style manner,
> then sync their changes back into 'trunk'.
>
>
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin
> Finck
> Sent: 15 February 2017 10:53
> To: ros-dev@reactos.org
> Subject: Re: [ros-dev] Microsoft switched to Git
>
> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
> > The number doesn't matter. The ReactOS project can't afford to lost
> > any long-time members. Git would be a benefit for all of us, but it
> > has to be a benefit for ALL of us.
>
> Let's not forget:
>
> - Part of the reasons developers had against Git may have been resolved by
> now.
> - Part of the problem may be that "Git is so different" to some devs, but
> I think this can be resolved by a detailed Wiki article showing how to do
> the same thing in SVN and Git. We already wrote such articles for
> TortoiseSVN after all!
> - And finally, we first need a plan for a Git move that doesn't suck. We
> tried SubGit and it failed for us. Then there is the "Merge workflow",
> which is supported very well by all tools, but creates a lot of parallel
> history. The "Rebase workflow" is more like what SVN does (keeping a linear
> history), but no idea how to enforce that with TortoiseGit.
>
> I think if a team could look after these things and help moving each and
> every developer towards Git, it may even be doable for us.
>
> Cheers,
>
> Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Ged Murphy]

I think the easiest path is to switch to a centralized style model using git.
That is, we have a master copy (aka trunk) that gives the feel of our existing 
model. That would allow devs that prefer SVN to mostly continue working as 
before, and give the devs who want to use git in a more traditional way the 
ability to branch off and work in a git style manner, then sync their changes 
back into 'trunk'.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: 15 February 2017 10:53
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Microsoft switched to Git

Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
> The number doesn't matter. The ReactOS project can't afford to lost 
> any long-time members. Git would be a benefit for all of us, but it 
> has to be a benefit for ALL of us.

Let's not forget:

- Part of the reasons developers had against Git may have been resolved by now.
- Part of the problem may be that "Git is so different" to some devs, but I 
think this can be resolved by a detailed Wiki article showing how to do the 
same thing in SVN and Git. We already wrote such articles for TortoiseSVN after 
all!
- And finally, we first need a plan for a Git move that doesn't suck. We tried 
SubGit and it failed for us. Then there is the "Merge workflow", which is 
supported very well by all tools, but creates a lot of parallel history. The 
"Rebase workflow" is more like what SVN does (keeping a linear history), but no 
idea how to enforce that with TortoiseGit.

I think if a team could look after these things and help moving each and every 
developer towards Git, it may even be doable for us.

Cheers,

Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Magnus Johnsson]

Wierd, any clue as to why?

There are some tools with git though that makes it operate with svn. Like,
as in that developers can use all the functions in git locally, but still
push/pull to SVN. Might be worth faffing about with and writing a guide? If
it works well and doesn't cause major headaches maybe people can use both.

I know the dual repositories are a bitch to maintain and not exactly bug
free, but it might be possible for people to use whichever tool fits them
best locally?
Actually, now I am itching to try it :).

I just feel like it would lower the entry point significantly for super
simple patches and maintenance. But then, I am not a reactos developer ;).

2017-02-15 11:47 GMT+01:00 David Quintana (gigaherz) <gigah...@gmail.com>:

> There was a talk last year, about the possibility of switching. At least
> one long-time member said if we fully switched, they'd leave the project in
> bad terms.
>
> On 15 February 2017 at 11:41, Magnus Johnsson <magnus...@gmail.com> wrote:
>
>> Sure, but, do you know that its a fact? Has anyone checked recently? We
>> are talking vehemently against it here, right, not 'minor annoyance'?
>> Not calling anyone out here, would just love to hear some input on what
>> they want from the repository system. No pooflinging, promise.
>>
>> 2017-02-15 11:35 GMT+01:00 David Quintana (gigaherz) <gigah...@gmail.com>
>> :
>>
>>> The number doesn't matter. The ReactOS project can't afford to lost any
>>> long-time members. Git would be a benefit for all of us, but it has to be a
>>> benefit for ALL of us. SVN works well enough meanwhile, even if passing
>>> patch files around is rather 1990s.
>>>
>>> On 15 February 2017 at 11:30, Magnus Johnsson <magnus...@gmail.com>
>>> wrote:
>>>
>>>> How many developers are we talking about here? :)
>>>>
>>>> 2017-02-15 11:19 GMT+01:00 Ged Murphy <gedmurphy.mailli...@gmail.com>:
>>>>
>>>>> Yeah, I had a meeting about this last week at work. We’re slowly doing
>>>>> the same, pushing all new projects to use tfs git, and give existing
>>>>> projects using vsts the option to convert if they wish.
>>>>>
>>>>> Git is far better at managing developers working in remote locations,
>>>>> and as most of the software industry has already moved towards devs 
>>>>> working
>>>>> remotely, it makes sense. There are very few big companies no longer using
>>>>> a distributed system such as git or mercurial.
>>>>>
>>>>>
>>>>>
>>>>> That fact that open source projects, which are inherently built on
>>>>> devs being remote, are still reluctant to move from a centralized to a
>>>>> distributed system seems archaic and self-detrimental. It’s a shame to 
>>>>> hold
>>>>> the project back because a few devs are unwilling to move forward.
>>>>>
>>>>>
>>>>>
>>>>> A distributed system can do everything a centralized system can do if
>>>>> you decide to model it in that way, and so much more if you decide to 
>>>>> model
>>>>> it in other ways.
>>>>>
>>>>>
>>>>>
>>>>> Ged.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *David
>>>>> Quintana (gigaherz)
>>>>> *Sent:* 15 February 2017 09:57
>>>>> *To:* ReactOS Development List <ros-dev@reactos.org>
>>>>> *Subject:* Re: [ros-dev] Microsoft switched to Git
>>>>>
>>>>>
>>>>>
>>>>> Unlike us, Microsoft probably doesn't care if a few of the developers
>>>>> would rather quit than switch. ;P
>>>>>
>>>>>
>>>>>
>>>>> On 15 February 2017 at 10:40, Colin Finck <co...@reactos.org> wrote:
>>>>>
>>>>> https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g
>>>>> it-and-some-back-story/
>>>>>
>>>>> I didn't expect Microsoft to switch to Git sooner than us..
>>>>>
>>>>> ___
>>>>> Ros-dev mailing list
>>>>> Ros-dev@reactos.org
>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Ros-dev mailing list
>>>>> Ros-dev@reactos.org
>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>
>>>>
>>>>
>>>> ___
>>>> Ros-dev mailing list
>>>> Ros-dev@reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>>
>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

I meant to add, I don't know if their opinion has softened with regards to
Git, since that discusion.

On 15 February 2017 at 11:47, David Quintana (gigaherz) <gigah...@gmail.com>
wrote:

> There was a talk last year, about the possibility of switching. At least
> one long-time member said if we fully switched, they'd leave the project in
> bad terms.
>
> On 15 February 2017 at 11:41, Magnus Johnsson <magnus...@gmail.com> wrote:
>
>> Sure, but, do you know that its a fact? Has anyone checked recently? We
>> are talking vehemently against it here, right, not 'minor annoyance'?
>> Not calling anyone out here, would just love to hear some input on what
>> they want from the repository system. No pooflinging, promise.
>>
>> 2017-02-15 11:35 GMT+01:00 David Quintana (gigaherz) <gigah...@gmail.com>
>> :
>>
>>> The number doesn't matter. The ReactOS project can't afford to lost any
>>> long-time members. Git would be a benefit for all of us, but it has to be a
>>> benefit for ALL of us. SVN works well enough meanwhile, even if passing
>>> patch files around is rather 1990s.
>>>
>>> On 15 February 2017 at 11:30, Magnus Johnsson <magnus...@gmail.com>
>>> wrote:
>>>
>>>> How many developers are we talking about here? :)
>>>>
>>>> 2017-02-15 11:19 GMT+01:00 Ged Murphy <gedmurphy.mailli...@gmail.com>:
>>>>
>>>>> Yeah, I had a meeting about this last week at work. We’re slowly doing
>>>>> the same, pushing all new projects to use tfs git, and give existing
>>>>> projects using vsts the option to convert if they wish.
>>>>>
>>>>> Git is far better at managing developers working in remote locations,
>>>>> and as most of the software industry has already moved towards devs 
>>>>> working
>>>>> remotely, it makes sense. There are very few big companies no longer using
>>>>> a distributed system such as git or mercurial.
>>>>>
>>>>>
>>>>>
>>>>> That fact that open source projects, which are inherently built on
>>>>> devs being remote, are still reluctant to move from a centralized to a
>>>>> distributed system seems archaic and self-detrimental. It’s a shame to 
>>>>> hold
>>>>> the project back because a few devs are unwilling to move forward.
>>>>>
>>>>>
>>>>>
>>>>> A distributed system can do everything a centralized system can do if
>>>>> you decide to model it in that way, and so much more if you decide to 
>>>>> model
>>>>> it in other ways.
>>>>>
>>>>>
>>>>>
>>>>> Ged.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *David
>>>>> Quintana (gigaherz)
>>>>> *Sent:* 15 February 2017 09:57
>>>>> *To:* ReactOS Development List <ros-dev@reactos.org>
>>>>> *Subject:* Re: [ros-dev] Microsoft switched to Git
>>>>>
>>>>>
>>>>>
>>>>> Unlike us, Microsoft probably doesn't care if a few of the developers
>>>>> would rather quit than switch. ;P
>>>>>
>>>>>
>>>>>
>>>>> On 15 February 2017 at 10:40, Colin Finck <co...@reactos.org> wrote:
>>>>>
>>>>> https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g
>>>>> it-and-some-back-story/
>>>>>
>>>>> I didn't expect Microsoft to switch to Git sooner than us..
>>>>>
>>>>> ___
>>>>> Ros-dev mailing list
>>>>> Ros-dev@reactos.org
>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Ros-dev mailing list
>>>>> Ros-dev@reactos.org
>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>>
>>>>
>>>>
>>>> ___
>>>> Ros-dev mailing list
>>>> Ros-dev@reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>>
>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

There was a talk last year, about the possibility of switching. At least
one long-time member said if we fully switched, they'd leave the project in
bad terms.

On 15 February 2017 at 11:41, Magnus Johnsson <magnus...@gmail.com> wrote:

> Sure, but, do you know that its a fact? Has anyone checked recently? We
> are talking vehemently against it here, right, not 'minor annoyance'?
> Not calling anyone out here, would just love to hear some input on what
> they want from the repository system. No pooflinging, promise.
>
> 2017-02-15 11:35 GMT+01:00 David Quintana (gigaherz) <gigah...@gmail.com>:
>
>> The number doesn't matter. The ReactOS project can't afford to lost any
>> long-time members. Git would be a benefit for all of us, but it has to be a
>> benefit for ALL of us. SVN works well enough meanwhile, even if passing
>> patch files around is rather 1990s.
>>
>> On 15 February 2017 at 11:30, Magnus Johnsson <magnus...@gmail.com>
>> wrote:
>>
>>> How many developers are we talking about here? :)
>>>
>>> 2017-02-15 11:19 GMT+01:00 Ged Murphy <gedmurphy.mailli...@gmail.com>:
>>>
>>>> Yeah, I had a meeting about this last week at work. We’re slowly doing
>>>> the same, pushing all new projects to use tfs git, and give existing
>>>> projects using vsts the option to convert if they wish.
>>>>
>>>> Git is far better at managing developers working in remote locations,
>>>> and as most of the software industry has already moved towards devs working
>>>> remotely, it makes sense. There are very few big companies no longer using
>>>> a distributed system such as git or mercurial.
>>>>
>>>>
>>>>
>>>> That fact that open source projects, which are inherently built on devs
>>>> being remote, are still reluctant to move from a centralized to a
>>>> distributed system seems archaic and self-detrimental. It’s a shame to hold
>>>> the project back because a few devs are unwilling to move forward.
>>>>
>>>>
>>>>
>>>> A distributed system can do everything a centralized system can do if
>>>> you decide to model it in that way, and so much more if you decide to model
>>>> it in other ways.
>>>>
>>>>
>>>>
>>>> Ged.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *David
>>>> Quintana (gigaherz)
>>>> *Sent:* 15 February 2017 09:57
>>>> *To:* ReactOS Development List <ros-dev@reactos.org>
>>>> *Subject:* Re: [ros-dev] Microsoft switched to Git
>>>>
>>>>
>>>>
>>>> Unlike us, Microsoft probably doesn't care if a few of the developers
>>>> would rather quit than switch. ;P
>>>>
>>>>
>>>>
>>>> On 15 February 2017 at 10:40, Colin Finck <co...@reactos.org> wrote:
>>>>
>>>> https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g
>>>> it-and-some-back-story/
>>>>
>>>> I didn't expect Microsoft to switch to Git sooner than us..
>>>>
>>>> ___
>>>> Ros-dev mailing list
>>>> Ros-dev@reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>>>
>>>>
>>>> ___
>>>> Ros-dev mailing list
>>>> Ros-dev@reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>>
>>>
>>> ___
>>> Ros-dev mailing list
>>> Ros-dev@reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[David Quintana (gigaherz)]

The number doesn't matter. The ReactOS project can't afford to lost any
long-time members. Git would be a benefit for all of us, but it has to be a
benefit for ALL of us. SVN works well enough meanwhile, even if passing
patch files around is rather 1990s.

On 15 February 2017 at 11:30, Magnus Johnsson <magnus...@gmail.com> wrote:

> How many developers are we talking about here? :)
>
> 2017-02-15 11:19 GMT+01:00 Ged Murphy <gedmurphy.mailli...@gmail.com>:
>
>> Yeah, I had a meeting about this last week at work. We’re slowly doing
>> the same, pushing all new projects to use tfs git, and give existing
>> projects using vsts the option to convert if they wish.
>>
>> Git is far better at managing developers working in remote locations, and
>> as most of the software industry has already moved towards devs working
>> remotely, it makes sense. There are very few big companies no longer using
>> a distributed system such as git or mercurial.
>>
>>
>>
>> That fact that open source projects, which are inherently built on devs
>> being remote, are still reluctant to move from a centralized to a
>> distributed system seems archaic and self-detrimental. It’s a shame to hold
>> the project back because a few devs are unwilling to move forward.
>>
>>
>>
>> A distributed system can do everything a centralized system can do if you
>> decide to model it in that way, and so much more if you decide to model it
>> in other ways.
>>
>>
>>
>> Ged.
>>
>>
>>
>>
>>
>> *From:* Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *David
>> Quintana (gigaherz)
>> *Sent:* 15 February 2017 09:57
>> *To:* ReactOS Development List <ros-dev@reactos.org>
>> *Subject:* Re: [ros-dev] Microsoft switched to Git
>>
>>
>>
>> Unlike us, Microsoft probably doesn't care if a few of the developers
>> would rather quit than switch. ;P
>>
>>
>>
>> On 15 February 2017 at 10:40, Colin Finck <co...@reactos.org> wrote:
>>
>> https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g
>> it-and-some-back-story/
>>
>> I didn't expect Microsoft to switch to Git sooner than us..
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Microsoft switched to Git

[Huw Campbell]

And how many developers would prefer to use git?

On Wed, Feb 15, 2017 at 9:30 PM, Magnus Johnsson <magnus...@gmail.com>
wrote:

> How many developers are we talking about here? :)
>
> 2017-02-15 11:19 GMT+01:00 Ged Murphy <gedmurphy.mailli...@gmail.com>:
>
>> Yeah, I had a meeting about this last week at work. We’re slowly doing
>> the same, pushing all new projects to use tfs git, and give existing
>> projects using vsts the option to convert if they wish.
>>
>> Git is far better at managing developers working in remote locations, and
>> as most of the software industry has already moved towards devs working
>> remotely, it makes sense. There are very few big companies no longer using
>> a distributed system such as git or mercurial.
>>
>>
>>
>> That fact that open source projects, which are inherently built on devs
>> being remote, are still reluctant to move from a centralized to a
>> distributed system seems archaic and self-detrimental. It’s a shame to hold
>> the project back because a few devs are unwilling to move forward.
>>
>>
>>
>> A distributed system can do everything a centralized system can do if you
>> decide to model it in that way, and so much more if you decide to model it
>> in other ways.
>>
>>
>>
>> Ged.
>>
>>
>>
>>
>>
>> *From:* Ros-dev [mailto:ros-dev-boun...@reactos.org] *On Behalf Of *David
>> Quintana (gigaherz)
>> *Sent:* 15 February 2017 09:57
>> *To:* ReactOS Development List <ros-dev@reactos.org>
>> *Subject:* Re: [ros-dev] Microsoft switched to Git
>>
>>
>>
>> Unlike us, Microsoft probably doesn't care if a few of the developers
>> would rather quit than switch. ;P
>>
>>
>>
>> On 15 February 2017 at 10:40, Colin Finck <co...@reactos.org> wrote:
>>
>> https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g
>> it-and-some-back-story/
>>
>> I didn't expect Microsoft to switch to Git sooner than us..
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev