Thread (1 message) 1 message, 1 author, 2018-08-03

Re: What's cooking in git.git (Aug 2018, #01; Thu, 2)

From: Junio C Hamano <hidden>
Date: 2018-08-03 16:08:54

Stefan Beller [off-list ref] writes:
On Thu, Aug 2, 2018 at 4:02 PM Junio C Hamano [off-list ref] wrote:
quoted
* sb/config-write-fix (2018-08-01) 3 commits
 - git-config: document accidental multi-line setting in deprecated syntax
 - config: fix case sensitive subsection names on writing
 - t1300: document current behavior of setting options

 Recent update to "git config" broke updating variable in a
 subsection, which has been corrected.

 Not quite?
 cf. [ref]
I'd rather point to
https://public-inbox.org/git/xmqqftzx67vo.fsf@gitster-ct.c.googlers.com/
https://public-inbox.org/git/xmqqva8t4s63.fsf@gitster-ct.c.googlers.com/
instead (reason: shoddiness),
Thanks; I do not think the series was particulary shoddy, but does
deserve a bit more polishing.
Personally I do not want to care about the old notation
and by implementing it the way the series is, the
old notation doesn't see any *changes*.
Yup, I agree that it is good enough.
quoted
* ds/commit-graph-with-grafts (2018-07-19) 8 commits
  (merged to 'next' on 2018-08-02 at 0ee624e329)
 + commit-graph: close_commit_graph before shallow walk
 + commit-graph: not compatible with uninitialized repo
 + commit-graph: not compatible with grafts
 + commit-graph: not compatible with replace objects
 + test-repository: properly init repo
 + commit-graph: update design document
 + refs.c: upgrade for_each_replace_ref to be a each_repo_ref_fn callback
 + refs.c: migrate internal ref iteration to pass thru repository argument

 The recently introduced commit-graph auxiliary data is incompatible
 with mechanisms such as replace & grafts that "breaks" immutable
 nature of the object reference relationship.  Disable optimizations
 based on its use (and updating existing commit-graph) when these
 incompatible features are in use in the repository.
Makes sense as a whole, but I dislike the first 2 patches
(they were my suggestion) for the refs API. I plan to re send patches
https://public-inbox.org/git/20180730194731.220191-1-sbeller@google.com/
but fixed for real.

(do not let this stop you from merging down this series)
Well, I do not think we are in a particular hurry to get this down
to 'master', and honestly I'd feel safer to cook a topic that has
potential impact to the core longer in 'next' than other things like
this one (the distinction between the "core" and "other" being how
many things are potentially affected, and because commit-graph is
being integrated into history walking, a bug in the subsystem has a
lot bigger impact than say "rebase -i" that breaks "rebase -i
--root" by producing a malformed author-script file, whose impact
may be severe but limited).
quoted
* sb/submodule-update-in-c (2018-07-18) 6 commits
 - submodule--helper: introduce new update-module-mode helper
 - builtin/submodule--helper: factor out method to update a single submodule
 - builtin/submodule--helper: store update_clone information in a struct
 - builtin/submodule--helper: factor out submodule updating
 - git-submodule.sh: rename unused variables
 - git-submodule.sh: align error reporting for update mode to use path

 "git submodule update" is getting rewritten piece-by-piece into C.

 Will merge to 'next'.
Please do not, AFAICT this is still breaking in combination with the
series merged at 7e25437d35a (Merge branch 'sb/submodule-core-worktree',
2018-07-18) and I do not recall fixing the interaction between those two.
Thanks for stopping me.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help