Re: [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(a)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(a)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(a)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(a)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(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[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-…

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 <ionucu(a)videotron.ca> 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
>  <drakekaizer666(a)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(a)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(a)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(a)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(a)reactos.org
> > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > >
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > > >  
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

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

Hi ! Here are some thoughts as an answer to Ziliang's mail:

>   De : Ros-dev [mailto:[e-mail]] 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-…
>  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=…
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-repo…
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-…
, 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