GitHub is fucking broken fucking again
-
@ais523 said:
tl;dr: blakeyrat's company is trying to use git for a purpose for which it wasn't designed, with a client for which it wasn't designed, on an operating system it wasn't designed for. And if it wasn't for the client being so buggy, it would actually almost work!
Even if it worked, it's still a confusing unusable hostile mess. It's bad software. It's bad on Linux. It's bad on Windows. It's bad on OS X.
If you design a program without taking even a fraction of a millisecond to think about the end-user experience, you're a bad programmer. I don't give a shit if you're Linux Torvalds or God Himself, Git is a FUCKING AWFUL PROGRAM. Not fit for purpose.
You know what? I ... I think ... I think Lotus Notes is actually a more usable program than Git. I really do. Git is actually worse than Lotus Notes.
-
It took a while for this to really set in. When we talk about distributed source control, you have to realize that 2-tier is actually the simplest possible use-case (well, there's 1-tier but then it's barely source control). Every repository (including your local) can be the master of n other repositories, which can potentially create a large network of daisy-chained repositories. You can also have multiple remote repositories for a single local repository. I believe this feature doesn't exist because it only makes sense with very simple set ups.
Also, as pointed out by ais523, just use a shell script that does both operations together to do your commit/pushes.
-
@joe.edwards said:
Also, as pointed out by ais523, just use a shell script that does both operations together to do your commit/pushes.
I think the issue is that git doesn't support anonymous / multiple heads in a branch, so a simple script wouldn't work very well for what blakey wants. As I understand it, this is a design decision, with which some obviously disagree. I can see pros and cons (and since I use Mercurial, I deal with these all the time, and I'm fine with them). Reading this:
The rest of the uses of anonymous heads were solved in git in much simpler ways; ‘git pull’ automatically merges the remote head, and remote namespaces of branches allow you to see their status after doing ‘git fetch’.
I'm not a fan of that (automatic merges are one reason I've ditched svn!). I suppose that you could write a post-commit hood that pulled changes down and did this merge and push after that's done, but that sounds like a recipe for disaster.
tl;dr; Once again, blakey uses a powerful tool without understanding its purpose or philosophy or consequences of what he thinks he wants.
-
I've found it's actually pretty good for sneakernet.
When I start a pet project I'll usually create a local git repo for it. Then, if I need to roam to a different computer, usually behind a different firewall, I'll just git clone to a USB key. When I get to the next computer, I'll git clone from the USB key to that computer, do some work, and push back to the USB key when I leave. It's pretty easy to have a roaming repository this way, with all the advantages of branching and merging and revision history that I wouldn't get just copying the source to the USB drive.
-
Here's the next part of my email chain with the GitHub guy:
@GitHub support guy said:
I'm going to do my best to address your concerns.
1)The gibberish in your source code files are merge conflict markers that are created to help you resolve the conflicts between files [1].
2) The 'detached HEAD' error happens when GitHub for Windows interrupts a sync due to merge conflicts between the local and remote repository. Fixing this involves opening the shell, running 'git status' to see the specific files with conflicts, fixing those conflicts, and then running a 'git rebase --continue' to finish off what GitHub for Windows was initially trying to do. I agree that this is cumbersome to new Git users, and we're working on a better way to handle merge conflicts directly in the GUI so that users don't have to email support to figure out what on earth is going on.
3) The difference with Git is that it is distributed [2], whereas SVN is one central repo. Git allows for offline development, so that you don't constantly have to be pushing to the central repo like in SVN.
Auto-syncing is an interesting feature idea, and I can pass along to the developers.
4) Having a name and email is pretty important, because this allows you to track down who made specific commits. That way you can find out who to blame bugs on. :)
Git was the first source control I ever used, so it's hard for me to fully understand what it's like coming from something else. I appreciate these types of conversations, because they help give me insight into what it's like to switch to Git.
Cheers,
[1] http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merge-Conflicts
[2] http://git-scm.com/about/distributedAnd my reply:
@Blakeyrat said:
1) I understand why it's there, what I don't understand is why the actual files are modified. Why can't Git make a diff between the local version and the server version on-the-fly without making the code un-compile-able? Or at least put the diffs in a separate file without touching my originals. Wouldn't that be a much better solution? As-is, I'm terrified of accidentally checking-in a code file with "merge conflict markers" in it. Like I said before, the entire point of a source control system is to protect my source from getting corrupted and store it safely-- when using Git, it's the source control system itself corrupting my source files!
2) I figured that out, of course, but as I posted it's hostile towards those who prefer to use a GUI. I don't have the rote memorization skills to use a CLI, I just plain simply don't. That doesn't stop me from programming, as long as I'm using an IDE with good intellisense-ish features. But it feels like nobody at Git or GitHub cares for people like me. I'm a usability guy, I build GUIs. But I'm just as development-minded, and I deserve consideration by tools made for development.
Also don't you think that's a pretty fundamental feature to lack, especially considering your version number is above 1.0?
3) But our team doesn't need "distributed", so I don't care about that. What we *do* need is people to be forced to sync the repository because that is an obvious and demonstrable problem on our team. And since every other source control system I've used does this by default, I find it shocking and amazing that Git doesn't even have an option to do it.
Your reply is like me complaining that my car doesn't have a rear-view mirror so I backed into a wall, and you replying "but it has cruise control!" Well I don't see what cruise control has to do with lacking a rear-view mirror. (To make the obligatory awful car analogy.) And I don't see what being distributed has to do with lacking the feature to force commits to sync right away.
4) We all have GitHub logins, we all commit using our GitHub logins. Why can't the server fill that in based on our GitHub account names? Why not just auto-fill the "real name" field with my GitHub username if it's blank? And auto-fill the email field with whatever email is in my GitHub account? Right?
-
@blakeyrat said:
1) I understand why it's there, what I don't understand is why the actual files are modified. Why can't Git make a diff between the local version and the server version on-the-fly without making the code un-compile-able? Or at least put the diffs in a separate file without touching my originals. Wouldn't that be a much better solution? As-is, I'm terrified of accidentally checking-in a code file with "merge conflict markers" in it. Like I said before, the entire point of a source control system is to protect my source from getting corrupted and store it safely-- when using Git, it's the source control system itself corrupting my source files!
I'm trying to understand what would happen if it worked as you propose. I guess that if there is anything that causes a conflict, the original file would be left alone? Of course, this doesn't make it necessarily compileable, since changes elsewhere might require updates in this file. Or they might leave it compileable, but with more subtle errors. This would also increase the likelihood that an unmerged file would be committed, wiping out valuable changes, especially with careless GUI client users who could get into the habit of marking things as resolved to get the error messages to go away. Leaving the results of the merge right there in the source seems like the best way to ensure that it gets dealt with.
I don't understand why you're so worried about things getting corrupted. The whole point is that you have the history stored, so you can always go back and try again if you mess up the merge. Checking in an unmerged version (that isn't obviously wrong) seems far worse than having conflict information in the file, since the conflict stuff is a big red flag that clues you into what went wrong (forgot to resolve the merge!).
But seriously, why is "unmerged" more correct than "merged with conflict information?"
The whole "open a shell" thing is ridiculous on their part. What, they can't show you the text of what went wrong in a log window or something? Are the files not marked as conflicted (maybe this doesn't make sense in the "detached head" scenario...I'm not familiar enough with git to be sure)? That stuff is way worse than the original WTF dealing with profile directories.
-
@boomzilla said:
STOP TALKING ABOUT WHY SOFTWARE ISN'T WORKING AND JUST FIX IT ALREADY.
I didn't say it wasn't working - I just said it was unable to cope with Blakey's particular configuration.
I'm guessing it works well in other configurations and Blakey's an exception.. and after reading what his config is like I'd expect some graceful degredation. TRWTF is still that error message.
Let's not forget the other extreme is software that ONLY works for one specific configuration and refuses to do anything lest it encounters that particular setup - is it broken, or is the config broken?
-
@Cassidy said:
@boomzilla said:
STOP TALKING ABOUT WHY SOFTWARE ISN'T WORKING AND JUST FIX IT ALREADY.
I didn't say it wasn't working - I just said it was unable to cope with Blakey's particular configuration.
QUIT MAKING EXCUSES FOR SHIT SOFTWARE. <a href="http://www.youtube.com/watch?v=N3rh7tRert0>I HATE HATE HATE HATE HATE YOU.
-
@blakeyrat said:
1) I understand why it's there, what I don't understand is why the actual files are modified.
Because they aren't the "actual files" in the way that you think. They're your working copy. The real "actual files" are safely stored in the repo where you can get them back any time. The working copy is where you do work, like resolving a merge conflict.
@blakeyrat said:
Why can't Git make a diff between the local version and the server version on-the-fly without making the code un-compile-able?
Why would you want your code to compile after a merge conflict? That would be HORRIBLE. You can always just abort the merge and go back to what you had. Git assumes if you try to merge something, you really mean it, and if there's a hiccup then you want to resolve it and move on.
@blakeyrat said:
Or at least put the diffs in a separate file without touching my originals.
Your originals are safely stored in the repo. And Git will never put conflict data in your uncommitted files. You don't need to be so protective!
@blakeyrat said:
As-is, I'm terrified of accidentally checking-in a code file with "merge conflict markers" in it.
Why? Do you have no testing in place? You can just fix your bad commits later anyway. At least it won't compile and have subtle bugs.@blakeyrat said:
Like I said before, the entire point of a source control system is to protect my source from getting corrupted and store it safely-- when using Git, it's the source control system itself corrupting my source files!
No it isn't. It's only "corrupting" your working copy. Which is just a copy and it doesn't matter what happens to it. Even if you just delete all the files with conflicts in them, it doesn't matter and you don't lose anything. You can just check them out again or reset the whole working copy whenever.
In my experience, doing everything in-place with one working copy is great. I don't have to go hunting around for secret files. I can fix and test my conflicts, change branches, etc, without having to move files around, change environments or anything else. I'm sorry if you don't like it, but you don't even seem to get the point of the whole thing.
On the other hand the GitHub client looks pretty awful...
-
@superjer said:
@blakeyrat said:
when using Git, it's the source control system itself corrupting my source files!
No it isn't. It's only "corrupting" your working copy. Which is just a copy and it doesn't matter what happens to it.
Won't that mean losing changes you've made to your local files?
(not a GitHub user, but I get the impression Blakey's scared of losing all the modification work he's just done)
-
@Cassidy said:
@superjer said:
@blakeyrat said:
when using Git, it's the source control system itself corrupting my source files!
No it isn't. It's only "corrupting" your working copy. Which is just a copy and it doesn't matter what happens to it.
Won't that mean losing changes you've made to your local files?
(not a GitHub user, but I get the impression Blakey's scared of losing all the modification work he's just done)
No! This is one key implementation difference between things like svn and most DVCSes. The point is that the merge is done between committed changesets (or whatever git calls them). So your changes are already preserved in the repo. Subversion would make you pull down changes from others and do the merge right there in your working copy, which can lead to exactly the problem you've brought up.
-
Git (and other DVCS's like Mercurial) was designed to address the needs of open source software projects. Here's how the development of a single Git project is intended to proceeed:
- A single person A creates software X by themselves, using a local Git repository. Once X is complete, they create a GitHub (or other public Git repo) and push it to there.
- B sees the software and wants to add features to it. Since they have read-only access to A's public repository, they clone A's repo into a local repo and keep working on that, never pushing because they don't have write permission.
- B finishes their own fork of the software and publishes it on their own GitHub.
Now this makes all well and sense in the open source world, but for teams and closed-source developers (and people like me who use source control to not only control the source but to shuttle it around between systems) this system is a nightmare. Git is by design for one person alone on one machine alone to do work on a project and for many people to have read-only access to the source. Most commercial situations are completely the opposite from that.
That said, I'm surprised TortoiseGit hasn't come up in the thread yet. It's what I use when I have to subject myself to that nightmare.
-
@MiffTheFox said:
Now this makes all well and sense in the open source world, but for teams and closed-source developers (and people like me who use source control to not only control the source but to shuttle it around between systems) this system is a nightmare.
Because no open source projects are worked on by teams of people? I find DVCS way easier to manage with multiple people than a CVCS.
@MiffTheFox said:
Git is by design for one person alone on one machine alone to do work on a project and for many people to have read-only access to the source.
I think you've misunderstood DVCS. Yes, the point is that you have different repos where only a few (or one) people have write access, and everyone works on their own personal repo. But there's nothing that prevents having a centralized repo where many people have write access (a la github or sourceforge or bitbucket or your own server, etc).
-
While I strongly disagree that Git is for individual developers, it's a good point to bring up forked projects. Not all workflows involve pushing changes upstream. A fork is a prime example of when you'd want to periodically merge changes (features, bugfixes, etc) down from a master (which itself may be a fork) but never push changes back up.
This is another common scenario where automatically pushing to master is undesirable.
-
Yes, Git can be used as a centralized VCS just like SVN can be used by a single developer forking a project from a read only repo. (svn co http://svn.some-oss-project.org/ & svnadmin create /home/user/svn/some-oss-fork & svn switch --relocate http://svn.some-oss-project.org/ file:///home/user/svn/some-oss-fork) (WARNING: I have not tried this!)
The point is do you want to?
-
@MiffTheFox said:
Yes, Git can be used as a centralized VCS just like SVN can be used by a single developer forking a project from a read only repo. (svn co http://svn.some-oss-project.org/ & svnadmin create /home/user/svn/some-oss-fork & svn switch --relocate http://svn.some-oss-project.org/ file:///home/user/svn/some-oss-fork) (WARNING: I have not tried this!)
The point is do you want to?
What the hell are you talking about?* It's still different, even when you maintain a central, canonical repository that multiple people push to. The biggest problem with current CVSes like svn isn't their centralized nature. It's their branching method and the fact that they follow the merge-commit paradigm rather than the commit-merge paradigm. I'm not sure if this was an explicit thing that DVCS developers went out to solve, or just a happy accident forced upon them by the nature of a DVCS.
* Good lord, now I really feel like I'm channeling blakeyrat.
-
@MiffTheFox said:
That said, I'm surprised TortoiseGit hasn't come up in the thread yet. It's what I use when I have to subject myself to that nightmare.
TortoiseGit is so buggy it doesn't even install. In the process of failing to install, it downloads 500 MEGABYTES of crap. I'm not exaggerating.
-
@MiffTheFox said:
I've had repository corruption because of TortoiseGit, but never from any other frontend. TortoiseGit is the only one (that I've seen) that acts on the repository directly without using Git, and has stupid locks applied to files that break things. GitExtensions is still far superior.That said, I'm surprised TortoiseGit hasn't come up in the thread yet. It's what I use when I have to subject myself to that nightmare.
