More stupid Git errors THIS TIME IN FIRST-PERSON!
-
[git-cola] sadly takes some elbow grease to get going on Windows.
It was relatively painless on Windows for me: I downloaded this zip file and run the exe it contained, which installed Python 2.7 as part of the process.
Git for Windows (if you have Git Bash you should be all set).
Yeah, I already had this, so that probably helped...
I read that they were working on some batteries-included installer, though I have no idea how far along they are.
Probably quite far?
:D
-
The fact you can break your computer with a hammer doesn't mean the hammer is broken.
I just took a look at the git man page for the first command that popped into my head, git-branch.
The most glaring issues that jumped out at me were the command line options:-m/--moveis actually a rename operation-Mis the same as-m, except it says it won't give you an error if a branch with that name already exists-Mbehaviour when a branch name exists is undefined. I'm assuming it means it will delete it if it exists.-dwill only delete a branch that has been fully merged in or one of any other "Yes I'm sure" operations done, while-Dis a "kill it with fire" operation. Oh, you accidentally pressed shift/capslock? Have fun diving through git internals to fix whatever you just screwed up!
A more appropriate analogy is that git is a hammer with shards of glass embedded in the handle. Sure you can do all kinds of great things with it.
But it still fucking hurts to use it.
Filed Under: WONTFIX ASDESIGNED
-
Competitor in terms of what? Number of features, being really good at any specific thing, or ability to integrate with other tools? Because if there was just one bad git gui, ok, maybe that's just bad design, but if nobody is able to create a git workflow that makes sense, at what point it's it safe to assume that the architecture is just inherently fucked?
I mean, I don't personally hate git, it seems to get the job done for me—though I've never needed any features from it that aren't present in just about every vcs—but the point is this self-congratulatory “git's not that hard to use, you must just be really stupid if you don't see how fancy it is, I heard git was spun out of real gold” shtick is pretty dumb.
-
-m/--move is actually a rename operation
mv, this is @Salamander. @Salamander, this ismv.-M is the same as -m, except it says it won't give you an error if a branch with that name already exists
Ok.-M behaviour when a branch name exists is undefined. I'm assuming it means it will delete it if it exists.
It will overwrite it. That's what the error prevents.....
@Salamander said:-d will only delete a branch that has been fully merged in or one of any other "Yes I'm sure" operations done, while -D is a "kill it with fire" operation. Oh, you accidentally pressed shift/capslock? Have fun diving through git internals to fix whatever you just screwed up!
Ok... Perhaps they should've used a--kill-it-with-fireoption?I'm not seeing the issue here with any of these honestly...
Filed Under: CLOSED: INVALID
-
mv, this is @Salamander. @Salamander, this is mv.
A) it's not even the same command name as mv and
B) git-remote rename, this is @sloosecannon. @sloosecannon, this isgit-remote rename.It will overwrite it. That's what the error prevents.....
That's your assumption. It never actually says what it does, so for all you know it could rename the old branch.Ok... Perhaps they should've used a --kill-it-with-fire option?
Or instead of having the safe commands differ from the unsafe-and-will-delete-shit commands by a single character being uppercase instead of lowercase, they could have used--force.
Which they do for other commands on the same man page.
This is a common trend with git, and it's why there are so many people who hate it, despite it having some otherwise really good features.
-
Competitor in terms of what? Number of features, being really good at any specific thing, or ability to integrate with other tools?
Competitor in terms of "does what I want in a VCS", which I guess most closely matches "number of features" in your list though with the added caveat that they are useful features.For instance, I miss
git add --patchso much that I wrote a script to give me that behavior (in a very poor imitation, but one that is still useful enough I use it with some regularity) in Subversion; if there wasn't a move to Git underway at the company I work for already, I might break down and write something that emulates Git's index along with better--patchemulation andadd --interactive. (I have also been sorely tempted to usegit-svn, but I tried using it a few years ago and remembered it not working so well, and suspect our current repository is way too monolithic to work reasonably. Though I think one or two people use or have used it or the Mercurial equivalent...)I'm also a heavy rebase user, and that's not supported by most VCSs.
Also
git stash.
-
That's the one where you choose which of lines you've edited get added to the commit? That just sounds like you're spending more time committing stuff to source control than I'd ever want to. I mean, I realize how half-ass that might make me sound, like I don't give a shit about my commit history, but I just haven't yet actually run into a scenario where that level of anal retention would have come in handy.
Edit: I feel like this post might have been somewhat unreasonable. Obviously everybody's going to have a different style of working, and it wouldn't be fair to prevent you from doing the kind of stuff that suits you just so some people can have a smoother experience.
Probably a better angle to take would have been to point out that these actions are actually almost entirely separate from the ‘repository’ aspect of source control, and your idea of having a separate tool to manage your uncommitted changes probably would have been a better way of doing things than baking those operations directly into the interface to your repo.
-
GIT stash is pretty great, though.
-
GIT stash is pretty great, though.
In TFS, your stash is on the server and you can pull it down from anywhere. Git's feature is a piece of shit by comparison.
Cue herd of morons coming in here to tell me Git can't keep it on the server because it's "distributed".
-
I can see how that would be handy, but I kind of feel like I should be telling you that I've never needed that feature and you're an idiot for wanting it, just for parity with the way I responded to @EvanED a couple posts ago.
-
And firstly, why should someone have to learn something that is strictly worse than the alternatives, for every use case that matters, just because that's what's in vogue in the industry right now?
The same reason I had to learn TTCN-3 - because he has to use it at work. The powers that be decided what they're going to use and he'll either play along or leave.-d will only delete a branch that has been fully merged in or one of any other "Yes I'm sure" operations done, while -D is a "kill it with fire" operation. Oh, you accidentally pressed shift/capslock? Have fun diving through git internals to fix whatever you just screwed up!
git reflog # to see your recent operations along with commit hashes git checkout $branch_name # it should checkout from remote; if branch doesn't exist there, add -b git reset --hard $hash_of_your_last_commit
-
With git we use temporary branches and push them if local stashing isn't enough. That is after you learn how to create branches and manage them so it might be a bit too advanced for you right now.
-
Not sure if patronizing or blakeybaiting...
-
Blakeyrat isn't allowed to make branches.
That's probably the main reason why he's having trouble.
-
Does being able to revert fuckups excuse making it so easy to cause those fuckups in the first place?
Yes or no.
-
-
I believe you mentioned only being able to create branches belonging to specific tickets a while ago?
-
Yesss?
Do you... do you understand that that is not the same thing as "Blakeyrat isn't allowed to make branches"?
-
Well wouldn't that be the
to creating temporary "stash"-branches?
-
Yesss?
And... so what?
-
git/git-rebase.sh at 77bd3ea9f54f1584147b594abc04c26ca516d987 · git/git
Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documen...
Why @blakeyrat was running a script named
git-rebase.sh, I have no idea.
-
By the way, the error message was added in 2005 by the original author of the script:
rebase: one safety net, one bugfix and one optimization. · git/git@7f4bd5d
When a .dotest from a previously failed rebase or patch application exists, rebase got confused and tried to apply mixture of what was already there and what is being rebased. Check the existence o...
-
Does being able to revert fuckups excuse making it so easy to cause those fuckups in the first place?
Look. I've never said git is easy. You get plenty of occasions to shoot yourself in a foot. More than most people are comfortable with. I know this, and don't like git much myself, for exactly this reason. But the "have fun diving through internals" retort just doesn't work in this case, because while it's very easy to fuck yourself up, it's equally easy to fix that stuff up after you do it.Unless you use GUI - then you're screwed.
Why @blakeyrat was running a script named git-rebase.sh, I have no idea.
Me neither. Windows doesn't have Bourne-compatible shell after all.
-
-
Well, someone on your computer was. Unless someone wrote a script that prints that message that isn't named git-rebase.sh...
-
I wasn't.
My best bet is that you were indirectly running this script because your GUI of choice hidden it behind a nice button labeled so you thought clicking it is a good idea.
-
We were talking about
git stash, which is a convenience feature. Tfs has an even more convenient feature. For you to come up with an awkward shitty slow way of doing the same thing as if that matters, well, maybe you need to reconsider your definition of ‘stupid’.
-
git isn't hard, you're just stupid
It's pretty obvious @hifi's entire ego is built around being good at shit like git. Try replacing git with any other product to see how ridiculous that attitude is:
- Windows isn't hard, you're just stupid
- Brainfuck isn't hard, you're just stupid
- Lotus Notes isn't hard, you're just stupid
-
>git isn't hard, you're just stupid
It's pretty obvious @hifi's entire ego is built around being good at shit like git. Try replacing git with any other product to see how ridiculous that attitude is:
- Windows isn't hard, you're just stupid
- Brainfuck isn't hard, you're just stupid
- Lotus Notes isn't hard, it's just stupid
FTFY
-
I didn't say TFS was bad or git was better, just that you can do the same thing with somewhat different approach on git if you know your tool, which blakeyrat doesn't. I've never even used TFS so how could I say anything bad about it?
-
Yes, I'm too stupid for brainfuck, you got me. Though, I wouldn't complain that brainfuck is broken just because I'm too stupid to write anything with it.
-
Or instead of having the safe commands differ from the unsafe-and-will-delete-shit commands by a single character being uppercase instead of lowercase, they could have used
--force.
Which they do for other commands on the same man page.
This is a common trend with git, and it's why there are so many people who hate it, despite it having some otherwise really good features.Process for implementing a new git command:
- Look at examples of git's existing commandline conventions.
- Smoke some crack.
- Fuck the existing conventions.
- What conventions?
-
Brainfuck isn't hard, you're just stupid
If you find Brainfuck, a language so simple you car write entire spec on your palm, too hard for you, then you're too stupid to live.Mind you, it doesn't mean it's easy to get something done with brainfuck. Digging ground isn't very hard to get, but it is hard to get done (say, if you need 10x10m hole, 5m deep).
On the other hand, git is hard at first, but difficulty curve flattens very quickly.
-
[code]
git pull
Updating 85c35cd..d938066
error: Your local changes to the following files would be overwritten by merge:
[some file names, but that's not important right now]
Please, commit your changes or stash them before you can merge.
Aborting
[/code]Um, actually, I'd prefer to pull the latest changes, and then see if my local changes actually compile and run before committing them. So I guess now I'll have to:
git diff --cached > changes.diffand hope thatpatch -p1 < changes.diffcan make sense of that (which it usually can...)- spend the next n hours futzing around with
git stashand risk git destroying all my uncommitted work becuase I used-Dinstead of-dsomewhere. - commit my untested changes anyway, and then hope I can use "Amend Last Commit" to finesse that change once I've actually got HEAD onto my local workspace.
- Fuck it all, and just have a broken commit.
Workflow!
-
Also, while I'm thinking about it:
Your local changes to the following files would be overwritten by mergeThat is not how merge is supposed to work.
-
I've been meaning to write a brainfuck interpreter in our inhouse business rules engine, just to prove that I can. But I haven't been bored enough.
-
You merge with a commit.... so actually, that makes a lot of sense. The local changes are uncommitted, so you can't make a merge commit without a local commit to base them on.
-
- I have local file X1 with some deltas in it. Let's call them ΔL
- Server has the file version X2, and knows the deltas between X1 and X2 (ΔS)
- As long as there's nothing conflicting between ΔS and ΔL, then we should be able to apply ΔS to my local file X1 to give me local file X2 with my changes ΔL still in it.
- I mean, that's how every source control I've used has worked.
Filed under: Anyway, this is now an academic discussion, as I just copied the files in question out of the way, did the pull, copied them back and reverted the changes which weren't my local ones, It'd be nice if we had tools to do that kind of thing for us though
-
Right, Git works that way too. It just needs to be committed first. Junk commits don't hurt anyone and you can get rid of them if you interactive rebase... (or just don't worry about em at all...)
-
Yeah, I'd prefer try to avoid rebasing if at all possible, as it seems more likely to cause problems than fix them.
Eh, maybe I'll give that a go next time. Intentionally checking in code which hasn't compiled and passed tests still seems weird to me though.
-
Yeah... I think that's part of the whole "distributed" mindset - Since it's still a local commit, the fact that it hasn't been tested isn't an issue. It only becomes a problem if you then push it.
I really wish this kind of stuff was better explained - that's one thing they don't do a good job of - Easy-to-understand documentation........
-
I often work on feature branches that don't pass tests in the middle of development, but I'd still feel weird committing non-compiling code. Part of me wonders though why I'm integrating upstream changes into a half-broken working copy to begin with - in our current working model I sometimes don't sync a project with upstream for several weeks, and I rarely have non-compiling code in my working copy for more than a day or so unless I'm doing a major refactor.
-
That's true. The other option is to upstream-sync after you finish your feature. Of course that doesn't work if you're working on the same thing with someone else...
-
git diff --cached > changes.diff and hope that patch -p1 < changes.diff can make sense of that (which it usually can...)
Two WTFs: first, you usedpatchinstead ofgit apply(yeah, this command name is WTF, but isn't that hard to remember); second, you saved your local changes to diff file instead of stashing them.spend the next n hours futzing around with git stash and risk git destroying all my uncommitted work becuase I used -D instead of -d somewhere.
Before pull:git stash. After pull:git stash pop. Seriously, stash is probably the easiest git feature to learn. And there's no -d nor -D anywhere.commit my untested changes anyway, and then hope I can use "Amend Last Commit" to finesse that change once I've actually got HEAD onto my local workspace.
Hint: if you dogit pull --rebase(or-r), all your local commits will be reverted, then reapplied as if you worked with the new version (the one you just pulled) right from the start; then, after resolving conflicts if they happened, you can dogit reset HEAD^and pretend you never made this broken commit. This lets you keep nice history. Though personally, I'd still use stash.Fuck it all, and just have a broken commit.
If you make any mistake, you can alwaysgit reset --hard $hash_of_commit_you_want_to_start_over_with. All your commited changes are still there in repo, just not attached to any branch - and if you forgot to write down the hashes, you can always usegit reflog.
-
And @Gaska tells you how to preserve your workflow
His Git-fu is more powerful than mine
-
His Git-fu is more powerful than mine
Maybe, but I'm still a beginner. I still have no idea what the fuck read-tree even though it saved my ass a few times (I have a coworker who's guru of all things Linux-y, but he's terrible teacher so I hardly ever know what I'm doing when he dictates all those magic spells to me).
-
Two WTFs: first, you used patch instead of git apply (yeah, this command name is WTF, but isn't that hard to remember);
*sigh* of course it's
git apply, there's an outside chance that an unitiated person is going to trygit patch...And people wonder why git has this reputation for being hard to use.
-
I love how you ignored all the parts of my post that say you're not even trying to learn git, and focused only on the single line where I mention an actual fuckup of git's authors, saying how terrible it is as if I didn't already say that.
-
But we do agree that it's a fuckup right?
-
Yes. It doesn't change the fact you were ranting about problems that don't exist.
