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

I made my own Git

tonystr.net

Post reply on HN
Print view View original

151–160 of 184 posts

Re: I made my own Git

#151

Post by Brian_K_White »

pwdisswordfishy wrote: post #145
nasretdinov wrote: post #37

Nice work! On a complete tangent, Git is the only SCM known to me that supports recursive merge strategy [1] (instead of the regular 3-way merge), which essentially always remembers resolved conflicts without you needing to do anything. This is a very underrated feature of Git and somehow people still manage to choose rebase over it. If you ever get to implementing merges, please make sure you have a mechanism for re…

New to me was discovering within the last month that git-merge doesn't have a merge strategy of "null": don't try to resolve any merge conflicts, because I've already taken care of them; just know that this is a merge between the current branch and the one specified on the command-line, so be a dutiful little tool and just add it to your records. Don't try to "help". Don't fuck with the index or the worktree. Just re…

What does that even mean? There already is reset hard.

Re: I made my own Git

#152

Post by adastra22 »

embedding-shape wrote: post #112
adastra22 wrote: post #79

Earlier quoted context omitted.

Those things exist for git too, e.g. git-bug. But the first-class to do it in git is email.

Email isn't a wiki, bug tracking, documentation and all the other stuff Fossil offers as part of their core design. The point is for it to be in one place, and local-first. If you don't trust me, read the list of features and give it a try yourself: https://fossil-scm.org/home/doc/trunk/www/index.wiki

I am aware of fossil. Did you look up git-bug?

Re: I made my own Git

#153

Post by lmm »

arunix wrote: post #54
nasretdinov wrote: post #37

Nice work! On a complete tangent, Git is the only SCM known to me that supports recursive merge strategy [1] (instead of the regular 3-way merge), which essentially always remembers resolved conflicts without you needing to do anything. This is a very underrated feature of Git and somehow people still manage to choose rebase over it. If you ever get to implementing merges, please make sure you have a mechanism for re…

I remember in a previous job having to enable git rerere, otherwise it wouldn't remember previously resolved conflicts. https://git-scm.com/book/en/v2/Git-Tools-Rerere

Rerere is dangerous and counterproductive - it tries to give rebase the same functionality that merge has, but since rebase is fundamentally wrong it only stacks the wrongness.

Re: I made my own Git

#154

Post by seba_dos1 »

lmm wrote: post #153
arunix wrote: post #54

Earlier quoted context omitted.

I remember in a previous job having to enable git rerere, otherwise it wouldn't remember previously resolved conflicts. https://git-scm.com/book/en/v2/Git-Tools-Rerere

Rerere is dangerous and counterproductive - it tries to give rebase the same functionality that merge has, but since rebase is fundamentally wrong it only stacks the wrongness.

Cherry-picks being "fundamentally wrong" is certainly an interesting git take.

Re: I made my own Git

#155

Post by seba_dos1 »

Phelinofist wrote: post #90
Phelinofist wrote: post #44

Earlier quoted context omitted.

I selfhost Gitea. The instance is crawled by AI crawlers (checked the IPs). They never cloned, they just browse and take it directly from there.

For reference, this is how I do it in my Caddyfile: (block_ai) { @ai_bots { header_regexp User-Agent (?i)(anthropic-ai|ClaudeBot|Claude-Web|Claude-SearchBot|GPTBot|ChatGPT-User|Google-Extended|CCBot|PerplexityBot|ImagesiftBot) } abort @ai_bots } Then, in a specific app block include it via import block_ai

Most of then pretend to be real users though and don't identify themselves with their user agent strings.

Re: I made my own Git

#156

Post by pwdisswordfishy »

Brian_K_White wrote: post #151
pwdisswordfishy wrote: post #145

Earlier quoted context omitted.

New to me was discovering within the last month that git-merge doesn't have a merge strategy of "null": don't try to resolve any merge conflicts, because I've already taken care of them; just know that this is a merge between the current branch and the one specified on the command-line, so be a dutiful little tool and just add it to your records. Don't try to "help". Don't fuck with the index or the worktree. Just re…

What does that even mean? There already is reset hard.

What do you mean, "What does it mean?" It means what I wrote.

> There already is reset hard.

That's not... remotely relevant? What does that have to do with merging? We're talking about merging.

Re: I made my own Git

#157

Post by cozzyd »

tverbeure wrote: post #149
gxnxcxcx wrote: post #86

Earlier quoted context omitted.

I'm Kenyan. I don't write like ChatGPT, ChatGPT writes like me https://news.ycombinator.com/item?id=46273466

Thanks for that link. This part made me laugh though: > These detectors, as I understand them, often work by measuring two key things: ‘Perplexity’ and ‘burstiness’. Perplexity gauges how predictable a text is. If I start a sentence, "The cat sat on the...", your brain, and the AI, will predict the word "floor." I can't be the only one who's brain predicted "mat" ?

And I thought it would be a hat...

Re: I made my own Git

#158

Post by 3eb7988a1663 »

PunchyHamster wrote: post #106
mkleczek wrote: post #55

Earlier quoted context omitted.

Much more principled (and hence less of a foot-gun) way of handling conflicts is making them first class objects in the repository, like https://pijul.org does.

I feel like people making new VCSes should just re-use GIT storage/network layer and innovate on top of that. Git storage is flexible enough for that, and that way you can just.... use it on existing repos with very easy migration path for both workflows (CI/CD never need to care about what frontend you use) and users

It is my understanding that under the hood, the repository has quite a bit of state that can get mangled. That is why naively syncing a git repo with say Dropbox is not a surefire operation.

Re: I made my own Git

#160

Post by kbolino »

Brian_K_White wrote: post #151
pwdisswordfishy wrote: post #145

Earlier quoted context omitted.

New to me was discovering within the last month that git-merge doesn't have a merge strategy of "null": don't try to resolve any merge conflicts, because I've already taken care of them; just know that this is a merge between the current branch and the one specified on the command-line, so be a dutiful little tool and just add it to your records. Don't try to "help". Don't fuck with the index or the worktree. Just re…

What does that even mean? There already is reset hard.

The name "null" is confusing; you have to pick something. However, I think what is desired here is the "theirs" strategy, i.e. to replace the current branch's tree entirely with the incoming branch's tree. The end result would be similar to a hard reset onto the incoming branch, except that it would also create a merge commit. Unfortunately, the "theirs" strategy does not exist, even though the "ours" strategy does exist, apparently to avoid confusion with the "theirs" option [1], but it is possible to emulate it with a sequence of commands [2].

[1]: https://git-scm.com/docs/merge-strategies#Documentation/merg...

[2]: https://stackoverflow.com/a/4969679/814422

Post reply on HN