Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)

2016-11-28 Thread Jonathan Tan
On Mon, Nov 28, 2016 at 4:06 PM, Junio C Hamano  wrote:
> 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)

2016-11-28 Thread Junio C Hamano
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.



Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)

2016-11-28 Thread Jonathan Tan

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)

2016-11-28 Thread Junio C Hamano
Duy Nguyen  writes:

> 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)

2016-11-26 Thread Duy Nguyen
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/
-- 
Duy


Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)

2016-11-25 Thread Jakub Narębski
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)

2016-11-23 Thread Junio C Hamano
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
 -