Git
-
[jinpa]$ git reset --soft HEAD~2
fatal: Cannot do a soft reset in the middle of a merge.
[jinpa]$ git merge --abort
fatal: There is no merge to abort (MERGE_HEAD missing).
[jinpa]$
-
@jinpa you appear to be in hell.
-
@jinpa On a possibly more productive note, what did you do to get Git to do this to you? Note, I don't want to hold out any hope of solving your problem, I just want to avoid doing this to myself.
-
@jinpa On a possibly more productive note, what did you do to get Git to do this to you?
I tried to solve a problem I was having with Git.
-
-
@jinpa On a possibly more productive note, what did you do to get Git to do this to you?
I tried to solve a problem I was having with Git.
The problem was "using Git." Now you can't use it. Problem solved.
-
@HardwareGeek said in Git:
@jinpa On a possibly more productive note, what did you do to get Git to do this to you?
I tried to solve a problem I was having with Git.
The problem was "using Git." Now you can't use it. Problem solved.
If only!
-
For me, the primary nightmare when using Git is running "git fetch" and seeing any branch coming back "(forced update)". It universally means that someone, somewhere, is fucking about, and if you are anywhere near that branch, you are going to have problems.
-
@jinpa you appear to be in hell.
Indeed. He's using git, therefore he's in hell.
-
@Steve_The_Cynic said in Git:
For me, the primary nightmare when using Git is running "git fetch" and seeing any branch coming back "(forced update)". It universally means that someone, somewhere, is fucking about, and if you are anywhere near that branch, you are going to have problems.
Did I happen to mention that I recently did
Well, I tried to, anyway, with my boss's blessing, to obliterate about 10 GB of compiled stuff that shouldn't have been checked-in in the first place. However, I lacked force_push permission, and he never got around to granting it to me.git push -f origin/master
?
It's only 10 GB.
-
-
@HardwareGeek you monster.
-
@jinpa you appear to be in hell.
Or at least some sort of limbo.
At least his head is in place.
-
@jinpa you appear to be in hell.
Or at least some sort of limbo.
At least his head is in place.
We don't know that for sure.
-
@Steve_The_Cynic said in Git:
For me, the primary nightmare
whenis using Gitis running "git fetch" and seeing any branch coming back "(forced update)".It universally means thatsomeone, somewhere, is fucking about, and if you are anywhere near that branch,you are going to have problems.FTFY.
-
I tried to solve a problem I was having with Git after having done something utterly stupid.
Here, FTFY.
-
@jinpa you appear to be in hell.
Or at least some sort of limbo.
I'm included to think that Purgatory would be more apt, but I suppose I could be persuaded otherwise.
-
@jinpa you appear to be in hell.
Or at least some sort of limbo.
At least his head is in place.
We don't know that for sure.
Indeed.
-
I tried to solve a problem I was having with Git after having done something utterly stupid.
Here, FTFY.
Probably. However, I'm one of those who thinks that an action isn't stupid unless you know enough to know better.
-
@levicki said in Git:
@jinpa That sentence broke my brain parser. Git is an extremely powerful tool and as such should be used with great care and understanding. Or if you can't be bothered, just use a cheatsheet. You don't try to drill a hole in your pecker using Black & Decker. Or maybe you do, and now you can't HEAD~2.
If you couldn't parse the sentence, I think that says a lot right there. As far as I can tell, it's a sound sentence.
You can, of course, disagree with the content or implication of a sentence you have no problem parsing.
-
@levicki said in Git:
@jinpa English is not my first language, but you could have said "An action is stupid if you do it knowing it may backfire". It conveys the same meaning without negations and does not require knowledge of language-specific colloquialism.
No, that would have had a completely different meaning. I understand that English is not your first language - I think a native speaker would have been less likely to have thought that those two sentences had the same meaning.
It's sort of like on the front page -- if I don't have much experience with a programming language, I try to avoid arguing with people who do.
But to end with a positive, your English is an order of magnitude better than my best second language.
-
@jinpa you appear to be in hell.
Or at least some sort of limbo.
At least his head is in place.
Not his fetch_head though.
:thatsthejoke:
-
@HardwareGeek said in Git:
Well, I tried to, anyway, with my boss's blessing, to obliterate about 10 GB of compiled stuff that shouldn't have been checked-in in the first place. However, I lacked force_push permission, and he never got around to granting it to me.
It's only 10 GB.That's what
p4 obliterateis for. Well, except that you're using Git.
-
@Steve_The_Cynic
p4 obliteratewon't help you if you don't have obliterate permission.
-
@Steve_The_Cynic
p4 obliteratewon't help you if you don't have obliterate permission.True, quite right. And of course a git equivalent of
obliteratewould require forced updates anyway, as it would rewrite history and consequently change the SHA1 commit IDs.
-
@Steve_The_Cynic I suppose the only reason
p4 obliteratedoesn't change commit hashes is because there's no such thing as commit hashes there?
-
@Steve_The_Cynic I suppose the only reason
p4 obliteratedoesn't change commit hashes is because there's no such thing as commit hashes there?More to the point, if they are there, they aren't used as commit identifiers. Perforce commit identifiers are simple serial numbers (e.g. 7859 - my most recent submitted changelist at home) attached to the changelist (== commit) in the same way that the commit hash is attached to the commit in git. If something amends a changelist (e.g. obliterate), the identifier doesn't change.
This sort of thing leads to a curious conundrum. In systems like Perforce or Subversion, which cope with history rewrite much less badly than Git does, people rewrite history much less often than they do in git.
-
@Steve_The_Cynic said in Git:
This sort of thing leads to a curious conundrum. In systems like Perforce or Subversion, which cope with history rewrite much less badly than Git does, people rewrite history much less often than they do in git.
It's mostly because of bad tutorials that list history rewriting as the best solution to many problems. People wouldn't rewrite history nearly as often if they weren't told it's the best thing they can do.
-
@levicki said in Git:
@jinpa That sentence broke my brain parser. Git is an extremely
powerfulunintuitive tool and as such should be used with great care and understanding. Or if you can't be bothered, just usea cheatsheetvisual studio. You don't try to drill a hole in your pecker using Black & Decker. Or maybe you do, and now you can't HEAD~2
-
I tried to solve a problem I was having with Git after having done something utterly stupid.
Here, FTFY.
Probably. However, I'm one of those who thinks that an action isn't stupid unless you know enough to know better.
I think you're wrong here. You consider it unnecessary to even share a glimpse of it which just might help pinpoint the solution. Which means that either you're ignorant enough to not even remember what the problem was or how you tried to solve it, but proud enough to not be willing to admit it, or that you know exactly what and how you screwed up but are so embarrassed that you're feeding any additional information by spoonful.
This reminds me of the folks who blame the bugs in the compiler for not compiling their typo-ridden code.
-
@Steve_The_Cynic said in Git:
Perforce commit identifiers are simple serial numbers (e.g. 7859 - my most recent submitted changelist at home) attached to the changelist (== commit) in the same way that the commit hash is attached to the commit in git.
So how does it cope with two people making commits to the same branch at the same time? I know that there are many possible ways — I know what SVN, git and fossil all do, and they all have different solutions, so I'm not making any assumptions here — so I'm genuinely curious which one is used by Perforce as I've never worked on a project that used it.
-
@Steve_The_Cynic said in Git:
Perforce commit identifiers are simple serial numbers (e.g. 7859 - my most recent submitted changelist at home) attached to the changelist (== commit) in the same way that the commit hash is attached to the commit in git.
So how does it cope with two people making commits to the same branch at the same time? I know that there are many possible ways — I know what SVN, git and fossil all do, and they all have different solutions, so I'm not making any assumptions here — so I'm genuinely curious which one is used by Perforce as I've never worked on a project that used it.
Perforce branches are in pathname-space rather than version-number space. It leads to ... oddities ... at times, especially in e.g. build files that contain absolute paths (STC slaps bad programmer with the hot end of a GAU-8), but it avoids certain other issues. And the other thing about Perforce is that it prefers exclusive-checkout for actual editing.(1) (In general, you branch into a namespace of your own choosing, work there, then merge back into the "master" namespace. That's hardly surprising, except that the namespaces in question are in file-path-name space.)
(1) On reflection, that's probably the answer to your question. Exclusive locking mitigates a bunch of problems, while creating others of its own. I like Perforce, but I wouldn't ever want to say that it's a perfect solution to anything, but that's true of git as well, and at least Perforce's error conditions are less ... opaque ... than git's. Let's finish this by adding two points:
- Lots of game companies use Perforce because its handling of binary artefacts (like texture files, map data, etc.) is extremely good, even if it, like all the others, remains unable to do meaningful diffs and merges on binaries.
- My Perforce depot at home is older than git. The oldest changelists I can find are dated in late summer of 2001.
EDIT: on reflection, when I said, "that's true of git as well", I meant the part about it not being a perfect solution, not the part about me liking it.
-
@Gąska Is there any legitimate reason to rewrite history instead of amending commits / creating new commits other than, say, mistakingly commiting secret data that mustn’t show up in the repo?
-
@Gąska Is there any legitimate reason to rewrite history instead of amending commits / creating new commits other than, say, mistakingly commiting secret data that mustn’t show up in the repo?
Amending commits is a form of history rewrite(1). If you've already pushed the pre-amendment commit, when you push the post-amendment commit, people who fetch/pull afterwards will receive "forced update" messages.
(1) It changes the commit hash, and is therefore indistinguishable from anything else that changes the commit hash.
-
@Steve_The_Cynic I obviously meant before pushing.
-
@Steve_The_Cynic said in Git:
when you push the post-amendment commit, people who fetch/pull afterwards will receive "forced update" messages.
You should really say "when you force push". The regular git push will give you a message that the post-amendment commit cannot be pushed to the repo because there are some commits you don't have in your local branch (obviously because you just clobbered them with the amend command).
The real
is then that the remote repository allows a force push from anyone (including the repo admins, who should know better).
-
The real
is then that the remote repository allows a force push from anyone (including the repo admins, who should know better).The real
is more serious: git has (by overt policy decision on the part of its cobblers-together(1)) no concept whatsoever of access control.(1) Normally I'd say "designers" but it's clear from the list of which commands do what that git was cobbled together rather than designed, so they are cobblers-together, not designers.
EDIT: clarification: what I mean is that git understands that there is such a thing as access control, but refuses to take any responsibility for it.
-
@Steve_The_Cynic I obviously meant before pushing.
Well in that case you need to distinguish which "the" repo you mean. Git is fully distributed, so there is no "the" repo, just lots of loosely linked local repos. This looseness is simultaneously git's greatest strength and its greatest weakness. Well, second-greatest, right after the lack of access control.
-
@Steve_The_Cynic Are we talking now about the lack of file locks or just about not being able to do bad stuff through
git push?The latter can be found in the Github help pages under "protected branches", and any other remote repository worth its salt should have something similar (I know we have force push disabled in our VSTS instance).
-
@Steve_The_Cynic said in Git:
when you push the post-amendment commit, people who fetch/pull afterwards will receive "forced update" messages.
You should really say "when you force push".
That's a largely futile distinction. The question of "force" or "not-force" is merely a mechanism for achieving (or not) a result (pushed the bogus(1) commit), and the problems arise from the result, not the mechanism.
(1) All pushes(2) of rewritten history are bogus, without exception. It may be that the bogus push was done to reverse a commit+push that was also bogus (for a different reason), but it remains bogus.
(2) That's slightly extravagant. I can actually think of one exception: if the organisation's "central" or "master" repo is backed up by IT people, I can push my "private" branch(3) from my local repo to the central one to get it backed up. If I rewrite on my repo, I'll still want to be able to push that rewrite.
(3) In this context, the word "private" means "not meant for others to use", since git's defaults don't really provide any way to enforce that.
-
@Steve_The_Cynic Are we talking now about the lack of file locks or just about not being able to do bad stuff through
git push?The latter can be found in the Github help pages under "protected branches", and any other remote repository worth its salt should have something similar (I know we have force push disabled in our VSTS instance).
Not sure. I'm not a git admin. I know that I've read substantial critiques of git's lack of in-built access control, and also that e.g. gitolite is an add-on rather than an inherent part of the system. (And it produces error messages that are beyond git's usual standards of opacity. Grr.)
The question that springs immediately to mind is: Is that stuff part of git or part of GitHub?
And don't forget that "remote repository" is grotesquely ambiguous. Does it mean a public-ish repository out in the Internet (example: GitHub's repositories) or does it mean a repository on a central server within a development organisation that is then cloned down to individual development machines? (The answer, of course, is that it means both, which is why it's ambiguous.)
-
So how does it cope with two people making commits to the same branch at the same time?
@Steve_The_Cynic said in Git:
And the other thing about Perforce is that it prefers exclusive-checkout for actual editing.(1) (In general, you branch into a namespace of your own choosing, work there, then merge back into the "master" namespace.
So.. what happens when people try to merge back to master at the same time?
Edit: I guess exclusive locking.
-
@Steve_The_Cynic said in Git:
@Steve_The_Cynic
p4 obliteratewon't help you if you don't have obliterate permission.True, quite right. And of course a git equivalent of
obliteratewould require forced updates anyway, as it would rewrite history and consequently change the SHA1 commit IDs.As I explained to someone (I think it was our local git expert, who was trying to help me do this), I'm trying to do the equivalent of
p4 obliterate, but in git, which doesn't make that easy.INB4, "Git doesn't make anything easy."
-
@Gąska Is there any legitimate reason to rewrite history instead of amending commits / creating new commits other than, say, mistakingly commiting secret data that mustn’t show up in the repo?
Or very large files that consume at lot of space in your repo. Simply deleting isn't the answer, because they are still in the repo and can be recovered by checking-out the appropriate commit. Removing them entirely requires making the repo forget they were ever checked in.
This isn't a huge problem in our case; our origin repo is in-house. But github doesn't like repos over 1 GB and flat-out refuses to deal with repos over 5 GB. ("No longer welcome here.") Some of our individual commits are bigger than that.
-
@Steve_The_Cynic said in Git:
it produces error messages that are beyond git's usual standards of opacity.
How is that even possible?
@Steve_The_Cynic said in Git:
or does it mean a repository on a central server within a development organisation that is then cloned down to individual development machines?
In our use case, that is the only thing it means. Our repo is not even in the same universe as "public-ish."
-
So.. what happens when people try to merge back to master at the same time?
Edit: I guess exclusive locking.At the same time, yeah. If one after the other, it'll complain if there are any conflicts, and the merge tools are fairly decent. If there are no code conflicts, but there are functional conflicts, the post-commit hook that launches the regression test suite will catch it. (You do have one of those — or pre-commit hook — right?)
-
You must create a repository and make some McGyver on it.
(I found this on StackOverflow, so it must be a valid solution. Unfortunately, the question has since been deleted, but I'm convinced it sums up the git experience.)
-
@HardwareGeek said in Git:
Some of our individual commits are bigger than [5 GB].
I am … disturbed, yet curious.
The largest commits I've had to deal with were in a project where an idiot "developer" put all the content images in a 140 MB .zip file and committed that, then rebuilt the .zip with each commit when content images changed. But that was PEBCAK, I'm assuming you had a legitimate case?
-
@DCoder I'm not sure you'd call it a legitimate case; if you want to claim we do version control wrong, I wouldn't necessarily disagree. (I've never met a hardware company that does it right. At least we know what branches are.) But if a problem exists, it's more of a PEBMAK.
We get code from an external development partner. When we get a new release, it goes straight into master, as-is. But it doesn't overwrite the previous version, nor even a new branch. It goes into a new directory, side-by-side with the previous version(s).
This code is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. As much as ~20 GB. For each release.
Then any tweaks we have to do to get it to work in our environment go into a bug-fix branch. Which then gets merged into master as soon as it's shown to be working.
The bug fix commits are fairly trivial; we've got this down to, usually, just one or two configuration files. It's the original, as-is, commit that is huge.
-
@uschwarz Welcome back, lurker!
