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

High-Level Problems with Git and How to Fix Them

gregoryszorc.com

Post reply on HN
Print view View original

251–260 of 294 posts

Re: High-Level Problems with Git and How to Fix Them

#251

Post by geezerjay »

lucideer wrote: post #80
popopopo wrote: post #64

Earlier quoted context omitted.

wow. > I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. I did and do this every time I have…

If this is the "correct" way to learn, the problems are not with the user. A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

> If this is the "correct" way to learn, the problems are not with the user.

OP's advice was essentially to first learn how to use a tool in a sandbox before screwing up mission-critical services. I really don't understand why you perceived the need to learn how to use a tool in a sandbox as problem that lies somewhere else other than the clueless newbie who's taking his first steps.

Letting toddlers learn how to ride a bike by installing training wheels doesn't mean that bicycles are flawed or poorly designed.

Re: High-Level Problems with Git and How to Fix Them

#252

Post by geezerjay »

golergka wrote: post #148
popopopo wrote: post #64

Earlier quoted context omitted.

wow. > I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. I did and do this every time I have…

> correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. What if your repo with full history is about 30gb?

Why are you learning how to use hit by testing commands on a 30gb repo?

Re: High-Level Problems with Git and How to Fix Them

#253

Post by lucideer »

notzorbo3 wrote: post #188
lucideer wrote: post #80

Earlier quoted context omitted.

If this is the "correct" way to learn, the problems are not with the user. A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

> A well designed ui should be learnable while being used Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn. > creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability. Again, strongly disagree. Git…

> Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn.

See, I don't think you do disagree. I said a UI should be learnable while being used - vi is. I said nothing about it that learning needing to happen quickly.

I use vim every day; it's not my primary editor, but I'm incredibly comfortable with it, which I wasn't for years after I started using it. But during those years of learning, I never got stuck with an unusable dev environment, I never lost data, I never had to Google how to proceed in order to get my work done. If I ran into a problem, I had the option of opening an alternative editor and continuing with my nice non-corrupted dev env, or I could choose to spend some time figuring out the vim way (and learn something).

vi/vim have no foot guns.

Perhaps this comparison is slightly unfair to git - vi is much simpler insofar as a modal interface is a simpler concept to grok than directed acyclic graphs. So they're not directly comparable, since vi's main barrier to learning is memorising commands and git's is conceptual. However - as has been mentioned elsehwere - hg makes a fine candidate in that regard.

Re: High-Level Problems with Git and How to Fix Them

#254

Post by mar77i »

klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

As the main developer on the project and the resident guru, I ask everyone working on this project to create a branch for their work and just drop me a message - a pull request. Which is a feature incompatible with some git workflows, like the linux kernel's, but finds wide adoption on git productivity tools like gitlab and github.

Re: High-Level Problems with Git and How to Fix Them

#255

Post by nine_k »

lucideer wrote: post #233
nine_k wrote: post #176

Earlier quoted context omitted.

Is writing programs and building them a part of your workflow? Do you even spend time on setting up your build? On acquiring an actual understanding of how it works? Other tools are no different. If it's an important tool, it pays to actually study it. Do not expect tools to do what you mean before you know well what you mean.

I think you're misinterpreting my post. I completely agree, you're absolutely right, but there's a huge different between what you're saying and what the gp was: that usability should not be a consideration for these tools. I do understand, in quite a bit of depth (which I'm sure is still far from complete), how Git works. I still prefer to use Mercurial because it doesn't require me to be continuously aware of the d…

OK, I can agree: git is not as safe, mistake-proof, or consistent as it could be.

What I like about git is that it gives a simple algebra of patches (diffs), and allows almost any sensible operation over them.

It would be great to build a different CLI on top of the same data structures (and maybe the same plumbing) that would expose a more consistent and usable interface, while allowing for [most of] the same capabilities, and preserving interoperability. I suppose git-hg tries to achieve something similar, too.

For me, much of the pain of git CLI was alleviated first by a set of aliases, and then by using magit from within emacs.

Re: High-Level Problems with Git and How to Fix Them

#256

Post by saltedmd5 »

kazinator wrote: post #242
saltedmd5 wrote: post #144

Earlier quoted context omitted.

Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations…

That is not correct; rebase per se doesn't rewrite history. Rebase is basically just cherry picks. You can rewind a branch and then cherry-pick, so that the picks are non-fastforward. That's rewriting history. Cherry picking without rolling back is fastforward, and so doesn't rewrite history. The Gerrit review system on top of Git is based on cherry-picking; it doesn't rewrite history. If some developers are collabor…

AFAIK rebase always rewrites history. If you rebase your feature branch, you have at least rewritten the history of the local branch even if you then delete it and push to a new remote branch. The trunk will subsequently get a FF merge.

Rebase might give you a "simpler" end result in terms of what the history looks like but conceptually it is much less simple in terms of its mechanism and its implications (e.g. rebasing a branch with multiple contributors screws up the audit trail as it now looks like they made their changes at a different time and in a different context to when they actually did) than the idea of a graph with two branches and a merge commit.

I have seen teams with limited git experience switch from habitually rebasing public branches to accepting merge commits and suddenly cure a whole host of workflow problems.

If you can rebase directly onto a fresh branch (not something I've seen) then I am fairly sure that that's not part of your average workflow - establishing new branches every time you want to update from trunk comes with its own communication overhead too.

Re: High-Level Problems with Git and How to Fix Them

#257

Post by j_s »

Klathmon wrote: post #17
klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

> A better VCS isn't going to solve that! It might! I feel like a "language aware" VCS would be able to help a lot in this area. I know there are 3rd party tools that can do this, but if a VCS came along that natively knew about some languages it could unlock some really cool features. Imagine instead of your VCS storing the text source, it stores the AST! Language aware means it can also integrate tightly with langu…

https://www.semanticmerge.com supports .NET languages, C/C++, and Java (with support for JavaScript planned). I would be interested to here any anecdotes from users of this product!

While struggling to search for this tool, I discovered https://www.gmaster.io: a beta Git client (for Windows) from the same company extending these ideas closer to the VCS level.

Codice Software's main product appears to be PlasticSCM; they've done a bit of marketing here on HN without catching much interest.

Re: High-Level Problems with Git and How to Fix Them

#258

Post by theptip »

mschaef wrote: post #240
AlexCoventry wrote: post #194

Earlier quoted context omitted.

> I don't think it's as appreciated that git's complexity generally discourages people from trying things out. Personally, I'm not shy about recursively copying the entire repository on disk to run potentially destructive experiments in a duplicated environment. Also, once you understand how to pull things out of the reflog, it's usually not hard to restore to a sane state.

> I'm not shy about recursively copying the entire repository on disk Agreed. > Also, once you understand how to pull things out of the reflog, That, and I'll also dump a git log of the last couple dozen commits into an editor buffer so that I can hang onto the commit ids. Until a GC cycle occurs, you don't lose the commits even if they aren't reachable through normal paths.

`git reflog` gives you the historical list of SHAs that you've pointed HEAD at; even if you destroy your branch with a rebase, you can still see what commit your branch pointed to before you started the operation.

Re: High-Level Problems with Git and How to Fix Them

#259

Post by theptip »

taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

Sounds like the OP would prefer the Gitless[1] porcelain; it removes the concept of staged files, and significantly simplifies the number of concepts required to work with Git.

(This is a fun project because there's also a paper[2] that analyzes the design of Git from a conceptual level, and comes up with the simplifications that Gitless implements.)

[1]: http://gitless.com/ [2]: https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c...

Re: High-Level Problems with Git and How to Fix Them

#260

Post by rntz »

zanchey wrote: post #189

This article can be summarised as: 1. Cache invalidation 2. Naming of things They seem like straightforward problems.

Could you elaborate for those of you who don't quite understand?

I understand the reference, but is there more to this comment than a joke?

Post reply on HN