Re: What's cooking in git.git (Sep 2021, #03; Fri, 10)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 10, 2021 at 3:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> --------------------------------------------------
> [New Topics]
>
> * en/stash-df-fix (2021-09-08) 3 commits
>  - stash: restore untracked files AFTER restoring tracked files
>  - stash: avoid feeding directories to update-index
>  - t3903: document a pair of directory/file bugs
>
>  Fix "git stash" corner case where the tentative change involves
>  changing a directory to a file (or vice versa).

I've got a v2 out to address all the feedback from Dscho, Stolee, and
you (https://lore.kernel.org/git/pull.1087.v2.git.git.1631269876.gitgitgadget@xxxxxxxxx/)

Relatedly, I also have a v2 of am-issues that hasn't been picked up
yet: https://lore.kernel.org/git/pull.1087.v2.git.git.1631269876.gitgitgadget@xxxxxxxxx/.
v1 was acked by Dscho; v2 has some fixes related to your feedback.

> * en/zdiff3 (2021-06-15) 2 commits
>  - update documentation for new zdiff3 conflictStyle
>  - xdiff: implement a zealous diff3, or "zdiff3"
>
>  "Zealous diff3" style of merge conflict presentation has been added.
>
>  Expecting a reroll.
>  cf. <CABPp-BE7-E03+x38EK-=AE5mwwdST+d50hiiud2eY2Nsf3rM5g@xxxxxxxxxxxxxx>

I just sent a reroll, since I did have some fixes from Phillip and
some new testcases, but it fails one of the testcases I made and I saw
another suboptimal case that I lost but would like to include.  I
still have this labelled RFC and it's definitely not ready.

I do plan to get back to it eventually, but am focusing more on other
topics, so you may want to eject this from seen for now.

> * ms/customizable-ident-expansion (2021-09-01) 1 commit
>  - keyword expansion: make "$Id$" string configurable
>
>  Instead of "$Id$", user-specified string (like $FreeBSD$) can be
>  used as an in-blob placeholder for keyword expansion.

Kinda disappointing to see mis-designs from CVS not only persist but
get extended.  Perhaps I'm just biased...

> * js/retire-preserve-merges (2021-09-07) 11 commits
>   (merged to 'next' on 2021-09-10 at f645ffd7a3)
>  + sequencer: restrict scope of a formerly public function
>  + rebase: remove a no-longer-used function
>  + rebase: stop mentioning the -p option in comments
>  + rebase: remove obsolete code comment
>  + rebase: drop the internal `rebase--interactive` command
>  + git-svn: drop support for `--preserve-merges`
>  + rebase: drop support for `--preserve-merges`
>  + pull: remove support for `--rebase=preserve`
>  + tests: stop testing `git rebase --preserve-merges`
>  + remote: warn about unhandled branch.<name>.rebase values
>  + t5520: do not use `pull.rebase=preserve`
>
>  The "--preserve-merges" option of "git rebase" has been removed.
>
>  Will merge to 'master'.

I'm not objecting, but I'm kind of surprised to see this after your
and Dscho's previous discussion at
https://lore.kernel.org/git/xmqqv939uis8.fsf@gitster.g/; I thought
it'd stay in next for a while.  Was this a mistake?

> * en/remerge-diff (2021-08-31) 7 commits
>  - doc/diff-options: explain the new --remerge-diff option
>  - show, log: provide a --remerge-diff capability
>  - tmp-objdir: new API for creating and removing primary object dirs
>  - merge-ort: capture and print ll-merge warnings in our preferred fashion
>  - ll-merge: add API for capturing warnings in a strbuf instead of stderr
>  - merge-ort: add ability to record conflict messages in a file
>  - merge-ort: mark a few more conflict messages as omittable
>
>  A new presentation for two-parent merge "--remerge-diff" can be
>  used to show the difference between mechanical (and possibly
>  conflicted) merge results and the recorded resolution.
>
>  What's the status of this one?

Well...you asked lots of good high level questions that I think you
felt I answered adequately.  I think that suggests the high level
ideas are at least okay.  It's also been tested in the wild for months
(and with the additional change of making `log -p` imply
--remerge-diff), so that suggests it won't blow up.

But as for actual patch review, the only one who has taken a look is
Sergey, who reviewed the diff-merges portion of patch 6 and was happy
with it.

It'd be great to get some more of these patches reviewed.  In
particular, if someone had time for just one patch, I'd really like to
see someone review one of these:
  * the tmp-objdir.c changes (patch 5)
  * the integration of all the pieces in log-tree.c and revision.c (patch 6)
  * the ll-merge.c changes (patch 3)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux