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

171–180 of 184 posts

Re: I made my own Git

#171

Post by eru »

alphabetag675 wrote: post #31
eru wrote: post #30

> These objects are also compressed to save space, so writing to and reading from .git/objects/ will always involve running a compression algoritm. Git uses zlib to compress objects, but looking at competitors, zstd seemed more promising: That's a weird thing to put so close to the start. Compression is about the least interesting aspect of Git's design.

When you are learning, everything is important. I think it is okay to cut the person some slack regarding this.

Yes, probably.

It's just that git does a much more interesting job with compression, actually. Lot's more to learn. They don't compress the snapshots via something like zstd directly, that comes much later after a delta step. (Interestingly, that delta compression step doesn't use the diffs that `git show` shows you for your commits.)

Re: I made my own Git

#173

Post by kbolino »

pwdisswordfishy wrote: post #170
Brian_K_White wrote: post #163

Earlier quoted context omitted.

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 cas…

I think this is what you want:

  git merge -s ours --no-ff --no-commit
This will initiate a merge, take nothing from the incoming branch, and allow you to decide how to proceed. This leaves git waiting for your next commit, and the two branches will be considered merged when that commit happens. What you may want to do next is:

  git checkout -p
This will interactively review each incoming change, giving you the power to decide how each one should be handled. Once you've completed that process, commit the result and the merge is done.

Re: I made my own Git

#174

Post by evntdrvn »

gxnxcxcx wrote: post #86
evntdrvn wrote: post #73

Earlier quoted context omitted.

There was a really great article or blog post published in the last few months about the author's very personal experience whose gist was "People complain that I sound/write like an LLM, but it's actually the inverse because I grew up in X where people are taught formal English to sound educated/western, and those areas are now heavily used for LLM training." I wish I could find it again, if someone else knows the li…

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

Thank you!!! :)

Re: I made my own Git

#175

Post by tverbeure »

cozzyd wrote: post #157
tverbeure wrote: post #149

Earlier quoted context omitted.

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...

No, that would be "in the hat."

Re: I made my own Git

#176

Post by [deleted] »

pwdisswordfishy wrote: post #170
Brian_K_White wrote: post #163

Earlier quoted context omitted.

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 cas…

[deleted]

Re: I made my own Git

#177

Post by seba_dos1 »

pwdisswordfishy wrote: post #170
Brian_K_White wrote: post #163

Earlier quoted context omitted.

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 cas…

You know that you can edit your merge commits any way you want and you don't have to rely on resolution strategies to do it for you, right?

Re: I made my own Git

#178

Post by [deleted] »

kbolino wrote: post #173
pwdisswordfishy wrote: post #170

Earlier quoted context omitted.

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 cas…

I think this is what you want: git merge -s ours --no-ff --no-commit This will initiate a merge, take nothing from the incoming branch, and allow you to decide how to proceed. This leaves git waiting for your next commit, and the two branches will be considered merged when that commit happens. What you may want to do next is: git checkout -p This will interactively review each incoming change, giving you the power to…

[deleted]

Re: I made my own Git

#179

Post by Guvante »

nasretdinov wrote: post #167
Guvante wrote: post #161

Earlier quoted context omitted.

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 freq…

Honestly if the tooling were better at keeping upstream on the left I wouldn't mind as much but IIRC `git pull` puts your branch on the left which means walking history requires analysing each merge commit to figure out where history actually is vs where a temporary branch is.

That is my main problem with merge, I think the commit ballooning is annoying too but that is easier to ignore.

Re: I made my own Git

#180

Post by pwdisswordfishy »

seba_dos1 wrote: post #177
pwdisswordfishy wrote: post #170

Earlier quoted context omitted.

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 cas…

You know that you can edit your merge commits any way you want and you don't have to rely on resolution strategies to do it for you, right?

Right. That's the entire basis for the discussion here. So why is this a question?
Post reply on HN