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

231–240 of 330 posts

Re: The git history command

#231

Post by klibertp »

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 case, they are powerful. The problem is that they are too flexible, so Git interop relies heavily on convention and discipline... which is fatal. The fact that (almost?) all states of JJ are representable in Git makes it easy to mess up your remote, and then you need a very solid understanding of Git to fix it.

If you can give `jj` a try on a greenfield, single-developer project, you probably should. It feels exactly like Git felt compared to Subversion (when you focus on JJ's strengths and use it in favorable conditions - it is young, after all). Get acquainted with `jj` on its terms, and if things click for you, you'll be a bit better prepared for the bumpy road that is Git interop later on.

[1] https://news.ycombinator.com/item?id=48903054

Re: The git history command

#232

Post by smcameron »

plorkyeran wrote: post #105
what wrote: post #20

Earlier quoted context omitted.

You probably shouldn’t be committing things that are broken…

You should be committing things that are broken all the time. Git works great as a persistent navigatible undo buffer, and you should commit every time you're in a state that you might want to return to.

That breaks git bisect.

Re: The git history command

#233

Post by locknitpicker »

account42 wrote: post #215
locknitpicker wrote: post #93

Earlier quoted context omitted.

> That sounds like it would break bisect Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a…

And you can also use bisect by first figuring out the broken commit some other way and then marking everything as good if its before that one or bad if its after - but that's not a very productive use of bisect and if its the only available one I think its fair to call it broken.

> And you can also use bisect by first figuring out the broken commit some other way (...)

Bisect exists to be a tool you can use to fix the problems you are facing.

It you are faced by problems you create for yourself and you are unwilling to work around the problems you are creating then there is no tool on earth that can help you.

Re: The git history command

#234

Post by dooglius »

locknitpicker wrote: post #88
GrandfatherTECH wrote: post #72

Earlier quoted context omitted.

What's up with the fix commits? Maybe I misunderstood you, but there ain't nothing wrong in fixing stuff you offer in your PR. And there can also be multiple commits even before the PR while you're developing your PR.

> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…

Hence GP's advice,

> Just squash everything before merging and call it a day.

Re: The git history command

#235

Post by locknitpicker »

assbuttbuttass wrote: post #226
locknitpicker wrote: post #93

Earlier quoted context omitted.

> That sounds like it would break bisect Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a…

Suppose we have a failing test. For many commits, gp carefully separated their change that would break our test, from the change that would fix the test. At some point, someone forgot to run the tests, and introduced a commit that broke the test without adding a second commit to fix it. Now it's treated as a "pre-existing failure," and many more commits are added on top. How would you identify the commit that broke t…

> How would you identify the commit that broke the test?

You're asking how to use bisect.

You start with a range of commits you picked. All that bisect does is help you search for a commit within that range that introduces a regression. The responsibility to specify which commits you cover is yours, not the tool.

Re: The git history command

#236

Post by locknitpicker »

dooglius wrote: post #234
locknitpicker wrote: post #88

Earlier quoted context omitted.

> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…

Hence GP's advice, > Just squash everything before merging and call it a day.

OP's advice is bad and lazy. You want to have a coherent commit history with isolated changes.

See my reply here https://news.ycombinator.com/item?id=48903456

Re: The git history command

#237

Post by locknitpicker »

CuriouslyC wrote: post #191
locknitpicker wrote: post #149

Earlier quoted context omitted.

> Isn't this solved if you squash the commits when merging the PR? In theory, yes. Squashing is an extreme approach to merging fixup commits. It also throws the baby out with the bathwater by removing individual commits that explain and clarify how and why some changes were introduced as part or a PR. If your PRs are tiny and don't introduce major changes then squashing is ok. Instead, you should do the right thing a…

Making small atomic commits as you go in the age of AI tends not to go great because it forces too much human in the loop in a lot of cases, and the percentage of AI code rework is significantly higher than manual code, so the history tends to be harder to keep clean. It's ironically easier to create a messy agent work branch then have the agent cherry pick independent PRs from it into atomic commits post-work.

> Making small atomic commits as you go in the age of AI tends not to go great because it forces too much human in the loop in a lot of cases (...)

You seem confused. In the age of AI your ai code assistants already do task-specific commits. In fact, you can easily create a skill to have ai do that for you. It can even use git history split.

You see where this is going?

Re: The git history command

#238

Post by assbuttbuttass »

locknitpicker wrote: post #235
assbuttbuttass wrote: post #226

Earlier quoted context omitted.

Suppose we have a failing test. For many commits, gp carefully separated their change that would break our test, from the change that would fix the test. At some point, someone forgot to run the tests, and introduced a commit that broke the test without adding a second commit to fix it. Now it's treated as a "pre-existing failure," and many more commits are added on top. How would you identify the commit that broke t…

> How would you identify the commit that broke the test? You're asking how to use bisect. You start with a range of commits you picked. All that bisect does is help you search for a commit within that range that introduces a regression. The responsibility to specify which commits you cover is yours, not the tool.

And then bisect fails because it finds one of the many commits that broke the test before the actual regression

Re: The git history command

#239

Post by BigTTYGothGF »

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…

> creating a branch starting at the problematic commit

Code always lives in a context, and when you're fixing a problem that exists in top-of-main the context of the fix needs to be top-of-main, not some commit way back in history. Also if you do it that way, you'd better hope that no later commit also touches that same line.

> I then get people coming to me and complaining they can't merge

A team needs to agree on git practice in advance, and not have one wildcard go off and do their own thing.

Re: The git history command

#240

Post by LtWorf »

skydhash wrote: post #207
LtWorf wrote: post #127

Earlier quoted context omitted.

Most people who squash things have never used git bisect, cannot solve a merge conflict and when there is one will just delete the directory and clone everything again. I've worked with such people. They can go on like this for an entire lifetime.

For me (I know you used most, not all). A PR is an atomic thing. Either one bug or one feature. Commits inside it are mostly time snapshots, and fixing formatting and linting errors. If I where to properly present the PR, it will also have been a single commit.

Good for you that we don't work together, because for sure I'd reject all of your pull requests until you learn :D

This could probably be helpful https://mtlynch.io/code-review-love/

Post reply on HN