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 <ion...@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 > <drakekaizer...@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 <co...@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@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
