On Wed, 2015-12-02 at 14:11 -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > What's cooking in git.git (Dec 2015, #01; Tue, 1) > > -------------------------------------------------- > > > > Here are the topics that have been cooking. Commits prefixed with > > '-' are only in 'pu' (proposed updates) while commits prefixed with > > '+' are in 'next'. > > > > This should by my final whats-cooking before handing things back to > > Junio. Thanks all for review help and for your patience during the past > > few weeks. > > I think I managed to get my working area (together with a handful of > new entries in the rerere database and a few merge-fix/ entries) in > sync with what you pushed out well enough that my automated > procedure would recreate the status of various branches you pushed > out exactly. > > I haven't caught up with the changes in the component branches, > though, so it may take a few days until I start picking up new > topics from the list traffic. > > > * bc/object-id (2015-11-20) 12 commits > > - remote: convert functions to struct object_id > > - Remove get_object_hash. > > - Convert struct object to object_id > > - Add several uses of get_object_hash. > > - object: introduce get_object_hash macro. > > - ref_newer: convert to use struct object_id > > - push_refs_with_export: convert to struct object_id > > - get_remote_heads: convert to struct object_id > > - parse_fetch: convert to use struct object_id > > - add_sought_entry_mem: convert to struct object_id > > - Convert struct ref to use object_id. > > - sha1_file: introduce has_object_file helper. > > > > More transition from "unsigned char[40]" to "struct object_id". > > > > This needed a few merge fixups, but is mostly disentangled from other > > topics. > > > > Will merge to 'next'. > > Aside from niggles on titles of a handful of changes in this topic, > I have a bit of concern with this one and dt/refs-backend-pre-vtable > topic (marked as "Will merge to 'master' two cycles from now.", > which I am reading as "two cycles" means 2 x (8-10 week release > cycle), not "two integration cycles by the maintainer, aka two > issues of What's cooking report", which is typically less than a > week). > > The merge resolution in 'pu' discards what this topic did to refs.c > because much of the original goes away from there, but does it mean > (remember, I haven't caught up with the contents of the topics yet) > that the merge reverts part of what this topic did, and in an ideal > world, if the other one were more mature when this topic got > started, more use of "unsigned char[40]" would have been migrated to > "struct object_id" in new files the other one introduced? Or > perhaps we would want to go the other way around, i.e. as this topic > conceptually is fairly straight-forward, merge this to 'next' and > then down to 'master' (which would not take two release cycles) and > then redo the other topic on top? > > > * mr/ff-refs (2015-11-28) 6 commits > > - builtin/ff-refs.c: mark some file-local variables static > > - ff-refs: Add tests > > - ff-refs: Add documentation > > - ff-refs: add --dry-run and --skip-worktree options > > - ff-refs: update each updatable ref > > - ff-refs: builtin cmd to check and fast forward local refs to their upstream > > > > Specialized command to fast-forward refs to match their upstream. > > > > I remain skeptical that this is necessary or sufficient. Comments > > welcome. > > > > Will hold. > > This is another one that needs some evil-merge interaction with > bc/object-id, but I have a feeling that this is not such a good > addition to our workflow elements, so I am not worried too much > about it. I'm inclined to eject this topic (and will welcome if > people come up with an alternative, perhaps based on the "let fetch > do so instead" approach discussed there). > > > * ps/rebase-keep-empty (2015-11-24) 2 commits > > - rebase: fix preserving commits with --keep-empty > > - rebase: test broken behavior with --keep-empty > > > > Keep duplicate commits via rebase --keep-empty. > > > > I'm not sure if I agree with this interpretation of the "rebase > > --keep-empty" documentation, but I haven't thought too hard about it. > > Comments welcome. > > "--keep-empty" has always been about keeping an originally empty > commit, not a commit that becomes empty because of rebasing > (i.e. what has already been applied to the updated base). The > documentation, if it leads to any other interpretation, needs to be > fixed. > > Besides, if "--keep-empty" were to mean "keep redundant ones that > are already in the updated base", the patch must do a lot more, > e.g. stop filtering with git-cherry patch equivalence. > > I'm inclined to eject this topic. > > > > * ls/test-must-fail-sigpipe (2015-11-28) 2 commits > > (merged to 'next' on 2015-12-01 at d374686) > > + add "ok=sigpipe" to test_must_fail and use it to fix flaky tests > > + implement test_might_fail using a refactored test_must_fail > > > > Fix some racy client/server tests by treating SIGPIPE the same as a > > normal non-zero exit. > > > > Will merge to 'master' two cycles from now. > > Hmm, perhaps I misread what you meant by "two cycles", as this is > only the test suite and I cannot imagine we would want to be > ultra-safe to cook that for two release cycles, and you did mean two > issues of "What's cooking" report? > > If so, I'll have to rethink the comment on bc/object-id I made > earlier... > > > * dt/refs-backend-pre-vtable (2015-11-20) 10 commits > > (merged to 'next' on 2015-11-24 at 8fd7293) > > + refs: break out ref conflict checks > > + files_log_ref_write: new function > > + initdb: make safe_create_dir public > > + refs: split filesystem-based refs code into a new file > > + refs/refs-internal.h: new header file > > + refname_is_safe(): improve docstring > > + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref() > > + copy_msg(): rename to copy_reflog_msg() > > + verify_refname_available(): new function > > + verify_refname_available(): rename function > > > > Code preparation for pluggable ref backends. > > > > Will merge to 'master' two cycles from now. > > ... that is, I'd very much prefer bc/object-id redone on top of an > updated codebase that already has dt/refs-backend-pre-vtable in it. >From a selfish perspective, I, would prefer for object-ids to not happen quite yet for the refs code. I have already prepared (but not yet sent) a new version of the refs backend vtable (and lmdb) code on top of refs-backend-pre-vtable, and it'll be a hassle to reroll it on top of new object-id stuff. I guess I'll go ahead and send mine now, and we can later make a decision about how to deal with the object-id stuff. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html