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

171–180 of 294 posts

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

#171

Post by mmebane »

maccam94 wrote: post #125
jcranmer wrote: post #36

Earlier quoted context omitted.

Coming from someone who learned hg well before git, and who's now being more or less forced to use git long after developing comfortable hg workflows, the staging area feels like a half-baked implementation of what it's supposed to be doing. I'm used to thinking of commits as atomic commits--roughly, each commit is the smallest change that atomically makes sense. So you should be able to use the staging area to build…

Some useful commands I'd use in scenarios like this are: git add -p # select what to add to the staging area git reset -p # deselect chunks that I decided I don't want anymore git stash # saves your working state in a temporary commit (not in your branch) git stash pop # restores the working state from the last git stash command and drops the temporary commit git rebase -i $start_point # where $start_point is either…

> I do wish git had some notion of sub-commits with their own messages

You could use the "fast-forward with merge commit" style. [1] Then you can treat the commits from the branch as sub-commits, and the merge commit as the parent commit.

[1]: https://stackoverflow.com/questions/15631890/how-to-achieve-...

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

#172

Post by drchickensalad »

jonthepirate wrote: post #48

In practice I have found the biggest missing feature that I wish existed is the ability to pull a single file from a known ref on a remote server. For example, give me the Dockerfile located in the root of the master branch tip. Can't do that. Instead, you have to clone the entire repo first.

Well you can clone with --depth=1, so performance wise it's not too bad at all, but yeah still gets all the other latest files.

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

#173

Post by rbehrends »

tomxor wrote: post #158
jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

I'd like to think I know git pretty well... I understand the internals, i've written cli tools that utilise all the plumbing commands, I understand the different types of objects merkel trees, and various form of references. Yet, once when I had a power failure by chance the second I fired the commit trigger... I was pretty hopeless at trying to clear up the mess of objects it exploded everywhere, I couldn't be bothe…

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 the prime suspect to me; there's nothing in Git's logic that should normally allow for such a problem.

See, for example, the "Failure to sync" section of SQLite's page on "How to Corrupt an SQLite Database".

[1] https://www.sqlite.org/howtocorrupt.html#_failure_to_sync

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

#174

Post by andreareina »

The reflog is an invaluable feature, I'm glad that I learned about it right when I started learning how to use git. Knowing that there's little I can do to permanently mess things up has given me the confidence to just try things out, speeding up my learning tremendously.

I agree that the default git porcelain leaves something to be desired. Personally I use and absolutely love magit, slightly tweaked to give me the defaults I want.

The staging area is one of the things that magit really improves on; you retain all its power while making it very cheap to use -- one keystroke to stage the selected file, or all modified files. I stage individual hunks à la `git add --patch` a lot, and sometimes need to include only part of the hunk I'm presented with. It wasn't uncommon for my editing the diff to result in an error with the git cli, now I select the lines I need and just stage those. And if you really don't want to use it, `--all` is easily set as a default for committing.

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

#175

Post by nhaehnle »

rbehrends wrote: post #166
nhaehnle wrote: post #157

Earlier quoted context omitted.

It is supported, it's just that the only thing keeping commits not on a branch alive is the reflog. Question: How does Mercurial deal with garbage collection? After all, the desire for garbage collection is by far not unique to Git -- any version control system that has the equivalent of `commit --amend` and rebase should provide it. As for not needing the extension, it seems to me that having "dangling" commits woul…

> Question: How does Mercurial deal with garbage collection? After all, the desire for garbage collection is by far not unique to Git -- any version control system that has the equivalent of `commit --amend` and rebase should provide it. Garbage collecion is an issue that is 100% unique to Git. No other VCS even thinks about throwing user data in the repository away without the user explicitly telling it to. Once you…

> I'm honestly not sure why you think you'd even need a GC for `hg commit --amend` or `hg rebase` (or similar operations in other VCSes).

Maybe you don't call it GC, but doing a rebase in Git leaves the old, pre-rebase version around. That is a feature: over the years, it has happened to me more than once that I'd missed something when resolving complex conflicts during the rebase. Being able to refer back to the state from before the rebase was very helpful in these cases.

If Mercurial throws the old version away unconditionally, that would suck very much indeed.

If Mercurial keeps the old version, then perhaps at some point in the future I'd really rather have all that old data removed as a simple matter of saving disk space. Surely nobody wants to do that manually?

Hence: you either have a system that makes it much easier than Git to lose data, or you need garbage collection.

I don't know what Mercurial does, but somehow, the fact that this dilemma isn't obvious to you -- somebody who clearly seems to know a lot about Mercurial -- doesn't instill a lot of confidence in it.

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

#176

Post by nine_k »

lucideer wrote: post #112
popopopo wrote: post #83

Earlier quoted context omitted.

a still, while people cry about UI (which is irrelevant part), other people just take time and learn git. by whatever measures. PS. throwing out things you test on. isn't that how every programming tutorial works? write code NOT in your main repository, test things out, throw it away (or keep it, whatever)?

> UI (which is irrelevant part) UI usability is irrelevant... ?!?? > isn't that how every programming tutorial works Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design. Secondly, even programming language designe…

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.

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

#177

Post by dboreham »

rbehrends wrote: post #173
tomxor wrote: post #158

Earlier quoted context omitted.

I'd like to think I know git pretty well... I understand the internals, i've written cli tools that utilise all the plumbing commands, I understand the different types of objects merkel trees, and various form of references. Yet, once when I had a power failure by chance the second I fired the commit trigger... I was pretty hopeless at trying to clear up the mess of objects it exploded everywhere, I couldn't be bothe…

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

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

#178

Post by muxator »

saltedmd5 wrote: post #144
zegl wrote: post #129

Earlier quoted context omitted.

`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.

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…

mercurial has "phases", which means that it allows free rebasibg and history rewriting for changes that are still not public.

As soon as a tree is pushes, those changes become public, and you need to explicitly force the history rewriting operations.

This is part of the " safe defaults" approach of mercurial.

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

#179

Post by dboreham »

3minus1 wrote: post #139
pritambaral wrote: post #126

Earlier quoted context omitted.

> I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Git has good documentation too. As long as we're doing personal experience, here's mine: I learned git from `git help` too (well, `git --help` and `git --help`), and I never needed to look for a git expert in my team for advanced operations; I did have to be one for others quite a few times , but when it wasn't an immedia…

Does anyone who's downvoting this comment care to explain why?

Because git dies not have good documentation.

Perhaps that's unfair to the documentation in that it does a good job of detailing commands and their options, but is urinating into a hurricane as far as trying to convey any notion of conceptual integrity for a piece of software that has none.

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

#180

Post by rbehrends »

nhaehnle wrote: post #175
rbehrends wrote: post #166

Earlier quoted context omitted.

> Question: How does Mercurial deal with garbage collection? After all, the desire for garbage collection is by far not unique to Git -- any version control system that has the equivalent of `commit --amend` and rebase should provide it. Garbage collecion is an issue that is 100% unique to Git. No other VCS even thinks about throwing user data in the repository away without the user explicitly telling it to. Once you…

> I'm honestly not sure why you think you'd even need a GC for `hg commit --amend` or `hg rebase` (or similar operations in other VCSes). Maybe you don't call it GC, but doing a rebase in Git leaves the old, pre-rebase version around. That is a feature: over the years, it has happened to me more than once that I'd missed something when resolving complex conflicts during the rebase. Being able to refer back to the sta…

> If Mercurial throws the old version away unconditionally, that would suck very much indeed.

Which is why it isn't done.

In core Mercurial, the old revisions are stored in a backup bundle in a separate backup directory. Note that bundles can transparently be used as read-only repositories, so you can view their logs as though they were still part of the parent repo, diff against them, pull from them, etc.

With the evolve extension, those revisions will simply be marked as obsolete, with obsolescence markers showing which revisions were replaced by which. The commits will be hidden, but are still part of the repository. If you ever want to get rid of the old revisions, you'd have to use (say) `hg strip -r 'exctinct()'`, which would store them as bundles as described above, or clone the repository and delete the old repository.

Plus, there are public, draft, and secret changesets. Public changesets are immutable and cannot be changed without user override.

Bazaar rebase will simply hide the old revisions; you can recover them with `bzr heads --all`. To permanently delete the revisions, you have to clone the repository and delete the old version (and all backups). And, of course, there's rarely a reason to use rebase in Bazaar.

> Hence: you either have a system that makes it much easier than Git to lose data, or you need garbage collection.

As I described above, neither. In every case, you need to go through several steps each requiring the user to affirmatively express their desire to delete data.

And as disk space is really cheap these days, hardly anyone ever actually deletes the data in practice, as there's no point to it.

> I don't know what Mercurial does, but somehow, the fact that this dilemma isn't obvious to you -- somebody who clearly seems to know a lot about Mercurial -- doesn't instill a lot of confidence in it.

I think your dilemma is largely an imaginary one, fretting over a resource (disk space) that is too plentiful to require micromanagement.

Keep in mind that most of the data in your repository will come from other people; there's only so much source code or text that a single person can write in a day. If you're generating massively large binary assets, a DVCS is probably the wrong tool, anyway, because of scaling concerns. This inherently limits the amount of "wasted" data that you can have in a repository to a percentage of the repository size.

Post reply on HN