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

141–150 of 175 posts

Re: Git Undo

#141

Post by recursive »

nolemurs wrote: post #113
recursive wrote: post #112

Earlier quoted context omitted.

By specifying the parts you want to include when you commit. I think it's unnecessary for any reasonable work flow, and doesn't manage to break even on its benefit vs. cognitive cost.

So you want a long command line argument were you tag specific line numbers and have to get it all right at once? That sounds terrible to me. Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful. I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.

I really would prefer not to even use a CLI for this operation, since I think it's not well suited to the kind of interaction commits entail.

A "staging area" is a useful concept, but it's not one that needs to exist outside the UI of whatever tool you're using to generate the commit.

Re: Git Undo

#142

Post by svachalek »

krupan wrote: post #131
an_account wrote: post #109

Earlier quoted context omitted.

Rebasing also rewrites all your commits to have a different parent commit.

Nope, parent is correct. If you use hg's changeset evolution and run rebase, and then do a hg log --graph --hidden you can see that your original commits have not been touched, other than to mark them as hidden and obsolete.

This is a discussion about git.

Re: Git Undo

#143

Post by krupan »

svachalek wrote: post #142
krupan wrote: post #131

Earlier quoted context omitted.

Nope, parent is correct. If you use hg's changeset evolution and run rebase, and then do a hg log --graph --hidden you can see that your original commits have not been touched, other than to mark them as hidden and obsolete.

This is a discussion about git.

They both work the same here, I just used hg because it illustrates the inner workings nicely. With git you don't get the nice hidden commits view, just the refleg (which is trying to show you the same thing).

Re: Git Undo

#144

Post by StavrosK »

nolemurs wrote: post #135
StavrosK wrote: post #126

Earlier quoted context omitted.

> Personally I like tools that are powerful and efficient once learned over tools that I can use without any learning. I prefer powerful and efficient tools that I can use without any learning, since the two aren't mutually exclusive. > if you just take a couple hours to really try to understand what it's doing and why it's not that hard, What is it in git's architecture and design that mandates that a file should be…

> prefer powerful and efficient tools that I can use without any learning, since the two aren't mutually exclusive. They're not necessarily mutually exclusive, but in my experience there's often a trade off. I would argue that git is about as simple to as it can be without taking power away from the user by forcing an abstraction on him. > What is it in git's architecture and design that mandates that a file should b…

> there's often a trade off

I agree with you there. It doesn't mean that things are as bad as "weak tools or hard-to-learn tools", but there's a tradeoff.

> I have to agree that the choice of command line arguments is the weakest element of git.

I think there's a fundamental misunderstanding here. Git's conceptual model is hard to learn, but there's no way around that. If you want to be proficient in Git, you have to understand the conceptual model, and people find it hard and mostly give up, and say that git's core is badly designed (which it's not).

This muddies the waters for people who claim that git's porcelain is badly designed (which it is), because then other people mistake that for the former argument, and we end up talking at cross-purposes.

I think we can both agree that git's core/architecture is great, and the porcelain is quite bad.

> Git isn't intuitive before you understand the data model

I think this meshes with my previous paragraph, but I think git could be much more intuitive (and require much less mandatory learning of the internals for someone to be productive with it) if the porcelain were better designed.

Re: Git Undo

#145

Post by rav »

krupan wrote: post #143
svachalek wrote: post #142

Earlier quoted context omitted.

This is a discussion about git.

They both work the same here, I just used hg because it illustrates the inner workings nicely. With git you don't get the nice hidden commits view, just the refleg (which is trying to show you the same thing).

You can see hidden commits with git log --reflog.

Re: Git Undo

#146

Post by atsaloli »

grok2 wrote: post #122
atsaloli wrote: post #74

Earlier quoted context omitted.

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…

I think you should read back to yourself what you wrote -- you are essentially saying git is complex. Anything complex with enough time and understanding can become easy, but do you need the complexity in the first place? Most developers usually want a simple workflow where they don't want to deal with too many idiosyncrasies of the tool they use. You want to checkin and checkout mostly, but instead one needs to unde…

I understand.

Git allows you to do a lot more than check in and check out. It's a powerful tool for collaborating on source code.

To the extent that one doesn't confront what Git actually is, it can seem mysterious or needlessly complex. There's a method to the madness. :)

Re: Git Undo

#147

Post by blakeyrat »

oblio wrote: post #41
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 i…

Except we all knew how to write better UIs back in 2008 when Git was first written. It's not some brand-new research that only came to light a few years ago. We knew how to do usability tests in 2008. We knew what patterns worked and what didn't. We knew how to build discoverable software.

Why the heck wasn't the UI improved back then, before the thing was even released?

I mean, while your explanation is correct, it doesn't explain or excuse the pure incompetence of the original developers when it comes to usability issues. Their laziness or ignorance back then has confused and irritated thousands or millions of developers now, and continues to, and will continue to for the foreseeable future.

Make sure the shit you're going to set in stone is good before you grab the chisel, guys. You're professional software developers, not clowns.

Sorry for the rant.

Re: Git Undo

#148

Post by blakeyrat »

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…

A CLI is a user interface.

The problem with Git (well, one of many many problems with Git) is that it conflates its user interface with machine interfaces-- which means tools that have to work with Git (like those GUI clients) have to use the CLI to do so. They don't have a more powerful option, like an officially-supported API or a shared library they could call into. This is terrible software design.

Re: Git Undo

#149

Post by blakeyrat »

nolemurs wrote: post #115
StavrosK wrote: post #95

Earlier quoted context omitted.

This is a good article: https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi... > Once you understand Git's data model, the UI is perfectly intuitive So it's not intuitive at all. Not to mention that every damn command is inconsistent with every other command! To remove a file, git rm. To remove a branch, git branch -D. To remove a commit, git reset --hard HEAD^. How is this intuitive, consistent, or even san…

I mean, I'll agree, if you insist on trying to create an abstraction to understand git, you can beat your head against the wall for days trying to figure out how it works. On the other hand, if you just take a couple hours to really try to understand what it's doing and why it's not that hard, and it's way more effective and powerful than any other tool out there. Personally I like tools that are powerful and efficie…

> Personally I like tools that are powerful and efficient once learned over tools that I can use without any learning.

You say that as if the two are mutually-exclusive. They aren't.

Re: Git Undo

#150

Post by niftich »

blakeyrat wrote: post #148
Cthulhu_ wrote: post #43

Earlier quoted context omitted.

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…

A CLI is a user interface. The problem with Git (well, one of many many problems with Git) is that it conflates its user interface with machine interfaces-- which means tools that have to work with Git (like those GUI clients) have to use the CLI to do so. They don't have a more powerful option, like an officially-supported API or a shared library they could call into. This is terrible software design.

libgit2 [1]

In fact, there exist many alternative 'frontends' to Git. There are even protocol translators like Hg-Git [2], and many importers that typically use the fast-import format to ingest Git-impl primitives [3]

[1] https://libgit2.github.com/

[2] http://hg-git.github.io/

[3] https://github.com/frej/fast-export

Post reply on HN