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

241–250 of 330 posts

Re: The git history command

#241

Post by kreco »

ninkendo wrote: post #200
kreco wrote: post #184

Earlier quoted context omitted.

There is no aggression. If your product has a reputation to confuse users compared to other products, your product confuses users. Let's not start to bend reality just to back up some narrative because after reading a N hours documentation everything is OK.

> If your product has a reputation to confuse users compared to other products, your product confuses users. Is your contention that all reputations are deserved, by definition? That’s certainly an interesting take. It leaves zero room for the concept of an “unfair reputation” for example. Maybe you should rethink your argument here.

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.

Re: The git history command

#242

Post by twister2920 »

ninkendo wrote: post #200
kreco wrote: post #184

Earlier quoted context omitted.

There is no aggression. If your product has a reputation to confuse users compared to other products, your product confuses users. Let's not start to bend reality just to back up some narrative because after reading a N hours documentation everything is OK.

> If your product has a reputation to confuse users compared to other products, your product confuses users. Is your contention that all reputations are deserved, by definition? That’s certainly an interesting take. It leaves zero room for the concept of an “unfair reputation” for example. Maybe you should rethink your argument here.

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?

Re: The git history command

#243

Post by steeleduncan »

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 top of Git rather than a new SCM.

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

Re: The git history command

#244

Post by twister2920 »

palata wrote: post #183
debugnik wrote: post #145

Earlier quoted context omitted.

They're replying to > The UI of git - for better or worse - directly reflects its internals.

> Half the git commands are low level, half are high level. Can't we say that the low level level commands reflect its internal? ...

of course we can, that's not what the original comment said though

Re: The git history command

#245

Post by BigTTYGothGF »

hackrmn wrote: post #211
nixon_why69 wrote: post #203

Earlier quoted context omitted.

> the value that Git provides -- branching (not just ephemeral branching for your local convenience). I think this is the disconnect. I could see big libraries maintaining branches for each major release and I understand why linux does it. But if I'm maintaining FooService at work then I actually do just want a linear graph of all the commits that have been in production, in commit order.

If you want that, mandate developers use prefixes like `!fixup` and do `git rebase` _on your end_ -- why force upon everyone your ideas especially if it also squashes all development history? This also removes development friction because people can work with Git on their end the way they like without regard to some convention that can be avoided -- save for the "!fixup" thing which can be considered useful metadata.

I want development history to be squashed. I want to have a nice clean `git log` that I can look back thru and not see a mess of 'WIP' and 'fix' and other noise.

Unless you're saving every keystroke from your editor you're already squashing history, we're just arguing about degrees.

Re: The git history command

#246

Post by twister2920 »

account42 wrote: post #219
ellefire wrote: post #137

Earlier quoted context omitted.

It's expensive when you factor in each PR having to wait for someone to come and review it - it's easier to get your work done in larger PRs when that's the case, although it's a perverse incentive

Even with low review turnaround, having each PR get to a defined "goal" makes it clear if the early commits that prepare the co-debase for the goal are going in the right direction. If they were submitted as individual PRs the reviewer can only check that they don't break things but has to trust the submitter that the design is right for what will follow.

easy solution is to design ahead of PR time

Re: The git history command

#247

Post by seanc »

quibono wrote: post #169

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around... Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day. Also: does anyone know if `magit` has history support?

Not as such, but out of the box you get reword and fixup as first-class rebase macros. I use them all the time.

If you wanted to split a commit you'd still have to use a magit-assisted rebase.

So if magit added explicit 'history' support I just about wouldn't notice, it would mostly be under the hood.

Re: The git history command

#248

Post by ninkendo »

twister2920 wrote: post #242
ninkendo wrote: post #200

Earlier quoted context omitted.

> If your product has a reputation to confuse users compared to other products, your product confuses users. Is your contention that all reputations are deserved, by definition? That’s certainly an interesting take. It leaves zero room for the concept of an “unfair reputation” for example. Maybe you should rethink your argument here.

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.

Re: The git history command

#249

Post by ninkendo »

kreco wrote: post #241
ninkendo wrote: post #200

Earlier quoted context omitted.

> If your product has a reputation to confuse users compared to other products, your product confuses users. Is your contention that all reputations are deserved, by definition? That’s certainly an interesting take. It leaves zero room for the concept of an “unfair reputation” for example. Maybe you should rethink your argument here.

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 dismissals with fallacious arguments. You can do better.

Re: The git history command

#250

Post by skydhash »

LtWorf wrote: post #240
skydhash wrote: post #207

Earlier quoted context omitted.

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/

The only point not addressed by reviewing changes at a PR level instead of a commit level is

  7. Break up large changelists
First a PR shouldn’t introduce scope screep, where you are actually introducing more than one change. And second.

  Instead of changing everything at once, can you change the dependencies first and add the new feature in a subsequent changelist? Can you keep the codebase in a sane state if you add half of the feature now and the other half in the next changelist?
When the only reason to change a dependency is for a new feature, you keep everything together. That way, we can revert a feature at once without needing to hunt down related commits. I abhor unused code in the main branch.

And I say that if you can’t review a PR as a single patch, there’s bigger problem. As a reviewer, the only thing that matters is the change and its purpose, not a particular workflow/ritual.

Post reply on HN