Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On 11/21/2018 01:00 AM, Junio C Hamano wrote: * md/list-lazy-objects-fix (2018-10-29) 1 commit - list-objects.c: don't segfault for missing cmdline objects "git rev-list --exclude-promissor-objects" had to take an object that does not exist locally (and is lazily available) from the command line without barfing, but the code dereferenced NULL. That sympotom may be worth addressing, but I think the "fix" is overly broad and is wrong. Giving a missing object should be diagnosed as an error, not swept under the rug silently. Thank you for taking a look. I just sent v3 of the patch: https://public-inbox.org/git/20181205214346.106217-1-matv...@google.com/T/#u which is different from v2 in that it honors the presence or absence of --ignore-missing. It will only sweep things under the rug if that flag is passed.
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
Stefan Beller writes: >> * sb/submodule-recursive-fetch-gets-the-tip (2018-10-31) 11 commits >> [...] >> >> "git fetch --recurse-submodules" may not fetch the necessary commit >> that is bound to the superproject, which is getting corrected. >> >> Is the discussion on this topic over? What was the outcome? > > Please don't merge down the topic in the current state. Thanks. It won't happen until the final anyway ;-)
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
> > * sb/submodule-recursive-fetch-gets-the-tip (2018-10-31) 11 commits > [...] > > "git fetch --recurse-submodules" may not fetch the necessary commit > that is bound to the superproject, which is getting corrected. > > Is the discussion on this topic over? What was the outcome? Please don't merge down the topic in the current state. I have a local updated version sitting on my disk and plan to send it once I made sure it addressed all comments of various revisions.
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Sun, Nov 25, 2018 at 11:02:05AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I do also think in the long run we should be fixing the "unreachable > > always become loose" issues. > > I think I've seen an idea of collecting them into a garbage pack > floated for at least a few times here. What are the downsides? We > no longer will know when these unreachable ones were last accessed > individually so we need to come up with a different policy around > their expiration? As the common traits among objects in such a > garbage pack (iow the way we discover the objects that need to be > placed in there) does not involve path information and we lose the > ability to compress them well? Yes, the main issue is handling the expiration/mtime. We may lose some input to the delta heuristics, but: - the current alternative is non-delta loose objects (so just shoving those in a pack is no worse for disk space, and probably better because of less inode/file overhead) - if they were already packed we can often just retain the existing deltas (and we get this basically for free with the existing code) - we could still walk unreachable bits of the graph, starting at dangling commits, to find the path information (we do this to some degree already to avoid dropping objects depended on by "unreachable but recent" objects, but I don't know how systematic we are about making sure to hit walk down from root trees first) The most thorough discussion I know of in this direction is the one around: https://public-inbox.org/git/20170610080626.sjujpmgkli4mu...@sigill.intra.peff.net/ -Peff
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
Jeff King writes: > I do also think in the long run we should be fixing the "unreachable > always become loose" issues. I think I've seen an idea of collecting them into a garbage pack floated for at least a few times here. What are the downsides? We no longer will know when these unreachable ones were last accessed individually so we need to come up with a different policy around their expiration? As the common traits among objects in such a garbage pack (iow the way we discover the objects that need to be placed in there) does not involve path information and we lose the ability to compress them well?
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Thu, Nov 22, 2018 at 07:36:54PM +0100, Ævar Arnfjörð Bjarmason wrote: > > Yeah, my intent had been to circle back around to this, but I just > > hadn't gotten to it. I'm still pondering a config option or similar, > > though I remain unconvinced that the cases in which you've showed it > > being slow are actually realistic or worth worrying about > > FWIW those "used to be 2ms are now 20-40ms" pushes on ext4 are > representative of the actual prod setup I'm mainly targeting. Now, I > don't run on ext4 this patch helps there, but it seems plausible that it > matters to someone who's counting on that performance. Those are actually the more interesting cases, I think. The ones I'm most skeptical of are the multi-second delays due to having 250K+ objects. I do also think in the long run we should be fixing the "unreachable always become loose" issues. > Buh yeah, it's certainly obscure. I don't blame you if you don't want to > hack on it, and not ejecting this out before 2.20 isn't going to break > anything for me. But do you mind if I make it configurable as part of my > post-2.20 "disable collisions?" No, not at all. > > (and certainly having an obscure config option is not enough to help > > most people). If we could have it kick in heuristically, that would be > > better. > > Aside from this specific scenario. I'd really prefer if we avoid having > heuristic performance optimizations at all costs. > > Database servers tend to do that sort of thing with their query planner, > and it results in cases where your entire I/O profile changes overnight > because you're now on the wrong side of some if/else heuristic about > whather to use some index or not. Yes, I agree that's a downside. I just think if we make everybody's performance 10% slower, they're not really going to notice and seek out a config option to flip to fix it. > > However, note that the cache-load for finding abbreviations _must_ have > > the complete list. And has been loading it for some time. So if you run > > "git-fetch", for example, you've already been running this code for > > months (and using the cache in more places is now a free speedup). > > This is reminding me that I need to get around to re-submitting my > core.validateAbbrev series, which addresses this part of the problem: > https://public-inbox.org/git/20180608224136.20220-21-ava...@gmail.com/ Yeah, I still agree that is a reasonable thing to do. > > At the very least, we'd want this patch on top, too. I also think René's > > suggestion use access() is worth pursuing (though to some degree is > > orthogonal to the cache). > > I haven't had time to test that, and wasn't prioritizing it since I > figured this was post-2.20. My hunch is it doesn't matter much if at all > on NFS. The roundtrip time is what matters, whether that roundtrip is > fstat() or access() probably not. Yes, that line of reasoning makes sense to me (but I think an easy 2-3% speedup on local filesystems may be worth it). -Peff
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Sat, Nov 24, 2018 at 11:11:36AM +0900, Junio C Hamano wrote: > > However, note that the cache-load for finding abbreviations _must_ have > > the complete list. And has been loading it for some time. So if you run > > "git-fetch", for example, you've already been running this code for > > months (and using the cache in more places is now a free speedup). > > > > At the very least, we'd want this patch on top, too. I also think René's > > suggestion use access() is worth pursuing (though to some degree is > > orthogonal to the cache). > > OK, will queue, but I wonder where 66f0 comes from before silently > doing s/66f04152be/3a2e08245c/ myself. Whoops, I thought I made double-sure to pull the commit id from origin/jk/loose-object-cache instead of my original local commits, but obviously I didn't. Thanks for catching it. -Peff
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
Jeff King writes: > Yeah, my intent had been to circle back around to this, but I just > hadn't gotten to it. I'm still pondering a config option or similar, > though I remain unconvinced that the cases in which you've showed it > being slow are actually realistic or worth worrying about (and certainly > having an obscure config option is not enough to help most people). If > we could have it kick in heuristically, that would be better. Me neither and I agree. > However, note that the cache-load for finding abbreviations _must_ have > the complete list. And has been loading it for some time. So if you run > "git-fetch", for example, you've already been running this code for > months (and using the cache in more places is now a free speedup). > > At the very least, we'd want this patch on top, too. I also think René's > suggestion use access() is worth pursuing (though to some degree is > orthogonal to the cache). OK, will queue, but I wonder where 66f0 comes from before silently doing s/66f04152be/3a2e08245c/ myself. > -- >8 -- > Subject: [PATCH] odb_load_loose_cache: fix strbuf leak > > Commit 66f04152be (object-store: provide helpers for > loose_objects_cache, 2018-11-12) moved the cache-loading code from > find_short_object_filename(), but forgot the line that releases the path > strbuf. > > Reported-by: René Scharfe > Signed-off-by: Jeff King > --- > sha1-file.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sha1-file.c b/sha1-file.c > index 5894e48ea4..5a272f70de 100644 > --- a/sha1-file.c > +++ b/sha1-file.c > @@ -2169,6 +2169,7 @@ void odb_load_loose_cache(struct object_directory *odb, > int subdir_nr) > NULL, NULL, > >loose_objects_cache); > odb->loose_objects_subdir_seen[subdir_nr] = 1; > + strbuf_release(); > } > > static int check_stream_sha1(git_zstream *stream,
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Thu, Nov 22 2018, Jeff King wrote: > On Wed, Nov 21, 2018 at 11:48:14AM +0100, Ævar Arnfjörð Bjarmason wrote: > >> >> On Wed, Nov 21 2018, Junio C Hamano wrote: >> >> > * jk/loose-object-cache (2018-11-13) 9 commits >> > (merged to 'next' on 2018-11-18 at 276691a21b) >> > + fetch-pack: drop custom loose object cache >> > + sha1-file: use loose object cache for quick existence check >> > + object-store: provide helpers for loose_objects_cache >> > + sha1-file: use an object_directory for the main object dir >> > + handle alternates paths the same as the main object dir >> > + sha1_file_name(): overwrite buffer instead of appending >> > + rename "alternate_object_database" to "object_directory" >> > + submodule--helper: prefer strip_suffix() to ends_with() >> > + fsck: do not reuse child_process structs >> > >> > Code clean-up with optimization for the codepath that checks >> > (non-)existence of loose objects. >> > >> > Will cook in 'next'. >> >> I think as noted in >> https://public-inbox.org/git/e5148b8c-9a3a-5d2e-ac8c-3e536c0f2...@web.de/ >> that we should hold off the [89]/9 of this series due to the performance >> regressions this introduces in some cases (while fixing other cases). >> >> I hadn't had time to follow up on that, and figured it could wait until >> post-2.20 for a re-roll. > > Yeah, my intent had been to circle back around to this, but I just > hadn't gotten to it. I'm still pondering a config option or similar, > though I remain unconvinced that the cases in which you've showed it > being slow are actually realistic or worth worrying about FWIW those "used to be 2ms are now 20-40ms" pushes on ext4 are representative of the actual prod setup I'm mainly targeting. Now, I don't run on ext4 this patch helps there, but it seems plausible that it matters to someone who's counting on that performance. Buh yeah, it's certainly obscure. I don't blame you if you don't want to hack on it, and not ejecting this out before 2.20 isn't going to break anything for me. But do you mind if I make it configurable as part of my post-2.20 "disable collisions?" > (and certainly having an obscure config option is not enough to help > most people). If we could have it kick in heuristically, that would be > better. Aside from this specific scenario. I'd really prefer if we avoid having heuristic performance optimizations at all costs. Database servers tend to do that sort of thing with their query planner, and it results in cases where your entire I/O profile changes overnight because you're now on the wrong side of some if/else heuristic about whather to use some index or not. > However, note that the cache-load for finding abbreviations _must_ have > the complete list. And has been loading it for some time. So if you run > "git-fetch", for example, you've already been running this code for > months (and using the cache in more places is now a free speedup). This is reminding me that I need to get around to re-submitting my core.validateAbbrev series, which addresses this part of the problem: https://public-inbox.org/git/20180608224136.20220-21-ava...@gmail.com/ > At the very least, we'd want this patch on top, too. I also think René's > suggestion use access() is worth pursuing (though to some degree is > orthogonal to the cache). I haven't had time to test that, and wasn't prioritizing it since I figured this was post-2.20. My hunch is it doesn't matter much if at all on NFS. The roundtrip time is what matters, whether that roundtrip is fstat() or access() probably not. > -- >8 -- > Subject: [PATCH] odb_load_loose_cache: fix strbuf leak > > Commit 66f04152be (object-store: provide helpers for > loose_objects_cache, 2018-11-12) moved the cache-loading code from > find_short_object_filename(), but forgot the line that releases the path > strbuf. > > Reported-by: René Scharfe > Signed-off-by: Jeff King > --- > sha1-file.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sha1-file.c b/sha1-file.c > index 5894e48ea4..5a272f70de 100644 > --- a/sha1-file.c > +++ b/sha1-file.c > @@ -2169,6 +2169,7 @@ void odb_load_loose_cache(struct object_directory *odb, > int subdir_nr) > NULL, NULL, > >loose_objects_cache); > odb->loose_objects_subdir_seen[subdir_nr] = 1; > + strbuf_release(); > } > > static int check_stream_sha1(git_zstream *stream,
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Wed, Nov 21, 2018 at 11:48:14AM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Nov 21 2018, Junio C Hamano wrote: > > > * jk/loose-object-cache (2018-11-13) 9 commits > > (merged to 'next' on 2018-11-18 at 276691a21b) > > + fetch-pack: drop custom loose object cache > > + sha1-file: use loose object cache for quick existence check > > + object-store: provide helpers for loose_objects_cache > > + sha1-file: use an object_directory for the main object dir > > + handle alternates paths the same as the main object dir > > + sha1_file_name(): overwrite buffer instead of appending > > + rename "alternate_object_database" to "object_directory" > > + submodule--helper: prefer strip_suffix() to ends_with() > > + fsck: do not reuse child_process structs > > > > Code clean-up with optimization for the codepath that checks > > (non-)existence of loose objects. > > > > Will cook in 'next'. > > I think as noted in > https://public-inbox.org/git/e5148b8c-9a3a-5d2e-ac8c-3e536c0f2...@web.de/ > that we should hold off the [89]/9 of this series due to the performance > regressions this introduces in some cases (while fixing other cases). > > I hadn't had time to follow up on that, and figured it could wait until > post-2.20 for a re-roll. Yeah, my intent had been to circle back around to this, but I just hadn't gotten to it. I'm still pondering a config option or similar, though I remain unconvinced that the cases in which you've showed it being slow are actually realistic or worth worrying about (and certainly having an obscure config option is not enough to help most people). If we could have it kick in heuristically, that would be better. However, note that the cache-load for finding abbreviations _must_ have the complete list. And has been loading it for some time. So if you run "git-fetch", for example, you've already been running this code for months (and using the cache in more places is now a free speedup). At the very least, we'd want this patch on top, too. I also think René's suggestion use access() is worth pursuing (though to some degree is orthogonal to the cache). -- >8 -- Subject: [PATCH] odb_load_loose_cache: fix strbuf leak Commit 66f04152be (object-store: provide helpers for loose_objects_cache, 2018-11-12) moved the cache-loading code from find_short_object_filename(), but forgot the line that releases the path strbuf. Reported-by: René Scharfe Signed-off-by: Jeff King --- sha1-file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sha1-file.c b/sha1-file.c index 5894e48ea4..5a272f70de 100644 --- a/sha1-file.c +++ b/sha1-file.c @@ -2169,6 +2169,7 @@ void odb_load_loose_cache(struct object_directory *odb, int subdir_nr) NULL, NULL, >loose_objects_cache); odb->loose_objects_subdir_seen[subdir_nr] = 1; + strbuf_release(); } static int check_stream_sha1(git_zstream *stream, -- 2.20.0.rc1.703.g93fba25b62
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Wed, Nov 21, 2018 at 6:08 PM Stephen P. Smith wrote: > > Picking up someones stalled patch is one thing, picking up Linus' patch is in > a different league. No, I think it works the other way - my random patches are likely the _least_ important ones, simply because I can carry them around in my own tree anyway, and my workflows may be odd by most git standards. If I'm the only user of the "human" date format, then Junio is absolutely right to not move it to the main branch. I have some other private patches in my tree that have been mentioned on the list but that nobody else got excited about: - Add 'human' date mode - Make 'git gc --prune=now' mean 'prune after start of command' - ls-remote: add "--diff" option to show only refs that differ none of which are in the least important, but that I find personally useful. Linus
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Thu, Nov 22, 2018 at 11:31 AM Stephen P. Smith wrote: > > On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote: > > [Stalled] > > > > * lt/date-human (2018-07-09) 1 commit > > - Add 'human' date format > > > > A new date format "--date=human" that morphs its output depending > > on how far the time is from the current time has been introduced. > > "--date=auto" can be used to use this new format when the output is > > goint to the pager or to the terminal and otherwise the default > > format. > > What needs to be done with this patch to move it along? In e.g. "Git Test Coverage Report (Wednesday Nov 21)" by Stolee you can see that the new code in date.c is largely uncovered. Adding tests for the behavior would be a good start. > I see that both Linus and Junio have signed the patch. That just means Linus wrote it and Junio ran "git am -s" on it.
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Wednesday, November 21, 2018 6:06:13 PM MST Junio C Hamano wrote: > "Stephen P. Smith" writes: > > On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote: > >> [Stalled] > >> > >> * lt/date-human (2018-07-09) 1 commit > >> > >> - Add 'human' date format > >> > >> A new date format "--date=human" that morphs its output depending > >> on how far the time is from the current time has been introduced. > >> "--date=auto" can be used to use this new format when the output is > >> goint to the pager or to the terminal and otherwise the default > >> format. > > > > What needs to be done with this patch to move it along? > > In a random order as they come to my mind: > > - Support by people other than the original author; I was trying to decide if you were wanting someone besides Linus to carry this through (knowing that he was unlikely to do so). The idea seems reasonable to me. I don't mind doing so if neither of you object. > > - Deciding what to call this (i.e. Linus's personal preference >would not be the only 'human' style, but we may declare it is >good enough as "a" human format, not "the" human format); > > - Some mechanism (either technical or documentation) to prevent >endless stream of "I like human output, but I'd tweak it slightly >this way" updates in the future; > > - Doc; > > - Command line completion; > > - Tests; > > - Waiting for the end of feature freeze before the upcoming >release. > > There may be others, but without all of the above, I'd feel a bit > uncomfortable. > I wouldn't think this would go in now since the patch has been stalled for months. It is also on the pu branch. > > I see that both Linus and Junio have signed the patch. > > That does not assert that the code is desirable thing to add. It > just says we made sure that we legally have rights to include it, if > we want to. Picking up someones stalled patch is one thing, picking up Linus' patch is in a different league.
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
"Stephen P. Smith" writes: > On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote: >> [Stalled] >> >> * lt/date-human (2018-07-09) 1 commit >> - Add 'human' date format >> >> A new date format "--date=human" that morphs its output depending >> on how far the time is from the current time has been introduced. >> "--date=auto" can be used to use this new format when the output is >> goint to the pager or to the terminal and otherwise the default >> format. > > What needs to be done with this patch to move it along? In a random order as they come to my mind: - Support by people other than the original author; - Deciding what to call this (i.e. Linus's personal preference would not be the only 'human' style, but we may declare it is good enough as "a" human format, not "the" human format); - Some mechanism (either technical or documentation) to prevent endless stream of "I like human output, but I'd tweak it slightly this way" updates in the future; - Doc; - Command line completion; - Tests; - Waiting for the end of feature freeze before the upcoming release. There may be others, but without all of the above, I'd feel a bit uncomfortable. > I see that both Linus and Junio have signed the patch. That does not assert that the code is desirable thing to add. It just says we made sure that we legally have rights to include it, if we want to.
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Wednesday, November 21, 2018 2:00:16 AM MST Junio C Hamano wrote: > [Stalled] > > * lt/date-human (2018-07-09) 1 commit > - Add 'human' date format > > A new date format "--date=human" that morphs its output depending > on how far the time is from the current time has been introduced. > "--date=auto" can be used to use this new format when the output is > goint to the pager or to the terminal and otherwise the default > format. What needs to be done with this patch to move it along? I see that both Linus and Junio have signed the patch.
js/vsts-ci, was Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
Hi Junio, On Wed, 21 Nov 2018, Junio C Hamano wrote: > * js/vsts-ci (2018-10-16) 13 commits > . travis: fix skipping tagged releases > . README: add a build badge (status of the Azure Pipelines build) > . tests: record more stderr with --write-junit-xml in case of failure > . tests: include detailed trace logs with --write-junit-xml upon failure > . git-p4: use `test_atexit` to kill the daemon > . git-daemon: use `test_atexit` in the tests > . tests: introduce `test_atexit` > . ci: add a build definition for Azure DevOps > . ci/lib.sh: add support for Azure Pipelines > . tests: optionally write results as JUnit-style .xml > . test-date: add a subcommand to measure times in shell scripts > . ci/lib.sh: encapsulate Travis-specific things > . ci: rename the library of common functions > > Prepare to run test suite on Azure DevOps. > > Ejected out of 'pu', as doing so seems to help other topics get > tested at TravisCI. > > https://travis-ci.org/git/git/builds/452713184 is a sample of a > build whose tests on 4 hang (with this series in). Ejecting it > gave us https://travis-ci.org/git/git/builds/452778963 which still > shows breakages from other topics not yet in 'next', but at least > the tests do not stall. Sorry about that. FWIW my current plan is to work a bit more on the Windows phase (to make it faster), and to split out the `test_atexit` patches (because they cause those hangs). I still think it is the right thing to do, but I lack the time to take care of it within the next weeks. Instead, I will try to run even the Windows phase in --verbose-log mode so that the --junit-xml code can pick up the verbose logs right away (read: no more re-running upon test failures). Hopefully this won't cause a speed regression. Ciao, Dscho
Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)
On Wed, Nov 21 2018, Junio C Hamano wrote: > * jk/loose-object-cache (2018-11-13) 9 commits > (merged to 'next' on 2018-11-18 at 276691a21b) > + fetch-pack: drop custom loose object cache > + sha1-file: use loose object cache for quick existence check > + object-store: provide helpers for loose_objects_cache > + sha1-file: use an object_directory for the main object dir > + handle alternates paths the same as the main object dir > + sha1_file_name(): overwrite buffer instead of appending > + rename "alternate_object_database" to "object_directory" > + submodule--helper: prefer strip_suffix() to ends_with() > + fsck: do not reuse child_process structs > > Code clean-up with optimization for the codepath that checks > (non-)existence of loose objects. > > Will cook in 'next'. I think as noted in https://public-inbox.org/git/e5148b8c-9a3a-5d2e-ac8c-3e536c0f2...@web.de/ that we should hold off the [89]/9 of this series due to the performance regressions this introduces in some cases (while fixing other cases). I hadn't had time to follow up on that, and figured it could wait until post-2.20 for a re-roll.
What's cooking in git.git (Nov 2018, #06; Wed, 21)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The group of last-minute fixes marked as "Will merge to 'master'" hopefully will be part of -rc1. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * ab/dynamic-gettext-poison (2018-11-09) 2 commits (merged to 'next' on 2018-11-18 at 13247a3be6) + Makefile: ease dynamic-gettext-poison transition + i18n: make GETTEXT_POISON a runtime option Our testing framework uses a special i18n "poisoned localization" feature to find messages that ought to stay constant but are incorrectly marked to be translated. This feature has been made into a runtime option (it used to be a compile-time option). * ab/range-diff-no-patch (2018-11-14) 3 commits (merged to 'next' on 2018-11-17 at c42e0891d0) + range-diff: make diff option behavior (e.g. --stat) consistent + range-diff: fix regression in passing along diff options + range-diff doc: add a section about output stability The "--no-patch" option, which can be used to get a high-level overview without the actual line-by-line patch difference shown, of the "range-diff" command was earlier broken, which has been corrected. * ab/rebase-in-c-escape-hatch (2018-11-16) 2 commits (merged to 'next' on 2018-11-17 at a01be221c7) + tests: add a special setup where rebase.useBuiltin is off + rebase doc: document rebase.useBuiltin The recently merged "rebase in C" has an escape hatch to use the scripted version when necessary, but it hasn't been documented, which has been corrected. * ag/p3400-force-checkout (2018-11-12) 1 commit (merged to 'next' on 2018-11-17 at 87ff48d52a) + p3400: replace calls to `git checkout -b' by `git checkout -B' Perf test tweak. * cb/notes-freeing-always-null-fix (2018-11-13) 1 commit (merged to 'next' on 2018-11-17 at 47aeec5fc9) + builtin/notes: remove unnecessary free Code cleanup. * dd/poll-dot-h (2018-11-14) 1 commit (merged to 'next' on 2018-11-18 at b6745f3308) + git-compat-util: prefer poll.h to sys/poll.h A build update. * ds/push-squelch-ambig-warning (2018-11-07) 1 commit (merged to 'next' on 2018-11-18 at 5e8b3db129) + pack-objects: ignore ambiguous object warnings "git push" used to check ambiguities between object-names and refnames while processing the list of refs' old and new values, which was unnecessary (as it knew that it is feeding raw object names). This has been optimized out. * ds/reachable-topo-order (2018-11-02) 7 commits (merged to 'next' on 2018-11-13 at 4155d01aee) + t6012: make rev-list tests more interesting + revision.c: generation-based topo-order algorithm + commit/revisions: bookkeeping before refactoring + revision.c: begin refactoring --topo-order logic + test-reach: add rev-list tests + test-reach: add run_three_modes method + prio-queue: add 'peek' operation The revision walker machinery learned to take advantage of the commit generation numbers stored in the commit-graph file. * jk/close-duped-fd-before-unlock-for-bundle (2018-11-17) 1 commit (merged to 'next' on 2018-11-17 at 2fe598284e) + bundle: dup() output descriptor closer to point-of-use When "git bundle" aborts due to an empty commit ranges (i.e. resulting in an empty pack), it left a file descriptor to an lockfile open, which resulted in leftover lockfile on Windows where you cannot remove a file with an open file descriptor. This has been corrected. * jk/curl-ldflags (2018-11-05) 1 commit (merged to 'next' on 2018-11-13 at d1387a3aa0) + build: link with curl-defined linker flags The way -lcurl library gets linked has been simplified by taking advantage of the fact that we can just ask curl-config command how. * jk/unused-parameter-fixes (2018-11-06) 14 commits (merged to 'next' on 2018-11-13 at 8d3625b4ae) + midx: double-check large object write loop + assert NOARG/NONEG behavior of parse-options callbacks + parse-options: drop OPT_DATE() + apply: return -1 from option callback instead of calling exit(1) + cat-file: report an error on multiple --batch options + tag: mark "--message" option with NONEG + show-branch: mark --reflog option as NONEG + format-patch: mark "--no-numbered" option with NONEG + status: mark --find-renames option with NONEG + cat-file: mark batch options with NONEG + pack-objects: mark index-version option as NONEG + ls-files: mark exclude options as NONEG + am: handle --no-patch-format option + apply: mark include/exclude options as NONEG Various functions have been audited for "-Wunused-parameter" warnings and bugs in them got fixed. * jk/verify-sig-merge-into-void
