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
fr.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
>> &
e 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 G
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:
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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'&q
000
> 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
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
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.
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'.
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
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
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 d
emote, 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.
>>>>>
>>>>>
>>>
ems 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 mod
odel 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)
>>
;> 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
34 matches
Mail list logo