More stupid Git errors THIS TIME IN FIRST-PERSON!

blakeyrat

The conflict resolution can take place in a virtual repo separate from the (completely intact and working) actual repo. To give just one solution totally off the top of my head.

boomzilla

And then the virtual repo has the state? But isn't the state of the repo now, "has virtual repo?"

blakeyrat

The state is "my boot to Boomzilla's face".

Stop it. I'm not going to participate in your little game, fuck off.

Jaloopa

I'm confused. What's the state of @boomzilla's game and is it dirty?

boomzilla

@blakeyrat said:

Stop it. I'm not going to participate in your little game, fuck off.

Then stop your nonsensical babbling about state because it's retarded. Just throw some "poop"s or "fart"s in there so we know you're just shitting around and not speaking like a serious person.

JBert

@Yamikuronue said:

Sure. But Git has more of them. So we've moved the wrong direction IMO.

I believe the only controversial one is the staged/index/cached state (yes, 3 names for the same state

), and I like it when using git-cola. It basically fits my chaotic development style whereby I might make a ton of changes in documentation and code alike, then commit those seperately. While TortoiseSVN has recently started offering something, it works inverted: you need to mark your changed files for backup, then modify them so the only stuff going into the commit are the changes that remain. In the end though, the staging area should have been optional.

Most other states exist in other version systems as sub-states: they hardly make a difference between "you have changes" and "you have changes with version conflicts on top" - or at least they don't before clobbering your files with those conflicts.

pdemanget

That is fun, I used to like Git and Lotus Notes. But I also blame git very often for being so obscure.

Yamikuronue

...What is your workflow and how is it different than Tortoise SVN's "Here's all the changes we can find, check the boxes for the files you want to commit." Are we talking breaking one file's changes into multiple commits per code block or what?

Shoreline

@blakeyrat said:

It's almost as if... GUIs are better at user interaction than CLIs? Hm!

@blakeyrat said:

SourceTree is fucking awful.

Relativity applies. What do you recommend?

@Jaloopa said:

What's the state of @boomzilla's game and is it dirty?

If so, I want in.

blakeyrat

@Shoreline said:

Relativity applies. What do you recommend?

Nothing. All Git GUI clients suck ass.

If your server supports HTTPS, use Visual Studio's in-built one.

If not, GitHub for Windows to push/pull and VS to do everything else. GitHub for Windows doesn't do merge conflicts and (on my machine at least) is incapable of creating commits for mysterious reasons their support guy couldn't figure out.

JBert

@Yamikuronue said:

Are we talking breaking one file's changes into multiple commits per code block or what?

Pretty much - though it obviously depends on what I'm working on that day. There are days where TortoiseSVN's "stage all" would be fine as well.

On a related note: TortoiseGit works like TortoiseSVN: it's complete files or the modification dance.

EvanED

@Yamikuronue said:

Are we talking breaking one file's changes into multiple commits per code block or what?

That's one of the things I talk about. git add --patch alone is enough, for me, to make up for the occasional annoyance of git. At the command line, the index is also (IMO) often far, far more convenient to use than having to list every file you want to commit in a single svn commit command. And that's ignoring add --interactive...

Git's implementation of the index has completely changed the way I work with version control, and I miss it deeply when I'm using a different system.

sloosecannon

@blakeyrat said:

If I understood Git, would that error message magically turn into a better one? Would it's instructions for resolving the problem magically become correct?

Well I understood it. And I think I understand Git. So....

blakeyrat

@sloosecannon said:

Well I understood it.

I understood it too, that doesn't make it a good error message.

I understand it well enough to know its directions for removing the corrupted files is DEAD WRONG on the OS it happens to be running on.

sloosecannon

Eh, not if you use Git Bash. Which is the "correct' way to use it. So actually........

blakeyrat

More rebasing fun and joy:

git -c diff.mnemonicprefix=false -c core.quotepath=false -c "sequence.editor='C:\Program Files (x86)\Atlassian\SourceTree\stree_gri'" -c "core.editor='C:\Program Files (x86)\Atlassian\SourceTree\stree_gri'" rebase -i --autosquash X
Rebasing (1/3)

error: could not apply X

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Could not apply X

Completed with errors, see above.

Resolved WHAT problem? You didn't tell me about a problem. You just said "could not apply". Git: the software you have to be telepathic to use!

bugmenot

@blakeyrat said:

The conflict resolution can take place in a virtual repo separate from the (completely intact and working) actual repo.

Blakey! Baby! That's exactly what 'git stash' is for. Stash your uncommitted changes, fool around with whatever operations you have to make, and 'git reset --hard $BRANCH && git stash pop' if everything blows up in your face.

bugmenot

@blakeyrat said:

> error: could not apply X

When you have resolved this problem, run "git rebase --continue".If you
prefer to skip this patch, run "git rebase --skip" instead.To check out the
original branch and stop rebasing, run "git rebase --abort".
Could not apply X
Completed with errors, see above.

Resolved WHAT problem?

I bet that you were rebasing three commits. Know how I know?

Rebasing (1/3)

Git -like all VCS software- stores each new revision as a diff between the new revision and the previous one. It's natural -when replaying history- to apply these diffs to arrive at a given revision.

So, if the application of a diff fails, "Could not apply such and such diff" is a natural thing to say. Even the folks who'd never touched anything but a Windows box in their professional lives back at that Windows-only shop I worked at knew what it meant to apply a diff or patch to a file.

I also bet that both instances of "apply X" in the error report is a redacted "apply $SHORTLOG_THAT_YOU_DONT_WANT_US_TO_SEE".

If you chill for a second and think about what the software is telling you about, it becomes easier to use. :)

blakeyrat

@bugmenot said:

I bet that you were rebasing three commits. Know how I know?

Rebasing (1/3)

HOLY SHIT ARE YOU SHERLOCK HOLMES!?

@bugmenot said:

Git -like all VCS software- stores each new revision as a diff between the new revision and the previous one. It's natural -when replaying history- to apply these diffs to arrive at a given revision.

Ok.

@bugmenot said:

So, if the application of a diff fails, "Could not apply such and such diff" is a natural thing to say.

How about saying why it failed? Did that occur to you?

How can applying a diff fail anyway?

@bugmenot said:

I also bet that both instances of "apply X" in the error report is a redacted "apply $SHORTLOG_THAT_YOU_DONT_WANT_US_TO_SEE".

I have no idea what this means. If you think I'm purposefully holding back information, you're crazy... what I quoted is literally all I saw. The only thing I redacted is the name of the commit because it could give away what company I work for.

@bugmenot said:

If you chill for a second and think about what the software is telling you about, it becomes easier to use.

Explain how "thought" can solve this for me.

Because what I think is it's telling me gibberish.

EvanED

@blakeyrat said:

How can applying a diff fail anyway?

Conflict. Same as when you update in, say, Subversion. It's waiting for you to resolve the conflict and then resume the rebase.

Admittedly, the error message should say that; "conflict" and "resolve" are the term used basically universally by version control software. Not that Git cares about that, as much as I like it overall.

EvanED

@bugmenot said:

Git -like all VCS software- stores each new revision as a diff between the new revision and the previous one.

Point of order: this is actually not true. Git does not store diffs; it stores every full version of a file and relies on compression to not be a glutton with space. (Which... works much better than I'd have ever expected -- its repos are usually smaller than Subversion repos, which do store diffs -- so.. whatever.) Though this is mostly an implementation detail and doesn't affect the resolution here, because it's doing the same thing (applying diffs, just it has to compute them first).

svieira

@Yamikuronue said:

If it takes multiple steps and you can do other things in between the steps, it's not atomic. It's been divided.

Chuckles True - however, if I do:

BEGIN;
INSERT INTO MyMagicTable (anIntThatIsConstrainedToBeGreaterThanZero)
VALUES (0);

the INSERT is still atomic even if the transaction extends beyond the life of the call.

In the same way the merge is atomic (either the changes are added to the commit log or they are not). The transaction around the merge holds until you either git reset --hard COMMITISH (ROLLBACK) or vim problem/file{s} + git commit (ROLLBACK + edit + re-run transaction). That doesn't change the atomicity of the merge itself.

@blakeyrat said:

Either that or ~~you~~ [I] don't understand what the word "atomic" means when applied to software. [ ]

Circuitsoft

git -c diff.mnemonicprefix=false -c core.quotepath=false -c "sequence.editor='C:\Program Files (x86)\Atlassian\SourceTree\stree_gri'" -c "core.editor='C:\Program Files (x86)\Atlassian\SourceTree\stree_gri'" rebase -i --autosquash X

Holy f**k, that's a screwy way of doing a rebase.

So, what happened here is that SourceTree made a new branch called X pointing to 3 commits back from where you are, then asked Git to do an interactive rebase onto that point, and pointed to its own internal tool as an editor, which I assume did something non-interactively with the spec file it was passed, and never gave you any chance to interact, thus making you even more confused.

Blame SourceTree. I have no idea what it was tying to do, but there are much easier ways to do that programmatically.

What you could do at this point is run "git status" which should tell you about any conflicted files so that you can deal with merge/patch-apply conflicts. Once the files are in a good state, run "git rebase --continue" and you're good to go.

Masaaki_Hosoi

Can't tell you how many GIT repos I've accidentally nuked with simple mistakes. It's a lot like working with Linux, really.

Of course, whenever I relay these experiences to people who actually like Git (for whatever reason), they are almost invariably quick to tell me that it's easier to fuck up a repo with SVN. Somehow.

blakeyrat

@EvanED said:

Conflict. Same as when you update in, say, Subversion. It's waiting for you to resolve the conflict and then resume the rebase.

How could their possibly be a conflict when I'm doing a rebase? I was just (trying to) merge 3 perfectly normal commits into one and change the message on it. If there was some conflict, wouldn't I have seen the conflict when I made the commits in the first place? Hell, conflict with what? It's all code in my own branch!

@Circuitsoft said:

Holy f**k, that's a screwy way of doing a rebase.

Blah blah blah, point is, it's fucking broken.

@Circuitsoft said:

What you could do at this point is run "git status" which should tell you about any conflicted files so that you can deal with merge/patch-apply conflicts.

No i can't. Because when I hit "ok", it rolled-back to the starting "state".

@Masaaki_Hosoi said:

Of course, whenever I relay these experiences to people who actually like Git (for whatever reason), they are almost invariably quick to tell me that it's easier to fuck up a repo with SVN. Somehow.

They're full of shit. I used Subversion for like a decade. I had more problems with Git in the first 3 months of me using it than I did in the entire decade of using Subversion.

gleemonk

Can't remember the last time I'd fucked a Git repo so badly I had to clone it again. But then, working with a system teaches you to avoid pitfalls and teaches you how to get out of its pitfalls at the same time. 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 experience this CLI reliance myself because we use Git to develop and deploy websites, and most of my peers have no programming much less CLI background. I get a constant stream of microwtf from them (I'm fine thank you). They'd started to collect these CLI lines we'd used to unfuck the repo from the state a GUI tool had inflicted. Now for some tasks they use the CLI direct because the graphical tool would likely mess things up again. So I can see how in Git if you can't accept the CLI you'll end up as unhappy ranter.

blakeyrat

@gleemonk said:

But then, working with a system teaches you to avoid pitfalls and teaches you how to get out of its pitfalls at the same time.

Why don't we all just adopt a system without the pitfalls in the first place?

@gleemonk said:

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 highly doubt it would work any better if I were using a CLI.

@gleemonk said:

I experience this CLI reliance myself because we use Git to develop and deploy websites, and most of my peers have no programming much less CLI background.

Then picking a source control system that relies on a CLI interface was a pretty stupid decision for you, wasn't it?

ChrisH

Makes me glad (again) to work in an all-Microsoft shop using VS, TFS and SQL Server only.

Being able to tell underlings to fuck off when they come and ask if they might be allowed to use git as a frontend is pretty satisfying as well. I used to do that just on gut feeling (you WILL use the tools provided and you will LIKE them), but it sounds like there are objective reasons as well. All the better.

flabdablet

@boomzilla said:

And then the virtual repo has the state?

It comes off the old bed, and goes on the TV!

Filed under: voom

sloosecannon

@blakeyrat said:

How could their possibly be a conflict when I'm doing a rebase? I was just (trying to) merge 3 perfectly normal commits into one and change the message on it

!

In what world does a merge not have the ability to cause a conflict?

blakeyrat

@sloosecannon said:

In what world does a merge not have the ability to cause a conflict?

In the world where the changes are in one single branch in one single repo, and the merge is merging each commit with the one preceding it.

sloosecannon

@blakeyrat said:

In the world where the changes are in one single branch in one single repo, and the merge is merging each commit with the one preceding it.

Because that's always the case with a rebase, right?

Jaloopa

@sloosecannon said:

Because that's always the case with a rebase, right?

It was in this case, as he's already said

sloosecannon

@Jaloopa said:

It was in this case, as he's already said

Correct.

I'm pointing out the cognitive dissonance that was invoked by
@blakeyrat said:

How could their possibly be a conflict when I'm doing a rebase? I was just (trying to) merge 3 perfectly normal commits into one and change the message on it

FrostCat

@Masaaki_Hosoi said:

it's easier to fuck up a repo with SVN.

Yeah, that doesn't excuse git, though.

FrostCat

@sloosecannon said:

cognitive dissonance

But in this case, the "merge" is really just "collapse three sequential commits down into one."

blakeyrat

@sloosecannon said:

Because that's always the case with a rebase, right?

I don't give a shit. That's the case for what I'm doing. Maybe you're off in la-la-land, but I'm not describing some hypothetical error that happened to a theoretical purple elephant on Mars, I'm describing an actual error that actually happened to the actual me.

And why that error message makes no sense and is stupid and is probably a bug in Git.

hifi

There are no good git GUIs that I've tried and anything that tries to wrap around git CLI is broken and should be avoided without exceptions.

Yamikuronue

@hifi said:

~~anything that tries to wrap around~~ git ~~CLI~~ is broken and should be avoided without exceptions.

BRTFY

gleemonk

@blakeyrat said:

Why don't we all just adopt a system without the pitfalls in the first place?

Because a system without the pitfalls would be a lame system that wouldn't allow doing advanced shit. We could argue endlessly which implementation is better regarding its protection against pitfalls. I would not want to live in a world where you get to decide what is good for us all.

@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.

@blakeyrat said:

Then picking a source control system that relies on a CLI interface was a pretty stupid decision for you, wasn't it?

You be the judge :-) Consider that we'd been using Subversion before that, and that the switch was generally perceived as a liberation.

Planar

@gleemonk said:

willfully malcontent mind

Best description of Blakeyrat ever.

blakeyrat

@gleemonk said:

Because a system without the pitfalls would be a lame system that wouldn't allow doing advanced shit.

I don't want to do "advanced shit". I want basic shit to work. And in any case, the two aren't mutually-exclusive.

lightsoff

It would appear that the problem is that you've taken a perfectly serviceable car, ripped out the transmission and brakes and replaced them with jelly.

And you're now blaming the car manufacturer because the clutch is spongy.

blakeyrat

What the fuck are you talking about.

Vaire

@blakeyrat, I love you
I signed up for an account just to be able to say that. You amuse me greatly. You're like the grumpy cat of professional programmers. Your posts are just, delicious
And I agree with you, git can die in a fire

FrostCat

@Vaire said:

I signed up for an account just to be able to say that.

You probably just made him sad given how much he hates Discurse. You've increased its usage!

Buddy

@ChrisH said:

Being able to tell underlings to fuck off when they come and ask if they might be allowed to use git as a frontend is pretty satisfying as well. I used to do that just on gut feeling (you WILL use the tools provided and you will LIKE them), but it sounds like there are objective reasons as well.

YOU are the problem.

ChrisH

@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?

Buddy

I'd prefer it if people would put a bit of rational thought into choosing an appropriate tool for the job. People basing shit on gut feelings and telling anyone that disagrees with them to fuck off like it makes their dick hard is exactly how we ended up with with git as the industry standard in the first place.

Gąska

@Masaaki_Hosoi said:

Of course, whenever I relay these experiences to people who actually like Git (for whatever reason), they are almost invariably quick to tell me that it's easier to fuck up a repo with SVN. Somehow.

Have you ever had to restore trunk after some idiot deleted it? We had such accident once at my company. Took three days to fix all the mergeinfo.