Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
Phillip Wood writes: >> * ra/rebase-i-more-options (2019-09-09) 6 commits >> ... >> Is this ready for 'next'. > > Nearly, but not quite I think cf [1]. Also I'm still not convinced > that having different behaviors for --ignore-whitespace depending on > the backend is going to be helpful but maybe they are close enough not > to matter too much in practice [2]. > > [1] > https://public-inbox.org/git/20190806173638.17510-1-rohit.ashiwal...@gmail.com/T/#m965ce1f09d1d1b8010c04db0eabd4b19ce99fe82 OK, so I'll leave a note that this needs to consider existing GIT_COMMITTER_DATE environment variable, etc, with a reference to <5adde732-173b-d24d-d23f-bb4d04307...@gmail.com>. A URL to public-inbox.org is good, but that is because those who do not use public-inbox.org (or after the site goes out of service) can still identify exactly which message you are referring to if you use the https://public-inbox.org/git/$message_id_without_brackets format. Unlike that form, the format you used only identifies the thread starter, and without public-inbox.org in service, a reader cannot tell which message in the thread you are referring to, even if the reader had full mailing list archive. IOW, I would have appreciated if the above reference were done like so: https://public-inbox.org/git/5adde732-173b-d24d-d23f-bb4d04307...@gmail.com/ Thanks.
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
Hi Elijah
On 05/10/2019 01:40, Elijah Newren wrote:
On Fri, Oct 4, 2019 at 4:49 AM Phillip Wood wrote:
Hi Junio
On 03/10/2019 06:04, 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/rebase-i-show-HEAD-to-reword (2019-08-19) 3 commits
- sequencer: simplify root commit creation
- rebase -i: check for updated todo after squash and reword
- rebase -i: always update HEAD before rewording
(this branch is used by ra/rebase-i-more-options.)
"git rebase -i" showed a wrong HEAD while "reword" open the editor.
Will merge to 'next'.
That's great, thanks
* ra/rebase-i-more-options (2019-09-09) 6 commits
- rebase: add --reset-author-date
- rebase -i: support --ignore-date
- sequencer: rename amend_author to author_to_rename
- rebase -i: support --committer-date-is-author-date
- sequencer: allow callers of read_author_script() to ignore fields
- rebase -i: add --ignore-whitespace flag
(this branch uses pw/rebase-i-show-HEAD-to-reword.)
"git rebase -i" learned a few options that are known by "git
rebase" proper.
Is this ready for 'next'.
Nearly, but not quite I think cf [1]. Also I'm still not convinced that
having different behaviors for --ignore-whitespace depending on the
backend is going to be helpful but maybe they are close enough not to
matter too much in practice [2].
Sorry I should have chimed in sooner; I can speak to the second point.
I would say that in practice it doesn't matter a lot; in most cases
the two overlap. Both am's --ignore-whitespace and merge's
-Xignore-space-change are buggy (in different ways) and should be
fixed, but I'd consider them both to be buggy in edge cases. I
recommended earlier this summer that Rohit submit the patches without
first attempting to fix apply or xdiff, and kept in my TODO list
that'd I'd go in and fix xdiff later if Rohit didn't have extra time
for it. I did a little digging back then to find out the differences
and suggested some text to use to explain them and to argue that they
shouldn't block this feature:
"""
am's --ignore-space-change (an alias for am's --ignore-whitespace; see
git-apply's description of those two flags) not only share the same
name with diff's --ignore-space-change and merge's
-Xignore-space-change, but the similarity in naming appears to have
been intentional with am's --ignore-space-change and merge's
-Xignore-space-change being designed to have the same functionality
(see e.g. the commit messages for f008cef4abb2 ("Merge branch
'jc/apply-ignore-whitespace'", 2014-06-03) and 4e5dd044c62f
("merge-recursive: options to ignore whitespace changes",
2010-08-26)). For the most part, these options do provide the same
behavior. However, there are some edge cases where both apply's
--ignore-space-change and merge's -Xignore-space-change fall short of
optimal behavior, and in different ways. In particular,
--ignore-space-change for apply will handle whitespace changes in the
context region but not in the region the other side modified, and
-Xignore-space-change will delete whitespace changes even when the
other side had no changes (thus treating both sides as unmodified).
Fixing these differences in edge cases is left for future work; this
patch simply wires interactive rebase to also understand
--ignore-whitespace by translating it to -Xignore-space-change.
"""
I've got another email with even more detail if folks need it.
Thanks for clarifying that, it sounds like it shouldn't be a problem in
practice then (especially if you're planning some improvements)
Best Wishes
Phillip
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
On Fri, Oct 4, 2019 at 4:49 AM Phillip Wood wrote:
>
> Hi Junio
>
> On 03/10/2019 06:04, 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/rebase-i-show-HEAD-to-reword (2019-08-19) 3 commits
> > - sequencer: simplify root commit creation
> > - rebase -i: check for updated todo after squash and reword
> > - rebase -i: always update HEAD before rewording
> > (this branch is used by ra/rebase-i-more-options.)
> >
> > "git rebase -i" showed a wrong HEAD while "reword" open the editor.
> >
> > Will merge to 'next'.
>
> That's great, thanks
>
> >
> > * ra/rebase-i-more-options (2019-09-09) 6 commits
> > - rebase: add --reset-author-date
> > - rebase -i: support --ignore-date
> > - sequencer: rename amend_author to author_to_rename
> > - rebase -i: support --committer-date-is-author-date
> > - sequencer: allow callers of read_author_script() to ignore fields
> > - rebase -i: add --ignore-whitespace flag
> > (this branch uses pw/rebase-i-show-HEAD-to-reword.)
> >
> > "git rebase -i" learned a few options that are known by "git
> > rebase" proper.
> >
> > Is this ready for 'next'.
>
> Nearly, but not quite I think cf [1]. Also I'm still not convinced that
> having different behaviors for --ignore-whitespace depending on the
> backend is going to be helpful but maybe they are close enough not to
> matter too much in practice [2].
Sorry I should have chimed in sooner; I can speak to the second point.
I would say that in practice it doesn't matter a lot; in most cases
the two overlap. Both am's --ignore-whitespace and merge's
-Xignore-space-change are buggy (in different ways) and should be
fixed, but I'd consider them both to be buggy in edge cases. I
recommended earlier this summer that Rohit submit the patches without
first attempting to fix apply or xdiff, and kept in my TODO list
that'd I'd go in and fix xdiff later if Rohit didn't have extra time
for it. I did a little digging back then to find out the differences
and suggested some text to use to explain them and to argue that they
shouldn't block this feature:
"""
am's --ignore-space-change (an alias for am's --ignore-whitespace; see
git-apply's description of those two flags) not only share the same
name with diff's --ignore-space-change and merge's
-Xignore-space-change, but the similarity in naming appears to have
been intentional with am's --ignore-space-change and merge's
-Xignore-space-change being designed to have the same functionality
(see e.g. the commit messages for f008cef4abb2 ("Merge branch
'jc/apply-ignore-whitespace'", 2014-06-03) and 4e5dd044c62f
("merge-recursive: options to ignore whitespace changes",
2010-08-26)). For the most part, these options do provide the same
behavior. However, there are some edge cases where both apply's
--ignore-space-change and merge's -Xignore-space-change fall short of
optimal behavior, and in different ways. In particular,
--ignore-space-change for apply will handle whitespace changes in the
context region but not in the region the other side modified, and
-Xignore-space-change will delete whitespace changes even when the
other side had no changes (thus treating both sides as unmodified).
Fixing these differences in edge cases is left for future work; this
patch simply wires interactive rebase to also understand
--ignore-whitespace by translating it to -Xignore-space-change.
"""
I've got another email with even more detail if folks need it.
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
Hi Junio On 03/10/2019 06:04, 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/rebase-i-show-HEAD-to-reword (2019-08-19) 3 commits - sequencer: simplify root commit creation - rebase -i: check for updated todo after squash and reword - rebase -i: always update HEAD before rewording (this branch is used by ra/rebase-i-more-options.) "git rebase -i" showed a wrong HEAD while "reword" open the editor. Will merge to 'next'. That's great, thanks * ra/rebase-i-more-options (2019-09-09) 6 commits - rebase: add --reset-author-date - rebase -i: support --ignore-date - sequencer: rename amend_author to author_to_rename - rebase -i: support --committer-date-is-author-date - sequencer: allow callers of read_author_script() to ignore fields - rebase -i: add --ignore-whitespace flag (this branch uses pw/rebase-i-show-HEAD-to-reword.) "git rebase -i" learned a few options that are known by "git rebase" proper. Is this ready for 'next'. Nearly, but not quite I think cf [1]. Also I'm still not convinced that having different behaviors for --ignore-whitespace depending on the backend is going to be helpful but maybe they are close enough not to matter too much in practice [2]. [1] https://public-inbox.org/git/20190806173638.17510-1-rohit.ashiwal...@gmail.com/T/#m965ce1f09d1d1b8010c04db0eabd4b19ce99fe82 [2] https://public-inbox.org/git/20190806173638.17510-1-rohit.ashiwal...@gmail.com/T/#m94e059c18b7bbcc721d12b190bd4aaecc5e8d591
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
Elijah Newren writes: > Actually, René posted a code cleanup suggestion for patch 2/8, so I > sent a V3 re-roll[1]. Could you pick up V3 instead of merging V2 down > to next? > > [1] https://public-inbox.org/git/20191003202709.26279-1-new...@gmail.com/ Thanks for stopping me. Will take a look.
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
Emily Shaffer writes: > On Thu, Oct 03, 2019 at 02:04:39PM +0900, 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. >> >> 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 >> > > Hi Junio, > > How do you feel about > https://public-inbox.org/git/20190930220355.108394-1-emilyshaf...@google.com/ > which fixes a user-facing SIGABRT during partial clone operations? It's > reviewed by Peff and Christian. Already picked up on the tip of cc/multi-promisor and pushed out, I think, as part of yesterday's integration cycle. Thanks for fixing.
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
On Wed, Oct 2, 2019 at 10:22 PM Junio C Hamano wrote: > > * en/fast-imexport-nested-tags (2019-10-02) 8 commits > - fast-export: handle nested tags > - t9350: add tests for tags of things other than a commit > - fast-export: allow user to request tags be marked with --mark-tags > - fast-export: add support for --import-marks-if-exists > - fast-import: add support for new 'alias' command > - fast-import: allow tags to be identified by mark labels > - fast-import: fix handling of deleted tags > - fast-export: fix exporting a tag and nothing else > > Updates to fast-import/export. > > Will merge to 'next'. Actually, René posted a code cleanup suggestion for patch 2/8, so I sent a V3 re-roll[1]. Could you pick up V3 instead of merging V2 down to next? [1] https://public-inbox.org/git/20191003202709.26279-1-new...@gmail.com/
Re: What's cooking in git.git (Oct 2019, #01; Thu, 3)
On Thu, Oct 03, 2019 at 02:04:39PM +0900, 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. > > 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 > Hi Junio, How do you feel about https://public-inbox.org/git/20190930220355.108394-1-emilyshaf...@google.com/ which fixes a user-facing SIGABRT during partial clone operations? It's reviewed by Peff and Christian. - Emily
