![[gb]](/mwf/flags/gb.png "United Kingdom")
Grah, seriously. How are you people putting up with this. Mercurial at least plays nice for 10 minutes, Git just is an endless stream of frustration. Every time I give it a chance, it just bites me harder. Timeline of my newest adventure, where I wanted git to mange 1 (!) document I was editing using a "git-wip" tool that auto-commits when saving. Reconstructed mostly directly from my ".bash_history", I am not making this up.
-> Well, okay, would have been to good to be true.
-> Ah, "checkout" sound familiar, let's try that. Does git know abbreviations?
-> Okay, that's a no. Would have supposed these Unix-y tools to have that, oh well.
-> "fatal: Not a git repository (or any of the parent directories): .git". What? Why should ".git" be a repository?
-> Just checking whether Git actually created something strange
-> Maybe he needs a target instead of that strange ".git"? Let's try that. Uhm, same error.
-> Maybe it was referring to that ".git" in the URL? Use a different one. No, that isn't it either. Still the same error.
-> Remember that the "ls" wouldn't have shown me a ".git" directory
-> Okay, I guess that's the wrong command. Hm, "fetch objects and refs from another repository" sounds right, I heard Git calls stuff strangely.
-> Oh come on. The same error message I don't understand? This is getting ridiculous.
-> ... I am seriously getting sick of this error.
-> Bingo. Now that wasn't so hard, was it?
... a little boring configuration later ...
-> So far so good, that seems to be working alright.
-> Had done a test change to the file, I read that this would commit it somewhere
-> Some strange error about a missing revision. Great, borked already? Let's see how Git sees stuff.
-> Uhm, nothing. Maybe it's in another branch or something? How to get a list of branches?
-> Yeah, would have been too good to be true
-> Hm, glancing quickly over the list again... "Shows various types of objects". A branch is an object, right? Maybe I'll end up with "git show branches" or something, but "git show" will probably give me some guidance.
-> What the. No, that's not helpful at all.
-> Screen was filled with crap, let's try this again
-> Ah, it changes *and* lists. Uhm, still only lists one branch. That can't be right. At this point I actually start reading the git-wip source code.
-> That's what I read git-wip would create. Hm, no comment from Git, I guess that's good? So the branch exists?
-> Let's switch back. No comment either. Wait a moment, that's not how Git names things. And still no comment from Git? Did it *create* a branch there?
-> Grah, it did. Great, now I have to get rid of those.
-> Let's first get back
-> This command is clearly not intuitive enough for me.
-> Was there any kind of "hidden" branch somewhere maybe by any chance? Whatever "remote-tracking" is supposed to be. Doesn't look like it.
-> Well, let's remove at least that one
-> Maybe it's working now that the branch exists? I would actually consider it much more intuitive if a commit created a branch... What's an empty branch even supposed to be?
-> First small actual aha-moment with git. It worked. After minutes of despair. Let's do something else to cool off.
... from home ...
-> Great, that works just as well as Darcs. Also faster, admittedly.
-> Except that the wip/master branch wasn't mirrored for some reason. Oh well, it's not that important anyway, but I must remember that behaviour if I intent to ever doing anything serious with branches.
-> Let's be adventurous and add some stuff. No feedback, I guess that's good again?
-> Okay, the rest under "System" you can add recursively. Uh wait, that doesn't work?
-> Can't see any switch. Interactive mode sounds nice, maybe that will help?
-> Okay, I see the list of files in that directory. For some reason he gives me a whole list of what I could do with them. I already said I want to add stuff, didn't I? Look around for a bit and choose "a" for adding unversioned files.
Git answers:
-> What? Yes, that's what I want to do. Hilarity ensures:
This is clearly pointless, I cancel it. It takes me a few more minutes until I realize that "add" seems to be recursive by default and that the files in question are already in the repository. For such a potentially huge operation, I would have at least expected feedback. But for now it begs the question: How do I get files *out* of the repository?
-> Too good to be true again. You know, there are tools that manage to get about 50% on my "too good to be true" attempts.
-> Uhm, what? What other name could you possibly give it?
-> What the. I see, git wants to force me to read stuff again.
-> ... okay, that's just typical.
-> So "co" you don't know, but for "rm" you provide *only* the abbreviation?! That's a bad idea in so many ways it's not even funny.
-> And yeah, it didn't work because it was a directory
-> That didn't work either because it wasn't empty. Git faithfully replicates everything I hate about Unix command line utilities.
-> So what's the files I am adding right now? Uhm, Git?
-> Helpful as ever. Wall of text, zero relevance to what I'm trying to do
-> I again go through the list. I don't understand. How is an add not a "change between commits, commit and working tree, etc"?! I fall into the same trap again.
-> And give up. Yes, I know, by reading one step further, "status" could have actually solved that problem. But after that "rm" thing I was completely out of patience.
... after cooling off again and working a bit on stuff ...
-> Ah, now the files appear in the list. Well, looks good, let's commit this with the rest, then transfer this back to work.
-> What, I need to type that stuff in again? Why can't it just remember that like Darcs and Mercurial do?
-> And Git again throws a wall of text at me. I am in kind of a hurry, don't have time to read it. It tells me the warning can be disabled, so it can't be that bad.
... at work ...
-> Good, my changes are there. For some reason a merge was created. Can't really see why. Maybe I added a file somewhere before.
-> Wait, what? That's the old file without my changes!
-> Well, at least that's how I remember it.
-> That's what Mercurial would have me do.
-> Git's suggestion. GIt's answer doesn't look like this is the right direction.
-> Suddenly I remember the warning at home saying something about this. Great, it says my document was updated! Wait, it wasn't updated at all. What is going on here?!
-> The point where I started writing this. I wanted to try what exactly the response of this was. Now it says it deletes files?!
-> Just needed to re-check: No, changes still gone. Now I'm sitting here and have to go home again, because Git is holding my work hostage from me. In my eyes, that's the last straw, I don't ever want to feel like data can get lost in the versioning system.
Now someone go ahead and point out what obvious thing I did wrong, I don't really care. Right now my rate of hitting the right functionality in Git is under 10%, not even counting the times where it actually made matters worse. I seem utterly incompatible with this tool. Back to Darcs.
git get https://github.com/bartman/git-wip.git-> Well, okay, would have been to good to be true.
git --help-> Ah, "checkout" sound familiar, let's try that. Does git know abbreviations?
git co https://github.com/bartman/git-wip.git-> Okay, that's a no. Would have supposed these Unix-y tools to have that, oh well.
git checkout https://github.com/bartman/git-wip.git-> "fatal: Not a git repository (or any of the parent directories): .git". What? Why should ".git" be a repository?
ls-> Just checking whether Git actually created something strange
git checkout https://github.com/bartman/git-wip.git git-wip-> Maybe he needs a target instead of that strange ".git"? Let's try that. Uhm, same error.
git checkout git://github.com/bartman/git-wip-> Maybe it was referring to that ".git" in the URL? Use a different one. No, that isn't it either. Still the same error.
ls .git-> Remember that the "ls" wouldn't have shown me a ".git" directory
git help-> Okay, I guess that's the wrong command. Hm, "fetch objects and refs from another repository" sounds right, I heard Git calls stuff strangely.
git fetch git://github.com/bartman/git-wip.git-> Oh come on. The same error message I don't understand? This is getting ridiculous.
git pull git://github.com/bartman/git-wip.git-> ... I am seriously getting sick of this error.
git clone git://github.com/bartman/git-wip.git-> Bingo. Now that wasn't so hard, was it?
... a little boring configuration later ...
git init
git add org/
git add org/42.org
git commit -m "Initial"
git log-> So far so good, that seems to be working alright.
git-wip-> Had done a test change to the file, I read that this would commit it somewhere
git-wip log-> Some strange error about a missing revision. Great, borked already? Let's see how Git sees stuff.
git log-> Uhm, nothing. Maybe it's in another branch or something? How to get a list of branches?
git branches-> Yeah, would have been too good to be true
git --help-> Hm, glancing quickly over the list again... "Shows various types of objects". A branch is an object, right? Maybe I'll end up with "git show branches" or something, but "git show" will probably give me some guidance.
git show-> What the. No, that's not helpful at all.
git --help-> Screen was filled with crap, let's try this again
git branch-> Ah, it changes *and* lists. Uhm, still only lists one branch. That can't be right. At this point I actually start reading the git-wip source code.
git branch wip/master-> That's what I read git-wip would create. Hm, no comment from Git, I guess that's good? So the branch exists?
git branch HEAD-> Let's switch back. No comment either. Wait a moment, that's not how Git names things. And still no comment from Git? Did it *create* a branch there?
git branch-> Grah, it did. Great, now I have to get rid of those.
git branch master-> Let's first get back
git branch --help-> This command is clearly not intuitive enough for me.
git branch -a-> Was there any kind of "hidden" branch somewhere maybe by any chance? Whatever "remote-tracking" is supposed to be. Doesn't look like it.
git branch -d HEAD-> Well, let's remove at least that one
git-wip-> Maybe it's working now that the branch exists? I would actually consider it much more intuitive if a commit created a branch... What's an empty branch even supposed to be?
git log wip/master-> First small actual aha-moment with git. It worked. After minutes of despair. Let's do something else to cool off.
... from home ...
git init
git pull ...@...:...-> Great, that works just as well as Darcs. Also faster, admittedly.
git branch-> Except that the wip/master branch wasn't mirrored for some reason. Oh well, it's not that important anyway, but I must remember that behaviour if I intent to ever doing anything serious with branches.
git add work
git add work/random-stuff
git add work/random-stuff/random-stuff.cabal-> Let's be adventurous and add some stuff. No feedback, I guess that's good again?
cd work/random-stuff
git add -r System-> Okay, the rest under "System" you can add recursively. Uh wait, that doesn't work?
git add --help-> Can't see any switch. Interactive mode sounds nice, maybe that will help?
git add -i System-> Okay, I see the list of files in that directory. For some reason he gives me a whole list of what I could do with them. I already said I want to add stuff, didn't I? Look around for a bit and choose "a" for adding unversioned files.
Git answers:
Add untracked>>-> What? Yes, that's what I want to do. Hilarity ensures:
Add untracked>> y
Huh (y)?
Add untracked>> yes
Huh (yes)?
Add untracked>> do it already
Huh (do)?This is clearly pointless, I cancel it. It takes me a few more minutes until I realize that "add" seems to be recursive by default and that the files in question are already in the repository. For such a potentially huge operation, I would have at least expected feedback. But for now it begs the question: How do I get files *out* of the repository?
git revert dist-> Too good to be true again. You know, there are tools that manage to get about 50% on my "too good to be true" attempts.
git remove dist-> Uhm, what? What other name could you possibly give it?
git delete dist-> What the. I see, git wants to force me to read stuff again.
git help-> ... okay, that's just typical.
git rm dist-> So "co" you don't know, but for "rm" you provide *only* the abbreviation?! That's a bad idea in so many ways it's not even funny.
git rm -r dist-> And yeah, it didn't work because it was a directory
git rm -rf dist-> That didn't work either because it wasn't empty. Git faithfully replicates everything I hate about Unix command line utilities.
git diff-> So what's the files I am adding right now? Uhm, Git?
git diff --help-> Helpful as ever. Wall of text, zero relevance to what I'm trying to do
git --help-> I again go through the list. I don't understand. How is an add not a "change between commits, commit and working tree, etc"?! I fall into the same trap again.
git show-> And give up. Yes, I know, by reading one step further, "status" could have actually solved that problem. But after that "rm" thing I was completely out of patience.
... after cooling off again and working a bit on stuff ...
git commit-> Ah, now the files appear in the list. Well, looks good, let's commit this with the rest, then transfer this back to work.
git push-> What, I need to type that stuff in again? Why can't it just remember that like Darcs and Mercurial do?
git push ...@...:...-> And Git again throws a wall of text at me. I am in kind of a hurry, don't have time to read it. It tells me the warning can be disabled, so it can't be that bad.
... at work ...
git log-> Good, my changes are there. For some reason a merge was created. Can't really see why. Maybe I added a file somewhere before.
emacs 42.org-> Wait, what? That's the old file without my changes!
git branch-> Well, at least that's how I remember it.
git update-> That's what Mercurial would have me do.
git update-ref-> Git's suggestion. GIt's answer doesn't look like this is the right direction.
git reset-> Suddenly I remember the warning at home saying something about this. Great, it says my document was updated! Wait, it wasn't updated at all. What is going on here?!
git checkout-> The point where I started writing this. I wanted to try what exactly the response of this was. Now it says it deletes files?!
git reset-> Just needed to re-check: No, changes still gone. Now I'm sitting here and have to go home again, because Git is holding my work hostage from me. In my eyes, that's the last straw, I don't ever want to feel like data can get lost in the versioning system.
Now someone go ahead and point out what obvious thing I did wrong, I don't really care. Right now my rate of hitting the right functionality in Git is under 10%, not even counting the times where it actually made matters worse. I seem utterly incompatible with this tool. Back to Darcs.
![[de]](/mwf/flags/de.png "Germany")
> Now someone go ahead and point out what obvious thing I did wrong, I don't really care.
A random introduction to git would have helped more than git --help. The idiosyncrasies of the command line interface unfortunately are the price we have to pay for the superiority git offers in other areas. Personally, I just use git gui and gitk for almost everything and ignore the issues. (I think the only tool I regularly use the command line for is git rebase -i. The lack of gui support for rebase is the only thing that holds us back from switching to git, as I don't want to force our graphics and script developers to use a command line. Without hg-git I'd propose that we just accept the spurious merge commits.) It helps that gitk --all is a much nicer way to find out what a repository contains than any terminal based tool could ever be.
Git doesn't eat any data that has been committed. Even if you told git to delete or move a branch, you can still create a new branch that points to the commit id the old branch pointed to and resurrect the branch that way. (You get the commit id from .git/logs. I read about it somewhere and never bothered to find out whether git has a tool to display the log or where the logs are mentioned in the docs. The directory layout and file format is obvious enough.) Only after a month or so unused data is garbage collected. With Mercurial, one has to hope that a tool made a dedicated backup and guess which backup contains the needed data based on the date of the backup file. Mercurial tried to solve the problem by not providing destructive tools, but that just doesn't work.
> Mercurial tried to solve the problem by not providing destructive tools, but that just doesn't work.
The way like "hg resolve" is not destructive?
I never used hg resolve, but apparently it only destroys working copy contents. That is trivial with any version control system for good reason - "Throw away these changes I don't want anymore" is a commonly needed operation. Even during a merge - it's easy to resolve a conflict the wrong way, and starting over is a reasonable option in that case. Maybe hg resolve -m should be the default. But just as with unfortunate git defaults, it's probably too late to fix that...
> I never used hg resolve, but apparently it only destroys working copy contents. That is trivial with any version control system for good reason
Sure. But why is this operation called "resolve"? I expect resolve to mark the conflict as resolved, and not to throw away all my changes and let the the conflict remain unresolved.
Peter pointed out that many git commands don't do what he expects them to do. But obviously hg is not that much better.
Trying to autoresolve a conflict again does have some connection to resolve. It's just that that is likely to result in mercurial being again unable to resolve the conflict automatically, just like the first time. Note that I'm not defending the choice the mercurial developers made, just that I can see why they made it :-)
I don't think this is just the command line. When I tried using the GUI, I was struggling with the exact same problems: None of the buttons seemed to do what I thought it did. It also threw huge amounts of terms at me that I didn't understand. Mercurial isn't great, but at least it has a basic underlying model that you don't have to buy a new dictionary for. I still have no idea what "remote-tracking" is supposed to be. Or what that stuff "show" prints actually means. Or what "checkout" does ("Checkout a branch or paths to the working tree"?!). Or what exactly went wrong there in the end. What's the point? A few seconds speed increase? I can live without that.
> I still have no idea what "remote-tracking" is supposed to be.
It's a branch that tracks a remote branch. Exactly what it says on the tin ;-)
> What's the point? A few seconds speed increase? I can live without that.
Having local branches that you can conveniently switch between without permanently attaching a label to every commit is extremely helpful when developing experimental features. gitk is a lot better than hgtk log. Not having to manually remove unwanted commits while not loosing anything not only saves time but also effort. And when the few seconds speed increase are the difference between starting to get distracted and having instantaneous results, they do matter.
> It's a branch that tracks a remote branch.
Yeah, but what is "tracking"? Is that a copy, or a link, or maybe gathering some sort of statistical data? And wasn't the whole point of distributed versioning systems to have all data locally and then sync it when requested?
> local branches
Yep, point taken. Just not my kind of workflow, I guess. I mainly expect my VCS to do "same state on X machines", not "multiple states on one machine".
> And when the few seconds speed increase are the difference between starting to get distracted and having instantaneous results, they do matter.
Well, not necessarily, when you make the interface more complicated in exchange. The trap is that it might even be more satisfying to use the more complex interface - because it rewards the problem solving involved with a snappy response. In the end, you still lose productivity. I am a bit mindful of this argument.
> Yeah, but what is "tracking"? Is that a copy, or a link, or maybe gathering some sort of statistical data? And wasn't the whole point of distributed versioning systems to have all data locally and then sync it when requested?
A branch is just a name for a particular commit with some associated behaviour. A remote-tracking branch is made to point to the same commit the branch in the tracked remote repository points to when a sync is requested. (By first copying the commit and its ancestors from the remote to the local repository if necessary, of course.) So it's a copy and a link?
When you have multiple remotes - say one for your laptop, one for openclonk.org, and one for my public repository, and each of those repositories has a branch named foo, you'd have remote-tracking branches named laptop/foo, origin/foo and guenther/foo. And you'd probably also have a branch named simply foo, which you'd use to push to the foo branch on openclonk.org.
> I mainly expect my VCS to do "same state on X machines", not "multiple states on one machine".
Well, I mainly expect my VCS to remember previous state :-)
From what you describe this sounds most like a read-only local "clone" of the remote repository to me. Except that obviously commits are stored as a graph, so the actual information consists of a simple pointer into the up-to-date graph. Correct?
Okay, that too, obviously. But in my case Git was a bit too reluctant to get away from that previous state :(
> Well, I mainly expect my VCS to remember previous state :-)
Okay, that too, obviously. But in my case Git was a bit too reluctant to get away from that previous state :(
Yes. The remote-tracking branch is of course overwritten every time you push to or fetch from the remote, but otherwise not intended to be modified.> Okay, that too, obviously. But in my case Git was a bit too reluctant to get away from that previous state :(
I'm also not particularly happy about the behavior of pushing to non-bare repositories. I'm not sure why that can't just also update the working copy if the updated branch is currently checked out. Obviously the intended workflow is to pull from various other repositories and to push to dedicated remote repositories. You can push to repositories with working copies, but you then need to specify a different branch name to use in that repository and not overwrite the currently checked out branch.
That is obviously NOT the way of finding out how stuff works.
Uhm, so what would you do instead?
First readings some documents on how git works/tutorials? Even the manpage of git tells you to "See gittutorial(7) to get started".
Yeah, and take the formal git certification course, right. I have learned CVS, SVN, Bazaar, Darcs and Mercurial so far (in roughly that order) just doing my usual learning-by-doing routine, and *now* I should start reading tutorials? Make no mistake: I have read a good number of "Git for CVS/Darcs/Mercurial users" blog posts so far. I think I have a pretty good grasp of how Git works internally. Yet the interface digusts me everytime I use it.
Dictionary of git, word of the day: Indexed changes.
Dictionary of git, word of the day: Indexed changes.
![[ua]](/mwf/flags/ua.png "Ukraine")
Well, from the posts above we can see it realy works :-)
If you read closely, you'll notice that nobody helped with Peters problem. I could have - I've a pretty good idea what went wrong. (Okay, you could call mentioning "a random introduction to git" and "gitk --all" as helping, but I'd call it a politer form of RTFM.)
*rofl*
I know, I know. But I thought I have made clear that I'm not asking for help - I don't like doing that, I prefer to figure stuff out myself - just expressing my frustration. It really sucks when you sit at work and have nothing to show because such a tool messed up a simple copy operation. Sorry if anyone got offended.
I just thought it funny that that actually worked :)
Well, I had discussed my quarrels with git with Günther already, so he knew where I was coming from. Another way to look at it is that I wanted to give some more actual meat to my claim that I somehow always manage to misuse Git... I know it is probably a complicated perception problem, because I mainly want to "get" the viewpoint of people that continue claiming that Git takes over the best from all existing DVCS. I don't want to learn Git, I want to learn to like Git. So I am looking for some kind of use case relevant to me where git shines. So far without success.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
