{"thread":{"id":"49439","subject":"Git for Windows for Unix?","startedAt":"2018-09-27T16:01:23Z","lastAt":"2018-09-29T15:14:22Z","messageCount":10,"participants":["Ævar Arnfjörð Bjarmason","Jonathan Nieder","Derrick Stolee","Duy Nguyen","SZEDER Gábor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"359062","messageId":"87va6rhqup.fsf@evledraar.gmail.com","threadId":"49439","inReplyTo":null,"subject":"Git for Windows for Unix?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-27T16:01:18Z","receivedAt":"2018-09-27T16:01:23Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"I had an IRC conversation with Johannes saying I didn't know Git For\nWindows builds perfectly well for Linux, this just isn't advertised in\nthe ANNOUNCE E-Mails, so I hadn't tried.\n\nJohannes doesn't build his own tarballs, but these are provided at:\nhttps://github.com/git-for-windows/git/tags diffing\nhttps://github.com/git/git/tags v.s. what Junio releases shows:\n\n    $ diff -ru git-2.19.0 git-2.19.0.gh\n    Only in git-2.19.0: configure\n    Only in git-2.19.0/git-gui: version\n    Only in git-2.19.0: version\n\nSo to use these you need to grab the GitHub tarball, create a \"version\"\nfile saying e.g. 2.19.0.windows.1 or whatever it is (derived from the\nname of the tarball), and if applicable make your own configure script.\n\nGFW is a \"friendly fork\", but a permanent one it seems. The diff between\nit and 2.19.0 proper is ~10k lines, and e.g. this last release had\nexperimental stash/rebase in C that 2.19.0 didn't.\n\nSo it would be great if this were packaged up by linux distro as some\n\"alterate\" package of git. I'm putting Jonathan in the \"To\" line because\nI'm mainly interested in this for Debian, but maybe there's wider\ninterest at git-packagers...\n"},{"id":"359063","messageId":"20180927160523.GA112066@aiede.svl.corp.google.com","threadId":"49439","inReplyTo":"87va6rhqup.fsf@evledraar.gmail.com","subject":"Re: Git for Windows for Unix?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-09-27T16:05:23Z","receivedAt":"2018-09-27T16:05:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n\n> GFW is a \"friendly fork\", but a permanent one it seems. The diff between\n> it and 2.19.0 proper is ~10k lines, and e.g. this last release had\n> experimental stash/rebase in C that 2.19.0 didn't.\n>\n> So it would be great if this were packaged up by linux distro as some\n> \"alterate\" package of git. I'm putting Jonathan in the \"To\" line because\n> I'm mainly interested in this for Debian, but maybe there's wider\n> interest at git-packagers...\n\nPlease coordinate with Dscho to get these patches into \"next\" upstream.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"359064","messageId":"d3d82080-f3e7-50cd-df81-1fed3198eb88@gmail.com","threadId":"49439","inReplyTo":"87va6rhqup.fsf@evledraar.gmail.com","subject":"Re: Git for Windows for Unix?","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2018-09-27T16:18:07Z","receivedAt":"2018-09-27T16:18:10Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 9/27/2018 12:01 PM, Ævar Arnfjörð Bjarmason wrote:\n> I had an IRC conversation with Johannes saying I didn't know Git For\n> Windows builds perfectly well for Linux, this just isn't advertised in\n> the ANNOUNCE E-Mails, so I hadn't tried.\n\nWe run CI to ensure it builds and tests on Mac OSX, too. This is \nimportant to the VFS for Git group, as we work on making that work for \nMac clients. We have our fork of Git for Windows at \nhttps://github.com/microsoft/git.\n\n> GFW is a \"friendly fork\", but a permanent one it seems. The diff between\n> it and 2.19.0 proper is ~10k lines, and e.g. this last release had\n> experimental stash/rebase in C that 2.19.0 didn't.\n\nHopefully we can learn from having this experimental feature in the wild \nand improve the patches on-list by fixing issues.\n\nWe do have a desire to move as much as possible upstream. It's difficult \nto find time to pay down that \"fork debt\".\n\nThanks,\n\n-Stolee\n\n"},{"id":"359065","messageId":"87tvmaj4fq.fsf@evledraar.gmail.com","threadId":"49439","inReplyTo":"20180927160523.GA112066@aiede.svl.corp.google.com","subject":"Re: Git for Windows for Unix?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-27T16:22:33Z","receivedAt":"2018-09-27T16:22:41Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Sep 27 2018, Jonathan Nieder wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>\n>> GFW is a \"friendly fork\", but a permanent one it seems. The diff between\n>> it and 2.19.0 proper is ~10k lines, and e.g. this last release had\n>> experimental stash/rebase in C that 2.19.0 didn't.\n>>\n>> So it would be great if this were packaged up by linux distro as some\n>> \"alterate\" package of git. I'm putting Jonathan in the \"To\" line because\n>> I'm mainly interested in this for Debian, but maybe there's wider\n>> interest at git-packagers...\n>\n> Please coordinate with Dscho to get these patches into \"next\" upstream.\n\nI understand that this happens at some trickle, but how up-to-date that\nis goes back & forth, here's the history of differences for all major\nreleases since 2.0.0 to 2.19.0:\n\n    $ for rel in {0..19} ; do echo 2.$rel.0 vanilla v.s. gfw: && git diff --stat v2.$rel.0..$(git tag -l | grep v2.$rel.0.windows) -- '*.[ch]' '*.txt' '*.sh' |grep 'files changed'; done\n    2.0.0 vanilla v.s. gfw:\n     1790 files changed, 242271 insertions(+), 76973 deletions(-)\n    2.1.0 vanilla v.s. gfw:\n     1757 files changed, 231844 insertions(+), 75560 deletions(-)\n    2.2.0 vanilla v.s. gfw:\n     1733 files changed, 222517 insertions(+), 74745 deletions(-)\n    2.3.0 vanilla v.s. gfw:\n     66 files changed, 1612 insertions(+), 234 deletions(-)\n    2.4.0 vanilla v.s. gfw:\n     83 files changed, 2483 insertions(+), 299 deletions(-)\n    2.5.0 vanilla v.s. gfw:\n     89 files changed, 3150 insertions(+), 512 deletions(-)\n    2.6.0 vanilla v.s. gfw:\n     94 files changed, 3327 insertions(+), 538 deletions(-)\n    2.7.0 vanilla v.s. gfw:\n     95 files changed, 3616 insertions(+), 590 deletions(-)\n    2.8.0 vanilla v.s. gfw:\n     60 files changed, 3091 insertions(+), 497 deletions(-)\n    2.9.0 vanilla v.s. gfw:\n     60 files changed, 2945 insertions(+), 482 deletions(-)\n    2.10.0 vanilla v.s. gfw:\n     79 files changed, 6053 insertions(+), 1271 deletions(-)\n    2.11.0 vanilla v.s. gfw:\n     113 files changed, 6337 insertions(+), 1051 deletions(-)\n    2.12.0 vanilla v.s. gfw:\n     110 files changed, 4509 insertions(+), 868 deletions(-)\n    2.13.0 vanilla v.s. gfw:\n     122 files changed, 4217 insertions(+), 919 deletions(-)\n    2.14.0 vanilla v.s. gfw:\n     151 files changed, 5237 insertions(+), 1093 deletions(-)\n    2.15.0 vanilla v.s. gfw:\n     178 files changed, 4903 insertions(+), 912 deletions(-)\n    2.16.0 vanilla v.s. gfw:\n     172 files changed, 4614 insertions(+), 940 deletions(-)\n    2.17.0 vanilla v.s. gfw:\n     163 files changed, 4574 insertions(+), 882 deletions(-)\n    2.18.0 vanilla v.s. gfw:\n     163 files changed, 4688 insertions(+), 883 deletions(-)\n    2.19.0 vanilla v.s. gfw:\n     184 files changed, 9197 insertions(+), 1271 deletions(-)\n\nSo it's similar to various packages that have \"alternates\" and are semi\nor permanently forked, like emacs & xemacs, JDK etc., although I can't\nrecall one offhand that's quite similar to GFW v.s. git.git.\n\nMy only stake in this is I thought it would be neat to be able to \"apt\ninstall git-for-windows\", but I understand there's a support burden, but\nif some *nix packagers are interested, maybe never taking it out of the\nDebian equivalent of \"experimental\" and saying \"this is unsupported, go\nto the GFW tracker...\" when bugs are filed would cut down on the support\nburden.\n"},{"id":"359066","messageId":"20180927162623.GB112066@aiede.svl.corp.google.com","threadId":"49439","inReplyTo":"87tvmaj4fq.fsf@evledraar.gmail.com","subject":"Re: Git for Windows for Unix?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-09-27T16:26:23Z","receivedAt":"2018-09-27T16:26:28Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nÆvar Arnfjörð Bjarmason wrote:\n\n> So it's similar to various packages that have \"alternates\" and are semi\n> or permanently forked, like emacs & xemacs, JDK etc., although I can't\n> recall one offhand that's quite similar to GFW v.s. git.git.\n>\n> My only stake in this is I thought it would be neat to be able to \"apt\n> install git-for-windows\", but I understand there's a support burden, but\n> if some *nix packagers are interested, maybe never taking it out of the\n> Debian equivalent of \"experimental\" and saying \"this is unsupported, go\n> to the GFW tracker...\" when bugs are filed would cut down on the support\n> burden.\n\nIf someone else wants to package git-for-windows for Debian, I am\nhappy to offer them advice and will not stop them.\n\nThat said, that seems to me like a lot of work to avoid adding some\npatches to \"next\" that belong in \"next\" anyway.  I understand why the\nGit for Windows maintainer does not always have time to upstream\npromptly, which is why I suggest working with him to find a way to\nhelp with that.\n\nIf there's something I'm missing and Git is actually an uncooperative\nupstream like the cases you've mentioned, then I'd be happy to learn\nabout that so we can fix it, too.\n\nSincerely,\nJonathan\n"},{"id":"359067","messageId":"CACsJy8BdqdRtCVHriniFhpFf0brESetZaFs_w3P3hZ+5xFBbdg@mail.gmail.com","threadId":"49439","inReplyTo":"87tvmaj4fq.fsf@evledraar.gmail.com","subject":"Re: Git for Windows for Unix?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-27T16:28:34Z","receivedAt":"2018-09-27T16:29:03Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Sep 27, 2018 at 6:24 PM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> My only stake in this is I thought it would be neat to be able to \"apt\n> install git-for-windows\",\n\nThat's what private builds are for (or \"PPA\" if debian has an\nequivalent). I already largely ignore any Windows reports because I\ndon't know the differences in the fork. What's next? If a linux bug\nreport comes, will I have to double check with the reporter whether\nit's GFW build or git.git?\n-- \nDuy\n"},{"id":"359244","messageId":"87ftxtieeg.fsf@evledraar.gmail.com","threadId":"49439","inReplyTo":"20180927162623.GB112066@aiede.svl.corp.google.com","subject":"Re: Git for Windows for Unix?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-28T19:57:11Z","receivedAt":"2018-09-28T19:57:15Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Sep 27 2018, Jonathan Nieder wrote:\n\n> Hi,\n>\n> Ævar Arnfjörð Bjarmason wrote:\n>\n>> So it's similar to various packages that have \"alternates\" and are semi\n>> or permanently forked, like emacs & xemacs, JDK etc., although I can't\n>> recall one offhand that's quite similar to GFW v.s. git.git.\n>>\n>> My only stake in this is I thought it would be neat to be able to \"apt\n>> install git-for-windows\", but I understand there's a support burden, but\n>> if some *nix packagers are interested, maybe never taking it out of the\n>> Debian equivalent of \"experimental\" and saying \"this is unsupported, go\n>> to the GFW tracker...\" when bugs are filed would cut down on the support\n>> burden.\n>\n> If someone else wants to package git-for-windows for Debian, I am\n> happy to offer them advice and will not stop them.\n\nThanks, presumably this is going to be more involved than just\ndownloading the source .deb, replacing the source tarball &\ns/2.19.0/2.19.0.windows.../, since presumably both would need to be\naware of each other not to conflict, or would need update-alternatives\nintegration.\n\n> That said, that seems to me like a lot of work to avoid adding some\n> patches to \"next\" that belong in \"next\" anyway.  I understand why the\n> Git for Windows maintainer does not always have time to upstream\n> promptly, which is why I suggest working with him to find a way to\n> help with that.\n>\n> If there's something I'm missing and Git is actually an uncooperative\n> upstream like the cases you've mentioned, then I'd be happy to learn\n> about that so we can fix it, too.\n\nThat's one and valid way to look at it, convergence would be ideal.\n\nAnother way to look at it, which is closer to what I was thinking about,\nis to just view GFW as some alternate universe \"next\" branch (which by\nmy count is ~2-3k commits ahead of master[1]).\n\nFrom that perspective if/how/when it's all converging is just inside\nbaseball. I can install git from \"testing\" in Debian, and get the same\nversion that's probably stress tested by tens of thousands of users, or\n\"experimental\" (next) that's probably run by tens or hundreds of people,\nmaybe thousands.\n\nI'd just like to have some easy way to install the gfw, which I'm\nassuming is used by a lot more users than any of those.\n\nOne reason to do that these days is to get git-stash and git-rebase\nthat's a lot faster, yeah I could just pick those from the ML or build\nfrom \"pu\", but I'm betting the GFW version has been tested a lot more.\n\nI can just build it for myself, the reason I sent this mail was just to\na) see if there were some packagers that were interested in making\nnon-windows packages for it (e.g. some linux distros) b) it wasn't clear\nto me before what the extent of the divergence with vanilla git was, and\nthat there wasn't much Windows-specific about GFW, it's just a fork\nwhose maintainer happens to just make releases on that OS (but as I've\nlearned, also tests them on Linux VMs).\n\n1. $ git log --max-parents=1 --pretty=format:%s v2.19.0...v2.19.0.windows.1|sort|uniq|wc -l\n   2346\n\n   sort|uniq because without that we get ~27k commits, a lot of these\n   seem to be automated commits made by some bots.\n"},{"id":"359248","messageId":"20180928204233.GA193055@aiede.svl.corp.google.com","threadId":"49439","inReplyTo":"87ftxtieeg.fsf@evledraar.gmail.com","subject":"Re: Git for Windows for Unix?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-09-28T20:42:33Z","receivedAt":"2018-09-28T20:42:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Sep 27 2018, Jonathan Nieder wrote:\n\n>> That said, that seems to me like a lot of work to avoid adding some\n>> patches to \"next\" that belong in \"next\" anyway.  I understand why the\n>> Git for Windows maintainer does not always have time to upstream\n>> promptly, which is why I suggest working with him to find a way to\n>> help with that.\n>>\n>> If there's something I'm missing and Git is actually an uncooperative\n>> upstream like the cases you've mentioned, then I'd be happy to learn\n>> about that so we can fix it, too.\n>\n> That's one and valid way to look at it, convergence would be ideal.\n>\n> Another way to look at it, which is closer to what I was thinking about,\n> is to just view GFW as some alternate universe \"next\" branch (which by\n> my count is ~2-3k commits ahead of master[1]).\n\nYou could view it that way, but I don't.  Many Git for Windows patches\nhave never even visited the Git mailing list.\n\nThanks,\nJonathan\n"},{"id":"359285","messageId":"20180929111900.GH23446@localhost","threadId":"49439","inReplyTo":"87ftxtieeg.fsf@evledraar.gmail.com","subject":"Re: Git for Windows for Unix?","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-09-29T11:19:00Z","receivedAt":"2018-09-29T11:19:08Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Sep 28, 2018 at 09:57:11PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> Another way to look at it, which is closer to what I was thinking about,\n> is to just view GFW as some alternate universe \"next\" branch (which by\n> my count is ~2-3k commits ahead of master[1]).\n\n> 1. $ git log --max-parents=1 --pretty=format:%s v2.19.0...v2.19.0.windows.1|sort|uniq|wc -l\n>    2346\n\nThis command is missing a\n\n  grep -v -i -E '(^fixup!|^squash!|mingw|vcxproj|msvc|win32|vs2015|windows)'\n\nfrom the middle of the pipe, then it's \"only\" ~1500.\n\n"},{"id":"359290","messageId":"87efdcibed.fsf@evledraar.gmail.com","threadId":"49439","inReplyTo":"20180928204233.GA193055@aiede.svl.corp.google.com","subject":"Re: Git for Windows for Unix?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-09-29T15:14:18Z","receivedAt":"2018-09-29T15:14:22Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 28 2018, Jonathan Nieder wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Thu, Sep 27 2018, Jonathan Nieder wrote:\n>\n>>> That said, that seems to me like a lot of work to avoid adding some\n>>> patches to \"next\" that belong in \"next\" anyway.  I understand why the\n>>> Git for Windows maintainer does not always have time to upstream\n>>> promptly, which is why I suggest working with him to find a way to\n>>> help with that.\n>>>\n>>> If there's something I'm missing and Git is actually an uncooperative\n>>> upstream like the cases you've mentioned, then I'd be happy to learn\n>>> about that so we can fix it, too.\n>>\n>> That's one and valid way to look at it, convergence would be ideal.\n>>\n>> Another way to look at it, which is closer to what I was thinking about,\n>> is to just view GFW as some alternate universe \"next\" branch (which by\n>> my count is ~2-3k commits ahead of master[1]).\n>\n> You could view it that way, but I don't.  Many Git for Windows patches\n> have never even visited the Git mailing list.\n\nNot to beat this point to death, just replying because I'm not sure if\nwe're talking past each other, or if you're just vehemently making the\npoint that these patches *really* should be sent to the ML (which I\ndon't disagree with at all).\n\nI meant \"alternative universe 'next'\" in the sense that it's a published\nbranch that's shipped to people and is consistently ahead of master, not\nthat the same process of sending patches to git@vger.kernel.org has been\nused to generate it.\n\nIn the case of GFW they have their own internal contribution mechanism,\nGitHub PRs etc., and only eventually submit things to the ML.\n"}]}