More stupid Git errors THIS TIME IN FIRST-PERSON!
-
Have you ever had to restore trunk after some idiot deleted it?
yes.
fortunately I had pulled just before the inopportune deletion, so i was able to fix it by swearing at the contractor in Russian* and just did a
git push --forcefrom my repo, that restored like all but three commits.* actually i was shouting the recipe for my grandmother's spaghetti bolognese. but the contractor didn't know that.
-
I was talking about SVN.
-
ooooh.
yeah no.
that's called "recover from backups" where i came from.
-
The whole point of having VCS is backup of everything! Why should I ever backup the database of all backups!?
-
because you're not an idiot that trusts in only one level of backups.
-
I think backing up backups is idiotic. Having multiple copies of backups, however, is perfectly reasonable.
-
so you don't do a backup of the server your central VCS is stored on?
i mean that's okay if you're using a DVCS like git because all the clints have the full metadata to restore from, but for SVN they don't necessarily have that metadata.
and anyway rebuilding servers sucks. far better to have a backup to restore.
-
Better back up that server git repo, because two git repos are not necessarily identical after a sync.
And yes, Subversion needs backups too. While it has improved greatly, back in 2008 only the BerkeleyDB storage was stable. It needed manual cleaning every time the server crashed, and thanks to some dodgy mirroring this could happen often back then.
-
point taken.
see backups are good! and the VCS repository should NOT be your only level of backup.
-
I highly doubt it would work any better if I were using a CLI.@gleemonk said:
Gleemonk I think has a point, though I think put blame in the wrong place. GUI/CLI isn't really the issue, but most of the non-terminology problems you've posted here are primarily or entirely the result of whatever the hell SourceTree is doing on top of Git, and most or all of the rest are missing features of the GUIs you've used. So "switch to the Git CLI" would be an effective, if unnecessary diagnosis; I used TortoiseGit when I was on Windows and that both seemed to work and is more feature complete than the MSVS plugin (in particular, supporting stash). Then again, while I have a few complaints about it, Git is one of the few pieces of software that I actually like using as opposed to just tolerate, so I have whatever particular brand of brain damage makes someone say that and maybe you should take that Tortoise recommendation with a grain of salt.You have to accept how the tool works though, and with Git it seems that relying on a GUI is not how it works.
(I also realize you don't have the freedom to pick your tools, but realize that the blame for your problems is mostly not with Git.)
-
Have you ever had to restore trunk after some idiot deleted it?
Hah, that happened at my company too. The log for the commit that restored it was "Well that was bad."Took three days to fix all the mergeinfo.
I wasn't around at those points, but I don't think it caused much of a problem. But, I'm equally sure that there was no need to worry about mergeinfo at that point. (Hell, I'm not sure anyone uses mergeinfo now. We don't work in a super branch-heavy manner, and I think everyone who deals with branches just got used to using Subversion before it supported it. And soon we'll be switching to Git and that point becomes moot...)
-
-
@Buddy said:
YOU are the problem.
So you'd rather have each and every one of your colleagues using whatever shitty tool tickled his (yes HIS you microaggressionist gender bullshitting idiots out there) fancy that day?This is how we do this where I work. It has its pros but many cons with it. Would not recommend, 2/10.
-
-
What I said before about bad git GUIs mostly comes from SourceTree. Just wrapping up a half ass GUI on top of a CLI program is what makes SourceTree a horrible program to use. It does all kinds of magic and hides you intermediate steps which would help you understand a problem when you encounter one but instead it just shows you the raw error from git CLI, yay.
Worst thing many new git users do is when they encounter a problem, any problem, they clone the repo again and do something differently completely ignoring the state they ended up before. This way of problem solving just makes them end up in the same situation more often than not and then again blame the tool like blakey here does (which was amusing to some point).
@blakeyrat, you have many good points about user friendliness but honestly I think most of it is SourceTree being utter crap or GitHub for Windows (hint: both are CLI wrappers). Just stop using them and use the CLI like suggested. The CLI isn't the most user friendly tool because it was originally written by that lunatic you keep referring to but it does get the job done when you know how to use it and it has never let me in unrecoverable state.
Read Pro Git or use it as your reference when you want to do something. Try to understand the process of going from A to B instead of just hitting your keyboard blindly until an error comes up and you get another reason to rant. Complain again after you've solved a problem correctly and git made it too complicated for you than it would need to be in your ideal world.
Not knowing how git works or using broken GUIs is a bad excuse to complain it's broken. It's like complaining driving a brand new manual transmission car is hard because you've never been properly taught how to use it and that automatic transmission of that 20 year old Volvo was sooooo much better. Git requires you to use the clutch and stick and it comes with a lot of gears.
-
-
-
given our relative positions i've got to say, i don't find your version particularly funny actually.
:-/
-
@blakeyrat said:
I highly doubt it would work any better if I were using a CLI.
I have the opposite assumption. My limited exposure to GUI interfaces left me with the impression that they break down as soon as I try to do anything remotely advanced, leaving the repo in a state they don't know how to fix. Maybe the situation has improved now.
CLI interfaces, on the other hand, do exactly what you tell them to do.
Meaning you break the repository just as badly, but now it's your fault for not being able to figure out what no git GUI could figure out either.
-
I'd prefer it if people would put a bit of rational thought into choosing an appropriate tool for the job.
I'm not talking about choosing a tool - we did that very carefully and TFS does everything we need (and lots of things we don't (yet)).I'm talking about having an established and working toolchain and then individual developers wanting to use Sublime because they don't like VS's colour scheme or something, and git because they are used to fucking around on the command line instead of just using the TFS client integrated into their IDE.
This is how we do this where I work. It has its pros but many cons with it. Would not recommend, 2/10.
It's how they did it at my last place of work as well, which contributes a lot to the dick hardness I get out of the current situation (thanks for that, @Buddy)
-
so you don't do a backup of the server your central VCS is stored on?
Yes, I don't backup. I make mirrors though. It protects me in case the main server goes down. I don't need protection from data corruption - if you do, then your VCS sucks balls.
-
Yes, I don't backup.
then i pray that murphy never strikes you.
I for one will have the servers backed up because i'm not willing to lose the time it takes to rebuild them when they fallover. and they will eventually, even with the best sysadmin in the world servers age.
-
I don't backup. I make mirrors though
And when somebody accidentally the whole thing, then what?
-
Accidentally the whole network? Well, fuck.
-
I don't see why it's anyone's business what I do in my own local repo. Stuff like that goes in the remote in a receive hook, not in a local pre-commit hook. I want to be able to make shitty test branches or be able to make lots of commits that I may throw away or combine and/or split with
rebase -i.I'll push things that are ready to be pushed and I think it makes perfect sense that I am not allowed to push whatever I want. But until then I want to be able to do my job without getting nagged by management's mandatory micromanagement tools. I don't want to have someone write a program that keeps checking if I'm making a mistake, before I've made it in any real sense.
-
See, if you're using git and have your own local repo, the hook would be run before a push was accepted, not before a commit. SVN is centralized; it's nobody's business what you do in your own working copy, but once you try to commit to the repo and impact other people, it runs the precommit hook.
I wouldn't do the same things in git as I do in svn because the underlying model is different.
ETA: I'm leaving the above paragraphs alone, but I've just realized this is the Git thread, not my SVN thread, so it's mostly irrelevant. Sorry about that.
-
No wonder, where I work the only Windows user is the one still struggling with
gitafter 2 years. I think the tools there suck more. He does not want us to remove any code from repo, thinks the code is lost to him, and still pushing binary blobs, and zip files like it is dropbox. The only times I have had to struggle with git were when I had to remove his huge binary blobs from history to avoid slow pulls. I have to check if there is an add-on for git (gitlab actually) to automatically ignore certain file types (or sizes), or make them un-versioned at least.One has to agree the CLI git commands are not well-thought-out or even consistent, there should be some easy-to-remember commands for normal work-flow. Some throw-away commands mostly for beginners with non-cryptic syntax. For example I always install git-up, and it helps A LOT, maybe it should be part of git already. Some git extension that cleans up the bad old choice of command names in git CLI (like something as simple as removing a remote branch) also would be nice without the curse of backward compatibility.
-
I'm kind of at the point where I'll do a
git clonefrom the command line, and then just usegit guifor most of any git interactions. (And also, outside of "Amend last commit", I don't bother with rebase, as the costs vastly outweigh the benefits.)
Aside from the fact thatgit guibasically sucks, and has no keyboard acceleration whatsoever, it will allow you to commit, review and push changes out of your local repo. Although every now and again, something like this will happen, just to keep things fresh:
Bonus
git guifeature for Windows users though:
Wait, that's not a feature. That's a bug...
-
Bugs in Git?!??!? WHAAAA!
-
-
-
You have any other way to diff and check in parts of a file in a semi-sane manner [other than
git gui]?
-
git add --interactive, as alluded to up-thread?
-
Also
git add --patch, which is like a shortcut to the "patch" command in--interactive.
-
Name even one that's not caused by shitty GUIs or your incompetence.
-
You have any other way to diff and check in parts of a file in a semi-sane manner [other than
git gui]?
I think I posted it before, but here it goes again:It's basic as in essence it does what
git guidoes, just with less trouble.
It has at least a decent menu bar (git guihides basic stuff in context menus all over the place), handy context menus in the index list and diff view, decent shortcuts and a small prefences section.
-
git-cola
I will investigate this. Everyone else seems determined to propose the git command line as an option, and we all know that it really isn't.
Now, if TortoiseGit could do partial file commits... eh, a man can dream...
EDIT:
git-colaseems good enough to replacegit gui(not that that's a particularly high bar to clear). I'm willing to overlook the fact it's written in Python.Filed under: using Python to fix your git problems seems a bit like intentionally contracting gonorrhea to cure syphilis...
-
I just use git-gui for 99.9% of what I do, and drop to command-line if I really need to do something weird.
Which so far has happened roughly twice, I don't recall why or what I did, but basically I just followed the instructions and it did whatever it was that I needed at the time.
Will look at git-cola, sounds like it's better.
A colleague has finally realised that they really should be using a VCS instead of dated ZIPs, and git is basically the only choice as they just want a local repo that they can back up - rather than jumping into the actual corporate VCS server and being scared of trashing something important.
-
git is basically the only choice as they just want a local repo that they can back up
There are several options aside from Git; Mercurial is another very strong contender of course, and then there are other, much less widely used, options. Or there's use the corporate VCS...
-
Should have added "that is used in the company".
It's irrelevant as to whether Mercurial is better, worse or indifferent as nobody here uses it, so nobody could answer their questions about it, daft or otherwise.
-
@Buddy said:
I'd prefer it if people would put a bit of rational thought into choosing an appropriate tool for the job.
I'm not talking about choosing a tool - we did that very carefully and TFS does everything we need (and lots of things we don't (yet)).I'm talking about having an established and working toolchain and then individual developers wanting to use Sublime because they don't like VS's colour scheme or something, and git because they are used to fucking around on the command line instead of just using the TFS client integrated into their IDE.
Ok, VS also has a git client baked in, so I'm not sure what the problem is there. More importantly, are you saying you not only disregard the people who work for you's preferences for how they collaborate with each other, but you actually go in and set rules about what they can and can't do on their own machines? Did you know that the most common complaint about team fortress is that the main people who like it are micromanaging fucktards who want to lock down everyone's access to everything? Way to fit that stereotype to a tee.
-
Name even one that's not caused by shitty GUIs or your incompetence.
Holy shit, I'm causing bugs in Git? I've never even downloaded the source code!
Am I... am I a wizard!?
-
The fact you can break your computer with a hammer doesn't mean the hammer is broken.
Also, before you inevitably call me a moron for thinking you have ever swung a hammer near anything electronic, know that I have a habit of talking in metaphors. Yes, metaphors are harder to interpret than straight forward text, but they make the discussion more colorful.
-
EDIT: git-cola seems good enough to replace git gui (not that that's a particularly high bar to clear). I'm willing to overlook the fact it's written in Python.
@lightsoff said:Will look at git-cola, sounds like it's better.
I don't know if you installed it already, but if you didn't I think you should heed this warning: it installs and works without effort on Ubuntu, but it sadly takes some elbow grease to get going on Windows. You basically will need Python, a matching PyQt installer and a working version of Git for Windows (if you have Git Bash you should be all set).I read that they were working on some batteries-included installer, though I have no idea how far along they are.
-
No, because it's a shit metaphor. Blakey didn't type
git rm -rf /; he's just trying to get a level of usability out of it that he already knows is possible from a vcs.
-
-
It's so unlike you to talk about yourself in third person... wait it wasn't Blakey
Anyway, git isn't that hard. It is hard, but not that hard. Remeber we're talking about professional programmer with years of experience here. If he wanted to learn how to work with git properly, he would already. But he won't, because he has strong aversion to CLI, and CLI is the only way to work with git properly. I don't know why, but every single git GUI thingy is absolutely terrible - both in appearance and functionality. They're terrible user experience even by open source standards. But Blakey will rather suffer endless unknown errors than learn this dozen of commands he needs and be done with it, because fuck you that's why.
-
Clown vomit!
It isn't very colorful. Been there, done that. Don't ask me more about it, okay?
-
Firstly, this comparing-people-to-blakeyrat meme is pretty fucking tedious.
Firstly, I'd rather be a rat for actually reading what someone said and trying to comprehend their point of view, than a goose whose signature move is willfully misinterpreting people's arguments.
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?
-
And firstly, why should someone have to learn something that is strictly worse than the alternatives
"Alternatives". IMO there's only one competitor for Git that I'd consider in 98% of cases (not restricted by things otherwise in use by the organization or whatever), and that's Mercurial. I don't want to get into a debate about which is better overall and I almost don't care, but I definitely think that neither is even close to being strictly better than the other.
