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

161–170 of 184 posts

Re: I made my own Git

#161

Post by Guvante »

nasretdinov wrote: post #59
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

I believe rerere is a local cache, so you'd still have to resolve the conflicts again on another machine. The recursive merge doesn't have this issue — the conflict resolution inside the merge commits is effectively remembered (although due to how Git operates it actually never even considers it a conflict to be remembered — just a snapshot of the closest state to the merged branches)

Are people repeatedly handling merge conflicts on multiple machines?

If there was a better way to handle "I needed to merge in the middle of my PR work" without introducing reverse merged permanently in the history I wouldn't mind merge commits.

But tools will sometimes skip over others work if you `git pull` a change into your local repo due to getting confused which leg of the merge to follow.

Re: I made my own Git

#162

Post by EdSchouten »

oconnor663 wrote: post #133
EdSchouten wrote: post #51

Earlier quoted context omitted.

It depends on the architecture. On ARM64, SHA-256 tends to be faster than BLAKE3. The reasons being that most modern ARM64 CPUs have native SHA-256 instructions, and lack an equivalent of AVX-512. Furthermore, if your input files are large enough that parallelizing across multiple cores makes sense, then it's generally better to change your data model to eliminate the existence of the large inputs altogether. For exa…

As far as I know, most CDC schemes requires a single-threaded pass over the whole file to find the chunk boundaries? (You can try to "jump to the middle", but usually there's an upper bound on chunk length, so you might need to backtrack depending on what you learn later about the last chunk you skipped?) The more cores you have, the more of a bottleneck that becomes.

You can always use a divide and conquer strategy to compute the chunks. Chunk both halves of the file independently. Once that’s done, you redo the chunking around the midpoint of the file forward, until it starts to match the chunks obtained previously.

Re: I made my own Git

#163

Post by Brian_K_White »

pwdisswordfishy wrote: post #156
Brian_K_White wrote: post #151

Earlier quoted context omitted.

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.

Neither of these are answers or explainations. So you said nothing, and then said nothing again.

I also "mean what I wrote". Man that was sure easy to say. It's almost like saying nothing at all. Which is anyone's righ to do, but it's not an argument, nor a definition of terms, nor communication at all. Well, it does communicate one thing.

Re: I made my own Git

#164

Post by teiferer »

storystarling wrote: post #130
teiferer wrote: post #63

Earlier quoted context omitted.

I don't really get why they need to clone in order to scrape ...? > It feels weird to think that LLMs are being trained on my code, especially when I'm painfully aware of every corner I'm cutting. That's very much expected. That's why the quality of LLM coding agents is like it is. (No offense.) The "asking LLMs for advice" part is where the circular aspect starts to come into the picture. Not worse than looking at S…

Cloning gets you the raw text objects directly. If you scrape the web UI you're dealing with a lot of markup overhead that just burns compute during ingestion. For training data you usually want the structure to be as clean as possible from the start.

Sure, cloning a local copy. But why clone on github?

Re: I made my own Git

#165

Post by valleyer »

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…

Doesn't `git merge -s ours` do this?

    This resolves any number of heads, but the resulting tree of the merge is always
    that of the current branch head, effectively ignoring all changes from all other
    branches. It is meant to be used to supersede old development history of side
    branches. Note that this is different from the -Xours option to the ort merge strategy.

Re: I made my own Git

#166

Post by nasretdinov »

ezst wrote: post #140
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…

On recursive merging, by the author of mercurial https://www.mercurial-scm.org/pipermail/mercurial/2012-Janua...

Yeah, the point about high complexity of the recursive merge is valid, and that's what I would expect from the Mercurial devs too. I personally find it a bit unfortunate that Git ended up winning tbh, but since it did, I think it makes sense to at least cherish what it has out of the box :)

Re: I made my own Git

#167

Post by nasretdinov »

Guvante wrote: post #161
nasretdinov wrote: post #59

Earlier quoted context omitted.

I believe rerere is a local cache, so you'd still have to resolve the conflicts again on another machine. The recursive merge doesn't have this issue — the conflict resolution inside the merge commits is effectively remembered (although due to how Git operates it actually never even considers it a conflict to be remembered — just a snapshot of the closest state to the merged branches)

Are people repeatedly handling merge conflicts on multiple machines? If there was a better way to handle "I needed to merge in the middle of my PR work" without introducing reverse merged permanently in the history I wouldn't mind merge commits. But tools will sometimes skip over others work if you `git pull` a change into your local repo due to getting confused which leg of the merge to follow.

One place where it mattered was when I was working on a large PHP web site, where backend devs and frontend devs would be working in the same branch — this way you don't have to go back and forth to get the new API, and this workflow was quite unique and, in my mind, quite efficient. The branchs also could live for some time (e.g. in case of large refactorings), and it's a good idea to merge in the master branch frequently, so recursive merge was really nice. Nowadays, of course, you design the API for your frontend, mobile, etc, upfront, so there's little reason to do that anymore.

Re: I made my own Git

#168

Post by ezst »

nasretdinov wrote: post #166
ezst wrote: post #140

Earlier quoted context omitted.

On recursive merging, by the author of mercurial https://www.mercurial-scm.org/pipermail/mercurial/2012-Janua...

Yeah, the point about high complexity of the recursive merge is valid, and that's what I would expect from the Mercurial devs too. I personally find it a bit unfortunate that Git ended up winning tbh, but since it did, I think it makes sense to at least cherish what it has out of the box :)

In some ways, the legacy of mercurial lives through jujutsu/jj and offers some sanity and familiarity on top of git's UI. But with that said, mercurial is far from dead, major "under-the-hood" works are going strong (including a rewrite in rust), the hosting situation is getting good with heptapod (a branch of gitlab with native mercurial support).

I really don't see any downside to recommending mercurial in 2026. Git isn't just inferior as a VCS in the subjective sense of "oh… I don't like this or that inconsistent aspect of its UI", but in very practical and meaningful ways (on technical merit) that are increasingly forgotten about the more it solidifies as a monopoly:

- still no support for branches (in the traditional sense, as a commit-level marker, to delineate series of related commits) means that a branchy-DAG is border-line useless, and tools like bisect can't use the info to take you at the series boundaries

- still no support for phasing (to mark which commits have been exchanged or are local-only and safe to edit)

- still no support for evolve (to record history rewrites in a side-storage, making concurrent/distributed history rewrites safe and mostly automatic)

Re: I made my own Git

#169

Post by embedding-shape »

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

Earlier quoted context omitted.

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?

Indeed, I'd still claim that a 3rd party addition doesn't make Git as local-first as Fossil when it comes to other things than source code.

Re: I made my own Git

#170

Post by pwdisswordfishy »

Brian_K_White wrote: post #163
pwdisswordfishy wrote: post #156

Earlier quoted context omitted.

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.

Neither of these are answers or explainations. So you said nothing, and then said nothing again. I also "mean what I wrote". Man that was sure easy to say. It's almost like saying nothing at all. Which is anyone's righ to do, but it's not an argument, nor a definition of terms, nor communication at all. Well, it does communicate one thing.

This:

> don't try to resolve any merge conflicts ... Don't try to "help". Don't fuck with the index or the worktree.

... certainly is "nothing" in the literal sense--that that's what is desired of git-merge to do, but it's not "nothing" in the sense that you're saying.

git reset --hard has nothing to do with merging. Nothing. They're not even in the same class of operations. It's absolutely irrelevant to this use case. And saying so isn't "not an argument" or not communicating anything at all. git reset --hard does not in any sense effect a merge. What more needs to be (or can be) said?

If you want someone to help explain something to you, it's up to you to give them an anchor point that they can use to bridge the gap in understanding. As it stands, it's you who's given nothing at all, so one can only repeat what has already been described--

A resolution strategy for merge conflicts that involves doing nothing: nothing to the files in the current directory, staging nothing to be committed, and in fact not even bothering to check for conflicts in the first place. Just notate that it's going to be a merge between two parents X and Y, and wait for the human so they have an opportunity to resolve the conflicts by hand (if they haven't already), for them to add the changes to the staging area, and for them to issue the git-commit command that completes the merge between X and Y. What's unclear about this?

Post reply on HN