More stupid Git errors THIS TIME IN FIRST-PERSON!

blakeyrat

Begging the question about the desirability of the features to begin with. This is a dark road that you don't want to go down.

It would be hard to make the case against the legions of Linux fans shouting "you don't really need that!!!!!" like they do whenever you try to talk to them about a missing feature.

@TwelveBaud said:

But then why is the project so large?

Because Federal laws involving health insurance are fucking complex.

@TwelveBaud said:

If it's so large that neither Git nor TFS behave sanely on it, how are the humans expected to be able to do so?

But TFS can behave sanely on it. For example, TFS doesn't get slower as project size increases. TFS can checkout sub-projects (for example, if I'm only working on HSA account logic, I only need to checkout the project that builds the HSA DLL). Etc.

It's only Git that has problems with these basic things.

antiquarian

@blakeyrat said:

That doesn't mean I want to waste neurons on memorizing Git commands and quirks!

That reminds me of the episode of the Simpsons where Homer reaches the limit of what will fit into his brain and each new fact he learns causes him to forget something else. I didn't know that happened in real life.

TwelveBaud

@blakeyrat said:

(for example, if I'm only working on HSA account logic, I only need to checkout the project that builds the HSA DLL).

Well ...

...

I was about to say something along the lines of "well why isn't each DLL its own repository, since that's the unit of scope", but then I remembered how painful git submodule is and how it's absolutely nothing like svn externals and quickly gets annoying to try and use. Nope, you're right.

boomzilla

@blakeyrat said:

It would be hard to make the case against the legions of Linux fans shouting "you don't really need that!!!!!" like they do whenever you try to talk to them about a missing feature.

Yeah, kind of like how you do when I complain about stuff missing in Windows? It's legit to complain about a particular feature, but talking generically about "feature parity" is retarded. Stuff is different on purpose.

blakeyrat

@TwelveBaud said:

I was about to say something along the lines of "well why isn't each DLL its own repository, since that's the unit of scope",

Ok you agree with me, but I still want to point out that this is wrong.

The solution is the "unit of scope". It makes no sense for a Git repo to be anything smaller than a Visual Studio solution. The HSA DLL is one small part of a solution that includes health, dental, life insurance, HSA, FSA, TSA, DCA, etc. accounts. And the database schema. And the database patching scripts. And etc etc etc etc etc.

Fortunately, Visual Studio is written by non-morons and solutions work fine if only some of the projects in them are on disk. (The rest are simply marked as "offline" and ignored.)

@boomzilla said:

Yeah, kind of like how you do when I complain about stuff missing in Windows? It's legit to complain about a particular feature, but talking generically about "feature parity" is retarded. Stuff is different on purpose.

No it's not.

Stuff being different is fine-- if it's better than what was out there before. Part of being better is having more features. That's not to say that's the only way of being better (for example, the iPhone was a much better device than the WinMo 6.x and Blackberry devices it was competing with, but had fewer features), but it's an important one.

hifi

@TwelveBaud said:

... but then I remembered how painful git submodule is and how it's absolutely nothing like svn externals and quickly gets annoying to try and use. Nope, you're right.

Have you looked at git subtree? Can't say I have but it seems to be slightly better.

Gąska

@blakeyrat said:

Hey look. You reached the conclusion all sane people did back in fucking 1988.

Because guys back in 1988 were smart. They also reached the conclusion that CLI is better than GUI at non-interactive jobs (and by splitting your big interactive jobs to very little non-interactive parts, as is the case with most of Linux, you can get more versatile environment where you perform your job faster and better, if you're willing to learn all those commands).

@blakeyrat said:

Look, I know having "modes" is like cancer and Hitler rolled into one, but why not have a Git mode where it does have a single "master" server that can talk back and forth to the clients?

Because you can do just that in distributed model too? Except for file locking. But I've found that Mercurial, which is also DVCS, has some 3rd-party ~~hack~~ extension that allows locking files. Never used it though.

@blakeyrat said:

PROTIP: if you've made a design decision that makes it impossible to have feature-parity with your competitors, maybe it was a shitty design decision and you should flush it in the toilet post-haste.

Back in the early 80s, Microsoft released a seriously feature-impaired operating system (it didn't even have directories!) and yet they managed to dominate the market.

@TwelveBaud said:

About half a second, since the changeset only includes changed files. But the server has to be responding and reachable, and no one else can have locked any files you're trying to check in. Then again, TFS doesn't compute the SHA-1 hash of every single file in the work tree every checkin.

Now that you mention it, I wonder how much it takes on server's side. Because when commiting to Git, you're doing server's work.

tarunik

@HardwareGeek said:

You ignore DVCS concepts while using a tool whose entire existence is based on those concepts, then complain about that tool and expect people to take you seriously.

@blakeyrat here might as well be trying to fly a helicopter (Git) while having a few thousand hours in fixed wing aircraft (centralized VCSes). He should be glad that the consequences of this with Git vs a CVCS are not nearly as dramatic as reverting to fixed wing concepts while flying a rotorcraft.

dkf

@blakeyrat said:

If Git can't cope with large projects

It can. I'm working with a project in Git that is 800MB in size and 10 years old. I just think that it's easier when you don't roll the whole lot into one when it is really many things. (I try to have my build system do that for me.)

Magus

Cute. Over here, we're dealing with a 30yo codebase in a proprietary language, C, C++, C# and Delphi, split into two main solutions with random bits in other places, where our main branch weighs something like 2gb. With Resharper active, VS crashes if I get-specific-overwrite-all, because it can't parse the 80k files well.

Our build takes 3 hours usually, but checkins with TFS take around 2 seconds to go through... The only trouble we ever have with TFS is that our dumb, ancient, proprietary language no one else uses ends statements with a specific non-printing character, and if TFS sees that in the first n characters of a file, it marks it as binary, which makes the builtin compare not work right. And we deserve that.

I really can't imagine how git would handle our monstrous mixed-language solutions any better.

HardwareGeek

@TheCPUWizard said:

@boomzilla said:
Mercurial doesn't have git's detached head issues.

Programmer working with Git: http://img1.photographersdirect.com/img/262/wm/pd2992109.jpg

So Git is Goliath — arrogant, blustering giant — and Hg is David — young, inexperienced, wimpy — who is smart enough to kill the giant despite the imbalance in size and strength? I can live with that analogy.

I have no preference for one over the other; I've never used either, only CVCSs.

Gąska

@Magus said:

The only trouble we ever have with TFS is that our dumb, ancient, proprietary language no one else uses ends statements with a specific non-printing character, and if TFS sees that in the first n characters of a file, it marks it as binary, which makes the builtin compare not work right.

Put a copyright notice in comment at the beginning of each file?

Magus

Yes, that's pretty much what we do. A lot of the older files have giant version control comment blobs from whatever system we had before, and we have a sort of standard header template for new things. We'd like people to write new bits in C#, and that happens sometimes, but quite a bit happens in the old awfulness.

tar

@Magus said:

The only trouble we ever have with TFS is that our dumb, ancient, proprietary language no one else uses ends statements with a specific non-printing character, and if TFS sees that in the first n characters of a file, it marks it as binary, which makes the builtin compare not work right. And we deserve that.

You should start a thread about that. It sounds ~~awful~~ fascinating...

blakeyrat

@Gaska said:

Because guys back in 1988 were smart.

Smarter than developers today.

@Gaska said:

They also reached the conclusion that CLI is better than GUI at non-interactive jobs

Bullshit. They looked at that problem and invented WSH and AppleScript, far better solutions.

Linux is actually newer than both of those, and yet somehow substantially worse at scripting. Huh.

@Gaska said:

(and by splitting your big interactive jobs to very little non-interactive parts, as is the case with most of Linux, you can get more versatile environment where you perform your job faster and better, if you're willing to learn all those commands).

For an extremely limited definition of the word "job".

Here's a quiz, Linux-boy: my job is video editing for a TV show. How does splitting that interactive job into very little non-interactive parts help me? How does it make me faster and better at video editing?

@Gaska said:

Because you can do just that in distributed model too? Except for file locking.

So you can, but you can't. Awesome. Thanks, Sun Tzu.

@Gaska said:

Back in the early 80s, Microsoft released a seriously feature-impaired operating system (it didn't even have directories!) and yet they managed to dominate the market.

Not until after they wised-up and followed Apple's example in making the primary interaction of the OS a GUI.

@tarunik said:

@blakeyrat here might as well be trying to fly a helicopter (Git) while having a few thousand hours in fixed wing aircraft (centralized VCSes).

What I'm missing is an autopilot.

@dkf said:

It can. I'm working with a project in Git that is 800MB in size and 10 years old.

Ours is about 4.25 GB. I don't know how "old" it is, nor am I sure how that's relevant at all...

Correction: the back-end APIs are about 4 GB. The front-end, which is in a different Git repo, is about 80 MB.

@dkf said:

I just think that it's easier when you don't roll the whole lot into one when it is really many things.

This is so vague I can only assume you're talking about the Visual Studio solution/project hierarchy?

Again: you're not "rolling the whole lot into one", because a solution can contain many projects and a project can be in many solutions. It's not a one-to-many relationship, it's a many-to-many relationship.

Magus

It looks like this: ^SOMETHING(OTHERTHING,THING)>, where that last > is a nonprinting character displayed as a triangle thing. Most variables are global, and are referenced as ^(VARIABLENAME)>. Because everything is a string, you can't put spaces in function calls, because THING and THING are different. It also supports macros, in a purely textual sense. They literally copy the text of the macro in, make substitutions, and then run the compiler. Also, there is a max file length at compile time, meaning that calling macros risks not being able to compile your files. It was designed to fill a similar role to LaTeX and XAML at the same time somehow, and results in us having a database where everything is a string.

Ifs look like:

^IF(IFNAME,^(SOMEVARIABLE)>=Y)>
    ^SOMEACTION(THING)>
^:IFNAME:>

Also, the language completely ignores tabs and newlines like most languages ignore spaces, so a tab character is fine between parameters, and is the only thing that works at all for indentation, though I like tabs for that anyway.

sloosecannon

@blakeyrat said:

substantially worse at scripting

^{[citation needed]}

blakeyrat

@sloosecannon said:

[citation needed]

Do Linux GUIs have a macro recorder? Does the macro recorder record into human-readable scripts that the user can then edit to (for example) add variables or loops?

Because both AppleScript and WSH had that decades ago.

sloosecannon

That sounds completely useless. Also, they do exist. Citation still needed.

Gąska

@blakeyrat said:

Bullshit. They looked at that problem and invented WSH and AppleScript, far better solutions.

Neither WSH nor AppleScript is GUI-based. Also, WSH died a natural death due to being a giant security hole, and I never heard of AppleScript except from you. Maybe they weren't such a great idea?

@blakeyrat said:

For an extremely limited definition of the word "job".

Yes, limited to programming and sysadmin tasks.

@blakeyrat said:

Here's a quiz, Linux-boy

Fuck you. I don't want to be associated with Linux in any way. Neither I want to be associated with Windows, which is my favorite OS. Neither I want to be associated in any way with Poland, Europe, Coca-Cola (my favorite drink), or anything else related to my life. Maybe except Warlock's Gauntlet.

@blakeyrat said:

my job is video editing for a TV show. How does splitting that interactive job into very little non-interactive parts help me?

You cannot do that. Neither can you interactively edit video from CLI, no matter how awesome your CLI is. As I said, GUI is often better than CLI, but not always.

@blakeyrat said:

So you can, but you can't. Awesome. Thanks, Sun Tzu.

I have few years of experience with centralized VCSs and I never ever had to lock a single file. If this feature is so critical for your workflow, I think you're doing things very, very wrong, regardless of what you use to version your files.

@blakeyrat said:

Not until after they wised-up and followed Apple's example in making the primary interaction of the OS a GUI.

100% proof lies. MS-DOS monopolized the market years before Windows was made.

sloosecannon

@Gaska said:

programming

Emphasized for @blakey's benefit.

@Gaska said:

You cannot do that. CLI is. As I said, GUI is often better than CLI, but not always.

Eh, technically you probably could...... for generous values of "interactive"...

:pendant.pages:

@Gaska said:

I have few years of experience with centralized VCSs and I never ever had to lock a single file. If this feature is so critical for your workflow, I think you're doing things very, very wrong, regardless of what you use to version your files.

QFT. Locking files is only partially, maybe, a valid workflow for binary files that can't be easily merged. It's still stupid and a Bad Idea

blakeyrat

@sloosecannon said:

It's still stupid and a Bad Idea

Who the fuck are you to tell me what's a bad idea?

sloosecannon

+ Reply as linked Topic

sloosecannon

@blakeyrat said:

Who the fuck are you to tell me what's a bad idea?

Someone who had to deal with locked file stupidity. Never. Again.

There is literally nothing that locking does that cannot be achieved via merging things properly.

Gąska

Forgot one.

@blakeyrat said:

Linux is actually newer than both of those, and yet somehow substantially worse at scripting. Huh.

THE WHOLE LINUX ECOSYSTEM IS BUILT UPON MILLIONS OF LITTLE SCRIPTS AROUND VARIOUS PROGRAMS!!!!!!!!!!

Also, since shell scripts use exactly the same commands in exactly the same manner you would use during your normal use of those tools, you can use shell scripts for ANYTHING you can do manually. There's simply no way a mainly-GUI OS can beat Linux on scripting front.

sloosecannon

@Gaska said:

THE WHOLE LINUX ECOSYSTEM IS BUILT UPON MILLIONS OF LITTLE SCRIPTS AROUND VARIOUS PROGRAMS!!!!!!!!!!

inb4 "And that's why it sucks, moron"

blakeyrat

@sloosecannon said:

That sounds completely useless.

What was that site that reduced all the Linux arguments into little "trademarks"? Ah. Here: http://tmrepository.com/trademarks/

You Don't Need That.

blakeyrat

@Gaska said:

Neither WSH nor AppleScript is GUI-based.

Yes they are. And both had IDEs.

@Gaska said:

Also, WSH died a natural death due to being a giant security hole,

When did that happen?

@Gaska said:

and I never heard of AppleScript except from you.

Person who knows nothing about computers attempts to debate person who does. Full story on the 11:00 news.

@Gaska said:

Yes, limited to programming and sysadmin tasks.

Great; you've built a computer that's useless for 98% of the population, I hope you feel proud.

@Gaska said:

If this feature is so critical for your workflow, I think you're doing things very, very wrong, regardless of what you use to version your files.

Until SCMs can reasonably diff binary files like databases, it's necessary. If you've never used it... well, congratulations? I guess? But that doesn't mean the feature is not useful.

@sloosecannon said:

There is literally nothing that locking does that cannot be achieved via merging things properly.

Two people change the same SQL Server .mdf file simultaneously. Then try to merge their changes.

How do you "properly" handle that in Git?

@Gaska said:

THE WHOLE LINUX ECOSYSTEM IS BUILT UPON MILLIONS OF LITTLE SCRIPTS AROUND VARIOUS PROGRAMS!!!!!!!!!!

Right; and yet those are utterly useless for 98% of the population.

@Gaska said:

you can use shell scripts for ANYTHING you can do manually.

Oh I can? I can use a shell script to add auto-ducking to a 3-second clip of my TV show video file?

There is no way that is true. No way in HELL.

@Gaska said:

There's simply no way a mainly-GUI OS can beat Linux on scripting front.

Not only can it be done, but it was done on Mac Classic back in the early 90s.

You just don't know about it because you're utterly ignorant of the field you work in.

sloosecannon

@blakeyrat said:

Two people change the same SQL Server .mdf file simultaneously. Then try to merge their changes.

How do you "properly" handle that in Git?

Open both branches. Merge the changes. Or decide you don't need one copy and throw it away (which is basically what locking does. Only it's worse, because only one copy is available.

sloosecannon

@blakeyrat said:

What was that site that reduced all the Linux arguments into little "trademarks"? Ah. Here: http://tmrepository.com/trademarks/

You Don't Need That.

Ok. That's cool. I can make a site that reduces all @Blakeyrat arguments into "If it's open source, it sucks".
It still sounds completely useless. Also, you ignored the second part of my statement. Which is "despite being useless, there are things that actually do that already..."

That website is also hilariously hypocritical. Not that I care, because I'm not an Open Source Zealot(tm) (see what I did there?)

sloosecannon

@blakeyrat said:

utterly ignorant of the field you work in.

Says the guy who can't use a command line.

blakeyrat

@sloosecannon said:

Open both branches. Merge the changes.

So now you've completed wasted someone's time. They have to redo the work all over again. You're a fucking asshole.

If only that guy had some sort of feedback from his source control system that he shouldn't be touching that file because someone else is currently working with it... imagine how much time you would have saved! Imagine not being a fucking asshole!

sloosecannon

Selective reading at it's finest, folks!

If only there was a way to say "Accept the other guy's changes".........

Oh wait, there is!

TwelveBaud

Not in SQL Server Management Studio, and not in a Microsoft-provided tool that fits in a Git diff3 line. You have to rip all three versions out of the index, open them manually in Visual Studio, and reconcile each change manually.

Oh wait, I thought you said "merge changes". I didn't realize you said "destroy all my changes so I have to do them again." My mistake.

PleegWat

@sloosecannon said:

I can make a site that reduces all @Blakeyrat arguments into "If it's open source, it sucks".

ITYM "If it has at least one feature that isn't accessible via GUI, it sucks".

tar

So, uh, I just tried using git fetch in place of git pull, and it doesn't actually get the remote changes onto my local repo. I know this because I confirmed a change made it into origin/master did not actually show up on my PC.

I tried git fetch a second time and absolutely nothing happened. Of course, then I tried git pull anyway, and FUBARED my repo, but fortunately there were no local changes of any value, so I just moved it out of the way, and did a git clone, which finally got me up to date.

What did I do wrong here? I though that git fetch was just git pull without the merge at the end?

I have another copy of the repo which I called fetch on, and it's in the same state (although I haven't fuxx0red it by doing pull on it yet). Is that repo salvageable, or do I need to reclone that guy too?

Can someone explain to me what on earth I did wrong? I literally just ran git fetch when normally I was using git pull and that's all...

antiquarian

@PleegWat said:

I can make a site that reduces all @Blakeyrat arguments into "If it's open source, it sucks".

ITYM "If it has at least one feature that isn't accessible via GUI, it sucks".

You guys are overthinking things. It's really quite simple:

If it doesn't work the way blakeyrat wants it to, it sucks.

mott555

And this after I was basically told in my Git thread that Git never screws up repositories and SVN always does...

boomzilla

@blakeyrat said:

Two people change the same SQL Server .mdf file simultaneously. Then try to merge their changes.

How do you "properly" handle that in Git?

I had to look up what a .mdf file was. Holy crap, why would you want to have something like that? Is there a reason not to store stuff like that in text format as SQL and make it part of your build process to build something like that?

It sounds like storing an executable and then bitching about your SCM not merging your object files. But at least we seem to have found TRWTF in this case.

Worst case, the vendor who came up with the binary format could put out a diff utility for it that people could use. Those guys would be the alternate TRWTF, I guess, if this is considered a reasonable thing to do with the files.

Yamikuronue

@tar said:

without the merge at the end?

Presumably, it pulled down the fact that there were changes, but didn't merge them into your local repo, so you don't see them. Now your repo knows that it's behind, but it didn't try and apply the changes it missed.

I dunno why that's useful.

mott555

I think the proper way to handle Blakey's .mdf issue is with a cluebat applied to the other developer's face.

tar

Oh hang on...

$ git status
On branch master
Your branch is behind 'origin/master' by 10 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

wut?

boomzilla

@mott555 said:

I think the proper way to handle Blakey's .mdf issue is with a cluebat applied to the other developer's face.

I guess. If he's the guy that put it in the repo to begin with.

tar

Hehe, so you should use git fetch instead of git pull because:

half the time it will trash your local repo
the other half of the time it will tell you to call git pull anyway...

Yamikuronue

Yeah.

So basically, there's information about the commits, and there's the files that were changed as part of a commit. SVN keeps the former in a local sqlite database, I don't know what Git does. I've never really cared where SVN stores the info.

"Fetch" updates that database: the list of branches, the sequence of commits on each, where your local branch is in the history. That's akin to... I dunno, I guess svn log? It's stuff I don't usually worry about working with SVN.

"Pull" brings down both that information AND the actual changes, so that you're pointing at the latest revision the remote repository knows about, akin to an SVN update.

The advice I heard was that you should commit, then pull, then push. Commit so you don't lose your local changes if you merge badly, then pull to make sure you're up to date and merge if you have to, then push to give your change to everyone else.

tar

Yeah, I'm considering giving git pull --rebase a go at some point, next time I'm feeling adventurous, but for now I'm sticking with my workflow which has always worked for me on my machine, damnit!

Yamikuronue

There's also a fastforward.

I don't know how to do one, but that's a concept in git.

Protip: If you want to know how usable your shit is, give it to someone who is reasonably competent and independent with no guidance but your official docs and the internet, then come back in a few weeks and ask them to teach it to someone else. Every time they say "I don't know why, just do it", you fucked up your usability.

Gąska

@blakeyrat said:

Yes they are.

What part of writing text is GUI-based, exactly?

@blakeyrat said:

And both had IDEs.

So? Logo has IDE too.

@blakeyrat said:

When did that happen?

Several years ago.

@blakeyrat said:

Person who knows nothing about computers attempts to debate person who does.

At least you acknowledge your downsides.

@blakeyrat said:

Great; you've built a computer that's useless for 98% of the population, I hope you feel proud.

F1 car is useless for 98% of population too.

@blakeyrat said:

binary files

Ah. So this is a problem. Why haven't mentioned it earlier? It would save thousands of keystrokes on both sides.

Git sucks with binary files. Everyone knows it, though some die-hard fans might not admit it. Git is terrible tool for versioning binary files. If you need to work with them, go elsewhere. A right tool for a right job. And if your management enforces it, they're idiots.

@blakeyrat said:

Right; and yet those are utterly useless for 98% of the population.

Those million Linux shell scripts allow you to stalk your friends of Facebook. Also, any other activity that's performed on any other Linux server in existence.

@blakeyrat said:

Oh I can? I can use a shell script to add auto-ducking to a 3-second clip of my TV show video file?

I have no idea what ducking means in this context (Google only knows of this term referring to audio), but I'm pretty sure you could somehow make this through use of ffmpeg (a command-line-based video editor).

@blakeyrat said:

Not only can it be done, but it was done on Mac Classic back in the early 90s.

What could you do with AppleScript on MacOS Classic that you couldn't possibly on Lunix? Just to save me from having to read the first thing in mind, let's say I have a program that can replay recorded input (mouse movements and clicks, keyboard strokes) installed on my Linux hardware.

@blakeyrat said:

You just don't know about it because you're utterly ignorant of the field you work in.

I don't and never worked with anything fruity.

boomzilla

@Yamikuronue said:

"Fetch" updates that database: the list of branches, the sequence of commits on each, where your local branch is in the history. That's akin to... I dunno, I guess svn log? It's stuff I don't usually worry about working with SVN.

"Pull" brings down both that information AND the actual changes, so that you're pointing at the latest revision the remote repository knows about, akin to an SVN update.

I guess I could see how that could be a useful thing if you just wanted to peek at something. FTR, hg has pull which brings in the changes from the remote repo but it doesn't change what you're "pointed at." I think there's a subtle difference with git between that concept and your working copy. You just do a separate update when you're ready.

Gąska

@tar said:

So, uh, I just tried using git fetch in place of git pull, and it doesn't actually get the remote changes onto my local repo.

It does. It just doesn't merge it into any of your local branches. Which means you won't see any changes in any branches until you merge (or rebase) them with remote branch. If you have a branch "foo", you can access your local branch by name "foo" and the remote branch by name "origin/foo".

@tar said:

Of course, then I tried git pull anyway, and FUBARED my repo

I told you to use the -r option, didn't I?