Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On Tue, Oct 16, 2018 at 6:39 AM Phillip Wood wrote: > > If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a > > way to countermand an earlier --color-moved-ws= on the > > command line, I fully agree that it is a good idea. > > Oh I assumed --no-color-moved-ws was allowed but it isn't it. Allowing > --color-moved-ws=no as well would match what is allowed for > --color-moved. I'll try and look at that. Thanks for taking a look! Stefan
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On 12/10/2018 14:36, Junio C Hamano wrote: Phillip Wood writes: It would be nice if the parsing used starts_with(option_name, user_text) rather than strcmp() as well. Also I think --color-moved=no is valid as a synonym of --no-color-moved but --color-moved-ws=no is not supported. I am not sure about starts_with(). Do you mean we should accept "--color-mo", as that is a prefix of "--color-moved" that is not shared with any existing option, until we gain a different option "--color-more"? I was thinking of the option arguments rather than the option names although being able to abbreviate the names in the same way as the commands that parse_options() would be good too (I seem to remember someone saying they had some rough patches to use parse_options() for diff and log in a discussion of adding completion support to parse_options()) If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a way to countermand an earlier --color-moved-ws= on the command line, I fully agree that it is a good idea. Oh I assumed --no-color-moved-ws was allowed but it isn't it. Allowing --color-moved-ws=no as well would match what is allowed for --color-moved. I'll try and look at that. Best Wishes Phillip
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On Wed, Oct 10, 2018 at 7:43 AM Junio C Hamano wrote: > * nd/per-worktree-ref-iteration (2018-10-07) 9 commits > - SQUASH??? > - reflog expire: cover reflog from all worktrees > - fsck: check HEAD and reflog from other worktrees > - fsck: Move fsck_head_link() to get_default_heads() to avoid some globals > - revision.c: better error reporting on ref from different worktrees > - revision.c: correct a parameter name > - refs: new ref types to make per-worktree refs visible to all worktrees > - Add a place for (not) sharing stuff between worktrees > - refs.c: indent with tabs, not spaces > > What's the status of this topic? There's one bug spotted by Eric and a few test cases to be added in the reflog patch. -- Duy
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Phillip Wood writes: > It would be nice if the parsing used starts_with(option_name, user_text) > rather than strcmp() as well. Also I think --color-moved=no is valid as > a synonym of --no-color-moved but --color-moved-ws=no is not supported. I am not sure about starts_with(). Do you mean we should accept "--color-mo", as that is a prefix of "--color-moved" that is not shared with any existing option, until we gain a different option "--color-more"? If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a way to countermand an earlier --color-moved-ws= on the command line, I fully agree that it is a good idea.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On 11/10/2018 23:40, Junio C Hamano wrote: > Phillip Wood writes: > >> On 10/10/2018 06:43, Junio C Hamano wrote: >>> 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. >>> >>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits >>> - diff --color-moved: fix a memory leak >>> - diff --color-moved-ws: fix another memory leak >>> - diff --color-moved-ws: fix a memory leak >>> - diff --color-moved-ws: fix out of bounds string access >>> - diff --color-moved-ws: fix double free crash >>> >>> Various fixes to "diff --color-moved-ws". >>> >>> What's the status of this topic? >> >> I think it is ready for next - Stefan was happy with the last iteration. > > This is not about your fixes, but I was skimming the color-moved > support in general as a final sanity check to move this forward and > noticed that > > $ git diff --color-moved-ws=ignore-any master... > > does not do anything interesting, which is broken at at least two > points. > > * There is no "ignore-any" supported by the feature---I think that >the parser for the option should have noticed and barfed, but it >did not. It merely emitted a message to the standard output and >let it scroll away with the huge diff before the reader noticed >it. It would be nice if the parsing used starts_with(option_name, user_text) rather than strcmp() as well. Also I think --color-moved=no is valid as a synonym of --no-color-moved but --color-moved-ws=no is not supported. > * After fixing ignore-any to one of the supported option >(e.g. "ignore-all-spaces"), the color-moved feature still did not >trigger. I think the presence of --color-moved-ws by itself is a >hint that the user wants --color-moved to be used. If it turns >out that there are some valid use cases where --color-moved-ws >may have to be set but the color-moved feature should not be >enabled, then > > diff --color-moved-ws=ignore-all-space --no-color-moved > >can be used to countermand this, of course. > > Am I missing something or are these mere small sloppiness in the > current code? > > >
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Stefan Beller writes: > I think we should add these tweaks, such that > color-moved-ws implies color-moved (both config and CLI options) > and --color-moved implies --color (command line only) I am not sure what you mean by "both config and". I'd find it entirely sensible for a user to say "I do not always use the color-moved option, but when I do, I want it to handle the whitespace differences this way by default". So presence of diff.colorMovedWS configuration variable should never trigger the color-moved feature by itself, I would think.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On Thu, Oct 11, 2018 at 3:41 PM Junio C Hamano wrote: > * After fixing ignore-any to one of the supported option >(e.g. "ignore-all-spaces"), the color-moved feature still did not >trigger. I think the presence of --color-moved-ws by itself is a >hint that the user wants --color-moved to be used. If it turns >out that there are some valid use cases where --color-moved-ws >may have to be set but the color-moved feature should not be >enabled, then > > diff --color-moved-ws=ignore-all-space --no-color-moved > >can be used to countermand this, of course. I had the same idea for --color-moved to imply --color, but there we had some issues with configured settings, as we do not want diff.colorMoved to imply colored patches, but only when given on the command line. I think we should add these tweaks, such that color-moved-ws implies color-moved (both config and CLI options) and --color-moved implies --color (command line only)
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Phillip Wood writes: > On 10/10/2018 06:43, Junio C Hamano wrote: >> 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. >> >> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits >> - diff --color-moved: fix a memory leak >> - diff --color-moved-ws: fix another memory leak >> - diff --color-moved-ws: fix a memory leak >> - diff --color-moved-ws: fix out of bounds string access >> - diff --color-moved-ws: fix double free crash >> >> Various fixes to "diff --color-moved-ws". >> >> What's the status of this topic? > > I think it is ready for next - Stefan was happy with the last iteration. This is not about your fixes, but I was skimming the color-moved support in general as a final sanity check to move this forward and noticed that $ git diff --color-moved-ws=ignore-any master... does not do anything interesting, which is broken at at least two points. * There is no "ignore-any" supported by the feature---I think that the parser for the option should have noticed and barfed, but it did not. It merely emitted a message to the standard output and let it scroll away with the huge diff before the reader noticed it. * After fixing ignore-any to one of the supported option (e.g. "ignore-all-spaces"), the color-moved feature still did not trigger. I think the presence of --color-moved-ws by itself is a hint that the user wants --color-moved to be used. If it turns out that there are some valid use cases where --color-moved-ws may have to be set but the color-moved feature should not be enabled, then diff --color-moved-ws=ignore-all-space --no-color-moved can be used to countermand this, of course. Am I missing something or are these mere small sloppiness in the current code?
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On 10/10/2018 1:43 AM, Junio C Hamano wrote: * ds/reachable-topo-order (2018-09-21) 7 commits - revision.c: refactor basic topo-order logic - revision.h: add whitespace in flag definitions - commit/revisions: bookkeeping before refactoring - revision.c: begin refactoring --topo-order logic - test-reach: add rev-list tests - test-reach: add run_three_modes method - prio-queue: add 'peek' operation The revision walker machinery learned to take advantage of the commit generation numbers stored in the commit-graph file. What's the status of this topic? I've reached out for review, especially on the rather large patch "revision.c: refactor basic topo-order logic" but have received no messages about it. I don't think anyone has even done a cursory style review. I really think that this is a valuable topic, and it would be nice to have in 2.20, but I'm not pushing to merge something that no one has reviewed. * ds/format-commit-graph-docs (2018-08-21) 2 commits - commit-graph.txt: improve formatting for asciidoc - Docs: Add commit-graph tech docs to Makefile Design docs for the commit-graph machinery is now made into HTML as well as text. Will discard. I am inclined to drop these, as I do not see much clarity in HTML output over the text source. Opinions? These have been marked for discard for a few weeks. I agree they should be discarded. Thanks, -Stolee
Re: builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Johannes Schindelin writes: > https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051 > fixup! builtin rebase: support `-C` and `--whitespace=` For c7ee2134d4 (rebase-in-c-4-opts); a single liner that is obviously correct. > https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837 > fixup! builtin rebase: support `--gpg-sign` option For 28a02c5a79 (rebase-in-c-4-opts); the change looks correct (see a separate message). > https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc > fixup! rebase -i: implement the main part of interactive rebase as a > builtin You said Alban already has this in the update, which I took yesterday, so I'll ignore this one. > https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e > fixup! stash: convert apply to builtin I think we are expecting another round of update, so I'll ignore this one for now, too. > Speaking about the two `rebase` ones: they are simple fixup! commits, > could I trouble you to fetch and cherry-pick them into `pu`, or would you > prefer if I sent another iteration of `rebase-in-c-4-opts`? Rebuilding 4 will involve rebuilding all the later ones anyway, so I'll just try doing it myself and report back if I saw issues. Thanks.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Stefan Beller writes: >> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits > I would suggest merging to 'next'. OK. >> * sb/strbuf-h-update (2018-09-29) 1 commit > The patch as-is just adds names everywhere. > I'd be happy to resend with either > (a) not enforcing names everywhere, but only as needed or > (b) having names everywhere, capitalizing them NAMES in > the doc comment. > > I am tempted to ask for > (c) take as-is, defer the rewording of doc strings for a follow up patch. As long as the planned update eventually comes before all of us forget, (c) is fine by me. I'll mark it to be merged to 'next' for now, and follow through that plan, unless somebody else stops me before it happens. >> * sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits > Will resend after a local review. OK. Thanks for helping me in updating the status for various topics.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Phillip Wood writes: > On 10/10/2018 06:43, Junio C Hamano wrote: >> 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. >> >> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits >> - diff --color-moved: fix a memory leak >> - diff --color-moved-ws: fix another memory leak >> - diff --color-moved-ws: fix a memory leak >> - diff --color-moved-ws: fix out of bounds string access >> - diff --color-moved-ws: fix double free crash >> >> Various fixes to "diff --color-moved-ws". >> >> What's the status of this topic? > > I think it is ready for next - Stefan was happy with the last iteration. Thanks.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Johannes Sixt writes: > Am 10.10.18 um 07:43 schrieb Junio C Hamano: >> We haven't seen much complaints and breakages reported against the >> two big "rewrite in C" topics around "rebase"; perhaps it is a good >> time to merge them to 'next' soonish to cook them for a few weeks >> before moving them to 'master'? > > Please let me express my sincerest gratitude to Alban, Joel, > Paul-Sebastian, Pratik, and Dscho. It is such a pleasure to work with > the builtin rebase and stash commands on Windows now. I am using them > since a month or two, and they work extremely well for me. > > Thank you all for your hard work! OK. With another Ack from Dscho, I'd feel safe to merge the "rebase" topics 'next' and start cooking. "stash" seems to be almost there but I think it deserves a chance for a final touch-up before hitting 'next' (see another thread with Thomas). Thanks.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Thomas Gummerer writes: > There was a v9 of this series [*1*], which hasn't been picked up yet. > Was that intentional, or an oversight? ;-) Yes, I often miss patches that are buried in other discussions, but this time, it was quite deliberate. I saw comments that pointed out at least one thing that needs to be fixed before the series can move forward, so I skipped that iteration, anticipating another round of update. Also, I was waiting for [*3*] to be answered. > I left some comments on that iteration. Some were just style nits, > but I think at least [*2*] should be addressed before we merge this > down to master, not sure if any of my other comments apply to v8 as > well. I'm happy to send fixup patches, or a patches on top of > this series for that and my other comments, should they apply to v8, > or wait for Paul-Sebastian to send a re-roll. What do you prefer? The ideal from my point of view is to see responses to your comments in the original thread (which is about 1300 messages ago in the list archive by now) by Paul-Sebastian, possibly responded by you and/or others, resulting in a concensus on what the right update for the patches should be, finally followed by v10, which hopefully would be the final one. > [*1*]: > [*2*]: <20180930174848.ge2...@hank.intra.tgummerer.com> [*3*]
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Am 10.10.18 um 07:43 schrieb Junio C Hamano: We haven't seen much complaints and breakages reported against the two big "rewrite in C" topics around "rebase"; perhaps it is a good time to merge them to 'next' soonish to cook them for a few weeks before moving them to 'master'? Please let me express my sincerest gratitude to Alban, Joel, Paul-Sebastian, Pratik, and Dscho. It is such a pleasure to work with the builtin rebase and stash commands on Windows now. I am using them since a month or two, and they work extremely well for me. Thank you all for your hard work! -- Hannes
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On 10.10.18 07:43, Junio C Hamano wrote: * ts/alias-of-alias (2018-09-17) 3 commits (merged to 'next' on 2018-10-09 at ac19b4730b) + t0014: introduce an alias testing suite + alias: show the call history when an alias is looping + alias: add support for aliases of an alias An alias that expands to another alias has so far been forbidden, but now it is allowed to create such an alias. Will merge to 'master'. Oh well, I still have the changed comment stored locally. I guess that has to wait for another time. Anyways, thanks for pulling this in. PS: I hope that this E-Mail is formatted correctly. Thunderbird received an update and now it doesn't show me plain text when composing an E-Mail.
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> - diff --color-moved: fix a memory leak
> - diff --color-moved-ws: fix another memory leak
> - diff --color-moved-ws: fix a memory leak
> - diff --color-moved-ws: fix out of bounds string access
> - diff --color-moved-ws: fix double free crash
>
> Various fixes to "diff --color-moved-ws".
>
> What's the status of this topic?
Per [1] ("The whole series is
Reviewed-by: Stefan Beller "),
I would suggest merging to 'next'.
[1]
https://public-inbox.org/git/CAGZ79kbamUK=d+-ejy9vopdivzf7ovongz1zx9y04vr3hnm...@mail.gmail.com/
> * sb/strbuf-h-update (2018-09-29) 1 commit
> - strbuf.h: format according to coding guidelines
>
> Code clean-up to serve as a BCP example.
>
> What's the status of this one after the discussion thread stopped here?
> cf.
I was waiting for more discussion and stricter guidelines,
which never happened.
The only controversial issue about this patch is whether we want
to name all parameters or only when we feel like it.
Peff did not seem to care about this particular detail
https://public-inbox.org/git/20180929073827.gd2...@sigill.intra.peff.net/
You suggested to embrace it further and use caps for the parameter
names in the docs comment.
https://public-inbox.org/git/xmqq8t3lb8uu@gitster-ct.c.googlers.com/
The patch as-is just adds names everywhere.
I'd be happy to resend with either
(a) not enforcing names everywhere, but only as needed or
(b) having names everywhere, capitalizing them NAMES in
the doc comment.
I am tempted to ask for
(c) take as-is, defer the rewording of doc strings for a follow up patch.
> * sb/grep-submodule-cleanup (2018-10-10) 1 commit
> - builtin/grep.c: remove superfluous submodule code
>
> Code clean-up.
>
> cf. <20181010001037.74709-1-jonathanta...@google.com>
Will resend.
> * bw/submodule-name-to-dir (2018-08-10) 2 commits
> - submodule: munge paths to submodule git directories
> - submodule: create helper to build paths to submodule gitdirs
>
> In modern repository layout, the real body of a cloned submodule
> repository is held in .git/modules/ of the superproject, indexed by
> the submodule name. URLencode the submodule name before computing
> the name of the directory to make sure they form a flat namespace.
>
> Kicked back to 'pu', expecting further work on the topic.
> cf.
Thanks.
>
> * sb/submodule-move-head-with-corruption (2018-08-28) 2 commits
> - submodule.c: warn about missing submodule git directories
> - t2013: add test for missing but active submodule
>
> Will discard and wait for a cleaned-up rewrite.
> cf. <20180907195349.ga103...@aiede.svl.corp.google.com>
Yeah I think discarding this is the right move.
> * sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits
> - builtin/fetch: check for submodule updates for non branch fetches
> - fetch: retry fetching submodules if sha1 were not fetched
> - submodule: fetch in submodules git directory instead of in worktree
> - submodule.c: do not copy around submodule list
> - submodule: move global changed_submodule_names into fetch submodule struct
> - submodule.c: sort changed_submodule_names before searching it
> - submodule.c: fix indentation
> - sha1-array: provide oid_array_filter
> - string-list: add string_list_{pop, last} functions
>
> "git fetch --recurse-submodules" may not fetch the necessary commit
> that is bound to the superproject, which is getting corrected.
>
> Expecting a reroll.
> cf.
is fixed in
https://public-inbox.org/git/20180917213559.126404-7-sbel...@google.com/
> cf.
That is fixed locally
> cf.
That has been addressed via
https://public-inbox.org/git/20180925194755.105578-1-sbel...@google.com/
Will resend after a local review.
> * pk/rebase-in-c-6-final (2018-10-09) 1 commit
> - rebase: default to using the builtin rebase
> (this branch uses ag/rebase-i-in-c,
> js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c,
> pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts and
> pk/rebase-in-c-5-test; is tangled with ag/sequencer-reduce-rewriting-todo,
> jc/rebase-in-c-5-test-typofix and js/rebase-i-break.)
>
> The final step of rewriting "rebase -i" in C.
>
> Undecided.
> I've been using this (i.e. the whole "rebase -i" and "rebase"
> rewritten in C) in my personal build, and I also know users on
> Windows port have been using it with the last feature release. I
> am tempted to merge the whole thing to 'next' soonish.
>
> Opinions? It's the last chance to remove any existing and avoid
> any future "oops, that was wrong, and here is a fix-up"
> embarrassment in these topics.
Yes, please merge to next.
Stefan
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On Wed, Oct 10, 2018 at 09:59:16AM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Oct 10 2018, Junio C Hamano wrote: > > > * 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. > > There's been no activity on this for 6 months since I sent a "hey what's > going on with it" E-Mail in: > https://public-inbox.org/git/20180404204920.ga15...@sigill.intra.peff.net/ > > Maybe it should just be dropped? That's fine with me. I think it was a nice cleanup as long as nobody cared, but some people did seem to care. Maybe they care less now that more time has passed, but it just hasn't really been worth the time to revisit. I'm OK to drop it; the patches are on the list if we want to look at it again later. -Peff
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On 10/10, Junio C Hamano wrote: > * ps/stash-in-c (2018-08-31) 20 commits > - stash: replace all `write-tree` child processes with API calls > - stash: optimize `get_untracked_files()` and `check_changes()` > - stash: convert `stash--helper.c` into `stash.c` > - stash: convert save to builtin > - stash: make push -q quiet > - stash: convert push to builtin > - stash: convert create to builtin > - stash: convert store to builtin > - stash: mention options in `show` synopsis > - stash: convert show to builtin > - stash: convert list to builtin > - stash: convert pop to builtin > - stash: convert branch to builtin > - stash: convert drop and clear to builtin > - stash: convert apply to builtin > - stash: add tests for `git stash show` config > - stash: rename test cases to be more descriptive > - stash: update test cases conform to coding guidelines > - stash: improve option parsing test coverage > - sha1-name.c: add `get_oidf()` which acts like `get_oid()` > > "git stash" rewritten in C. > > Undecided. This also has been part of my personal build. I do not > offhand recall if this also had the same exposure to the end users > as "rebase" and "rebase -i". I am tempted to merge this to 'next' > soonish. > > Opinions? There was a v9 of this series [*1*], which hasn't been picked up yet. Was that intentional, or an oversight? I left some comments on that iteration. Some were just style nits, but I think at least [*2*] should be addressed before we merge this down to master, not sure if any of my other comments apply to v8 as well. I'm happy to send fixup patches, or a patches on top of this series for that and my other comments, should they apply to v8, or wait for Paul-Sebastian to send a re-roll. What do you prefer? [*1*]: [*2*]: <20180930174848.ge2...@hank.intra.tgummerer.com>
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On 10/10/2018 06:43, Junio C Hamano wrote: 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. * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits - diff --color-moved: fix a memory leak - diff --color-moved-ws: fix another memory leak - diff --color-moved-ws: fix a memory leak - diff --color-moved-ws: fix out of bounds string access - diff --color-moved-ws: fix double free crash Various fixes to "diff --color-moved-ws". What's the status of this topic? I think it is ready for next - Stefan was happy with the last iteration. Best Wishes Phillip
Re: builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Johannes Schindelin writes: > Speaking about the two `rebase` ones: they are simple fixup! commits, > could I trouble you to fetch and cherry-pick them into `pu`, or would you > prefer if I sent another iteration of `rebase-in-c-4-opts`? If it were only about me, then the former if I can do my own pace is easier. If you promise that you won't complain if a few commits lose the amlog notes by accident when such tree mangling is done, that would be even better, but I'd be careful anyway. I'd rather limit number of changes not seen on the list that come into my tree, so it is likely that I'd parrot these fixup commits or result of "commit --amend" to the list if we take that route. Johannes Schindelin writes: > Hi Junio, > > On Wed, 10 Oct 2018, Junio C Hamano wrote: > >> We haven't seen much complaints and breakages reported against the >> two big "rewrite in C" topics around "rebase"; perhaps it is a good >> time to merge them to 'next' soonish to cook them for a few weeks >> before moving them to 'master'? > > I would be in favor, as long as the fixup patches I have in Git for > Windows made it in: > > https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051 > fixup! builtin rebase: support `-C` and `--whitespace=` > > https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837 > fixup! builtin rebase: support `--gpg-sign` option > > https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc > fixup! rebase -i: implement the main part of interactive rebase as a > builtin > > https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e > fixup! stash: convert apply to builtin > > It seems that Alban picked up the `rebase -i` one, but the other three > have not made it into `pu` yet (the two `rebase` ones are really my fault, > I did not yet find time). > > Speaking about the two `rebase` ones: they are simple fixup! commits, > could I trouble you to fetch and cherry-pick them into `pu`, or would you > prefer if I sent another iteration of `rebase-in-c-4-opts`? > > Ciao, > Dscho
Re: js/mingw-wants-vista-or-above, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Johannes Schindelin writes: > Hi Junio, > > On Wed, 10 Oct 2018, Junio C Hamano wrote: > >> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits >> - mingw: bump the minimum Windows version to Vista >> - mingw: set _WIN32_WINNT explicitly for Git for Windows >> - compat/poll: prepare for targeting Windows Vista >> >> The minimum version of Windows supported by Windows port fo Git is >> now set to Vista. >> >> Will merge to 'next'. > > Could I ask you to fast-track this to `master`? The code in `master` > unfortunately no longer compiles in a current Git for Windows SDK, meaning > that all of our Continuous Testing fails as long as these patches are not > merged. Absolutely. There is no point keeping it in 'pu', as nobody would touch it in my tree until it hits 'next' and probably 'master' and the change would get wider exposure to folks to whom it matters in your tree anyway. Thanks for pinging.
js/mingw-wants-vista-or-above, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Hi Junio, On Wed, 10 Oct 2018, Junio C Hamano wrote: > * js/mingw-wants-vista-or-above (2018-10-04) 3 commits > - mingw: bump the minimum Windows version to Vista > - mingw: set _WIN32_WINNT explicitly for Git for Windows > - compat/poll: prepare for targeting Windows Vista > > The minimum version of Windows supported by Windows port fo Git is > now set to Vista. > > Will merge to 'next'. Could I ask you to fast-track this to `master`? The code in `master` unfortunately no longer compiles in a current Git for Windows SDK, meaning that all of our Continuous Testing fails as long as these patches are not merged. I do not see how this could affect non-Windows builds, so everybody else should be unaffected anyway. Thanks, Dscho
builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
Hi Junio, On Wed, 10 Oct 2018, Junio C Hamano wrote: > We haven't seen much complaints and breakages reported against the > two big "rewrite in C" topics around "rebase"; perhaps it is a good > time to merge them to 'next' soonish to cook them for a few weeks > before moving them to 'master'? I would be in favor, as long as the fixup patches I have in Git for Windows made it in: https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051 fixup! builtin rebase: support `-C` and `--whitespace=` https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837 fixup! builtin rebase: support `--gpg-sign` option https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc fixup! rebase -i: implement the main part of interactive rebase as a builtin https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e fixup! stash: convert apply to builtin It seems that Alban picked up the `rebase -i` one, but the other three have not made it into `pu` yet (the two `rebase` ones are really my fault, I did not yet find time). Speaking about the two `rebase` ones: they are simple fixup! commits, could I trouble you to fetch and cherry-pick them into `pu`, or would you prefer if I sent another iteration of `rebase-in-c-4-opts`? Ciao, Dscho
Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
On Wed, Oct 10 2018, Junio C Hamano wrote: > * 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. There's been no activity on this for 6 months since I sent a "hey what's going on with it" E-Mail in: https://public-inbox.org/git/20180404204920.ga15...@sigill.intra.peff.net/ Maybe it should just be dropped?
What's cooking in git.git (Oct 2018, #01; Wed, 10)
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. We haven't seen much complaints and breakages reported against the two big "rewrite in C" topics around "rebase"; perhaps it is a good time to merge them to 'next' soonish to cook them for a few weeks before moving them to 'master'? 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"] * ab/fsck-skiplist (2018-09-12) 10 commits (merged to 'next' on 2018-09-24 at 26adeb8b8f) + fsck: support comments & empty lines in skipList + fsck: use oidset instead of oid_array for skipList + fsck: use strbuf_getline() to read skiplist file + fsck: add a performance test for skipList + fsck: add a performance test + fsck: document that skipList input must be unabbreviated + fsck: document and test commented & empty line skipList input + fsck: document and test sorted skipList input + fsck tests: add a test for no skipList input + fsck tests: setup of bogus commit object (Originally merged to 'next' on 2018-09-17 at dc9094ba9b) Update fsck.skipList implementation and documentation. * bc/hash-independent-tests (2018-09-17) 11 commits (merged to 'next' on 2018-09-24 at 7c4a61fe46) + t5318: use test_oid for HASH_LEN + t1407: make hash size independent + t1406: make hash-size independent + t1405: make hash size independent + t1400: switch hard-coded object ID to variable + t1006: make hash size independent + t0064: make hash size independent + t0002: abstract away SHA-1 specific constants + t: update tests for SHA-256 + t: use hash translation table + t: add test functions to translate hash-related values (Originally merged to 'next' on 2018-09-17 at 9e94794d05) Various tests have been updated to make it easier to swap the hash function used for object identification. * ds/multi-pack-verify (2018-09-17) 11 commits (merged to 'next' on 2018-09-24 at f294a34aaf) + fsck: verify multi-pack-index + multi-pack-index: report progress during 'verify' + multi-pack-index: verify object offsets + multi-pack-index: fix 32-bit vs 64-bit size check + multi-pack-index: verify oid lookup order + multi-pack-index: verify oid fanout order + multi-pack-index: verify missing pack + multi-pack-index: verify packname order + multi-pack-index: verify corrupt chunk lookup table + multi-pack-index: verify bad header + multi-pack-index: add 'verify' verb (Originally merged to 'next' on 2018-09-17 at f27244f302) "git multi-pack-index" learned to detect corruption in the .midx file it uses, and this feature has been integrated into "git fsck". * nd/config-split (2018-09-12) 11 commits (merged to 'next' on 2018-09-24 at 150cb40d2c) + config.txt: move submodule part out to a separate file + config.txt: move sequence.editor out of "core" part + config.txt: move sendemail part out to a separate file + config.txt: move receive part out to a separate file + config.txt: move push part out to a separate file + config.txt: move pull part out to a separate file + config.txt: move gui part out to a separate file + config.txt: move gitcvs part out to a separate file + config.txt: move format part out to a separate file + config.txt: move fetch part out to a separate file + config.txt: follow camelCase naming (Originally merged to 'next' on 2018-09-17 at 33e6cb8f48) Split Documentation/config.txt for easier maintenance. * nd/test-tool (2018-09-11) 6 commits (merged to 'next' on 2018-09-24 at 23ad767573) + Makefile: add a hint about TEST_BUILTINS_OBJS + t/helper: merge test-dump-fsmonitor into test-tool + t/helper: merge test-parse-options into test-tool + t/helper: merge test-pkt-line into test-tool + t/helper: merge test-dump-untracked-cache into test-tool + t/helper: keep test-tool command list sorted (Originally merged to 'next' on 2018-09-17 at decbf86eeb) Test helper binaries clean-up. -- [New Topics] * ds/reachable-final-cleanup (2018-09-25) 1 commit - commit-reach: cleanups in can_all_from_reach... Code already in 'master' is further cleaned-up by this patch. Will merge to 'next'. * dz/credential-doc-url-matching-rules (2018-09-27) 1 commit - doc: clarify gitcredentials path component matching Doc update. Will merge to 'next'. * en/status-multiple-renames-to-the-same-target-fix (2018-09-27) 1 commit - commit: fix erroneous BUG, 'multiple renames on the same target? how?' The code in "git status" sometimes hit an assertion failure. This was caused by a structure that was reused without cleaning the data used for the first run, which has been
