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

The git history command

lalitm.com

Post reply on HN
Print view View original

251–260 of 330 posts

Re: The git history command

#251

Post by Someone »

bad_username wrote: post #129

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

> The UI of git - for better or worse - directly reflects its internals.

I disagree. For example, we have, from “git checkout —help”:

   git checkout has two main modes:

   1. Switch branches, with git checkout 

   2. Restore a different version of a file
The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals?

(And of course, there are many inconsistencies in the CLI that do not have to do with git internals that, even if you know what you want to do internally and which command to use, make figuring out the CLI incantation to do it harder than needed. That’s a different subject, but still contributes to “git is difficult to use”)

Re: The git history command

#252

Post by skydhash »

ozim wrote: post #229
bonzini wrote: post #133

Earlier quoted context omitted.

Nope. Perfectly curating history is indeed the opposite of squashing—you squash because you couldn't be bothered to curate your commits. Squashing is a workaround not an alternative solution.

You just contradicted your previous comment that was pointing out that fcraaldo is „spending effort in perfectly curating history” … or your comment was a joke with no indication it is a joke.

Yep, the curated history is the main branch, which the PR targets. The commit log in the Pr reflects the workflow of the author, which I have no interest in. As the reviewer, I’m only interested in the content (the description and the composite diff of the whole PR). I don’t review commit by commit.

Re: The git history command

#253

Post by klibertp »

steeleduncan wrote: post #243
klibertp wrote: post #231

IME, the only real pain point with JJ is Git integration. I love it, it's great in almost everything it does. Formalizing all the DSLs and using them consistently throughout the config and CLI is exactly how filesets, revsets, and templating should be implemented. The focus on exposing concepts as interfaces (without "directly reflecting internals"[1] in the UI) is only as good as the concepts themselves, and in JJ's…

In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now. I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on…

The backend itself is fine, it's just trying to use JJ as a Git frontend for projects developed on Github (among 20 other devs using git, where each of them uses git through different interface and/or in different style) that's currently not ideal :(

> However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM.

Yeah, but I think that's fine. Git is a solid foundation; it's not wrong to try to build on it initially. It gets you a usable implementation faster. It is a pain point, though.

> If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more.

Is that a danger? I don't see Git as a fast-moving target. And among all the "convenient wrappers on top of Git", JJ seems to have the design least tied to Git, so I think it has the highest chance of breaking out of the Git dependency in the future.

Re: The git history command

#254

Post by andawaywego »

hackrmn wrote: post #179
Hendrikto wrote: post #171

Earlier quoted context omitted.

Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.

My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentia…

can you elaborate what concrete value you've managed to extract from doing things like this? my gut reaction is that any benefit would be overshadowed by multiplying effort for other team members to catch up on their work, and if it makes it harder to work when even one person does it I can't imagine it scaling on a full team (or worse, something like a monorepo)

Re: The git history command

#255

Post by Myrmornis »

assbuttbuttass wrote: post #56
Myrmornis wrote: post #49

Earlier quoted context omitted.

One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).

That sounds like it would break bisect

You could reorder so that the test comes in a commit after the fix rather than before if you want to be able to use plain git bisect, so that no commits are failing. The important thing is that you can use git (i.e. revert in this case) to edit the history to remove the fix and verify the test fails.

Re: The git history command

#256

Post by kreco »

ninkendo wrote: post #249
kreco wrote: post #241

Earlier quoted context omitted.

You are moving the goalposts. I could show you thousands of message backing up the confusion. But you can keep nitpick irrelevant part of messages and pretend you are very smart.

You've made one and only one point in this thread so far: I'm addressing only that point. You've provided no other elaborations. You're saying "it has a reputation for being confusing, therefore it is confusing." That's a bullshit statement, IMO. If you made any other elaborations on why you disagree with the post you were arguing against, we'd have something else to discuss. But right now you're just posting shallow…

> You've made one and only one point in this thread so far: I'm addressing only that point. You've provided no other elaborations. You're saying "it has a reputation for being confusing, therefore it is confusing." That's a bullshit statement, IMO.

I'll repeat myself, I can show you thousands of messages point out how git is confusing. I can show you plenty of message saying "I used X it was fine, but I used git and it's cumbersome", please show me the same amount of messages telling "I used git it was fine, but I used XXX and it's cumbersome."

Re: The git history command

#257

Post by klibertp »

NateEag wrote: post #131
UnfitFootprint wrote: post #11

Earlier quoted context omitted.

I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter

Don't forget mergiraf, for tree-sitter-based conflict resolution: https://mergiraf.org/

I absolutely love the images on the landing page. "Inappropriate use of blame, push and pull to resolve a conflict" is pure genius. Even the name had a lot of thought put into it (didn't know about "Giraffe language" before). Beautiful! :)

Re: The git history command

#258

Post by andawaywego »

xeyownt wrote: post #182
kreco wrote: post #180

Earlier quoted context omitted.

> Git is not nearly as confusing as people make it out to be. The people are confused, it's a fact. So it is confusing. Stop gaslighting people.

If you ignore gravitation, a sphere earth can be very confusing.

plenty of models do fine with assuming a flat earth. git is an incredibly competent swiss army knife for building VCS but I'm not convinced it's the best we can ever do (nor we have ever done) for the simple linear history we expect from your usual corpo crud.

Re: The git history command

#260

Post by kreco »

ninkendo wrote: post #248
twister2920 wrote: post #242

Earlier quoted context omitted.

do you think everyone who claims to be confused by git is making it up? or do you just think you're better than them?

I've elaborated on why I think git's reputation is undeserved in sibling comments. kreco's contention is that "it has a reputation of being confusing, therefore it is confusing", which I think is bollocks. They're throwing accusations of "gaslighting" around. It's valid to think "yes it has a reputation for being confusing, but much of it is undeserved". It's not black-and-white.

> "yes it has a reputation for being confusing, but much of it is undeserved"

This is not what is written here:

> Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer.

> just does not cut it, if you call yourself a professional.

Post reply on HN