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

Git undo: We can do better

blog.waleedkhan.name

Post reply on HN
Print view View original

461–470 of 490 posts

Re: Git undo: We can do better

#461

Post by hassancf »

yarg wrote: post #220
alkonaut wrote: post #181

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like t…

There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and ga…

Can’t you create a branch from a commit that itself represents a branch? Is that no possible? What would it mean then to have a branch descend from a branch? I’m not sure I follow

Re: Git undo: We can do better

#462

Post by u801e »

npteljes wrote: post #410
u801e wrote: post #390

Earlier quoted context omitted.

Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.

My env doesn't do this. Here's what I did: git checkout -b test git push And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test" But in this situation, we actually push with "git push -u origin branchname". After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a pus…

Have you tried running:

  git push origin HEAD
In both Github and Github Enterprise, that command will create a branch with the same name on the remote.

Re: Git undo: We can do better

#463

Post by DangitBobby »

lmm wrote: post #436
DangitBobby wrote: post #342

Earlier quoted context omitted.

I try to make each commit a snapshot of a working repository (compileable or runnable or testable, whatever is the heuristic for working) where the difference between each snapshot can be explained by the commit message. Ideally they are isolated to a single logical "unit" of change (fix, refactor, add, remove). The goal here being to minimize the amount of confusion and work for anyone traveling up and down the tree…

Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through…

That's a very good point with rebasing. Thanks for explaining.

Re: Git undo: We can do better

#464

Post by Ensorceled »

lmm wrote: post #442
Ensorceled wrote: post #271

Earlier quoted context omitted.

I was replying to this part of your comment: > Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Seeking out that training would be useless since I don't use git enough. > Maybe git isn't the right tool for you? Git is definitely the tool for me. It's better than any other available tool f…

> Why the hell would I branch more? Just to get better at git? Sorry, I'm sorry that I work on a small team! Maybe I should go back to CVS? I have multiple branches on the go in a one-person project. I find that very useful. But if you don't, maybe you should go back to SVN? Using git without merging between branches seems like you're making your life complicated for no gain - like using a distributed system framewor…

I have multiple branches, we use gitflow (well modified). This isn't about branching, it's about what happens in the edge cases and how difficult git is when things go wrong.

The comment I'm replying to said "branch more" as if that would solve some kind of problem with edge case complexity.

Re: Git undo: We can do better

#465

Post by AlexSW »

cerved wrote: post #310
AlexSW wrote: post #282

Earlier quoted context omitted.

Agreed. I consider myself pretty competent at git (consistently helping out the rest of my team of ~15 people with it) and even then I've shot myself in the foot using `git checkout --` instead of `git reset` before to unstage a file, and lost all of my work on it. Really felt that should have given a warning.

use git stash instead to unstage changes not committed to the index and you'll never lose anything ever again

A bit late but for what it's worth I'm very familiar with `git stash` and use it all the time, and it's not clear how this helps my situation of aiming for one command and accidentally doing a very similar one but one which deletes work with no warning. For example, `git commit --` is a completely moronic way of deleting files, and I am baffled it took them so long to add aliases for it which have a coherent name.

Re: Git undo: We can do better

#466

Post by lisper »

lmm wrote: post #441
lisper wrote: post #48

Earlier quoted context omitted.

I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…

> 2. Git's merge is not smart enough to realize that identical changes in two branches are not actually a conflict. I've often ended up in situations where a small bug has been fixed in two branches which then won't merge without manual intervention. This is incredibly annoying. (To be fair, this is not unique to git. But because git encourages branching more than other systems, I encounter it more when using git in…

Yes, but to make that work you must do it for every change you want to make, even the most trivial. Find a typo while you're working on something else? You can't just fix it. You have to branch, edit, cherry pick, commit, and then push to make sure someone else doesn't find and fix the same typo. It's damned annoying because it would be so simple to fix: just tweak the diff algorithm to check if the conflicts are identical and auto-merge them if they are. How hard can that be?

Re: Git undo: We can do better

#467

Post by stormbrew »

zmmmmm wrote: post #350
stormbrew wrote: post #169

Earlier quoted context omitted.

like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/ ` (or really `refs/heads/origin/ `) is just a cached pointer to the last known state of tha…

so the distinction here is - origin master - origin/master <=== a local branch that you cached from the "origin master" remote, may or may not be in sync with the real "origin master"

yep, that's right. Or rather, origin and master are just two parameters given to pull/fetch/push to describe a target while origin/master is just the local name for, as you say, the locally cached ref.

Comparing against that locally cached ref is also what git uses to tell you how far behind/ahead of the upstream you are in `git status` or whatever. Fetch and push are the only git commands that actually talk to a remote (at the "user level" of the command set anyways, those are also composed of lower level commands).

Re: Git undo: We can do better

#468

Post by grogenaut »

seoaeu wrote: post #371
symlinkk wrote: post #308

Earlier quoted context omitted.

It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.

With other sorts of APIs you are given the choice between say the v1 version or the v2 version, with both endpoints being available at the same time. However, when it comes to command line programs for all practical purposes you can only have a single version installed at a time. And it of course doesn't help that essentially none of the existing scripts even check the versions of the software they run.

This is easily fixable with a new command or envvar.

This happens all the time

Re: Git undo: We can do better

#469

Post by meowface »

globular-toast wrote: post #459
lmm wrote: post #444

Earlier quoted context omitted.

> Your working directory is just like any other place on your filesystem. You can lose stuff if you do the wrong thing. Which means git is failing to do its whole job: keep the history of my work safe. I'd argue that git actually makes data on your filesystem less safe, because it pointlessly write-protects files in the .git directory, which encourages a bad habit of using rm -rf.

I've not once lost work in 15 years of using git. A bad workman always blames his tools.

A defender of a flawed tool always blames the user. (Steve Jobs's "you're holding it wrong".)

Re: Git undo: We can do better

#470

Post by stickfigure »

sam_lowry_ wrote: post #400
stickfigure wrote: post #265

Earlier quoted context omitted.

I was. But it wasn't quite as pointless as it sounds - the tool was a sort of tripwire-like system, with changes shipped to an append-only log, that itself was checkpointed in an early blockchain-ish structure. The threat model was "nation state actor" so the client wouldn't accept SHA1. It was actually a pretty cool system. I don't think it was ever sold though.

I do not remember jgit internals, but its API is pretty bad. I always assumed it was some kind of throwaway PoC suddenly turned popular.

> some kind of throwaway PoC suddenly turned popular

Wow, that description feels spot on.

Post reply on HN