[HN Gopher] Highlights from Git 2.36
___________________________________________________________________
Highlights from Git 2.36
Author : todsacerdoti
Score : 104 points
Date : 2022-04-18 16:44 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| jwilk wrote:
| Stricter repository ownership checks discuessed on HN:
|
| https://news.ycombinator.com/item?id=31009675
| clumsysmurf wrote:
| Anyone know of up-to-date binaries for Mac OS ... our work
| machines are heavily restricted, we can not compile from sources,
| use homebrew, install into /usr/local, etc.
|
| I just want something I can put in ~/.local/bin or something,
| like so many modern command line tools these days (fzf, rg, etc).
|
| git-osx-installer doesn't seem to be maintained. It still seems
| strange to me that in 2021 such a large project doesn't have
| official binaries for a popular platform.
| JamesSwift wrote:
| Maybe a single-user install of Nix Package Manager with a
| custom prefix in your home directory? Not sure if that breaks
| things or not
| Bilal_io wrote:
| See if you can extract the binary from here.
|
| https://mirrors.edge.kernel.org/pub/software/scm/git/
| petepete wrote:
| Hate to remind you but we're a third of the way through 2022.
| ainar-g wrote:
| On a related note, I seriously recommend everyone to set their
| merge.conflictStyle to diff3 (or even zdiff3 on newer Gits). It
| shows you all of your version, thier version, _and_ the original,
| common-ancestor version. It really should be the default, and, as
| far as I know, the only reason it isn 't is because there are
| some older diff(1) implementation that don't support three-way
| diffs.
|
| See https://blog.nilbus.com/take-the-pain-out-of-git-conflict-
| re... and https://stackoverflow.com/q/27417656.
| _ZeD_ wrote:
| Apart from the "Ten Thousand" xkcd reference, I heavely suggest
| to use the venerable kdiff3[1]
|
| [1] http://kdiff3.sourceforge.net/
| tvb12 wrote:
| I think this might be the project page now:
| https://invent.kde.org/sdk/kdiff3
| kapilvt wrote:
| Meld is also pretty nice https://meldmerge.org/
| glogla wrote:
| How can this be a thing since 2008 and I didn't know? Thank
| you!
| NeckBeardPrince wrote:
| I just learned about push-options last week.
|
| https://git-scm.com/docs/git-push#Documentation/git-
| push.txt...
|
| https://docs.gitlab.com/ee/user/project/push_options.html
| hiq wrote:
| What do you use them for? I went through the GitLab doc, I
| see how it could make sense for automated PRs, but for
| manual ones I don't see how I would benefit from them.
| tenken wrote:
| Debugging a deploy job (stage) from a feature branch via
| an env variable.
| mdaniel wrote:
| Please vote for the resulting issues from that thread in
| order to help others discover the feature:
| https://news.ycombinator.com/item?id=31040637
| kazinator wrote:
| Relevant:
| https://www.gnu.org/software/diffutils/manual/diffutils.html...
|
| When I'm merging, and things are really messed up due to
| unrelated things being diffed together, in a situation in which
| both must survive in the merged result, I do this:
|
| 1. Find syntactic boundaries before and after the conflict, in
| order to delimit an area that is a complete piece of top-level
| syntax, in which the conflict lies. So that is to say if the
| conflict is flanked by fragments of syntax, I include them.
|
| 2. I make a copy of this entire area, so that I have two
| consecutive copies of the complete syntactic unit, and
| therefore two copies of the conflict.
|
| 3. Go through the first copy and edit it with a view toward one
| side of the conflict.
|
| 4. Repeat on the second copy, but with a view toward keeping
| the changes from the other side of the conflict.
|
| Example (manually created): static void
| foo(int x) { <<<<<<< return x; }
| static void bar(int y) { return y;
| ======= return x + 1; } static
| void xyzzy(int z) { return z >>>>>>>
| }
|
| WTF? Ah, OK: there is originally a foo(), and one side added
| bar() and the other xyzzy(). We need both. Ah, and foo was
| tweaked t o be different.
|
| OK, what is the complete syntactic unit? We include everything
| from the "static void foo" to the closing brace after the
| >>>>>> and copy it. We include markers: //
| COPY A static void foo(int x) { <<<<<<<
| return x; } static void bar(int y) {
| return y; ======= return x + 1; }
| static void xyzzy(int z) { return z
| >>>>>>> } // COPY B static void
| foo(int x) { <<<<<<< return x; }
| static void bar(int y) { return y;
| ======= return x; } static void
| xyzzy(int z) { return z >>>>>>> }
|
| Now we work through COPY A, keeping the <<<<<<< side:
| // COPY A static void foo(int x) {
| return x; } static void bar(int y) {
| return y; } // COPY B static void
| foo(int x) { <<<<<<< return x + 1;
| } static void bar(int y) { return
| y; ======= return x; }
| static void xyzzy(int z) { return z
| >>>>>>> }
|
| Then through COPY B, keeping the >>>>>>> side:
| // COPY A static void foo(int x) {
| return x; } static void bar(int y) {
| return y; } // COPY B static void
| foo(int x) { return x + 1; }
| static void xyzzy(int z) { return z }
|
| Now get rid of the duplicate foo. It looks like we need the one
| which does "return x + 1": static void foo(int
| x) { return x + 1; } static
| void bar(int y) { return y; }
| static void xyzzy(int z) { return z }
| encryptluks2 wrote:
| Even better may be to install and use git-delta which does this
| amongst many other things:
|
| https://github.com/dandavison/delta
| lilyball wrote:
| The parent comment is about merge style, not diff style.
| Delta displays diffs, it's not a merge tool.
| encryptluks2 wrote:
| It is also a tool to resolve merges as well.
| aendruk wrote:
| How so? Its documentation on merge conflicts just reiterates
| setting `diff3`.
| lazulicurio wrote:
| Is there a way to change the output format? I find that
| "||||||| merged common ancestor" to be very noisy, visually.
| tylerFowler wrote:
| I think learning diff3 has had one of the largest ROIs of
| anything I've perhaps _ever_ learned. I show it to interns
| whenever I can, which tends to remind me just how daunting it
| is to use for the first time.
| karmakaze wrote:
| If I didn't use JetBrains' products for anything else, I'd
| still use it for git -> Resolve Conflicts.
| user3939382 wrote:
| Amen. I also have Kaleidoscope which is great for diffs but
| nothing beats Resolve Conflicts from JetBrains.
| vlovich123 wrote:
| The "More flexible fsync configuration" section made me think of
| [1]. I wonder how much faster Git would get by using Sqlite to
| manage the DB instead of using naked filesystem objects.
|
| [1] https://www.sqlite.org/fasterthanfs.html
| atonse wrote:
| Can't imagine it's too hard to adopt it this way?
|
| I know folks like MS have made big changes to the underlying
| storage layers to better handle massive repos.
| DiabloD3 wrote:
| I wish it was an option, especially for git on NTFS systems
___________________________________________________________________
(page generated 2022-04-18 23:01 UTC)