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

21–30 of 330 posts

Re: The git history command

#21

Post by rmunn »

jolmg wrote: post #17
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.

Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'.

Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.

Re: The git history command

#22

Post by jolmg »

rmunn wrote: post #21
jolmg wrote: post #17

Earlier quoted context omitted.

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

Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'. Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.

Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.

Re: The git history command

#23

Post by shepmaster »

jolmg wrote: post #22
rmunn wrote: post #21

Earlier quoted context omitted.

Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'. Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.

Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.

Ah, good catch. That's more of a graphic issue and not what I was trying to express. Updated the OP.

Re: The git history command

#24

Post by seba_dos1 »

hahahaa wrote: post #12

I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.

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.

Re: The git history command

#25

Post by rmunn »

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.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`.

I've almost never needed to run `get reset before-rebase`. But I have often done `git log -p before-rebase` and compared that to the post-rebase state of the branch, to ensure that the merge-conflict resolution(s) that came up during the rebase haven't accidentally introduced an unintended change.

Re: The git history command

#26

Post by shepmaster »

lelandfe wrote: post #19
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/

I'm not sure that answers my question. That shows a linear set of branches (my-feature-v3 depends on my-feature-v2 depends on my-feature-v1 depends on main). I'm asking about the case where two or more branches fork from a common ancestor and you want to fix the common ancestor.

Re: The git history command

#27

Post by skydhash »

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.

Git store whole files. The diff and the merge algorithm works by line by default, but that's because line is a rough unit of code (statement, expression, and definition happens mostly within one line).

Re: The git history command

#28

Post by bulatb »

seba_dos1 wrote: post #14
bulatb wrote: post #10

Earlier quoted context omitted.

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 confl…

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's going to mislead me.

None of that word salad should matter, but it does. Git will ruin everything with glee and there is always an excuse for why that's fine and it's the user's fault.

Re: The git history command

#30

Post by moezd »

what wrote: post #20
hahahaa wrote: post #12

I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.

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

With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch. Besides, aren't we all familiar with git commit -m "typo"?
Post reply on HN