.... 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 <drakekaizer...@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 <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 > _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
