Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git Branches: Intuition and Reality

jvns.ca

Post reply on HN
Print view View original

241–250 of 281 posts

Re: Git Branches: Intuition and Reality

#241

Post by silon42 »

chrismorgan wrote: post #66
keybored wrote: post #36

Earlier quoted context omitted.

Yup. “Storing moves” is the kind of thing that might sound intuitively obvious but then gets gnarly and non-obvious when you think about it for five minutes. And so something that might be “obvious” to do then turns out to be so non-obvious—how to catch all file moves (intent) outside of simple identitical content cases, and how do you represent them internally?—that you realize that just using snapshots is really th…

It’s completely trivial. The obvious and correct place is in the commit object just like author and date and such, since renaming is semantically part of the commit, not the tree: commit 0123456789abcdef0123456789abcdef01234567 parent fedcba9876543210fedcba9876543210fedcba98 author Nemo 1234567890 +0000 committer Nemo 1234567890 +0000 rename-from path1.old rename-to path1.new rename-from path2.old rename-to path2.new…

The problem with that scenario is that usually it doesn't support a real-world-scenario where you do a rename in the tool (like some IDE) and it doesn't do the corresponding git operation.

(yes, some IDE might have git integration, but personally I don't like my IDE messing with git, except read-only (annotate, diff))

Re: Git Branches: Intuition and Reality

#242

Post by gpderetta »

tharkun__ wrote: post #233
zie wrote: post #232

Earlier quoted context omitted.

aka Git is the simplest crappiest implementation that can work. Then they tacked a terrible UX onto it and shipped it. Chaos ensued and we as devs have spent the last almost 20 years fighting over trying to understand the chaos, we would have been way better off staying with SVN or Mercurial or Fossil(or pretty much any other VCS), but that ship has sailed and now we are stuck in the chaos. Now nobody understands the…

With all due respect, what a load of crap! SVN, branching that takes forever instead of a simple file with a commit hash in it? Are you serious? Mercurial, when I had to use it for almost 2 years? The single thing I missed the most is the fact that "everything is just a label" (or pointer if you will). Fossil I can't comment on with certainty, as I never really used it. This is probably gonna get voted into oblivion,…

> never close that terminal window. You might need that commit hash to reattach a label to it after you "destroyed" your branch

That's where the reflog comes handy.

Re: Git Branches: Intuition and Reality

#243

Post by chronial »

alex_smart wrote: post #156
tremon wrote: post #140

Earlier quoted context omitted.

git reset --hard is actually dangerous, because it throws away local modifications that were not yet committed. To undo just the commit and not the work, you should use git reset --soft (to undo just the git commit) or git reset --mixed (to undo both the git commit and the "git add"s leading up to the commit).

git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.

That's the reason why it was replaced by two separate, more sensible commands: git switch for switching branches etc, which is safe, and the inherently dangerous git restore for reverting changes in your working directory.

Re: Git Branches: Intuition and Reality

#244

Post by chronial »

afiori wrote: post #166
int0x80 wrote: post #133

Earlier quoted context omitted.

One thing that is risky about git reset --hard is that any non-committed changes are lost. That has bitten me a few times.

My controversial opinion is that git needs some kind of gui that help you keep track of the state of the repo

A very effective solution for that is a well-configured shell. IF you summarize the state of the repo in the prompt, it is always visible while typing a command.

Re: Git Branches: Intuition and Reality

#245

Post by thiht »

erik_seaberg wrote: post #196
MauranKilom wrote: post #60

I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash... How do you undo a merge that you didn't mean to do/did wrongly? git reset --hard Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature? git stash git checko…

Not a fan of the staging area, because it won't be tested. I would rather stash some changes to postpone them, then test and commit the workspace.

What does the staging area has to do with tests?

Re: Git Branches: Intuition and Reality

#246

Post by thiht »

MauranKilom wrote: post #60

I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash... How do you undo a merge that you didn't mean to do/did wrongly? git reset --hard Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature? git stash git checko…

I do that too (except I use a soft checkout instead of —hard, I prefer to review and delete the reset changes myself).

I tried using git worktree for a while when working on multiple branches, but it’s a pain to use… Stashing is easier.

Re: Git Branches: Intuition and Reality

#247

Post by alex_smart »

chronial wrote: post #243
alex_smart wrote: post #156

Earlier quoted context omitted.

git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.

That's the reason why it was replaced by two separate, more sensible commands: git switch for switching branches etc, which is safe, and the inherently dangerous git restore for reverting changes in your working directory.

It wasn't replaced, the other two commands were added to the cli.

It will take decades before git checkout will actually get replaced by git switch/restore in all the git books, tutorials and search results. Most normal users will keep learning and using git checkout in the meanwhile.

I understand why they can't actually deprecate existing commands. The git command is used in far too many existing shell scripts across thousands of companies.

I would argue that this is actually a fundamental deficiency of the "unix way" of doing things, where the same command is meant to be used both by human beings and in automated workflows. Automated workflows require backwards compatibility. Humans need easy to use interfaces that don't allow them to easily shoot themselves in the foot. The same tool cannot serve both needs.

Re: Git Branches: Intuition and Reality

#248

Post by alex_smart »

hnarn wrote: post #180
alex_smart wrote: post #156

Earlier quoted context omitted.

git checkout will also happily throw away local unstaged modifications, and I would argue that it is even more dangerous because I did not have to type "--hard" to shoot myself in the foot.

That does not sound right at all, I’m pretty sure there’s a warning when you try to checkout a branch that would override local unstaged changes. I might be wrong but I’d like some proof.

git checkout is overloaded and has two use cases. git checkout $branch is safe, git checkout $file_or_folder_name will help you shoot yourself in the foot.

Re: Git Branches: Intuition and Reality

#249

Post by cassianoleal »

jillesvangurp wrote: post #240
PaulDavisThe1st wrote: post #208

Earlier quoted context omitted.

> A git patch is just a textualized form of the list of commits you created locally. You can apply them to any branch you like. Not even branch. You can combine two unrelated repositories, and in theory you could cherry-pick commits from one of the original repositories to the other. Of course, in practice this rarely works because the files mentioned in the commit don't exist in the other repository. But there's not…

Git commits always have a parent. Applying git patches to a repository without the parent is not going to work. The repository must have the parent commit. You might force it to work without that but it's going to create conflicts, complicate merging, etc. The reason is that a git patch is not merely a diff but an export of the actual commit objects and referred content (trees, blob diffs, hashes, etc.). Applying the…

> Applying git patches to a repository without the parent is not going to work.

If that's the case (and I'm not saying it isn't - I really don't know), how does cherry-pick work?

I know I can cherry-pick commits in the same repo from entirely separate commit chains, where the only common ancestor is either my local HEAD or some other commit way below both of us.

Why would that not work for different repositories?

Re: Git Branches: Intuition and Reality

#250

Post by keybored »

bqmjjx0kac wrote: post #73
keybored wrote: post #57

Earlier quoted context omitted.

Git stores snapshots and that’s it. The whole tree, not per-file. As to why Linus doesn’t like storing file moves: https://public-inbox.org/git/Pine.LNX.4.58.0504150753440.721...

Man, he communicates like a dick all the time I guess.

He does argue in a borderline hysterical way on many occasions.
Post reply on HN