[ros-dev] Microsoft switched to Git

[Alex Ionescu]

.... 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
<drakekaizer666 at gmail.com> 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 <ionucu at videotron.ca> 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
>> <drakekaizer666 at gmail.com> 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 <colin at reactos.org> 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 at reactos.org
>> >> http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > Ros-dev mailing list
>> > Ros-dev at reactos.org
>> > http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>