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

71–80 of 175 posts

Re: Git Undo

#71

Post by rck404 »

Cthulhu_ wrote: post #43
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…

I prefer git CLI mostly, except for merge conflicts. Exclusively for git merge conficts I use IDEA IDE resources. Otherwise CLI is my friend because I feel safe (git push and git commit have the best color-coded messages in most OSes)

Re: Git Undo

#72

Post by sethammons »

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?

In my opinion, it is only valuable to present a pristine history to make sure that every "official" commit provides an application that can be ran. This allows git bisect to do amazing things. In other words, I will git merge --squash. When someone rewrites history after pushing, all they do is make everyone else have a bad day.

Re: Git Undo

#73

Post by dan00 »

m_mueller wrote: post #64
dan00 wrote: post #57

Earlier quoted context omitted.

I don't think that 'git undo' can tell with certainty which entries in the reflog are from it. It would be a crude heuristic that's going to break.

Is there maybe a way to annotate the commit message of HEAD without influencing the reflog?

You can't change the commit message of a commit without changing the commit, which in most cases is a bad idea, if you don't know pretty much exactly what your doing.

Replacing one heuristic with another won't make this a stable operation.

A lot of people had already the idea to encode relevant information inside of documentation and it was always a bad idea in the long run.

Re: Git Undo

#74

Post by atsaloli »

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.

I teach Git. I find many who have learned just enough to get by, and their shallow understanding hobbles them.

It's not enough to memorize command line "incantations", you have to understand what's happening.

Git is a sophisticated tool. There are over 100 subcommands!

Once you fully understand the basic terms (e.g., "detached", "HEAD", "branch", "commit", etc.) Git becomes less confusing.

http://www.verticalsysadmin.com/git/flyer.html describes a free webinar we offer on Git basics -- people who have used Git for years come away surprised how much they've learned.

Re: Git Undo

#75

Post by recursive »

yoavm wrote: post #49
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 pra…

I'm using CI and CD. If I want to find out if I've fixed a bug, I just run the build locally before pushing.

Re: Git Undo

#76

Post by recursive »

minitech wrote: post #54
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.

The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel free to use them, but that’s certainly not everyone.

I was at least a little confused by stage for a while. I still think the distinction between stage and commit is unnecessary at best.

Re: Git Undo

#77

Post by gwright »

gwright wrote: post #60
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?

Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers…

One clarification: amend, reset, rebase and their ilk don't 'manipulate the commit tree' other than adding commits. The manipulation is with the branch names associated with the commits.

I've always hated the common description of 'rebase' as 'rewriting history'. None of the existing commits are modified by rebase, new commits are added and the branch names are shuffled around.

Re: Git Undo

#78

Post by biehl »

gwright wrote: post #60
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?

Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers…

My two main arguments for "cleaned up history" are

1) Reviews are much more enjoyable when the commits reflect the final understanding of the problem rather than false starts etc.

2) Looking back through history is much more enjoyable when the commits reflect the final understanding of the problem rather than false starts etc.

Re: Git Undo

#80

Post by gwright »

biehl wrote: post #78
gwright wrote: post #60

Earlier quoted context omitted.

Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers…

My two main arguments for "cleaned up history" are 1) Reviews are much more enjoyable when the commits reflect the final understanding of the problem rather than false starts etc. 2) Looking back through history is much more enjoyable when the commits reflect the final understanding of the problem rather than false starts etc.

I agree 100%. In my mind the 'stable point' I mention above isn't reached until after the review process is complete and any recommend changes are applied, which often involves fixups, merging commits, splitting commits, re-arranging commits, and so on.
Post reply on HN