Thanks for this excellent cheat shit
Oh shit, git (2016)
151–160 of 280 posts
Re: Oh shit, git (2016)
#152Earlier quoted context omitted.
> Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its r…
> I.e. yes Git has some UI issues, but those are fixable In theory, yes. However, a decade on an I'm not sure any UI issues have been fixed? It turns out 'legacy' is a hard problem, including just for UI "porcelain". In part because people are used to what there is. (Which is a reason it's hard to get people to switch to something that isn't git either -- enough people have figured out how to do what they need with g…
There's definitely been a lot of UI fixes in the Git command-line client. I know because I wrote some small number of those patches.
There's also cases where Git's was and still is top-notch, e.g. in the use of terminal colors by default, and opening a pager for you smartly. Both of those were cases where Mercurial trailed behind for a while, although I think now it's caught up in that area.
I concede that Git's command-line UI still sucks in a lot of areas.
What I was pointing out with the "Repository Formats" reference is that one shouldn't conflate deficiencies in the underlying formats with UI deficiencies.
The latter is easy to fix, and the git command-line client doesn't have a monopoly on fixing those things. There's plenty of other top-notch UIs for Git. E.g. Emacs's Magit, and GUI clients like GitKraken, Sublime Merge etc.
Whereas the inverse isn't true. You can't really build a client like Magit on top of CVS.
Re: Oh shit, git (2016)
#153Earlier quoted context omitted.
Hi. Interesting to know thanks! Would you mind giving the current commands to achieve the three things you just listed? That way I learn the future restore command along with the current approach and you description. T
"git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files). "git restore --worktree" is the same as "git checkout -- file". "git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files. Though "git restore" should make it clear (or clearer) to the user what they want to restore withou…
Thanks really very helpful!
When you hoping to have git restore in the official git release?
Re: Oh shit, git (2016)
#154Earlier quoted context omitted.
> Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its r…
Your response to the first point appears to explain why Git largely replaced Subversion, but it is not clear that it applies to Mercurial.
I'm not saying it won't, just that transitory UI issues are unlikely to drive a mass exodus from one source control system to another.
To reference a reply of mine to your sibling comment[1], it would have been like going through a lot of trouble to move from Mercurial to Git some years ago just because Mercurial's terminal UI didn't use coloring.
Re: Oh shit, git (2016)
#155Earlier quoted context omitted.
This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you'v…
you just rebase on top of their changes. No biggie here. It does not matter one bit if their branch rewrites itself underneath.
Rebasing on rebased branches means everyone has to do the same conflict resolution again and again, and you're in trouble if one person decides to do it differently. Whereas when you merge, the first person does the conflict resolution and everyone else just picks it up.
Re: Oh shit, git (2016)
#156Earlier quoted context omitted.
CLI is fine until you acquire a habit of committing things chunk-wise and line-wise. E.g., I have these 20 files modified, but I'll quickly skim through and add/commit the lines/chunks that are done, and then continue working on the rest. CLI promotes a different kind of workflow, like "ok, I'm done, add/commit it all, and then move on".
What do you feel the UI does better than git add -p? The main concession I have is picking arbitrary files, but I feel like I've achieved 90%+ of what I want with ' .cs' or ' Controller*' etc.
It's more streamlined, it's easier to scroll through staged and unstaged changes fast and flip lines/hunks/whatever between the two as you go, and you don't have to fire an external editor upon each hunk because you're already in one - emacs or vim (if using spacemacs).
(Also, whether it's good or not, rebasing in all of its forms becomes your second nature because it becomes so easy...)
Re: Oh shit, git (2016)
#157Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.
I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…
You can use Mercurial with GitHub by using the hg-git plugin, which lets you push to and pull from a Git server repository from Mercurial.
It’s a really nice tool that I’ve been using for several years to push to git repositories.
Re: Oh shit, git (2016)
#158Earlier quoted context omitted.
Not as often as we'd like to[1], but it happens regularly in reviews, or when casually working together on the same thing in, or when basing branches on other people's unfinalized work, etc. If a team member is used to a force push / rebase type of workflow, it invariably means that stuff will blow up becuause they forgot they had rebased, or they do a force push out of habit, etc. If you include rebase / force push…
> but it happens regularly in reviews But then you already know someone is reviewing that branch! So both of you avoid force-pushing. > or when casually working together on the same thing in Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one. > or when basing branches on other people's unfinalized work Without any sort of hint to the guy w…
> Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one.
Well, one of force-pushing or casually working together had better be a rare exception, otherwise you'll do both at the same time. I'd rather not make force-pushing part of my normal workflow, because casually working together has more value to me.
> Without any sort of hint to the guy working on that branch? How do you know it's even in a stable state to build on if you have no communication?
Anything committed / pushed is assumed working (we tend to compile before commit). If they need to rework their changes, they'll rework their changes, but the current state of their branch is almost certainly closer to the final state of their branch than the current state of master is.
> Yes it breaks if you screw up, but I mean then you just deal with it right? It's a dumb mistake just like any other silly mistake that can happen during committing, it's infrequent, it's on an ephemeral branch, and it's completely reversible. I don't see why someone occasionally mistakenly pushing the wrong thing (forced or otherwise) on a branch that isn't even going to exist for much longer is such a catastrophic event that you have to formulate your whole team's entire development process around avoiding that event 100% at all costs?
The trouble is it's viral. By the time you've figured out it's happened, other people have probably pulled from that branch; at best they've spent time merging in the force-pushed version. More likely they've done that and then built more work on top of it, so either both versions make it into mainline and everyone is resolving conflicts, or you have to ask that person to rebase their work and create another chance for the same problem to occur.
Re: Oh shit, git (2016)
#159Earlier quoted context omitted.
Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the…
> Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.
lol, go back to jalopnik, dork.
Re: Oh shit, git (2016)
#160Earlier quoted context omitted.
> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…
I had a sudden flashback to using darcs, which was also based upon patches instead of commits. darcs was nice, up until you hit the exponential merge problem.
I don't know about Pijul, but it claims to have solved the exponential merge problem.