Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Elijah Newren writes: > Hi Junio, > > On Sun, Apr 29, 2018 at 8:25 PM, Junio C Hamano wrote: >> * en/rename-directory-detection-reboot (2018-04-25) 36 commits > >> >> Reboot of an attempt to detect wholesale directory renames and use >> it while merging. >> >> Will merge to 'next'. > > Usually you have a mini-release-note in your "What's cooking" emails > next to the series, so I'm assuming from the text here that you might > just be intending to re-use the release note you used with the > original series. For the rebooted series, it is probably worth adding > something to the release notes about how it also fixes the > unnecessary-update issue reported by Linus Thanks.
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Hi Junio, On Sun, Apr 29, 2018 at 8:25 PM, Junio C Hamano wrote: > * en/rename-directory-detection-reboot (2018-04-25) 36 commits > > Reboot of an attempt to detect wholesale directory renames and use > it while merging. > > Will merge to 'next'. Usually you have a mini-release-note in your "What's cooking" emails next to the series, so I'm assuming from the text here that you might just be intending to re-use the release note you used with the original series. For the rebooted series, it is probably worth adding something to the release notes about how it also fixes the unnecessary-update issue reported by Linus (https://public-inbox.org/git/CA+55aFzLZ3UkG5svqZwSnhNk75=fxjrkvu1m_rhbg54nooa...@mail.gmail.com/), a bug that's been with us for several years. Elijah
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
On 04/30, Junio C Hamano wrote: > * bw/protocol-v2 (2018-03-15) 35 commits > (merged to 'next' on 2018-04-11 at 23ee234a2c) > + remote-curl: don't request v2 when pushing > + remote-curl: implement stateless-connect command > + http: eliminate "# service" line when using protocol v2 > + http: don't always add Git-Protocol header > + http: allow providing extra headers for http requests > + remote-curl: store the protocol version the server responded with > + remote-curl: create copy of the service name > + pkt-line: add packet_buf_write_len function > + transport-helper: introduce stateless-connect > + transport-helper: refactor process_connect_service > + transport-helper: remove name parameter > + connect: don't request v2 when pushing > + connect: refactor git_connect to only get the protocol version once > + fetch-pack: support shallow requests > + fetch-pack: perform a fetch using v2 > + upload-pack: introduce fetch server command > + push: pass ref prefixes when pushing > + fetch: pass ref prefixes when fetching > + ls-remote: pass ref prefixes when requesting a remote's refs > + transport: convert transport_get_remote_refs to take a list of ref prefixes > + transport: convert get_refs_list to take a list of ref prefixes > + connect: request remote refs using v2 > + ls-refs: introduce ls-refs server command > + serve: introduce git-serve > + test-pkt-line: introduce a packet-line test helper > + protocol: introduce enum protocol_version value protocol_v2 > + transport: store protocol version > + connect: discover protocol version outside of get_remote_heads > + connect: convert get_remote_heads to use struct packet_reader > + transport: use get_refs_via_connect to get refs > + upload-pack: factor out processing lines > + upload-pack: convert to a builtin > + pkt-line: add delim packet support > + pkt-line: allow peeking a packet line without consuming it > + pkt-line: introduce packet_read_with_status > (this branch is used by bw/server-options.) > > The beginning of the next-gen transfer protocol. > > Will merge to 'master'. Awesome, I see you're already planning on merging this! I was just going to drop by and saw that internal testing showed that this *should* be ready to be merged to master :) Thanks! -- Brandon Williams
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Johannes Schindelin writes: >> As I wrote elsewhere, for a low-impact and ralatively old issue like >> this, it is OK for a fix to use supporting code that only exists in >> more recent codebase and become unmergeable to anything older than >> the concurrent 'maint' track as of the time when the fix is written. >> Even though it is sometimes nicer if the fix were written to be >> mergeable to codebase near the point where the issue originates, it >> is often not worth doing so if it requires bending backwards to >> refrain from using a newer and more convenient facility. > > So do you want me to clean up the backporting branches? I mean, we could... For a relatively obscure and low-impact bug that is old like this one, I'd actually prefer to be able to say "heh, if that hurts, either refrain from doing so, or update to the recent maintenance track that has a fix for it", to use the fix as an incentive to move the world forward ;-). After all, people have lived with the bug for a long time.
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Hi Junio, On Wed, 2 May 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > So the problem you found is not a problem with *my* branch, of course, as > > I did not fork off of ... > > Correct; there is no blame on you with the choice of the base. It > was my mistake that I didn't check if the series could be queueable > on the maintenance track that is one release older than the current > 'maint'. > > As I wrote elsewhere, for a low-impact and ralatively old issue like > this, it is OK for a fix to use supporting code that only exists in > more recent codebase and become unmergeable to anything older than > the concurrent 'maint' track as of the time when the fix is written. > Even though it is sometimes nicer if the fix were written to be > mergeable to codebase near the point where the issue originates, it > is often not worth doing so if it requires bending backwards to > refrain from using a newer and more convenient facility. So do you want me to clean up the backporting branches? I mean, we could easily fix that bug for the release trains v2.13.x - v2.16.x... Of course I do not propose to release them *now*, but if you find that another critical bug fix necessitates maintenance releases anyway, *and* if the branch ages well in `master`, you could simply merge them at that time. Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Johannes Schindelin writes: > So the problem you found is not a problem with *my* branch, of course, as > I did not fork off of ... Correct; there is no blame on you with the choice of the base. It was my mistake that I didn't check if the series could be queueable on the maintenance track that is one release older than the current 'maint'. As I wrote elsewhere, for a low-impact and ralatively old issue like this, it is OK for a fix to use supporting code that only exists in more recent codebase and become unmergeable to anything older than the concurrent 'maint' track as of the time when the fix is written. Even though it is sometimes nicer if the fix were written to be mergeable to codebase near the point where the issue originates, it is often not worth doing so if it requires bending backwards to refrain from using a newer and more convenient facility.
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
SZEDER Gábor writes: > On Mon, Apr 30, 2018 at 5:25 AM, Junio C Hamano wrote: >> * js/rebase-i-clean-msg-after-fixup-continue (2018-04-30) 4 commits >> - rebase --skip: clean up commit message after a failed fixup/squash >> - sequencer: always commit without editing when asked for >> - rebase -i: Handle "combination of commits" with GETTEXT_POISON >> - rebase -i: demonstrate bugs with fixup!/squash! commit messages > >> "git rebase -i" sometimes left intermediate "# This is a >> combination of N commits" message meant for the human consumption >> inside an editor in the final result in certain corner cases, which >> has been fixed. > >> Will merge to 'next'. > > This topic branches off from v2.16.3. However, its last patch uses > the sequencer's parse_head() function, which was only added in > v2.17.0-rc0~110^2~6 (sequencer: try to commit without forking 'git > commit', 2017-11-24), in topic 'pw/sequencer-in-process-commit', > leading to compilation errors. For a low-impact and ralatively old issue like this, it is OK for a fix to use supporting code that only exists in more recent codebase and become unmergeable to anything older than the concurrent 'maint' track as of the time when the fix is written. Even though it is sometimes nicer if the fix were written to be mergeable to codebase near the point where the issue originates, it is often not worth doing so if it requires bending backwards to refrain from using a newer and more convenient facility. Thanks for catching my wishful thinking and carelessness before it propagated to 'next'. I try to check tips of individual topic branches and also the integratoin result, but sometimes I get trusting too much and get sloppy when dealing with too many topics in flight.
Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]
On Tue, May 01 2018, Johannes Schindelin wrote: > I wonder whether `-!p` would be better/feasible? In *nix shells `git -!p ...` unquoted will turn that !p into whatever command you last ran that started with a "p", in my case `git -ping 8.8.8.8`. So there's a reason that's not the idiom in any *nix CLI program (as opposed to +p which I think was mentioned in a side-thread)>
Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]
On Tue, May 1, 2018 at 10:58 AM, Johannes Sixt wrote: > Am 01.05.2018 um 13:57 schrieb Johannes Schindelin: >> On Mon, 30 Apr 2018, Johannes Sixt wrote: >>> Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager >>> >>> I find -P is not that bad after all. >> >> To me, `-P` would suggest the positive action --pager rather than the >> negative --no-pager. > > >> Your use case is quite the corner case, I hope you realize that, as it >> seems that everybody else is fine with having -FRX as default options for >> `less`... And with copy/pasting from the `less` output. So introducing a >> sweet short option for --no-pager, for the benefit of maybe even only one >> user, seems quite... unusual. > > Given the ambivalence (or inconclusiveness), I retract this patch without > offering a replacement for the time being. Although paged output is generally nice, I frequently find myself typing --no-pager numerous times during the day, so I, for one, welcome having a short option (and would be sad to see this patch retracted). As with Hannes, I too find -P a reasonably intuitive and easy-to-remember short option.
Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]
Am 01.05.2018 um 13:57 schrieb Johannes Schindelin: Hi Hannes, On Mon, 30 Apr 2018, Johannes Sixt wrote: Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager "git --no-pager cmd" did not have short-and-sweet single letter option. Now it does. Will merge to 'next'. I consider your argument that -N is only an abbreviation for an unspecific "no" a valid one. So, I would like to be sure that we are not painting us into the wrong corner by squatting -N for --no-pager. I find -P is not that bad after all. To me, `-P` would suggest the positive action --pager rather than the negative --no-pager. I wonder whether `-!p` would be better/feasible? We do not have this pattern, yet, nor do I know it from some other utility. I do not want to set a precedent. Your use case is quite the corner case, I hope you realize that, as it seems that everybody else is fine with having -FRX as default options for `less`... And with copy/pasting from the `less` output. So introducing a sweet short option for --no-pager, for the benefit of maybe even only one user, seems quite... unusual. Granted, you cannot simply introduce an alias for `git --no-pager`. But maybe that is what we should do? Maybe we should start supporting aliases without specifying commands, opening the door for things like `git -c ui.color=false`, too. Then you could add `alias.n=--no-pager` and call `git n show HEAD`, and the -N and -P short options could still wait for a widely-popular option to require a short name. But then I can just as well have alias gitn='git --no-pager' in my .bashrc. Maybe I should do that. Given the ambivalence (or inconclusiveness), I retract this patch without offering a replacement for the time being. Thanks for a bit of sanity, -- Hannes
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Hi,
On Mon, 30 Apr 2018, SZEDER Gábor wrote:
> On Mon, Apr 30, 2018 at 5:25 AM, Junio C Hamano wrote:
> > * js/rebase-i-clean-msg-after-fixup-continue (2018-04-30) 4 commits
> > - rebase --skip: clean up commit message after a failed fixup/squash
> > - sequencer: always commit without editing when asked for
> > - rebase -i: Handle "combination of commits" with GETTEXT_POISON
> > - rebase -i: demonstrate bugs with fixup!/squash! commit messages
>
> > "git rebase -i" sometimes left intermediate "# This is a
> > combination of N commits" message meant for the human consumption
> > inside an editor in the final result in certain corner cases, which
> > has been fixed.
>
> > Will merge to 'next'.
>
> This topic branches off from v2.16.3. However, its last patch uses
> the sequencer's parse_head() function, which was only added in
> v2.17.0-rc0~110^2~6 (sequencer: try to commit without forking 'git
> commit', 2017-11-24), in topic 'pw/sequencer-in-process-commit',
> leading to compilation errors.
Great find.
As luck has it, I recently played with tbdiff and compared what Junio
applied vs what I have, and found only context line changes (and Junio's
extra Signed-off-by: lines).
So the problem you found is not a problem with *my* branch, of course, as
I did not fork off of v2.16.3 (which is a bit arbitrary, I must say: if
you want to fix these bugs for reals, you'd have to go all the way back to
where fixup!/squash! support was introduced).
However, as a maintainer I am sympathetic to the goal of wanting to have
*one* branch that does not need to be backported.
The patch to make all of this work is most likely this:
-- snip --
sequencer: backport parse_head()
This function exists in v2.17.0, and will be used in the upcoming fixes
for bugs when running `git rebase --skip` after a fixup/squash failed.
Signed-off-by: Johannes Schindelin
--
diff --git a/sequencer.c b/sequencer.c
index a766796d1a7..f9c478a4d79 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -695,6 +695,29 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
return run_command(&cmd);
}
+static int parse_head(struct commit **head)
+{
+ struct commit *current_head;
+ struct object_id oid;
+
+ if (get_oid("HEAD", &oid)) {
+ current_head = NULL;
+ } else {
+ current_head = lookup_commit_reference(&oid);
+ if (!current_head)
+ return error(_("could not parse HEAD"));
+ if (oidcmp(&oid, ¤t_head->object.oid)) {
+ warning(_("HEAD %s is not a commit!"),
+ oid_to_hex(&oid));
+ }
+ if (parse_commit(current_head))
+ return error(_("could not parse HEAD commit"));
+ }
+ *head = current_head;
+
+ return 0;
+}
+
static int is_original_commit_empty(struct commit *commit)
{
const struct object_id *ptree_oid;
-- snap --
I also had to apply this to make things compile with DEVELOPER=1:
-- snip --
diff --git a/sequencer.c b/sequencer.c
index f9c478a4d79..44b1874f459 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -2345,7 +2345,7 @@ static int commit_staged_changes(struct replay_opts *opts,
* We need to update the squash message to skip
* the latest commit message.
*/
- struct commit *commit;
+ struct commit *commit = NULL;
const char *path = rebase_path_squash_msg();
if (parse_head(&commit) ||
-- snap --
This should most likely be squashed into "rebase --skip: clean up commit
message after a failed fixup/squash".
Junio, for your convenience, I pushed what I have here to the
`clean-msg-after-fixup-continue-backport-v2.16.3` branch on
https://github.com/dscho/git
For shiggles, I also looked how far back I could push this, and backported
to v2.15.1, v2.14.3, v2.13.6, v2.12.5
Things got painful only really with v2.12.5. Like, really painful. And in
the end not even worth it... I managed to backport the changes, sure, but
that code path is not even used ;-)
For your convenience, I pushed all of the backports, just in case you want
to use them. I did leave a couple of fixup! commits in place, to show a
*little* better what I did and where.
Ciao,
Dscho
Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]
Hi Hannes, On Mon, 30 Apr 2018, Johannes Sixt wrote: > Am 30.04.2018 um 05:25 schrieb Junio C Hamano: > > * js/no-pager-shorthand (2018-04-25) 1 commit > > - git: add -N as a short option for --no-pager > > > > "git --no-pager cmd" did not have short-and-sweet single letter > > option. Now it does. > > > > Will merge to 'next'. > > I consider your argument that -N is only an abbreviation for an unspecific > "no" a valid one. So, I would like to be sure that we are not painting us into > the wrong corner by squatting -N for --no-pager. > > I find -P is not that bad after all. To me, `-P` would suggest the positive action --pager rather than the negative --no-pager. I wonder whether `-!p` would be better/feasible? Your use case is quite the corner case, I hope you realize that, as it seems that everybody else is fine with having -FRX as default options for `less`... And with copy/pasting from the `less` output. So introducing a sweet short option for --no-pager, for the benefit of maybe even only one user, seems quite... unusual. Granted, you cannot simply introduce an alias for `git --no-pager`. But maybe that is what we should do? Maybe we should start supporting aliases without specifying commands, opening the door for things like `git -c ui.color=false`, too. Then you could add `alias.n=--no-pager` and call `git n show HEAD`, and the -N and -P short options could still wait for a widely-popular option to require a short name. Ciao, Dscho
js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]
Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a short option for --no-pager "git --no-pager cmd" did not have short-and-sweet single letter option. Now it does. Will merge to 'next'. I consider your argument that -N is only an abbreviation for an unspecific "no" a valid one. So, I would like to be sure that we are not painting us into the wrong corner by squatting -N for --no-pager. I find -P is not that bad after all. -- Hannes
Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
On Mon, Apr 30, 2018 at 5:25 AM, Junio C Hamano wrote: > * js/rebase-i-clean-msg-after-fixup-continue (2018-04-30) 4 commits > - rebase --skip: clean up commit message after a failed fixup/squash > - sequencer: always commit without editing when asked for > - rebase -i: Handle "combination of commits" with GETTEXT_POISON > - rebase -i: demonstrate bugs with fixup!/squash! commit messages > "git rebase -i" sometimes left intermediate "# This is a > combination of N commits" message meant for the human consumption > inside an editor in the final result in certain corner cases, which > has been fixed. > Will merge to 'next'. This topic branches off from v2.16.3. However, its last patch uses the sequencer's parse_head() function, which was only added in v2.17.0-rc0~110^2~6 (sequencer: try to commit without forking 'git commit', 2017-11-24), in topic 'pw/sequencer-in-process-commit', leading to compilation errors.
What's cooking in git.git (Apr 2018, #04; Mon, 30)
What's cooking in git.git (Apr 2018, #04; Mon, 30) -- 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. 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 -- [New Topics] * cc/perf-aggregate-unknown-option (2018-04-26) 1 commit - perf/aggregate: use Getopt::Long for option parsing Perf-test helper updates. Will merge to 'next'. * ab/perl-python-attrs (2018-04-27) 3 commits - .gitattributes: add a diff driver for Python - .gitattributes: use the "perl" differ for Perl - .gitattributes: add *.pl extension for Perl We learned that our source files with ".pl" and ".py" extensions are Perl and Python files respectively and changes to them are better viewed as such with appropriate diff drivers. Will merge to 'next'. * is/parsing-line-range (2018-04-27) 2 commits . log: prevent error if line range ends past end of file . blame: prevent error if range ends past end of file Parsing of -L[][,[]] parameters "git blame" and "git log" take has been tweaked. Seems to break a few tests. * js/test-unset-prereq (2018-04-30) 1 commit - tests: introduce test_unset_prereq, for debugging Test debugging aid. Will merge to 'next'. -- [Stalled] * ld/p4-unshelve (2018-02-22) 1 commit - git-p4: add unshelve command "git p4" learned to "unshelve" shelved commit from P4. Will hold, perhaps drop and use format-change that uses a proper "diff". cf. * av/fsmonitor-updates (2018-01-04) 6 commits - fsmonitor: use fsmonitor data in `git diff` - fsmonitor: remove debugging lines from t/t7519-status-fsmonitor.sh - fsmonitor: make output of test-dump-fsmonitor more concise - fsmonitor: update helper tool, now that flags are filled later - fsmonitor: stop inline'ing mark_fsmonitor_valid / _invalid - dir.c: update comments to match argument name Code clean-up on fsmonitor integration, plus optional utilization of the fsmonitor data in diff-files. Waiting for an update. cf. * pb/bisect-helper-2 (2017-10-28) 8 commits - t6030: make various test to pass GETTEXT_POISON tests - bisect--helper: `bisect_start` shell function partially in C - bisect--helper: `get_terms` & `bisect_terms` shell function in C - bisect--helper: `bisect_next_check` shell function in C - bisect--helper: `check_and_set_terms` shell function in C - wrapper: move is_empty_file() and rename it as is_empty_or_missing_file() - bisect--helper: `bisect_write` shell function in C - bisect--helper: `bisect_reset` shell function in C Expecting a reroll. cf. <0102015f5e5ee171-f30f4868-886f-47a1-a4e4-b4936afc545d-000...@eu-west-1.amazonses.com> * mk/http-backend-content-length (2017-11-27) 4 commits - SQUASH??? - t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases - SQUASH??? - http-backend: respect CONTENT_LENGTH as specified by rfc3875 The http-backend (used for smart-http transport) used to slurp the whole input until EOF, without paying attention to CONTENT_LENGTH that is supplied in the environment and instead expecting the Web server to close the input stream. This has been fixed. Expecting a reroll. Suggested fixes to be used when rerolling is queued, but I'd prefer _not_ squashing them myself. Also, it may be too complex solution for the problem. cf. <20171204171308.ga13...@sigill.intra.peff.net> * jk/drop-ancient-curl (2017-08-09) 5 commits - http: #error on too-old curl - curl: remove ifdef'd code never used with curl >=7.19.4 - http: drop support for curl < 7.19.4 - http: drop support for curl < 7.16.0 - http: drop support for curl < 7.11.1 Some code in http.c that has bitrot is being removed. Expecting a reroll. * mk/use-size-t-in-zlib (2017-08-10) 1 commit . zlib.c: use size_t for size The wrapper to call into zlib followed our long tradition to use "unsigned long" for sizes of regions in memory, which have been updated to use "size_t". Needs resurrecting by making sure the fix is good and still applies (or adjusted to today's codebase). -- [Cooking] * fg/completion-external (2018-04-30) 1 commit - completion: load completion file for external subcommand The command line completion mechanism (in contrib/) learned to load custom completion file for "git $command" where $command is a custom "
