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

271–280 of 490 posts

Re: Git undo: We can do better

#271

Post by Ensorceled »

lugged wrote: post #130
Ensorceled wrote: post #126

Earlier quoted context omitted.

At one time I was an expert in 'C'. I was the goto guy at our company for porting and performance issues and was often just handed the entire project if it involved porting. I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.

I don't know what to tell you, commit more code? Branch more? Work in teams? Maybe git isn't the right tool for you? I have a set of commands I use multiple times a day, for everything else there are manuals and docs to reference. Git branch, commit, rebase, merge, clone, check out, pull, push, submodule, remote, and maybe a couple more, are there specific commands you don't use daily? Other than remote and submodule…

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 for my situation.

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?

Stop gate keeping.

Re: Git undo: We can do better

#272

Post by rileymat2 »

cerved wrote: post #251
saiojd wrote: post #112

Great work. I wish usability/ergonomy was taken more seriously for popular tools that everyone uses (like git). Another stupid pain point with git is the inability to commit empty directories. I mean, come on.

Git takes stability and extensibility seriously. Your demands and expectations on version control may be radically different from mine. Empty directories do not contain files or information, it's entirely reasonable for a VCS to omit such a feature. Not sure which use case for git is hindered by the inability to check-in empty directories. I would even suggest such a use-case may be a case of DIW

The use case it frustrates me in is when you want to work on the structure of the repository before you have all the code.

For instance, it is nice to think about the repo holistically sometimes before I have say an actual unit test to put in the directory, it is nice to create that structure in the repo.

Re: Git undo: We can do better

#273

Post by riquito »

Vinnl wrote: post #261
cerved wrote: post #242

Earlier quoted context omitted.

Git checkout branch means change the entire working tree to the reflect the state of the branch and git checkout file, checkout the state of that file in HEAD. Both commands to the same thing, change the state of your working tree to reflect a point checked into version control. It sounds like you are unaware of git switch branch and git switch -c new-branch

Just a tip: when teaching people, the readable alias is easier to remember and understand, i.e. git switch --create new-branch

It was a good example: it was obvious by the name of the branch and he/she was teaching the real word use case

Re: Git undo: We can do better

#275

Post by dorian-marchal »

stormbrew wrote: post #169
fierro wrote: post #146

Earlier quoted context omitted.

can you explain the `git pull origin master` thing one more time here?

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…

Also, one advantage of `git pull origin master:master` is that you don't have to checkout master first.

Re: Git undo: We can do better

#276

Post by marcosdumay »

zibzab wrote: post #50
sebmellen wrote: post #28

Earlier quoted context omitted.

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know

That is solely because of network effects. Anyone of them could be the popular one, as could any of the weirder ones like darcs, even it having technical flaws (mostly fixed by now).

Re: Git undo: We can do better

#277

Post by spicybright »

idoubtit wrote: post #61
Simplicitas wrote: post #2

This is an awesome idea. Can't wait to hear the objections from the purists.

I've watched the first case: amend a commit then undo. And I believe it shows serious shortcomings : - The interactive interface of `git undo` is probably too hard for beginners. Designing simple interfaces is hard, and you can't pplease everyone. - It seems `git undo` simply does a `git reset--hard` toward a designed commit. The user probably expected to return to the state before the last git action . Instead `git…

Why is it so hard to implement a git undo? You have a previous state, and a current state. Just roll it back.

Re: Git undo: We can do better

#278

Post by FractalHQ »

daxelrod wrote: post #178
nexuist wrote: post #151

Earlier quoted context omitted.

The problem is just that collaborative text editing between multiple users simultaneously is hard. It's a human problem and git attempts to be a technical solution but the abstraction fails at the edge cases. Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this hap…

I agree that collaborative text editing between multiple users simultaneously is hard. That doesn't mean that Git couldn't have a much better UI for this problem than it does. And while I agree that Git seems to have mostly won over SVN and Hg, it doesn't follow that it's because of its UI. (For example, I think that a lot of Git's success actually comes from the UI of GitHub, not Git itself, but I don't have evidenc…

Wow. Reading the home page of gitless made me both excited to use it and angry at how poorly designed git’s UI and UX are. Thanks for sharing this!

Re: Git undo: We can do better

#279

Post by dorian-marchal »

cerved wrote: post #224
atoav wrote: post #163

Earlier quoted context omitted.

I really would wish git would embrace the idea of not destroying any data unless specifically prompting for it first. Same for merging pull requests. How hard would it be to again prompt in case of conflict how to proceed?

Commits are immutable, itś incredibly hard to destroy data that has been committed. Even if they become loose objects, Git is very conservative when it comes to deleted that. If you have uncommitted data, git will refuse to do lots of operations. The default is always to not delete changes, even if resetting a branch. Contrast that with TFVC which tries its best to nuke everything within it's reach (that is not under…

Unfortunately, it is still very easy to lose data, e.g. by trying to undo a temporary commit with `git reset --hard HEAD^` (note the --hard option) before committing your changes.

Re: Git undo: We can do better

#280

Post by ryanmentor »

ethbr0 wrote: post #199
stormbrew wrote: post #105

Earlier quoted context omitted.

definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin m…

> levels of state This is the crux for me. Command naming is completely unrelated to and unindicative of state. It feels like surely there's an opportunity for the basic CRUD operations to be collapsed down into a standard "{action} {source} {target}" style. There will be nuances, specifically around branching, but the basics should be basic. As opposed to a Swiss Army knife, where you have to pull out the scissors a…

Are there any git frontends that do this today?
Post reply on HN