{"thread":{"id":"38647","subject":"Re: Any chance for a Git v2.1.5 release?","startedAt":"2015-02-25T00:55:26Z","lastAt":"2015-03-12T01:23:21Z","messageCount":8,"participants":["Kyle J. McKay","Junio C Hamano","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256612","messageId":"2D3EB6D1-3029-4F60-AF29-E044E92DB036@gmail.com","threadId":"38647","inReplyTo":"xmqqk2z7qe8s.fsf@gitster.dls.corp.google.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-02-25T00:55:26Z","receivedAt":"2015-02-25T00:55:26Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Feb 24, 2015, at 11:52, Junio C Hamano wrote:\n\n> Kyle J. McKay writes:\n>\n>> Which brings us back to the subject of this email, is there any \n>> chance\n>> for a v2.1.5 release?\n>> ...\n>> It appears that the average support lifespan of a Git release from\n>> initial release date through last released maintenance update is\n>> approximately 2-3 months with the 1.7.6 release being an exception at\n>> a little over 7 months.\n>\n> That matches my expectation.\n>\n> A typical cycle lasts for 8-12 weeks, and during that time, topics\n> that are bugfixes that have graduated to the 'master' branch are\n> merged to the 'maint' branch with some lag and then the tip of\n> 'maint' gets tagged as a maintenance release from time to time.\n> Some important but trivial fixes are further merged to older\n> maitenance tracks like 'maint-2.2', 'maint-2.1', etc.\n>\n> But these topics downmerged to older maint-* branches have to be\n> very trivial for an obvious reason: there are only 24 hours a day\n> and 7 days in a week, and bugs that affect real world use cases are\n> found by using the software in real world use cases. Usually I use\n> something a bit ahead of 'next' exactly for this reason---we would\n> want to catch bugs before topics are merged to 'master'. Although I\n> sometimes have \"let's use 'maint' for my work\" day once or twice\n> every month, I cannot afford to do that for anything older than the\n> tip of 'maint' myself.\n\nObviously there would have to actually be some interest in having an \nolder long-term-support release and some folks willing to exercise \nsuch a thing. Unless we can figure out a way to clone you. ;) ;)\n\n> The consequence of the above is this. v2.1.1 may be more stable\n> than v2.1.0 and v2.1.2 may be more stable than v2.1.1, but later\n> tagged versions on older maintenance tracks are made by merging\n> topics only after \"ah, these are obvious enough\" eyeballing without\n> real use (at least by me), once newer feature release is made and\n> there is a newer maintenance track. I would not be surprised if\n> v2.1.5, if it is made, has hidden interactions between the changes\n> since v2.1.4 and the older codebase to cause unforeseen bugs.\n>\n> When I say \"the tip of 'master' is meant to be more stable than any\n> tagged versions\", I do mean it.\n\nSome fixes would likely not be back portable (e.g. to fix X you first \nneed change Y which needs change Z which needs ...), not without \nending up pulling in things that exceed the scope of a \"maintenance\" \nupdate.\n\n> Having said all that, if I were to tag maint-2.1 branch as 2.1.5\n> today, we would have\n>\n> 6aaf956 is_hfs_dotgit: loosen over-eager match of \\u{..47}\n>\n> that does not exist in 2.1.4. Is that what you want?\n\nI suppose in that it fixes \"false positives\" it is a regression fix, \nbut if that's all that showed up in v2.1.5, no, that wouldn't make it \nworthwhile.\n\n>> If a v2.1.5 release is out of the question, would it be possible to\n>> periodically designate certain Git releases as \"long term support\"\n>> releases?\n>\n> I can designate ;-), but I do not think I'd be the right person to\n> maintain or long-term-support it. Are you volunteering to oversee\n> the \"LTS team\"?\n\nI could not promise a team of more than one member. And that would \nnot be full-time 24/7 either.\n\n> It would involve:\n>\n> - Monitor \"git log --first-parent maint-lts..master\" and find\n> the tip of topic branches that need to be down-merged;\n>\n> - Down-merge such topics to maint-lts; this might involve\n> cherry-picking instead of merge, as the bugfix topics may\n> originally be done on the codebase newer than maint-lts;\n\nI've been cherry-picking fixes for a while now onto older releases. I \ndon't suppose down-merging would be that much more difficult with a \nfallback to cherry-picking.\n\n> - Use the tip of the maint-lts branch in everyday work.\n>\n> The last item is the most important of the above, because I do not\n> have time for that. I can help with the first two to some degree,\n> though.\n\nThat's pretty much all I use at this point -- a slightly older release \nwith cherry-picked fixes. While it did cause me to find the problem \nwith the first version of the loose alternates fix, having only one \nperson use such a release doesn't provide that much coverage.\n\n> If the lts releases need to be tagged and published by me, then lts\n> team can have me pull from the tip of maint-lts they are confident\n> with and have me sign it and push it out.\n\nIt occurs to me that if the \"maint-lts\" updates were limited to crash \nfixes, regressions and security issues then often the pre-built man \npages and docs from the release it's based on could be used as-is with \nthe exception of the new release notes which might save some time.\n\n> If the primary concern you have with the currently maintained\n> releases is git-svn, perhaps a better way forward for you,\n> especially if you are willing to maintain your own \"release plus\n> patches\",\n\nThat was the discussion the admins had that we prefer to avoid rolling \nour own, but if there's no other option then we will do that. Some \nother Git hosters obviously do not have the same reticence about \nrolling their own Git release (as can be seen from the capabilities \nreturned). There are several fixes not yet in a release that are \nneeded besides just git-svn, but since the other fixes are all in \nmaster now they'll be out in the next release. But, picking up that \nrelease to get those fixes also exposes us to new code that has not \nyet had widespread use and a \"maint-lts\" would hopefully pick up the \nfixes without doing that.\n\n> might be to keep a patch that reverts recent git-svn\n> changes back to v2.1.whatever and deploy the up-to-date release\n> and that patch on top?\n\nThat has occurred to me assuming there's not some dependency issue \nthere that causes a cascade of reversions.\n\n>> Nice to have: The CVE-2014-9390 fix, but repo.or.cz does not create\n>> any working trees so it's not mandatory.\n>\n> Even if you do not have a working tree, people who use you as the\n> meeting place and push into you and fetch from you do, so I do not\n> necessarily agree with your assessment.\n\nHaving the feature does no good unless it's turned on. :) How \nexpensive would it be to turn such a feature on in terms of CPU \nusage? Running `git fsck` is rather expensive and the name of the \nconfig option suggests it's related, is it also as expensive? When \nsomeone pushes a 2GB pack, what impact does that option have on server \nload? All existing repos would have to be checked first. Do we eject \nany that fail? What about mirrors? Do we refuse to mirror from a \nsource that fails the check? As long as it's not too CPU expensive, I \ncould see turning it on immediately for new push repos and after \nchecking, existing push and mirror repos that pass. Hopefully all of \nthem just pass the check. So we cannot just deploy a CVE-2014-9390 \nfix even if we had it without first doing some work assuming the CPU \nload is not an issue. But it would be nice to have so we *could* \nproceed in that direction.\n\n-Kyle\n"},{"id":"256614","messageId":"xmqq4mqapo9r.fsf@gitster.dls.corp.google.com","threadId":"38647","inReplyTo":"2D3EB6D1-3029-4F60-AF29-E044E92DB036@gmail.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-25T05:13:04Z","receivedAt":"2015-02-25T05:13:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kyle J. McKay\" writes:\n\n>> I can designate ;-), but I do not think I'd be the right person to\n>> maintain or long-term-support it. Are you volunteering to oversee\n>> the \"LTS team\"?\n>\n> I could not promise a team of more than one member. And that would\n> not be full-time 24/7 either.\n\nHeh. Making noises to find like-minded people would be the first\nstep to build a viable team, and hopefully you are already doing a\ngood job here ;-)\n\n>> It would involve:\n>>\n>> - Monitor \"git log --first-parent maint-lts..master\" and find\n>> the tip of topic branches that need to be down-merged;\n>>\n>> - Down-merge such topics to maint-lts; this might involve\n>> cherry-picking instead of merge, as the bugfix topics may\n>> originally be done on the codebase newer than maint-lts;\n>\n> I've been cherry-picking fixes for a while now onto older releases. I\n> don't suppose down-merging would be that much more difficult with a\n> fallback to cherry-picking.\n>\n>> - Use the tip of the maint-lts branch in everyday work.\n>>\n>> The last item is the most important of the above, because I do not\n>> have time for that. I can help with the first two to some degree,\n>> though.\n>\n> That's pretty much all I use at this point -- a slightly older release\n> with cherry-picked fixes. While it did cause me to find the problem\n> with the first version of the loose alternates fix, having only one\n> person use such a release doesn't provide that much coverage.\n\nThat is why I used the word \"team\".\n\n> It occurs to me that if the \"maint-lts\" updates were limited to crash\n> fixes, regressions and security issues then often the pre-built man\n> pages and docs from the release it's based on could be used as-is with\n> the exception of the new release notes which might save some time.\n\nCutting release tarballs including the pre-formatting docs might\nconsume a lot of machine time, but it does not cost me time at all.\nI have Makefile for that ;-)\n\nJudging which fixes that have proven themselves to be safe and sound\n(by being in 'next', 'master' and hopefully 'maint' for some time)\nare worthy enough of down-merging to the LTS track is something I'd\nwant to farm out to the LTS team. I am already doing the \"safe and\nsound\" part by deciding which topics to merge to 'maint' among the\ntopics that have gone through 'pu' to 'next' to 'master' branches,\nbut not all that are worthy enough to be merged to 'maint' may be\nimportant enough to bother downmerging and updating LTS track with,\nand picking which ones matter to the LTS users is what the folks who\nare interested in the LTS can help.\n"},{"id":"256671","messageId":"DCB8EEAA-F6C3-4321-833E-39B80673C7E9@gmail.com","threadId":"38647","inReplyTo":"xmqq4mqapo9r.fsf@gitster.dls.corp.google.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-02-26T07:40:53Z","receivedAt":"2015-02-26T07:40:53Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Feb 24, 2015, at 21:13, Junio C Hamano wrote:\n\n> \"Kyle J. McKay\" writes:\n>\n>>> I can designate ;-), but I do not think I'd be the right person to\n>>> maintain or long-term-support it. Are you volunteering to oversee\n>>> the \"LTS team\"?\n>>\n>> I could not promise a team of more than one member. And that would\n>> not be full-time 24/7 either.\n>\n> Heh. Making noises to find like-minded people would be the first\n> step to build a viable team, and hopefully you are already doing a\n> good job here ;-)\n\nDoesn't seem to be catching much interest though. Maybe they're all \njust watching silently peering through the blinds waiting to see how \nit turns out. ;)\n\n>>> It would involve:\n>>>\n>>> - Monitor \"git log --first-parent maint-lts..master\" and find\n>>> the tip of topic branches that need to be down-merged;\n>>>\n>>> - Down-merge such topics to maint-lts; this might involve\n>>> cherry-picking instead of merge, as the bugfix topics may\n>>> originally be done on the codebase newer than maint-lts;\n>>\n>> I've been cherry-picking fixes for a while now onto older \n>> releases. I\n>> don't suppose down-merging would be that much more difficult with a\n>> fallback to cherry-picking.\n>>\n>>> - Use the tip of the maint-lts branch in everyday work.\n>>>\n>>> The last item is the most important of the above, because I do not\n>>> have time for that. I can help with the first two to some degree,\n>>> though.\n>>\n>> That's pretty much all I use at this point -- a slightly older \n>> release\n>> with cherry-picked fixes. While it did cause me to find the problem\n>> with the first version of the loose alternates fix, having only one\n>> person use such a release doesn't provide that much coverage.\n>\n> That is why I used the word \"team\".\n>\n>> It occurs to me that if the \"maint-lts\" updates were limited to crash\n>> fixes, regressions and security issues then often the pre-built man\n>> pages and docs from the release it's based on could be used as-is \n>> with\n>> the exception of the new release notes which might save some time.\n>\n> Cutting release tarballs including the pre-formatting docs might\n> consume a lot of machine time, but it does not cost me time at all.\n> I have Makefile for that ;-)\n>\n> Judging which fixes that have proven themselves to be safe and sound\n> (by being in 'next', 'master' and hopefully 'maint' for some time)\n> are worthy enough of down-merging to the LTS track is something I'd\n> want to farm out to the LTS team. I am already doing the \"safe and\n> sound\" part by deciding which topics to merge to 'maint' among the\n> topics that have gone through 'pu' to 'next' to 'master' branches,\n> but not all that are worthy enough to be merged to 'maint' may be\n> important enough to bother downmerging and updating LTS track with,\n> and picking which ones matter to the LTS users is what the folks who\n> are interested in the LTS can help.\n\nIf I were to keep a maint-lts up-to-date somewhere (with suitable down- \nmerges matching the manner in which you maintain your tree) that you \ncould pull from and potentially make releases from. I would not want \nto pick up anything that hadn't already made it into master or maint \nand I don't think any actual release based off maint-lts should have \nany fix that has not already appeared in another non-maint-lts \nrelease. So any given maint-lts release date would be expected to lag \nbehind the corresponding master/maint release date that contained the \nsame fixes (except possibly for a coordinated security fix release).\n\nThat said, there's no reason I couldn't also keep a pu-lts up-to-date \nsomewhere external to your tree that interested parties could grab \nthat would include fixes making their way into maint/master that I \nbelieve would be candidates for inclusion in maint-lts once they \ngraduated.\n\nI would like to better understand how the various heads are \nmaintained. I've read MaintNotes and I've got the concepts, but I'm \nstill a little fuzzy on some details. It looks to me like all topics \nstill only in pu after master has been updated are then rebased onto \nthe new master and then pu is rebuilt. MaintNotes doesn't get into \nthe rebasing details. None of the graphic log viewers I've tried are \nmuch help -- too many lines running around although the graphiclog on \nrepo.or.cz helps a bit as it shows --first-parent links as a bolder \nline, but still after the first page that's not much help either.\n\nI vaguely recall you may have explained some of this in more detail in \nthe context of explaining how you used the scripts in todo to put \neverything together when someone asked a question about it on the \nlist. But I can't seem to find that message anymore. :(\n\nI think I mostly understand how master, next and pu are maintained. \nBut MaintNotes says \"Whenever a feature release is made, 'maint' \nbranch is forked off from 'master' at that point.\" What happens to \nthe previous maint at that time? Is it just renamed to maint-X.X?\n\nAlso, how do you handle a down merge to maint when you have this:\n\n* (master)\n* merge topic foo\n|\\\n| * topic foo\n|/\n* c\n* b\n* a\n* (tag: vX.X.X, maint)\n*\n\nAnd you want to down merge topic foo into maint (where foo is a topic \nthat didn't even first enter pu until some time after the vX.X.X \nrelease). Won't doing 'checkout maint', 'merge \":/^topic foo\"' pull \nin commits a, b and c as well? I can think of several things to do \nhere, but how do you normally handle this situation?\n\n-Kyle\n"},{"id":"256705","messageId":"xmqqvbiol7fg.fsf@gitster.dls.corp.google.com","threadId":"38647","inReplyTo":"DCB8EEAA-F6C3-4321-833E-39B80673C7E9@gmail.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-26T20:54:59Z","receivedAt":"2015-02-26T20:54:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kyle J. McKay\" writes:\n\n> I would like to better understand how the various heads are\n> maintained. I've read MaintNotes and I've got the concepts, but I'm\n> still a little fuzzy on some details. It looks to me like all topics\n> still only in pu after master has been updated are then rebased onto\n> the new master and then pu is rebuilt.\n\nTopics in 'pu' not yet in 'next' _can_ be rebased, but unless there\nis a good reason to do so, I wouldn't spend extra cycles necessary\nto do such thing. I even try to keep the same base when replacing\nthe contents of a branch with a rerolled series. For example, today\nI have this:\n\n $ git config alias.lgf\n log --oneline --boundary --first-parent\n $ git lgf master..nd/slim-index-pack-memory-usage\n 3538291 index-pack: kill union delta_base to save memory\n 7b4ff41 FIXUP\n 45b6b71 index-pack: reduce memory footprint a bit\n - 9874fca Git 2.3\n\nand Duy has a newer iteration of it starting at $gmane/264429. What\nI would do, after saving these patches in a mbox +nd-index-pack,\nwould be to\n\n $ git checkout 9874fca\n $ git am -s3c ./+nd-index-pack\n $ git show-branch HEAD nd/slim-index-pack-memory-usage\n ... compare corresponding changes between the old and the new\n ... until I am satisified; otherwise I may tweak the new one\n $ git rebase -i 9874fca\n ... and then finally\n $ git branch -f nd/slim-index-pack-memory-usage HEAD\n\nto update the topic. Of course, it would be necessary to rebuild\n'pu' by merging all the topics that are in it on top of 'master'.\n\nhttps://github.com/gitster/git.git has these topic branches broken\nout and you can observe how they change over time from your local\nreflog for refs/remotes//.\n\n> I vaguely recall you may have explained some of this in more detail in\n> the context of explaining how you used the scripts in todo to put\n> everything together when someone asked a question about it on the\n> list. But I can't seem to find that message anymore. :(\n\nThere may be a copy in Documentaiton/howto/ somewhere.\n\n> I think I mostly understand how master, next and pu are maintained.\n> But MaintNotes says \"Whenever a feature release is made, 'maint'\n> branch is forked off from 'master' at that point.\" What happens to\n> the previous maint at that time? Is it just renamed to maint-X.X?\n\nAfter finishing 2.3.0 release, at some point while 'master' is still\nat 2.3.0, something like this would happen:\n\n $ git branch -m maint maint-2.2\n $ git branch maint master\n\n> Also, how do you handle a down merge to maint when you have this:\n>\n> * (master)\n> * merge topic foo\n> |\\\n> | * topic foo\n> |/\n> * c\n> * b\n> * a\n> * (tag: vX.X.X, maint)\n> *\n\nI don't, and this is done by making sure I do not get into such a\nsituation in the first place.\n\nA general rule of thumb when applying a set of patches that are\nfixes eventually worth having in older maintenance tracks is to find\nthe oldest maintenance branch and apply them there.\n"},{"id":"256726","messageId":"35E11B78-6FF8-41DE-BBF5-8978DA2F87A6@gmail.com","threadId":"38647","inReplyTo":"xmqqvbiol7fg.fsf@gitster.dls.corp.google.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-02-26T23:38:51Z","receivedAt":"2015-02-26T23:38:51Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Feb 26, 2015, at 12:54, Junio C Hamano wrote:\n\n> \"Kyle J. McKay\" writes:\n>\n>> I would like to better understand how the various heads are\n>> maintained. I've read MaintNotes and I've got the concepts, but I'm\n>> still a little fuzzy on some details. It looks to me like all topics\n>> still only in pu after master has been updated are then rebased onto\n>> the new master and then pu is rebuilt.\n>\n> Topics in 'pu' not yet in 'next' _can_ be rebased, but unless there\n> is a good reason to do so, I wouldn't spend extra cycles necessary\n> to do such thing. I even try to keep the same base when replacing\n> the contents of a branch with a rerolled series. For example, today\n> I have this:\n>\n> $ git config alias.lgf\n> log --oneline --boundary --first-parent\n> $ git lgf master..nd/slim-index-pack-memory-usage\n> 3538291 index-pack: kill union delta_base to save memory\n> 7b4ff41 FIXUP\n> 45b6b71 index-pack: reduce memory footprint a bit\n> - 9874fca Git 2.3\n>\n> and Duy has a newer iteration of it starting at $gmane/264429. What\n> I would do, after saving these patches in a mbox +nd-index-pack,\n> would be to\n>\n> $ git checkout 9874fca\n> $ git am -s3c ./+nd-index-pack\n> $ git show-branch HEAD nd/slim-index-pack-memory-usage\n> ... compare corresponding changes between the old and the new\n> ... until I am satisified; otherwise I may tweak the new one\n> $ git rebase -i 9874fca\n> ... and then finally\n> $ git branch -f nd/slim-index-pack-memory-usage HEAD\n>\n> to update the topic. Of course, it would be necessary to rebuild\n> 'pu' by merging all the topics that are in it on top of 'master'.\n\nThanks. That's helpful.\n\n> After finishing 2.3.0 release, at some point while 'master' is still\n> at 2.3.0, something like this would happen:\n>\n> $ git branch -m maint maint-2.2\n> $ git branch maint master\n\nSo the reason I don't notice force-updates to maint when this happens \nis because of the \"Sync with maint\" commits that make sure the new \nmaint contains the old one.\n\n>> Also, how do you handle a down merge to maint when you have this:\n>>\n>> * (master)\n>> * merge topic foo\n>> |\\\n>> | * topic foo\n>> |/\n>> * c\n>> * b\n>> * a\n>> * (tag: vX.X.X, maint)\n>> *\n>\n> I don't, and this is done by making sure I do not get into such a\n> situation in the first place.\n>\n> A general rule of thumb when applying a set of patches that are\n> fixes eventually worth having in older maintenance tracks is to find\n> the oldest maintenance branch and apply them there.\n\nIf I were to keep a maint-lts branch somewhere I would need to cherry- \npick topics with desired fixes that fall into that situation. That's \nwhat I expected but when you mentioned down merging the fixes I wanted \nto make sure I wasn't overlooking something.\n\nI'll see about setting up a maint-lts in a local git repository clone \nand tracking LTS fixes. If I'm able to keep that going without it \nbecoming a black-hole of temporal need that sucks the life right out \nof me ;) then perhaps we can have a discussion at a future date \nabout what would be needed for you to consider pulling from it and \nissuing LTS releases off it. :)\n\n-Kyle\n"},{"id":"256728","messageId":"xmqqpp8wjko2.fsf@gitster.dls.corp.google.com","threadId":"38647","inReplyTo":"35E11B78-6FF8-41DE-BBF5-8978DA2F87A6@gmail.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-26T23:51:57Z","receivedAt":"2015-02-26T23:51:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kyle J. McKay\" writes:\n\n>> After finishing 2.3.0 release, at some point while 'master' is still\n>> at 2.3.0, something like this would happen:\n>>\n>> $ git branch -m maint maint-2.2\n>> $ git branch maint master\n>\n> So the reason I don't notice force-updates to maint when this happens\n> is because of the \"Sync with maint\" commits that make sure the new\n> maint contains the old one.\n\nI could also do\n\n git branch maint-2.2 maint\n git push . master:maint ;# not +master:maint\n\nto make sure that I won't rewind 'maint', but this works because\n'master' is designed to be always a super-set of 'maint'.\n\n> If I were to keep a maint-lts branch somewhere I would need to cherry- \n> pick topics with desired fixes that fall into that situation. That's\n> what I expected but when you mentioned down merging the fixes I wanted\n> to make sure I wasn't overlooking something.\n\nYup. I _can_ become sloppy especially late in the release cycle and\nend up doing something silly like this:\n\n - Fork km/svn-fix from somewhere it _could_ be merged to 'maint'\n (e.g. \"the last big release\", e.g. v2.3.0).\n\n - Merge km/svn-fix to 'master' early in a cycle;\n\n - A mistake is found in the topic late in the cycle; as the next\n release will happen soon _anyway_, and I do not happen to\n consider km/svn-fix is so important a fix to be merged to\n 'maint', I apply a fix-up patch directly on top of 'master';\n\n - A release candidate is tagged from 'master'.\n\nThen even though you can easily grab a broken-out tree at\ngithub.com:gitster/git, km/svn-fix topic alone cannot be merged to\n'maint' as it would lack the late fix. I've been trying to be\ncareful but I cannot promise to be perfect X-<.\n"},{"id":"256757","messageId":"D1DF80CD81FD4C96BA973BFCD998E7B1@PhilipOakley","threadId":"38647","inReplyTo":"35E11B78-6FF8-41DE-BBF5-8978DA2F87A6@gmail.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-02-27T22:20:09Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Kyle J. McKay\" \n> On Feb 26, 2015, at 12:54, Junio C Hamano wrote:\n>\n>> \"Kyle J. McKay\" writes:\n>>\n>>> I would like to better understand how the various heads are\n>>> maintained. I've read MaintNotes and I've got the concepts, but I'm\n>>> still a little fuzzy on some details. It looks to me like all \n>>> topics\n>>> still only in pu after master has been updated are then rebased onto\n>>> the new master and then pu is rebuilt.\n>>\n>> Topics in 'pu' not yet in 'next' _can_ be rebased, but unless there\n>> is a good reason to do so, I wouldn't spend extra cycles necessary\n>> to do such thing. I even try to keep the same base when replacing\n>> the contents of a branch with a rerolled series. For example, today\n>> I have this:\n>>\n>> $ git config alias.lgf\n>> log --oneline --boundary --first-parent\n>> $ git lgf master..nd/slim-index-pack-memory-usage\n>> 3538291 index-pack: kill union delta_base to save memory\n>> 7b4ff41 FIXUP\n>> 45b6b71 index-pack: reduce memory footprint a bit\n>> - 9874fca Git 2.3\n>>\n>> and Duy has a newer iteration of it starting at $gmane/264429. What\n>> I would do, after saving these patches in a mbox +nd-index-pack,\n>> would be to\n>>\n>> $ git checkout 9874fca\n>> $ git am -s3c ./+nd-index-pack\n>> $ git show-branch HEAD nd/slim-index-pack-memory-usage\n>> ... compare corresponding changes between the old and the new\n>> ... until I am satisified; otherwise I may tweak the new one\n>> $ git rebase -i 9874fca\n>> ... and then finally\n>> $ git branch -f nd/slim-index-pack-memory-usage HEAD\n>>\n>> to update the topic. Of course, it would be necessary to rebuild\n>> 'pu' by merging all the topics that are in it on top of 'master'.\n>\n> Thanks. That's helpful.\n>\n>> After finishing 2.3.0 release, at some point while 'master' is still\n>> at 2.3.0, something like this would happen:\n>>\n>> $ git branch -m maint maint-2.2\n>> $ git branch maint master\n>\n> So the reason I don't notice force-updates to maint when this happens \n> is because of the \"Sync with maint\" commits that make sure the new \n> maint contains the old one.\n>\n>>> Also, how do you handle a down merge to maint when you have this:\n>>>\n>>> * (master)\n>>> * merge topic foo\n>>> |\\\n>>> | * topic foo\n>>> |/\n>>> * c\n>>> * b\n>>> * a\n>>> * (tag: vX.X.X, maint)\n>>> *\n>>\n>> I don't, and this is done by making sure I do not get into such a\n>> situation in the first place.\n>>\n>> A general rule of thumb when applying a set of patches that are\n>> fixes eventually worth having in older maintenance tracks is to find\n>> the oldest maintenance branch and apply them there.\n>\n> If I were to keep a maint-lts branch somewhere I would need to cherry- \n> pick topics with desired fixes that fall into that situation. That's \n> what I expected but when you mentioned down merging the fixes I wanted \n> to make sure I wasn't overlooking something.\n\n\nThe announcement a few days ago by Adam Spiers ($gmane/264405) of a new \nvideo of his git-deps tool ($gmane/262606) may be of interest for \ndetermining the dependency charts. It looked interesting for this type \nof issue.\n\nHis original blog is http://blog.adamspiers.org/2015/01/19/git-deps/ \nwith repo at https://github.com/aspiers/git-deps\n<\\minor bikeshed>\n>\n> I'll see about setting up a maint-lts in a local git repository clone \n> and tracking LTS fixes. If I'm able to keep that going without it \n> becoming a black-hole of temporal need that sucks the life right out \n> of me ;) then perhaps we can have a discussion at a future date \n> about what would be needed for you to consider pulling from it and \n> issuing LTS releases off it. :)\n>\n> -Kyle\n> --\nPhilip \n"},{"id":"257580","messageId":"935E98CF-A4E8-4392-B247-61863A9B033A@gmail.com","threadId":"38647","inReplyTo":"2D3EB6D1-3029-4F60-AF29-E044E92DB036@gmail.com","subject":"Re: Any chance for a Git v2.1.5 release?","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-03-12T01:23:21Z","receivedAt":"2015-03-12T01:23:21Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"The first two messages in this thread were dropped by the vger mailing \nlist for some unknown reason.\n\nIn an attempt to make the mailing list archives of this thread \ncomplete, the original two messages in this thread are included below.\n\n-Kyle\n\n---- BEGIN FIRST MESSAGE ----\nFrom: Kyle J. McKay \nDate: February 24, 2015 09:16:05 PST\nTo: Junio C Hamano \nCc: Git Mailing List \nSubject: Any chance for a Git v2.1.5 release?\nMessage-Id: \nContent-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes\n\nAs you know, I help out with repo.or.cz. Recently the admins have \nbeen discussing upgrading the version of Git we use in order to \nsupport newer features such as pack bitmaps. While we do use a \nslightly customized gitweb, we have always stuck to an official Git \nrelease for everything else.\n\nRepo.or.cz provides fetch (git, http, https, ssh), browsing (gitweb) \nand push (ssh, https). Additionally, created repositories can be \nmirrors (no push allowed) of other repositories (including svn via git- \nsvn). Email notification of ref changes (along with diffs) can also \nbe requested.\n\nWe are finding that in order to upgrade Git at this point we would \nneed to build a custom Git with cherry picked fixes for various issues \nthat have come up or they would likely be triggered by one of the \nservices repo.or.cz provides. In addition, as there are numerous \nreports of an unresolved issue with git-svn starting with v2.2.0 \nupgrading to v2.2.0 or later presents a problem since we have several \nmirrors that rely on git-svn.\n\nWhich brings us back to the subject of this email, is there any chance \nfor a v2.1.5 release?\n\nAfter reviewing a few release dates:\n\n2011-06-26T12:41:26-07:00 v1.7.6\n2012-02-05T23:51:07-08:00 v1.7.6.6\n\n2013-11-27T12:14:52-08:00 v1.8.5\n2014-02-13T13:42:01-08:00 v1.8.5.5\n\n2014-02-14T11:36:11-08:00 v1.9.0\n2014-05-30T10:15:10-07:00 v1.9.4\n\n2014-05-28T11:04:29-07:00 v2.0.0\n2014-07-30T14:20:01-07:00 v2.0.4\n\n2014-08-15T15:09:28-07:00 v2.1.0\n2014-10-29T10:48:57-07:00 v2.1.3\n\n2014-11-26T13:18:43-08:00 v2.2.0\n2015-01-12T14:06:20-08:00 v2.2.2\n\n2015-02-05T13:24:05-08:00 v2.3.0\n\n(I have omitted the dates of the 5 security releases on 2014-12-17 as \nthat seems like an extraordinary event unlikely to be repeated.)\n\nIt appears that the average support lifespan of a Git release from \ninitial release date through last released maintenance update is \napproximately 2-3 months with the 1.7.6 release being an exception at \na little over 7 months.\n\nIf a v2.1.5 release is out of the question, would it be possible to \nperiodically designate certain Git releases as \"long term support\" \nreleases? Meaning that they would receive maintenance updates (e.g. \nfixes for invalid memory accesses/crashes, regressions or security \nissues) for an extended period of time, say at least 6 months?\n\n\nHere's the analysis that led to this request:\n\n\nGoal 1: add support for symref=HEAD:refs/... capability\n\nGoal 2: add support for pack bitmaps\n\nNice to have: The CVE-2014-9390 fix, but repo.or.cz does not create \nany working trees so it's not mandatory.\n\n\nGoal 1:\n\nsymref=HEAD:refs/... requires at least Git 1.8.4.3. However, \nrepo.or.cz runs git-daemon with read-only access to the repositories \nand since Git 1.8.4.2 shallow clones require write access.\n\nThis was corrected in v2.0.0. So at least v2.0.0 would be needed for \nsymref=HEAD:refs/....\n\n\nGoal 2:\n\nPack bitmap support was added in v2.0.0, but it's probably not a good \nidea to run without 21134714 (pack-objects: turn off bitmaps when we \nsplit packs) just in case which requires at least v2.1.3.\n\n\nNice to have:\n\nIf at least v2.1.3 is required, then we might as well use v2.1.4 since \nthe primary change from v2.1.3 to v2.1.4 is the addition of the \nCVE-2014-9390 fix.\n\n\nWhat about a later release, v2.2.0 or later?\n\n\ngit-svn is reported to suffer from occasional \".git/ \nGit_svn_hash_XXXXXX: Bad file descriptor\" errors since v2.2.0 making \nthat a non-starter. No fix is currently available in the Git \nrepository.\n\nSince 660c889e (sha1_file: add for_each iterators for loose and packed \nobjects) loose objects in alternates directories may not be found when \npruning. This affects v2.2.0 and later. A fix is currently in \nmaster. This is an absolute must have for repo.or.cz as alternates \nare used to implement repository forks.\n\nSince d38379e (make update-server-info more robust), affecting v2.2.x, \nthe files used by non-smart HTTP clients could have the wrong \npermissions. This might preclude them from being updated correctly on \nrepo.or.cz. It would require research to see if repo.or.cz is \naffected. The fix for this d91175b2 (update-server-info: create info/ \n* with mode 0666) was released in v2.3.0.\n\n\nSo why not v2.1.4 then?\n\n\nThere's an XDL_FAST_HASH performance regression that affects v1.7.11 \nand later [1]. But that can be turned off in config.mak.\n\nNew repositories have an extra +x on the config file since v2.1.0 \n(fixed in v2.2.2), but we can compensate with a chmod after creating a \nnew repository.\n\nGit blame has a crashing regression since ea02ffa3 (mailmap: simplify \nmap_user() interface) that affects v1.8.2 and later. The fix is \ncurrently in master. repo.or.cz enables blame in the gitweb interface \nso that would be a serious regression.\n\nThere's an issue with ungetting EOF. That would seem unlikely to \naffect repo.or.cz, but, I wonder if any of the displays used by gitweb \ncould trigger attempts to read a .mailmap or .gitattributes blob? I \ndon't know. Would require research to be certain or just picking up \nthe fix which is currently in master.\n\nThere's a decimal_width overflow regression since dc801e7 (diff -- \nstat: use less columns for change counts) affecting v1.7.11 and later \nthat can lead to an infinite loop in some cases. Presumably either \ngitweb or the diffs sent out by the ref update email notification \nmechanism could trigger this. A fix is currently in master.\n\nThere is a regression since v1.7.1.1 where a fetch from a non-smart \nHTTP source could potentially fail to retrieve the correct objects. \nAs repo.or.cz has several mirrors set up from non-smart HTTP sources a \nfix for this (currently in master) would be nice but is probably not \nmandatory since repo.or.cz is currently running a version of Git with \nthis regression and has not received any reports of failures that \ncould be related to this.\n\nSince fbd4a703 (list-objects: mark more commits as edges in \nmark_edges_uninteresting) affecting v1.8.4.2 and later combined with \n200abe74 (list-objects: only look at cmdline trees with edge_hint) \naffecting v1.9.0 and later there is a performance regression when \npushing with lots of refs to non-shallow repos. The fix 2dacf26d \n(pack-objects: use --objects-edge-aggressive for shallow repos) was \nreleased in v2.3.0.\n\n\n-Kyle\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/261638\n---- END FIRST MESSAGE ----\n\n---- BEGIN SECOND MESSAGE ----\nFrom: Junio C Hamano \nDate: February 24, 2015 11:52:03 PST\nTo: Kyle J. McKay \nCc: Git Mailing List \nSubject: Re: Any chance for a Git v2.1.5 release?\nMessage-Id: \nContent-Type: text/plain\n\nKyle J. McKay writes:\n\n> Which brings us back to the subject of this email, is there any chance\n> for a v2.1.5 release?\n> ...\n> It appears that the average support lifespan of a Git release from\n> initial release date through last released maintenance update is\n> approximately 2-3 months with the 1.7.6 release being an exception at\n> a little over 7 months.\n\nThat matches my expectation.\n\nA typical cycle lasts for 8-12 weeks, and during that time, topics\nthat are bugfixes that have graduated to the 'master' branch are\nmerged to the 'maint' branch with some lag and then the tip of\n'maint' gets tagged as a maintenance release from time to time.\nSome important but trivial fixes are further merged to older\nmaitenance tracks like 'maint-2.2', 'maint-2.1', etc.\n\nBut these topics downmerged to older maint-* branches have to be\nvery trivial for an obvious reason: there are only 24 hours a day\nand 7 days in a week, and bugs that affect real world use cases are\nfound by using the software in real world use cases. Usually I use\nsomething a bit ahead of 'next' exactly for this reason---we would\nwant to catch bugs before topics are merged to 'master'. Although I\nsometimes have \"let's use 'maint' for my work\" day once or twice\nevery month, I cannot afford to do that for anything older than the\ntip of 'maint' myself.\n\nThe consequence of the above is this. v2.1.1 may be more stable\nthan v2.1.0 and v2.1.2 may be more stable than v2.1.1, but later\ntagged versions on older maintenance tracks are made by merging\ntopics only after \"ah, these are obvious enough\" eyeballing without\nreal use (at least by me), once newer feature release is made and\nthere is a newer maintenance track. I would not be surprised if\nv2.1.5, if it is made, has hidden interactions between the changes\nsince v2.1.4 and the older codebase to cause unforeseen bugs.\n\nWhen I say \"the tip of 'master' is meant to be more stable than any\ntagged versions\", I do mean it.\n\nHaving said all that, if I were to tag maint-2.1 branch as 2.1.5\ntoday, we would have\n\n 6aaf956 is_hfs_dotgit: loosen over-eager match of \\u{..47}\n\nthat does not exist in 2.1.4. Is that what you want?\n\n> If a v2.1.5 release is out of the question, would it be possible to\n> periodically designate certain Git releases as \"long term support\"\n> releases?\n\nI can designate ;-), but I do not think I'd be the right person to\nmaintain or long-term-support it. Are you volunteering to oversee\nthe \"LTS team\"? It would involve:\n\n - Monitor \"git log --first-parent maint-lts..master\" and find\n the tip of topic branches that need to be down-merged;\n\n - Down-merge such topics to maint-lts; this might involve\n cherry-picking instead of merge, as the bugfix topics may\n originally be done on the codebase newer than maint-lts;\n\n - Use the tip of the maint-lts branch in everyday work.\n\nThe last item is the most important of the above, because I do not\nhave time for that. I can help with the first two to some degree,\nthough.\n\nIf the lts releases need to be tagged and published by me, then lts\nteam can have me pull from the tip of maint-lts they are confident\nwith and have me sign it and push it out.\n\nIf the primary concern you have with the currently maintained\nreleases is git-svn, perhaps a better way forward for you,\nespecially if you are willing to maintain your own \"release plus\npatches\", might be to keep a patch that reverts recent git-svn\nchanges back to v2.1.whatever and deploy the up-to-date release\nand that patch on top?\n\n> Nice to have: The CVE-2014-9390 fix, but repo.or.cz does not create\n> any working trees so it's not mandatory.\n\nEven if you do not have a working tree, people who use you as the\nmeeting place and push into you and fetch from you do, so I do not\nnecessarily agree with your assessment.\n---- END SECOND MESSAGE ----\n"}]}