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

Git Undo

megakemp.com

Post reply on HN
Print view View original

41–50 of 175 posts

Re: Git Undo

#41

Post by oblio »

panic wrote: post #38

I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all using a better frontend by now.

It's the "boil the oceans" problem (http://www.urbandictionary.com/define.php?term=%22boiling%20...). Same thing that happens with vi, for example.

You have a widely adopted tool with some real or perceived flaws. Everybody knows them and wants to fix them.

But unless you somehow get mass adoption from the start, the project flounders because everyone will be pointing out that you can't install & use the new tool in restricted environments or on very old environments.

So we're left with the lowest common denominator.

At this point, to break the cycle, either the original developers come with the 2.0 interface and push it hard (which might cause backlash: https://xkcd.com/1172/) or someone with a ton of pull and resources does it from outside (which could trigger a fork or other unpleasantness).

Re: Git Undo

#42

Post by chriswarbo »

angry-hacker wrote: post #35
chriswarbo wrote: post #33

Earlier quoted context omitted.

There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.). I agree with you, that history should be left alone; mostly I think of th…

But what good does it have for future devs if the history is -- Added this thing -- Fixed typo -- Capitalized the letter Etc.

One important reason is to avoid wasting time on gilding lilies.

Another reason is that the git information (e.g. from git blame) tells us when the code was written and in what order, rather than some post-hoc rearrangement.

For example, we might notice that code X is doing some tricky work which elsewhere is done by a helper function Y. We look at the git info and see that X was added after Y, so we try to figure out what special edge-cases X is trying to deal with that Y wasn't suitable for. Little do we realise that X was actually written before Y existed, but the commits got rearranged.

That kind of archeology is difficult to predict in advance (mostly because, if we realised all of the issues with our code beforehand, we'd fix them immediately!).

Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them. In fact, they might have access to much smarter tools and IDEs than we do.

Re: Git Undo

#43

Post by Cthulhu_ »

panic wrote: post #38

I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all using a better frontend by now.

One can argue semantics whether you call it a UI or a CLI, but hey. There's a number of GUI clients out there that depending on your criteria could be considered better. They're usually not as powerful as the CLI client though, and if they are, features like accessing the reflog are hard to find and use. There's also a few alternative CLIs out there, I've just done a quick googling and came across http://www.saintsjd.com/2012/01/a-better-ui-for-git/ and http://www.kennethreitz.org/essays/legit-the-sexy-git-cli.

Personally I prefer the CLI, it's the only tool that I can rely on to do what I tell it to do and to know what's happening. But it takes time and effort to get used to it.

Re: Git Undo

#44

Post by Dylan16807 »

rjbwork wrote: post #19

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

What does accurate history mean?

Do you commit after every 20 seconds of typing?

Why not?

The people cleaning up history have the same motivation.

Re: Git Undo

#45

Post by Cthulhu_ »

chriswarbo wrote: post #33
rjbwork wrote: post #19

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.). I agree with you, that history should be left alone; mostly I think of th…

I think a solid middle ground can be found. By focusing on making clean commits, instead of being tempted to make "whoops fixed" commits, you will become a better developer and your code will be cleaner. And your history, too.

At the very least, review your commits and clean then up before pushing - merge 'fix' commits if you didn't --amend them and review commit messages. What the commit does should be obvious from the subject.

I've also seen people write git commits as if they were a work log - things like "fixed a bug", or "implement feature X". That's the wrong way (IMO) to do git history, what the comment should say is what the /commit/ does, not what you did.

There is no I in programmng.

Re: Git Undo

#46

Post by panic »

Mchl wrote: post #13
richardwhiuk wrote: post #11

I worry about naming a function undo that doesn't necessarily undo what the user expects. Undo has a strong user expectation, and I'm not convinced this matches that.

Git already has `git branch` which doesn't in fact do any kind of branching but creates a label which follows commits when it's checked out.

Git also has 'git revert' which creates a new commit, 'git reset' which actually reverts (among other things), 'git checkout' which switches branches... the fact that all the other commands are confusing doesn't mean this new one has to be.

Re: Git Undo

#47

Post by p4bl0 »

phaemon wrote: post #37
p4bl0 wrote: post #28

I have this alias in my ~/.gitconfig: cancel = reset --soft HEAD^ I don't want an alias to hard reset, it seems to dangerous and a good way to lose some work. However a soft reset like this allow me to cancel the last commit and add an omitted file, or remove one from the commit, or simply to correct the commit message easily.

Actually, if that's all you want, you can do: git add # or "git rm --cached " to remove git commit --amend and it will replace with a new commit that has what you want. It's like a mini rebase -i

True, but I prefer to be able to see my staged changes as a whole to be sure that I did everything as I wanted.

Re: Git Undo

#48

Post by Dylan16807 »

chriswarbo wrote: post #42
angry-hacker wrote: post #35

Earlier quoted context omitted.

But what good does it have for future devs if the history is -- Added this thing -- Fixed typo -- Capitalized the letter Etc.

One important reason is to avoid wasting time on gilding lilies. Another reason is that the git information (e.g. from git blame) tells us when the code was written and in what order, rather than some post-hoc rearrangement. For example, we might notice that code X is doing some tricky work which elsewhere is done by a helper function Y. We look at the git info and see that X was added after Y, so we try to figure ou…

>Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them.

The ability of devs to collapse a bunch of commits into a useful summary is near zero right now. You can only achieve it by rewriting history. Unless you think that feature is going to be commonplace very very soon, there is a compelling reason to lie.

Re: Git Undo

#49

Post by yoavm »

rjbwork wrote: post #19

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

I never had the urge to rewrite the history of my code until I started using CI & CD. Since then, it happened to me few times that I wanted to fix something small and ended up trying multiple times, pushing a new "maybe this time?!" commit over and over again. Obviously it's not best practice, but it something you do when there's a rush.

Having 10 tiny commits like that are just failed attempts to fix a bug isn't practical. It makes reading and understanding your repository code _harder_. Git rebase helps me keep my log clean and understandable, thus making it something I can work with in the future.

Re: Git Undo

#50

Post by k__ »

mikekchar wrote: post #30
rjbwork wrote: post #19

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

It's just a way of looking at it. Let's say I'm in charge of a project. You send me a patch. I commit the patch. What I want in my history is that I committed your patch. I really don't care what you did in your history to create that patch. But it's equally valid to consider all your commits important in my history as well. It just depends on what you want. Personally, I never rebase, but I can understand why some p…

That's what I find hard with contributing to OSS often.

Many devs are happy with what you send them... as long if the history is right!

And right seems totally random to me.

Most are happy if you simply send them "one commit", but tell you to merge multiple commits before they accept it.

Others say "lets split this or that" before they accept it.

Then I have to go back and fiddle around with Git just to get my change landed...

Post reply on HN