Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.34

github.blog

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Highlights from Git 2.34

#61

Post by beermonster »

harrisi wrote: post #59
beermonster wrote: post #58

Earlier quoted context omitted.

Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.

This might help https://docs.github.com/en/repositories/configuring-branches...

That page details squashing and rebasing strategies. It doesn’t talk about different merge points being used in a merge when done on GH compared to when the same merge is performed locally on the command line.

Re: Highlights from Git 2.34

#62

Post by thriftwy »

jakub_g wrote: post #45

Major: A new default merge strategy > In Git 2.34, ort is now the default merge strategy, so you should notice faster merges with fewer bugs just by upgrading > a rewrite allowed Git to implement a merge strategy that doesn’t operate on the index

Git is awesome but it would really be great if they sunsetted merge instead of putting lipstick on it.

Merge of two good commits will silently produce bad commit.

Merges are not repeatable and can't be reasoned about.

Merges get in a way of git bisect.

Merge makes simple "git log" not contain all the log.

Good luck cherry-picking a merge commit.

Merge makes a commit which has important changes not apply to any specific revision of git log.

It's an enormous foot gun and a single contributor may inadvertenly taint your repository for life.

Merge is a make-believe working set operation, like if you could pretend to add apple to mango and get a pomelo.

Merge is VCS analog of lead acetate. Something you have no reason to ever put in your mouth.

Re: Highlights from Git 2.34

#63

Post by avar »

beermonster wrote: post #58
avar wrote: post #42

I've got some patches in this release. If anyone's got question that someone who contributes to git might be able to answer I'd love to help. Are there any specific things that git does that you wish were done better? I probably won't be able to help with very generic things like "it's complex", but if there's specific drawbacks in some particular commands I might be able to fix them. Or anything else, I'll monitor t…

Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.

GitHub (which I'm not affiliated with) does some (all?) of their server-side merging with libgit2, not git itself, although I know they're considering moving to git with the "ort" work. So perhaps it's one of the cases where libgit2's behavior differs?

Re: Highlights from Git 2.34

#64

Post by avar »

Lammy wrote: post #57
avar wrote: post #42

I've got some patches in this release. If anyone's got question that someone who contributes to git might be able to answer I'd love to help. Are there any specific things that git does that you wish were done better? I probably won't be able to help with very generic things like "it's complex", but if there's specific drawbacks in some particular commands I might be able to fix them. Or anything else, I'll monitor t…

> Are there any specific things that git does that you wish were done better? I wish `git-log`'s `--follow` wasn't optional so GitHub et al would show the complete history for files I `git mv`. Mercurial got this one right :)

Yeah, me to. I think that was always the plan, but nobody's had the time to go back, re-visit it, and make it so.

I'd say that most of the work of driving features forward in git is hunting down those various edge cases, taking the time to understand them, and explaining them to others. So if anyone's interested in flipping that particular switch it's very open to first-time contributions.

Re: Highlights from Git 2.34

#65

Post by namrog84 »

avar wrote: post #42

I've got some patches in this release. If anyone's got question that someone who contributes to git might be able to answer I'd love to help. Are there any specific things that git does that you wish were done better? I probably won't be able to help with very generic things like "it's complex", but if there's specific drawbacks in some particular commands I might be able to fix them. Or anything else, I'll monitor t…

I really enjoy git way more than others but working in unreal engine and with binary assets. I've always felt like git filr locks were an area that still needs more attention.

I know file locks are almost an antipattern for git. But there are definitely good use cases and arguments for better git support and related tooling support around them, especially for binary heavier areas.

The other thing I saw other day was sparse index or something. At work we have a monorepo and I wish that was more control or granularity over checking out a subset of a repo somehow. Our clones even with shallow fetch and lfs can be 5+ minutes for an area that should only take 3 seconds. But no good subset checkout.

Re: Highlights from Git 2.34

#66

Post by beermonster »

avar wrote: post #63
beermonster wrote: post #58

Earlier quoted context omitted.

Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.

GitHub (which I'm not affiliated with) does some (all?) of their server-side merging with libgit2, not git itself, although I know they're considering moving to git with the "ort" work. So perhaps it's one of the cases where libgit2's behavior differs?

Aha, that’s useful to know. Thanks!

Re: Highlights from Git 2.34

#67

Post by gravypod »

avar wrote: post #42

I've got some patches in this release. If anyone's got question that someone who contributes to git might be able to answer I'd love to help. Are there any specific things that git does that you wish were done better? I probably won't be able to help with very generic things like "it's complex", but if there's specific drawbacks in some particular commands I might be able to fix them. Or anything else, I'll monitor t…

I have two wishes for git:

1. A consistent cross-language API for reading and writing from a bare/remote git repo in ways that would make sense to an average programmer. Something like `git.stat("/file.txt", commit=...)`, `git.open("/file.txt", branch=...)` `git.list_commits(since=...)`, `git.create_commit(parrent_commits=[], branch="", ...)`

2. A good story, better than LFS, for storing large binaries over time.

For #2 I want to reproducibly build a debian image from vendored packages or recompile gcc from source so I need to check in a pre-built compiler. etc

Re: Highlights from Git 2.34

#68

Post by btschaegg »

avar wrote: post #42

I've got some patches in this release. If anyone's got question that someone who contributes to git might be able to answer I'd love to help. Are there any specific things that git does that you wish were done better? I probably won't be able to help with very generic things like "it's complex", but if there's specific drawbacks in some particular commands I might be able to fix them. Or anything else, I'll monitor t…

Something that has been nagging me for my workflow is how Git handles --autosquash.

I really like the idea, and wrote my personal little `git autosquash` command that tries to figure out the oldest commit it has to run `git rebase -ir --autosquash` on in order to merge all current "fixup! …" commits into their counterparts.

However, doing this in a simple shell script is rather dodgy if you run into more generic commit messages. Personally, I'd love it if git allowed me to create "fixup! " commits instead. I mean -- it's a fixup. It's not supposed to be readable anyway.

Re: Highlights from Git 2.34

#69

Post by martinvonz »

kadoban wrote: post #49
childintime wrote: post #24

Related: it's been a year since Pijul ( https://pijul.org ) began working towards 1.0 ( https://news.ycombinator.com/item?id=25032956 ). Seems to be coming along nicely, they're in alpha now and it's showing.

I keep checking in on that. In my case what I need to start seriously using it is two-way git interop. I need to be able to work in pijul locally and "publish" somehow to git. So far that still doesn't seem to exist.

If the Pijul feature you care most about is "first-class conflicts", you may want to check out my VCS: https://github.com/martinvonz/jj. It has git interop.

Re: Highlights from Git 2.34

#70

Post by kadoban »

martinvonz wrote: post #69
kadoban wrote: post #49

Earlier quoted context omitted.

I keep checking in on that. In my case what I need to start seriously using it is two-way git interop. I need to be able to work in pijul locally and "publish" somehow to git. So far that still doesn't seem to exist.

If the Pijul feature you care most about is "first-class conflicts", you may want to check out my VCS: https://github.com/martinvonz/jj . It has git interop.

Thanks, I'll check it out. Yeah, that's the main draw for me.
Post reply on HN