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

271–280 of 294 posts

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

#271

Post by cryptonector »

ssivark wrote: post #267
cryptonector wrote: post #261

Earlier quoted context omitted.

I agree. I want a VCS that does NOT try to hide how it works from me. I love that git gives me a) a bag of commits forming one or more rooted trees, b) symbolic names for commits/branches that resolve to individual commits in that bag. That's such a simple model. Remotes. Commits. Branches/tags. That's it. Merging and rebasing merely create new anonymous branches in the bag of commits, then move a branch name (if app…

Now, can that be explained to a git newbie in under half an hour, to get them up and running? IMO, the scary UI/UX of git is holding back the use of version control for a lot of digital documents beyond just source code. It needn't be this complicated.

I've tried to get noobies to use SourceTree on OS/X, with Mercurial or git, and it never goes well. Version control is just hard the moment you want to do anything other than linear commits. The moment you want to undo something partially, it gets ETOOHARD on most non-developers, and especially people like my mom.

On the other hand, when explaining the git model to sysadmins and developers, not sugar-coating it has worked best for me. I explain the bag-of-commits+nametable design. I explain the workspace and staging area. I show how one does things. This works for me.

Maybe git's UI "needn't be this complicated", but I do find that Mercurial's heavy-duty branches lead to hell very quickly and it's always difficult to recover -- and Mercurial is supposed to be simple! The lesson is that simplifying isn't easy, and not every simplification works well generally.

With git I can simplify in that I show users a small amount of abstract concepts (bag-of-commits, nametable) and a small set of common usages and then let them learn by experience and osmosis as they reach out for help when they stray past those usages. I can't do this with other VCSes. At some point it just becomes painful.

One of the nice things about git is that I can push users to make very linear history. This is nice because diving into the history of a tangled mess of merged branches is not easy, and it's actually very confusing to non-professionals. But even for professionals, linear history is far superior to a tangled mess of merged branches, and only git really gives us that power today.

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

#272

Post by cryptonector »

cjhanks wrote: post #29
gear54rus wrote: post #6

The general sentiment of this article is in things like: > A commit message is already too annoying for many users! So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.…

Unfortunately this is simply the reality for many developers. I have worked with multiple people whose commit logs would look something like... > e96ddd0 update code > 65c3072 update code > dd9ccc1 update code > 7992ef8 update code > 6c536e6 update code > ... Over and over several dozen commits. Which is technically fine if they know how to rebase. The overwhelming majority of my commits are simply 'git commit -a -m…

With Mercurial it's all like this. Plus merge commits referencing others' branches full of this sort of history.

History is rather useless if it isn't clean.

Suppose you have a bunch of maintenance releases, and you have to backport some commits occasionally. (Sometimes you realize that you have to do this long after the commits are written.) If those commits are logically organized and minimal, then it's easy to cherry-pick them from the mainline onto the maintenance release branches. If not, then you're in for a world of hurt, and ultimately may have to replicate the relevant bug fixes by hand.

Clean history is critical to a large project, and especially to a large project with maintenance branches.

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

#273

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…

This discussion won't see much more now that it's off the front page, but is there any work towards full undo support integrating with version control or even at the IDE level?

There's a lot of stuff that doesn't get checked in; I wouldn't necessarily want it all in the official history but it would be amazing to have a time-searchable view of the project's entire development story for my own personal review/rescue operations.

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

#274

Post by flukus »

dboreham wrote: post #177
rbehrends wrote: post #173

Earlier quoted context omitted.

I very much doubt that this is a Git issue, but suspect that it is instead a file system/OS/hardware issue. The problem is that operating systems generally offer only very limited guarantees about the atomicity of the bits actually being physically stored on a device (at least guarantees that can be used with reasonable efficiency). It should not normally be a problem, but a power failure just at the wrong time seems…

Um..a mission critical data store shouldn't be affected by a "power failure at just the wrong time".

Git is not a mission critical data store. Corruption should cause a bad day, not a disaster.

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

#275

Post by flukus »

CSMastermind wrote: post #193
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…

On source control anti-pattern I've run into is people thinking a commit is a 'save'. It's not. A commit should move you from one working state of your code to another. Compare that to saving my files which I do compulsively every 5 minutes or so regardless of the state the file is in.

I agree it's not a save, but a commit doesn't have to be in a working state either, at least on a private branch. A commit is a rollback point which may not even compile.

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

#276

Post by lpr22 »

xinsight wrote: post #202
nicoburns wrote: post #128

Earlier quoted context omitted.

Leaving any files uncommitted before a complex operation in git is a really bad idea (make a temporary commit if necessary). It's almost impossible to completely lose committed data, but pretty easy to destroy uncommitted data.

This. I also do a `git diff > save.patch` if there is something uncommmited that i don't want to commit at the moment. A patch file feels more comfortable to me than git stash, as i can easily view the patch files, and reapply them with `patch -p1 < save.patch`

You can show the diff with `git stash show` or also apply your patch with `git apply save.patch`

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

#277

Post by inimino »

mercutio2 wrote: post #210
inimino wrote: post #51

Earlier quoted context omitted.

As the author points out, it is an unnecessary primitive, once you learn about things like commit —amend, which you will inevitably eventually learn about anyway. Adding redundant ways to do the same thing is not the way to make a tool approachable. The basic problem is that git was designed to solve Linus’s problems, and Linus’s problems are not your problems. However, because of network effects, most of us end up u…

How does commit --amend in any way solve the same problem as the staging area? If I’ve got a big change which I want to split into three small internally consistent changes, with each change overlapping in many files, how in the world would --amend help?

It solves the problem I was directly replying to:

> I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

However, it does not replace all use cases of the staging area, which is why I gave it only as an example.

Of course, `commit --amend` with `-p` could solve your problem as well.

Alternatively, “create a new, 'pending’ commit, without a commit message, don’t point HEAD to it yet, and change most of the commit-related commands to modify this commit until it is finalized” also solves all the use cases of the staging area, because that is what the staging area is, but it is presented in a much more confusing way and ends up being yet another new concept for git beginners to grasp.

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

#278

Post by mercutio2 »

inimino wrote: post #277
mercutio2 wrote: post #210

Earlier quoted context omitted.

How does commit --amend in any way solve the same problem as the staging area? If I’ve got a big change which I want to split into three small internally consistent changes, with each change overlapping in many files, how in the world would --amend help?

It solves the problem I was directly replying to: > I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go. However, it does not replace all use cases of the staging area, which is why I gave it only as an example. Of course, `commit --amend` with `-p` could solve your problem as well. Alternatively, “create a new, 'pending’ commit, without a commit message, don’…

Fair points.

After thinking about this more, I find myself agreeing that in terms of beginner friendliness, the combination of incredible name confusion and the relative paucity of use cases where it’s necessary make the staging area an interesting area for significant change in the git defaults.

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

#279

Post by adrianN »

majewsky wrote: post #115
adrianN wrote: post #38

Earlier quoted context omitted.

"Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about. I'd argue that for any piece of software where a failure requires a root cause investigation the VCS history is a critical artifact and a great deal of care should be taken to make it easy to understand for what reasons changes happened and how they interact.

> "Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about. Realistically, though, you won't be able to figure out to which task management system this issue number refers, out of the five that your team used in the last 3 years. We have been through two different JIRAs and two different Github trackers in the last 3 years. Sometimes multiple s…

If you switch issue trackers every ten months without a migration strategy for old issues that's a pretty serious organizational problem. I hope that's not a mature company.

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

#280

Post by nurettin »

jononor wrote: post #203
nurettin wrote: post #10

>> And the Git staging area should be an opt-in feature. Thousands of yes! `git commit -a` just doesn't add the untracked files it is the most annoying misfeature of any version control system. Oh, I added unwanted project directories? I would then just remove them and put them to `.gitignore`, or create a `.gitignore` prior to `init`. Of course I could just alias `add -A . && commit -m` on every machine I ever conne…

Automatically adding untracked files would make it extremely easy to commit (and without other safeguards, push) unwanted changes. Annoying things like node_modules or binary screenshots that now bloats the repo history forever (unless one rewrites the history), or potential security breaches like passwords/keys or logs/configs with confidential information.

Then there is .gitignore_global for your node_modules/
Post reply on HN