301–310 of 352 posts
Doing mumbo-jumbo between branches with `git stash` is way to hell. Don't do it, you lose data. This fucker will unstash changes until first conflict, then it stop and present you with >>>>>>ID which nobody understand. Well I understand it, but never know which is which (theirs/ours label don't help here). You try to undo everything, but then you're fucked - all unstashed changes are removed from stash while conflict…
Earlier quoted context omitted.
> Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.
Ah. My mistake. 16s is not a big deal, but I'm assuming it would get much worse for larger repositories. Personally, my searches are either: 1. Restricted to all files that end in cpp, h, py, pl, etc. 2. Explicitly exclude .hg directories. I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters ( .cpp, .h) and is usually the first item in th…
And I disagree with this point:
Things like search time are *not* a productivity bottleneck.
Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems.
EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.
I've heard advice from #git on freenode not to use "git commit --amend", especially on shared repos. I wish I still had a log of the conversation or remembered the exact problem that led up to it, but it involved a simple amend totally screwing up my repo, and I've avoided it since.
Amending your commit in your own feature branch or fork isn't a problem. I often amend commits to make a cleaner git history to ease PR/code review.
git checkout master
git checkout -b 10-new-feature
# Make changes
git add example.code
git commit
git push origin 10-new-feature
# Oops... left a debug message, fix it.
git add example.code
git commit --amend
git push -f # Rewrites the remote history with your local modified version
Well, there are many more situations you can get into. Like cherry picking, force pushing, merge --no-commit, rebasing... almost any operation can end up going wrong. Just pay attention.
But he has the final solution to any git problem: cd .. sudo rm -r fucking-git-repo-dir git clone https://some.github.url/fucking-git-repo-dir.git
Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. Pe…
Certainly, it's got a lot of different switches and stuff, but since its data model is so simple, you can always understand what it's doing to your data. So you can read a description of what a switch does, and then understand exactly what will happen when you use it.
(The exception to this is automatic merge conflict resolution with rerere, which is just magic to me. But it's a bonus feature anyway)
For me, as a long time git user, git's UI and UX is approximately a bajillion times better than something like SVN, which can barely even do half the things that I use every day in git.
Maybe I haven't just dug deep enough into Subversion's manual, but can you tell me how to do the equivalent of "git log -p"? Last time I checked (SVN 1.8) that's not very trivial. Or how to revert a commit? IIRC that requires a merge.
So at least compared to subversion, git enables a workflow that was previously too much work, and gives me a better tool for working with version-controlled text data.
Mercurial is another thing I find puzzling, and I'm honestly interested why it is that people find it so much easier to use than git. I'm so used to working with throw-away branches that hg's default branching model just feels needlessly difficult to me, and good support for managing branches is the most important feature of a VCS, since any change you ever make is automatically a branch from the base. In git, this feels natural, since branches are a feature of the underlying data model, not something treated specially.
Just git reset should do. The --soft flag is implicit.
Amending and rebasing is something you should be careful with. If you've already pushed, you'll now need to force push. If another person has put new commits upstream, they will be wiped out irreparably. Not saying don't do it, just that it's very risky.
Instead of deleting and recloning the repo at the end, if you're really at that point, just doing git reset --hard origin/master should be equally as effective with fewer steps and less time.
Pulling down the repo a second time, however, can be more useful for just having a snapshot of the code in a second location that is totally independent of git traffic (don't pull to it very often). Say someone force pushes something that removes code. Your snapshot or someone else's non-pulled repo is your only hope of getting it back.
Actually the easiest thing is simply not to care about how your log looks. If you don't then there are ry only two things you need to know how to do: If you didn't push to origin do an ammend. If you did, revert soft and commit the previous code to revert it (you can also put a stash or patch to apply it back). Which frankly is what the article does, basically.
Having a messy and complex git log is not only about the visuals though. It can make it a lot harder to track down when/where/why bugs and problematic code was introduced. It makes both git bisect and git blame less useful.
I absolutely love git now. I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo. I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to…
Earlier quoted context omitted.
> Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.
Ah. My mistake. 16s is not a big deal, but I'm assuming it would get much worse for larger repositories. Personally, my searches are either: 1. Restricted to all files that end in cpp, h, py, pl, etc. 2. Explicitly exclude .hg directories. I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters ( .cpp, .h) and is usually the first item in th…
Things like search time are *not* a productivity bottleneck.
I happen to know that git grep is very carefully optimized. Someone cared a lot about making it run fast. Seems like a good guess that they did so because it was important to them or someone else, not just for funzies.
$ grep '^git grep' ~/.bash_history | wc -l
407
$ grep -w '^ls' ~/.bash_history | wc -l
37
$ wc -l ~/.bash_history
19421
Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. Pe…
God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easier to understand, but it never took off in a big way.
The problem, that I don't think anybody even expected, is that there are strong network effects on the selection of your CVS. That gives the tool that can handle more use cases a big advantage, and bigger still if those features are needed on the projects with more developers.