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

61–70 of 175 posts

Re: Git Undo

#61

Post by lmm »

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…

So what happens when two developers edit the same file, or make changes to different files that in combination break the system?

You need commits, you need the ability to merge. If you don't want to force all commits to happen online and everyone to resolve conflicts immediately then you need branches. You want tags if you're going to have releases (otherwise how do you refer to them?). At that point you basically have git.

All the complicated features were added because someone thought they needed them (there are certainly a few git features where I think that someone was wrong, but not many).

Re: Git Undo

#62

Post by dozzie »

amelius wrote: post #17

Why not just use a filesystem which supports snapshots? It would allow you to go back without even invoking git.

1. calculating differences

2. merging two or more different branches

3. transporting code (publishing it)

3a. accepting somebody else's patches

4. descriptions of history points

4a. pointers to parent code trees (especially with tree merges)

5. history traversals (bisecting, among the others)

Not to mention that you need either administrative privileges for creating a snapshot or a special kind of filesystem that supports this for non-administrator. And sysadmin still needs to prepare such a filesystem for your $HOME.

Re: Git Undo

#63

Post by newjersey »

Dylan16807 wrote: post #44
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.

The last time we had this discussion the consensus bottom line was that you try to avoid rewriting history once you have pushed it to a place where others have access to it.

Once you've published it, let it go. Do not mess with history. I think we can all agree on that.

The disagreement is whether I should squish my commits before I push it and I put that in the same pile of questions as am I obligated to my significant other and society at large to shave my legs before going out in public.

Re: Git Undo

#64

Post by m_mueller »

dan00 wrote: post #57
m_mueller wrote: post #12

Earlier quoted context omitted.

Could it be improved to have undo filter out its own reflog entries and instead have a 'redo' to undo those?

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?

Re: Git Undo

#65

Post by chriswarbo »

Dylan16807 wrote: post #48
chriswarbo wrote: post #42

Earlier quoted context omitted.

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.

> The ability of devs to collapse a bunch of commits into a useful summary is near zero right now

You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc.

Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that future dev can, considering the fact that you don't know what they might want?

The nice thing about git is that anyone can make a new branch from any point in the repo's history, merge, cherry pick, rebase, etc. to their heart's content, then garbage collect it once they've learned what they needed.

Re: Git Undo

#66

Post by Dylan16807 »

chriswarbo wrote: post #65
Dylan16807 wrote: post #48

Earlier quoted context omitted.

>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.

> The ability of devs to collapse a bunch of commits into a useful summary is near zero right now You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc. Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that…

What makes me think I can write better code than the thousand people downloading my repo later? I don't, but somebody should do the summarizing, and it might as well be me.

Smashing the diffs together gets you the least useful parts of a purposeful squash commit.

Re: Git Undo

#67

Post by _pmf_ »

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'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's wrong with organizing your source code in a single directory? Why do people insist on organizing them into subdirectories aud subsubdirectories instead of letting the main directory accurately reflect the size of the code base?

Re: Git Undo

#68

Post by Dylan16807 »

dozzie wrote: post #62
amelius wrote: post #17

Why not just use a filesystem which supports snapshots? It would allow you to go back without even invoking git.

1. calculating differences 2. merging two or more different branches 3. transporting code (publishing it) 3a. accepting somebody else's patches 4. descriptions of history points 4a. pointers to parent code trees (especially with tree merges) 5. history traversals (bisecting, among the others) Not to mention that you need either administrative privileges for creating a snapshot or a special kind of filesystem that sup…

What are you talking about? amelius is mentioning an alternative to the hacky "git undo", not an alternative to git. You put your git repo onto the filesystem.

As far as administration, most devs will have elevated rights or can use FUSE or something. We could talk about needing administrative privileges to install git, too, but it's pretty far removed from the central topic.

Re: Git Undo

#69

Post by CyberShadow »

Be careful with hard resets - they throw away working tree changes. Ironically, it's one of the few git operations you actually can't undo. (Usually I prefix such scripts with "git stash save" due to this.)

Re: Git Undo

#70

Post by shados »

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…

Personally, I only care about when the code hit master. Because that's when it could potentially have broken shit for everyone.

That I committed it locally is pretty irrelevant: I could just as well NOT have committed it, made a backup of the files on the side, copied them back in...from the perspective of the rest of my team, my local history is an implementation detail.

If the only thing I do is manipulate my local history, then open a PR and merge, master's history will actually show something much closer to the truth: That on X date I added something to master.

That I spent 6 weeks and 300 commits locally to do it (kids, don't do this at home!), literally doesn't matter to anyone.

Post reply on HN