Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
On Mon, Nov 28, 2016 at 4:06 PM, Junio C Hamanowrote: > Jonathan Tan writes: > >> On 11/23/2016 03:21 PM, Junio C Hamano wrote: >>> * jt/use-trailer-api-in-commands (2016-11-02) 6 commits >>> - sequencer: use trailer's trailer layout >>> - trailer: have function to describe trailer layout >>> - trailer: avoid unnecessary splitting on lines >>> - commit: make ignore_non_trailer take buf/len >>> - SQUASH??? >>> - trailer: be stricter in parsing separators >>> >>> Commands that operate on a log message and add lines to the trailer >>> blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and >>> "commit -s", have been taught to use the logic of and share the >>> code with "git interpret-trailer". >>> >>> What's the doneness of this topic? >> >> Stefan Beller mentioned [1] that this seemed OK to him from a cursory >> read. Do I need to look for another reviewer (or a more thorough >> review)? > > I gave it a cursory review when it was queued, too, so another > cursory read does not help very much ;) If I recall correctly, I > got an impression that it was reasonably well done. > > I haven't had a chance to look at the series again to see if the > SQUASH is just the simple matter of squashing it into the one > previous, which is the main reason why I haven't decided if it is > ready to be in 'next'. > > Thanks. Sorry, I'm not sure what you mean by this. The SQUASH is an update in documentation (for a C function) (reproduced below [1]) which can be squashed cleanly (just to confirm, I tried it using "git rebase -i"). It can also be rebased cleanly onto master or next (at least, as of now). If you are asking about whether I think the contents of your SQUASH commit is reasonable, I think that it is. [1] $ git show 7e7587d commit 7e7587d563ddb540875075e5a84359a8a96a5188 Author: Junio C Hamano Date: Wed Nov 2 19:28:53 2016 -0700 SQUASH??? diff --git a/trailer.c b/trailer.c index dc525e3..eefe91d 100644 --- a/trailer.c +++ b/trailer.c @@ -565,7 +565,9 @@ static int token_matches_item(const char *tok, struct arg_item *item, int tok_le /* * If the given line is of the form * "..." or "...", return the - * location of the separator. Otherwise, return -1. + * location of the separator. Otherwise, return -1. The optional whitespace + * is allowed there primarily to allow things like "Bug #43" where is + * "Bug" and is "#". * * The separator-starts-line case (in which this function returns 0) is * distinguished from the non-well-formed-line case (in which this function
Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
Jonathan Tanwrites: > On 11/23/2016 03:21 PM, Junio C Hamano wrote: >> * jt/use-trailer-api-in-commands (2016-11-02) 6 commits >> - sequencer: use trailer's trailer layout >> - trailer: have function to describe trailer layout >> - trailer: avoid unnecessary splitting on lines >> - commit: make ignore_non_trailer take buf/len >> - SQUASH??? >> - trailer: be stricter in parsing separators >> >> Commands that operate on a log message and add lines to the trailer >> blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and >> "commit -s", have been taught to use the logic of and share the >> code with "git interpret-trailer". >> >> What's the doneness of this topic? > > Stefan Beller mentioned [1] that this seemed OK to him from a cursory > read. Do I need to look for another reviewer (or a more thorough > review)? I gave it a cursory review when it was queued, too, so another cursory read does not help very much ;) If I recall correctly, I got an impression that it was reasonably well done. I haven't had a chance to look at the series again to see if the SQUASH is just the simple matter of squashing it into the one previous, which is the main reason why I haven't decided if it is ready to be in 'next'. Thanks.
Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
On 11/23/2016 03:21 PM, Junio C Hamano wrote: * jt/use-trailer-api-in-commands (2016-11-02) 6 commits - sequencer: use trailer's trailer layout - trailer: have function to describe trailer layout - trailer: avoid unnecessary splitting on lines - commit: make ignore_non_trailer take buf/len - SQUASH??? - trailer: be stricter in parsing separators Commands that operate on a log message and add lines to the trailer blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and "commit -s", have been taught to use the logic of and share the code with "git interpret-trailer". What's the doneness of this topic? Stefan Beller mentioned [1] that this seemed OK to him from a cursory read. Do I need to look for another reviewer (or a more thorough review)? [1]
Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
Duy Nguyenwrites: > On Thu, Nov 24, 2016 at 6:21 AM, Junio C Hamano wrote: >> * nd/rebase-forget (2016-10-28) 1 commit >> - rebase: add --forget to cleanup rebase, leave HEAD untouched >> >> "git rebase" learned "--forget" option, which allows a user to >> remove the metadata left by an earlier "git rebase" that was >> manually aborted without using "git rebase --abort". >> >> Waiting for a reroll. > > The reroll was > http://public-inbox.org/git/%3c20161112020041.2335-1-pclo...@gmail.com%3E/ Thanks.
Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
On Thu, Nov 24, 2016 at 6:21 AM, Junio C Hamanowrote: > * nd/rebase-forget (2016-10-28) 1 commit > - rebase: add --forget to cleanup rebase, leave HEAD untouched > > "git rebase" learned "--forget" option, which allows a user to > remove the metadata left by an earlier "git rebase" that was > manually aborted without using "git rebase --abort". > > Waiting for a reroll. The reroll was http://public-inbox.org/git/%3c20161112020041.2335-1-pclo...@gmail.com%3E/ -- Duy
Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
W dniu 24.11.2016 o 00:21, Junio C Hamano pisze: > * nd/rebase-forget (2016-10-28) 1 commit > - rebase: add --forget to cleanup rebase, leave HEAD untouched > > "git rebase" learned "--forget" option, which allows a user to > remove the metadata left by an earlier "git rebase" that was > manually aborted without using "git rebase --abort". > > Waiting for a reroll. It's always a good thing to stop requiring messing with .git insides. > * jc/reset-unmerge (2016-10-24) 1 commit > - reset: --unmerge > > After "git add" is run prematurely during a conflict resolution, > "git diff" can no longer be used as a way to sanity check by > looking at the combined diff. "git reset" learned a new > "--unmerge" option to recover from this situation. > > Will discard. > This may not be needed, given that update-index has a similar > option. OTOH update-index is considered plumbing, so having "git reset --unmerge" might be good thing (note that we can re-checkout file merge). > * jc/merge-drop-old-syntax (2015-04-29) 1 commit > (merged to 'next' on 2016-10-11 at 8928c8b9b3) > + merge: drop 'git merge HEAD ' syntax > > Stop supporting "git merge HEAD " syntax that has > been deprecated since October 2007, and issues a deprecation > warning message since v2.5.0. > > Will cook in 'next'. >
What's cooking in git.git (Nov 2016, #05; Wed, 23)
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. A new and hopefully final release candidate 2.11-rc3 has been tagged. 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"] * jc/for-each-ref-head-segfault-fix (2016-11-18) 1 commit (merged to 'next' on 2016-11-21 at 3c1f352316) + for-each-ref: do not segv with %(HEAD) on an unborn branch Using a %(HEAD) placeholder in "for-each-ref --format=" option caused the command to segfault when on an unborn branch. * jc/setup-cleanup-fix (2016-11-22) 2 commits (merged to 'next' on 2016-11-23 at e46785ec9c) + archive: read local configuration + mailinfo: read local configuration "git archive" and "git mailinfo" stopped reading from local configuration file with a recent update. * js/prepare-sequencer (2016-11-21) 1 commit (merged to 'next' on 2016-11-21 at 7cdf4ca421) + i18n: fix unmatched single quote in error message Fix for an error message string. * js/rebase-i-commentchar-fix (2016-11-21) 3 commits (merged to 'next' on 2016-11-22 at 88581dfe2e) + rebase -i: handle core.commentChar=auto + stripspace: respect repository config + rebase -i: highlight problems with core.commentchar "git rebase -i" did not work well with core.commentchar configuration variable for two reasons, both of which have been fixed. * jt/trailer-with-cruft (2016-11-21) 1 commit (merged to 'next' on 2016-11-22 at c68014088a) + doc: mention user-configured trailers Doc update. -- [New Topics] * jc/cache-tree-wip (2016-11-18) 4 commits - cache-tree: freshen the tree object at the top level - cache-tree: retire cache_tree_fully_valid() API function - commit: remove redundant check for active_cache_changed - freshen_object(): factor out a helper function * bw/push-dry-run (2016-11-23) 2 commits - push: fix --dry-run to not push submodules - push: --dry-run updates submodules when --recurse-submodules=on-demand (this branch uses hv/submodule-not-yet-pushed-fix.) * jk/rev-parse-symbolic-parents-fix (2016-11-16) 1 commit - rev-parse: fix parent shorthands with --symbolic * nd/worktree-list-fixup (2016-11-23) 3 commits - worktree list: keep the list sorted - get_worktrees() must return main worktree as first item even on error - worktree.c: zero new 'struct worktree' on allocation (this branch is used by nd/worktree-move.) -- [Stalled] * sb/push-make-submodule-check-the-default (2016-10-10) 2 commits - push: change submodule default to check when submodules exist - submodule add: extend force flag to add existing repos Turn the default of "push.recurseSubmodules" to "check" when submodules seem to be in use. Will hold to wait for hv/submodule-not-yet-pushed-fix * jc/bundle (2016-03-03) 6 commits - index-pack: --clone-bundle option - Merge branch 'jc/index-pack' into jc/bundle - bundle v3: the beginning - bundle: keep a copy of bundle file name in the in-core bundle header - bundle: plug resource leak - bundle doc: 'verify' is not about verifying the bundle The beginning of "split bundle", which could be one of the ingredients to allow "git clone" traffic off of the core server network to CDN. While I think it would make it easier for people to experiment and build on if the topic is merged to 'next', I am at the same time a bit reluctant to merge an unproven new topic that introduces a new file format, which we may end up having to support til the end of time. It is likely that to support a "prime clone from CDN", it would need a lot more than just "these are the heads and the pack data is over there", so this may not be sufficient. Will discard. * mh/connect (2016-06-06) 10 commits - connect: [host:port] is legacy for ssh - connect: move ssh command line preparation to a separate function - connect: actively reject git:// urls with a user part - connect: change the --diag-url output to separate user and host - connect: make parse_connect_url() return the user part of the url as a separate value - connect: group CONNECT_DIAG_URL handling code - connect: make parse_connect_url() return separated host and port - connect: re-derive a host:port string from the separate host and port variables - connect: call get_host_and_port() earlier - connect: document why we sometimes call get_port after get_host_and_port Rewrite Git-URL parsing routine (hopefully) without changing any behaviour. It has been two months without any support. We may want to discard this. * ec/annotate-deleted (2015-11-20) 1 commit -