I've never understood these complaints. I _like_ the staging area. I _like_ branching. They've never stood in my way in any form.
High-Level Problems with Git and How to Fix Them
161–170 of 294 posts
Re: High-Level Problems with Git and How to Fix Them
#162I like what this guy has to say so far, but it's a bit surprising that someone with his knowledge got this wrong: > The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached I dislike the mess of crappy synonyms too, but git diff --staged is already an alias, in fact it's the primary way I di…
> I dislike the mess of crappy synonyms too, but git diff --staged is already an alias
Problematically it's very little used, it's only mentioned once at the very tail end of the `—cached` description, `--cached` is still the primary flag, and the essay remains correct that references throughout the documentation are inconsistent.
It's not exactly hard to miss, if e.g. you learn git through the Pro Git book, the option is not mentioned once, and even the full text search has not indexed it.
Furthermore, there are many other commands which take a —cached flag but don't have a —staged alias (diff-index, submodule, check-attr, apply, rm)
Re: High-Level Problems with Git and How to Fix Them
#163Earlier 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?
I did not downvote the parent comment but I find
> Git has good documentation too.
hilarious. Git has a sprawling mess of disorganised man pages. I find calling that "good documentation" insulting to people who care about documenting things.
Re: High-Level Problems with Git and How to Fix Them
#164I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after b…
TD;DR: Magit is a lesson of UX. +1 for Magit. When I discovered it is when I discovered git. I assume tig must be similar although I've never looked into it but... With magit, from my editor, I can easily check: my git status, choose which hunks to stage or unstage, commit easily. I can switch branches with less than 10 keystrokes. etc. But to me, what's coolest about it is that I can easily see commit histories and…
My only beef with magit is that it's really slow for nontrivial projects ($dayjob's main codebase is 1MLOC and has ~110000 commits reachable from HEAD, "status" takes a good 5s, and adding/removing stuff from d/u or d/s quickly gets painful).
Re: High-Level Problems with Git and How to Fix Them
#165I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after b…
Magit is great! Even if Emacs is not for you I'd still recommend giving only Magit a try. It transformed my workflow from staging and committing full files in one step to using the staging area with parts of files or single lines if necessary (e.g. leave out work in progress parts of a source file). Some other stuff like interactive rebase I could only grok via Magit which in turn helped my Git-CLI skills.
Re: High-Level Problems with Git and How to Fix Them
#166Earlier quoted context omitted.
> As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. "Not well supported" in this context means that you can lose data (as commits that are not reachable from a ref can be garbage collected). Mind you, you have to ignore warnings…
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 have a user telling you to throw the data away, it can do that. There is no need for GC; this is purely an artifact of Git's implementation. 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).
> As for not needing the extension, it seems to me that having "dangling" commits would be very difficult to use without some decent visualization of the dangling commits, such as what the blog post shows with `hg show`.
I'm not sure where you get the idea. This feature is, after all, not unique to Mercurial. It's Git that has the oddball semantics that no other VCS on earth has. Mercurial has been able to graphically show the graph for ages and the ability to just list open heads, too (`hg heads`). If you look at the code, the implementation of the show command is largely just a templated graphlog of a particular revset. For example, `hg wip` [1] (for "work in progress") has been doing something similar just using revsets and templates from core Mercurial.
> The point of the purely functional data structures isn't to achieve atomicity (although potentially being a bit more robust to power loss etc. is certainly a nice side effect), it's a way of thinking about version control. I've never heard functional programmers use atomicity as the main argument for immutable data structures, either...
This is because functional languages do not have to worry about their state being destroyed by the user hitting Control-C or a power outage. This will simply terminate the program, whereas for Git it will interrupt a transaction in progress.
> The whole point of Git's design is that it chose a robust and crystal clear way of thinking about distributed versioning as its underlying model of what version control is, and then simply provided tools for manipulating that DAG.
This is what other version control systems do, too, without relying on purely functional data structures. The fact that the data structures are purely functional is, after all, not a property that is visible to the user other than through the side effects of garbage collection.
[1] http://jordi.inversethought.com/blog/customising-mercurial-l...
Re: High-Level Problems with Git and How to Fix Them
#167Earlier quoted context omitted.
I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming/ / ` in the original repo.
Isn't that up to the repository maintainer whether they allow pushes from other people? And sure, it litters your list with forks, but you can remove them as soon as the PR is merged. And that's the case for pretty much anything you contribute to (unless you can push there, of course).
> Isn't that up to the repository maintainer whether they allow pushes from other people?
That's an orthogonal concern. What they're saying is what the essay suggests at the end, Github could maintain a list of "contributor refs" in the source repository in the same way they expose PR refs (refs/pull/*/head).
This could be managed entirely by the service provider (e.g. github) and invisible to the repository maintainer until a PR is created.
Re: High-Level Problems with Git and How to Fix Them
#168Earlier quoted context omitted.
List of files is not enough, I always do 'git add -p' to see the actual changes. And sometimes I detect an error, and I want to fix it and then keep going without having to re-evaluate the changes I had already seen.
The authour of this article suggests a solution - `git commit --interactive` could prompt you for each change like `git add -p` does without needing a staging error. You're right though that it would take some cleverness in that command to allow you to fix a typo without restarting the operation.
> You're right though that it would take some cleverness in that command to allow you to fix a typo without restarting the operation.
Would it though? Just finish your commit ("q" to skip the current hunk and every following one), then use commit --amend —interactive for the rest of the changes.
Re: High-Level Problems with Git and How to Fix Them
#169Earlier quoted context omitted.
Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…
Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actually made three separate subchanges so I do partial stages to create each commit. I use git status -s and git diff quite a bit as a sanity check (for things like whitespace) and to do first party code review before I send anything out. The staging area is a co…
> I realize that I've actually made three separate subchanges so I do partial stages to create each commit.
You can trivially replicate that without staging by amending the HEAD commit, or building a bunch of partial commits then folding them with rebase -i. You can even do that automatically by committing with --fixup or --squash
Re: High-Level Problems with Git and How to Fix Them
#170Earlier quoted context omitted.
I have ADHD, so often as I am working on one feature, I will begin accidentally working on another unrelated feature along side it. I rely on staging a lot to ensure that each commit has only the parts that it needs.
Same here, I actually find `git add -p` to be very useful.
commit also has a -p flag.