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

161–170 of 175 posts

Re: Git Undo

#161

Post by u801e »

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…

> My repo histories are riddled with stuff like "finished X", "stubbed out Y", "fix typo in X"

Where I work, our commits from years ago are like that, and since practically all the people from that era have moved on, the history is practically useless when trying to determine what they were working on and why they were working on it.

In fact, I found what appeared to be a logical error in one of the many tools we have deployed. I tried to track down when it was added and the commit just said something like "fixing integration tests".

So, not only did they change some tests, but they also added some code as well.

In other words, the reason that line of code was added is very well hidden from this "future" (now present) dev.

Re: Git Undo

#162

Post by eridius »

gwright wrote: post #158
eridius wrote: post #152

Earlier quoted context omitted.

Given that commits are immutable objects, the only sane interpretation of "rewriting history" is that it rewrites your view of the history rather than somehow rewriting immutable content-addressed objects.

Sure, but lots of people using git don't really understand that commits are immutable or that the commit tree is an append-only data structure. The pervasive use of the phrase 'rewrite history' hinders this understanding.

I disagree. I've used Git for a long time, and talked to a lot of Git users, and I've never seen anyone say something that implied they thought they were literally modifying the commit objects, as opposed to rewriting the history of a branch.

Re: Git Undo

#163

Post by krupan »

minitech wrote: post #155
krupan wrote: post #133

Earlier quoted context omitted.

But why stage when you can just commit? You can use rebase -i to modify that commit later if you need.

You might not want to commit all of your changes at once.

commit can be followed by a file name. Or there is commit --interactive or commit --patch to choose what to commit (or git add versions of those).

Re: Git Undo

#164

Post by m12k »

nolemurs wrote: post #129
m12k wrote: post #100

Earlier quoted context omitted.

There can definitely be value in e.g. summarizing the final result and understanding after a number of 'failed' iterations. And that the many small commits can be considered "noise" if you only care about what happened at a high level. However, rewriting history with operations like squash or rebase IMO seems like a bad solution to a real problem - it really shows that we don't yet have the right abstractions or tool…

So, here's a question. I make a commit to implement a feature, then I realize there's a bug in my implementation, so I fix the bug, and then squash it into a single commit. What is the scenario where anyone is going to be perusing the history and he'll actually want to know about that bugfix? What's the actual value in that intermediate commit? Other than seriously contrived scenarios I can't think of any of the "leg…

Let's imagine for a second that the bug-fix you make isn't perfect. Maybe you ought to have refactored something a bit more instead. Maybe you made the bugfix a couple days after making the main feature commit, and you'd forgotten some detail. At any rate, half a year later someone has to sit down and figure out why the code is behaving weirdly sometimes. If you've got an accurate history of how the code was written, they'll have an indication that the code from the bugfix was added post-hoc, and might be inclined to investigate here. They'll understand that all these lines of code were not written at once, so the ones in the bugfix are more likely not to be fully cohesive with the rest of them.

Sure, in the happy case where your code is perfect, all those extra commits are just 'noise'. But when debugging, there can be value in the forensic information about the evolution of the code. Which also documents the evolution of the understanding of the person that wrote it. It can help answer questions like "why is _this_ here?" or "what were they thinking?!?" I've fixed bugs that would have taken much longer to narrow down if I hadn't had clues like that.

Re: Git Undo

#165

Post by swift »

recursive wrote: post #75
yoavm wrote: post #49

Earlier quoted context omitted.

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.

On some of the projects I've worked on, although I can easily run a subset of the tests as a sanity check, the full test suite takes hours to run and has to be run on several different platforms because there is a lot of platform-specific code. There's no way I or anyone else can have confidence in any substantial change until it's run through CI. This is a cycle that may repeat many, many times in some cases before some obscure, platform-specific bug can be tracked down. All of those intermediate attempts would quickly totally drown out the signal in the commit history. This is just one of many reasons why for larger projects, rewriting history is really the only practical option.

Re: Git Undo

#166

Post by swift »

Certhas wrote: post #108
minitech wrote: post #54

Earlier quoted context omitted.

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 disagree, the basics are confusing, because there is too much state. I think gitless ( http://gitless.com/#vs ) shows how a less confusing version looks.

Reminds me of hg patch queues, which I've always found to be drastically more error prone than git's staging feature when trying to commit some but not all of the changes you've made, but I haven't tried gitless and it may do it better.

Re: Git Undo

#167

Post by tempodox »

I find it wise to give git a command for reflogging. Flogging it only once would definitely not be enough by a long shot. It might afford the tortured git user some release, although it won't change git any.

Re: Git Undo

#168

Post by tempodox »

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'm surprised we're not all using a better frontend by now.

Chalk that up to the power of fashion and a misguided notion of technical proficiency.

Re: Git Undo

#169

Post by tempodox »

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.

Yep, git gives you more than enough rope to hang yourself with.

Re: Git Undo

#170

Post by tempodox »

supersan wrote: post #52

I wish there was a Dropbox for developers where you never had to worry once about commits or history or tags. Maybe just a big green "Release" button and that's all there is to it. Surely it won't be ideal for writing the Linux operating system but for most of the cases that would be more than enough to get the job done, keep eveyone in sync and yes a lot less confusing allowing you to focus on things that really mat…

Have you ever tried subversion?
Post reply on HN