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

41–50 of 330 posts

Re: The git history command

#41

Post by seba_dos1 »

hahahaa wrote: post #38
seba_dos1 wrote: post #24

Earlier quoted context omitted.

Commit graph is just a data structure. Sometimes it represents a "history", sometimes other things. Personally, I like it when project's repository represents the history of the project rather than the history of random things developers do on their machines, but you do you.

I am thinking of remote. Edits before pushing OK with me (they ate equivalent of recloning and redoing anyway)

Remotes aren't equal either. Sometimes the remote is my other machine, sometimes it's a fork on a forge used for producing CI artifacts.

It's a good rule of thumb to consider shared branches to be append-only, but not every remote branch is "shared" and, as with any proper rule of thumb, you can always find exceptions.

Re: The git history command

#42

Post by _nivlac_ »

I like `git history reword`, would've found that useful in the past (e.g. fixing a bad typo in an older commit).

It sounds like there was probably an equivalent using an existing command but this is easier for me to understand. Thanks for sharing!

Re: The git history command

#43

Post by paxys »

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

Re: The git history command

#44

Post by bulatb »

seba_dos1 wrote: post #32
bulatb wrote: post #28

Earlier quoted context omitted.

Such as moving down a fixup during interactive rebase when it's going to conflict with parents, or I've added more commits mid-rebase, or the rebase started in a tool and now I need to think about the tool's command and understand how many times the rebase point is view is backwards to interpret which is "ours" and which is "theirs" and whether it's the tool, my editor, or my own experience I should ignore because it…

There's nothing "backwards" in "rebase point of view". It's just automated cherry-picking - it's like applying patches, it's as forwards as it gets. People who think it's "backwards" usually just have holes in their mental model of the repository. And yes, I find tools doing what you're asking them to do to be rather fine. In fact, Git makes it easy to notice when you're adding commits mid-rebase, which is something…

I understand how rebase works and use it many times a day. Thanks for trying to explain but I won't respond further.

Re: The git history command

#45

Post by seba_dos1 »

bulatb wrote: post #44
seba_dos1 wrote: post #32

Earlier quoted context omitted.

There's nothing "backwards" in "rebase point of view". It's just automated cherry-picking - it's like applying patches, it's as forwards as it gets. People who think it's "backwards" usually just have holes in their mental model of the repository. And yes, I find tools doing what you're asking them to do to be rather fine. In fact, Git makes it easy to notice when you're adding commits mid-rebase, which is something…

I understand how rebase works and use it many times a day. Thanks for trying to explain but I won't respond further.

These aren't troubles of someone who understands. If anyone else reading this has these kinds of troubles too - don't worry, understanding abstractions takes time and effort, you'll get there eventually (not if you'll keep blaming others though).

Re: The git history command

#46

Post by jolmg »

paularmstrong wrote: post #7

`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.

Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the changes of the other PR so they should review that one first. Should they want to add changes to the first feature, they just need to checkout that branch, do the changes, and merge to the second feature branch so they're available there.

Re: The git history command

#47

Post by jolmg »

paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

> No one is ever going back and reading individual commits.

Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.

Re: The git history command

#48

Post by seba_dos1 »

paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

Of course we do and it helps tremendously when the graph is reasonable.

Re: The git history command

#49

Post by Myrmornis »

paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

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

Re: The git history command

#50

Post by [deleted] »

rmunn wrote: post #37
jolmg wrote: post #34

Earlier quoted context omitted.

> but branches can be moved around with less ceremony than tags `git tag -f` to move a tag. Personally, I just do `git show` when I'm feeling cautious, but I can generally just scroll up to find the last `git commit` I did with the hash in the output. `git reflog` should also have record of it, so everything else is kind of extra.

Good point, that's no more ceremony than moving a branch. I guess I've just gotten "branches are movable tags" so deep into my hindbrain that I absorbed "tags are hard to move". But that's not actually true, and for what I'm doing (save this point in history for a while) a tag makes slightly more sense, semantically, than a branch.

[deleted]
Post reply on HN