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

11–20 of 330 posts

Re: The git history command

#11

Post by UnfitFootprint »

thfuran wrote: post #5
skydhash wrote: post #3

> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I think that only happens when you work on code as text files (i.e character streams) instead of code (i.e structured content with meaning). Like you have commit A and commit B that is in conflict, you…

Git is the one treating code like a text file instead of code.

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

Re: The git history command

#13

Post by bentt »

Granted, I have a perspective of a game dev, but this kind of repo defiling just gives me the willies. IMO instead of finding a common ancestor and altering it, just make the desired change upstream and merge it to where it’s needed. If you can’t do that then you have already made a deal with the devil and might reconsider your approach. KISS

Re: The git history command

#14

Post by seba_dos1 »

bulatb wrote: post #10
skydhash wrote: post #3

> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I think that only happens when you work on code as text files (i.e character streams) instead of code (i.e structured content with meaning). Like you have commit A and commit B that is in conflict, you…

I can fully understand a conflict, know it's coming, and fear it anyway because I'll have to deal with Git's behavior to fix it.

Such as?

When you merge a commit in that changed a file that has been already changed since the common ancestor, Git runs a tool of your choice on this file. If the tool fails, it marks the file as needing a merge and doesn't let you commit it until you unmark it to confirm that you have merged it manually. In case of octopus merges, it will just abort early. That's basically its whole behavior when it comes to conflicts.

Re: The git history command

#15

Post by jolmg »

catlifeonmars wrote: post #9
jolmg wrote: post #6

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze `git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.

Do you use git reflog?

One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.

Re: The git history command

#16

Post by shepmaster »

> That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch).

I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and update `B` to `B'`:

  A ──► B ──► C ──► D  
        │              
        └───► E
I'll end up with this state, where `E` remains untouched?

  A ──► B' ─► C' ─► D'  
  │                   
  └───► B ──► E
(EDIT: Originally I had `E` point to `B'`, which doesn't make sense)

If I use `git history fixup`, it would also update `E` and end up with this?

  A ──► B' ─► C' ─► D'  
        │              
        └───► E'
If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.

Re: The git history command

#17

Post by jolmg »

shepmaster wrote: post #16

> That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch). I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and upda…

> I'll end up with this state, where `E` remains untouched?

Can't, because a commit's hash takes into account the parent hashes.

Haven't used --update-refs, but reading it, it should result in your third graph. So,

> is there a way to get `git rebase` to have the same behavior?

is already the case.

Re: The git history command

#18

Post by rmunn »

catlifeonmars wrote: post #8
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.

What does it mean to split a branch in two?

Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch.

The existing workflow for that would be (there are several possible workflows, but this is what I would do):

  git checkout intermingled-branch
  git branch bugfix-A
  git branch bugfix-B
  git checkout bugfix-A
  git rebase -i
  # Edit the file, keep commits that fix bug A, drop commits that fix bug B
  git push origin bugfix-A:bugfix-A
  git checkout bugfix-B
  git rebase -i
  # Edit the file, keep commits that fix bug B, drop commits that fix bug A
  git push origin bugfix-B:bugfix-B

Re: The git history command

#19

Post by lelandfe »

shepmaster wrote: post #16

> That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch). I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and upda…

See: https://blog.hot-coffee.dev/en/blog/git_update_refs/
Post reply on HN