Google closing Yet Another Service - GoogleCode
-
Because it's fundamental to the problem of version control.
Right; but it'd not fundamental to me, the user of their software. It's only fundamental to the developer of source control software. And their job is to abstract this shit away so I never have to think about it.
Plus you immediately notice deficiencies in the way centralized systems (all of them so far) do merging as they can't find the most recent common ancestor in certain cases even though it is well defined.
I don't notice the deficiencies in how, say, Subversion or TFS does merging because I'm too distracted by the millions of deficiencies in how Git does merging.
Then Git is not for you.
Duh?
The problem is, I don't have a choice. I have to use this shitty piece of ass, or be unemployed. What the idiots in IT have done is taken a really, really shitty product and made it a de-facto standard to the point where everybody in the industry needs to know it. That's bad and wrong. Badong. I will dedicate my life to the opposite of badong: gnodab!
... so anyway, imagine the thousands of man-hours wasted by the IT "groupthink" choosing this horrible inferior solution. It sucks. It really, really sucks.
-
Right; but it'd not fundamental to me, the user of their software. It's only fundamental to the developer of source control software. And their job is to abstract this shit away so I never have to think about it.
No, it's fundamental to the developer of software interested in using source control software to help him manage his shit.
-
Right; but it'd not fundamental to me, the user of their software. It's only fundamental to the developer of source control software.
Yes, fundamental for you, the user of version control software. Any version control software. Because that's what non-linear history is and how it behaves.
And their job is to abstract this shit away so I never have to think about it.
Unfortunately, they can't do it. Because they are different developers of different version control system and each will inevitably use different abstractions. Once you see the common concept, any version control system is the same old story. If you don't, they are all black magic. You seem to be fine with black magic though. I am not.
The problem is, I don't have a choice. I have to use this shitty piece of ass, or be unemployed.
Actually, you may try to use Mercurial (hg). It can just talk to git server as if it was it's own.
... so anyway, imagine the thousands of man-hours wasted by the IT "groupthink" choosing this horrible inferior solution. It sucks. It really, really sucks.
Obviously those people saw a point in that solution.
-
No, it's fundamental to the developer of software interested in using source control software to help him manage his shit.
Microsoft Office's "Track Changes" feature does like 90% of what SCM does, and somehow normal people can use that without ever having heard the term "acyclic directed graph".
-
Microsoft Office's "Track Changes" feature does like 90% of what SCM does, and somehow normal people can use that without ever having heard the term "acyclic directed graph"
Does it? How does it handle branches? Do people ever do stuff like have an older version that they deploy and maintain in addition to the newest versions?
That stuff is pretty handy, but I call bullshit.
-
Yes, fundamental for you, the user of version control software. Any version control software. Because that's what non-linear history is and how it behaves.
Right; and it should be impossible for me to use Photoshop without knowing exactly how it translates color between CMYK and RGB.
Unfortunately, they can't do it.
Undoubtedly, being utterly incompetent at writing software. But it would have been nice if they fucking tried.
If you don't, they are all black magic. You seem to be fine with black magic though. I am not.
Everybody's fine with "black magic" as you phrase it. If you're telling me you need to learn literally every detail of how your computer software and hardware works before you can even touch a mouse, you are either insane or a fucking liar.
The difference is how much "black magic" we find acceptable. It's a continuum.
Actually, you may try to use Mercurial (hg). It can just talk to git server as if it was it's own.
Can you recommend a good GUI client for it? Does one even exist?
Since Git is hugely more popular, and has zero good GUI clients, I'm guessing not.
Obviously those people saw a point in that solution.
A lot of developers are self-delusional, pick solutions based on what's popular instead of what's good, and never bother to measure their own performance afterward to find out if choosing the solution actually saved them work in reality.
-
That's why I said 90%, numbnuts.
-
Right; and it should be impossible for me to use Photoshop without knowing exactly how it translates color between CMYK and RGB.
You seem to be missing the point: The DAG in DVCS is not an implementation detail, but the entire concept! So the equivalent would be trying to use Photoshop without understanding the concept of layers.
-
Microsoft Office's "Track Changes" feature does like 90% of what SCM does, and somehow normal people can use that without ever having heard the term "acyclic directed graph".
And yet somehow (admittedly because I've used it a lot less), I still find it much more opaque and more trouble than I think I've ever had with Git. Funny how that works. :-)
-
That's why I said 90%, numbnuts.
Except not the stuff we were just talking about, so in reality, it's unfit for purpose, and anyways, not a valid counterpoint to not needing to understand this stuff.
Sorry, I thought you believed your comment to be relevant.
-
So the equivalent would be trying to use Photoshop without understanding the concept of layers.
And why shouldn't you be able to do that?
-
And why shouldn't you be able to do that?
Well, you are. You can add effects and use brushes without understanding layers. Same as you can commit your code and revert commits in git/hg/etc. without understanding their internal data model. But as soon as you want to make use the advanced features of either Photoshop (layers) or a DVCS (branches), you have to understand those concepts (layers/DAGs of commits).
I'm not claiming that Git's GUI isn't shit (it is) or that Git's command-line interface or documentation are user-friendly (they aren't). But even if it had a good GUI, you'd have to learn about how it structures the history internally to use its advanced features. Same as you have to learn about the concepts of OOP before being able to efficiently and correctly use the features of any modern programming language (to use another analogy).
-
Proponents of other DVCSs (which would include both @boomzilla and myself) think that while git might be OK for very large projects, most people would be better off with something else, such as Mercurial or Fossil, where more of the state gets shared by default. Things are a bit more synchronised, but for a smaller team that's no bad thing.
Yeah, I think git is probably a great fit for the Linux kernel team, but for my one-man hobby projects, it's probably ridiculous overkill. The limiting factor is time, and any time I spend trying to get to grips wiith git is time I could be spending haxxing on kodez, which certainly feels like a more productive thing to be doing of an evening.
Basically, I don't really want to have to think about my VCS, I want it to just work, or I want to have really clear documentation I can have confidence in following and understanding without too much mental effort on my part.
-
Subversion is complex, because it takes one concept, directories, and repurposes it for another thing, branches, for which it is not a good fit.
But for a lot of developers, treating branches as directories feels intuitive. Sure, we're talking specifically about Subversion here, but I've used Perforce before, and its branching model is not a milllion miles away from svn. You need to go about it in a slightly different way, but I once I was able to branch/merge in one, I was able to branch/merge in the other.
Sure, treating a branch as some nebulous cloud of diffs, is something I could eventually wrap my head around, but on my PC, I have my branch in a separate directory alongside my trunk; why shouldn't my VCS reflect that?
-
Microsoft Office's "Track Changes" feature does like 90% of what SCM does, and somehow normal people can use that without ever having heard the term "acyclic directed graph".
More like 10% -- it does nothing about problems as simple as merging two Word files together, never mind actual branching, or cherry-picking revisions, or any of the things I expect an actual VCS to handle.
Overall, Blakey, [i]stop confusing details with concepts![/i]
You seem to be missing the point: The DAG in DVCS is not an implementation detail, but the entire concept! So the equivalent would be trying to use Photoshop without understanding the concept of layers.
QFT!
-
Overall, Blakey, stop confusing details with concepts!
I don't know what that means.
But even if it had a good GUI, you'd have to learn about how it structures the history internally to use its advanced features.
If it had a good GUI, it would teach me those concepts. So no, I wouldn't have to expend effort to learn them, I'd learn them simply by using the product.
And, again, that is difficult to do. And, again, I'm sure the Git team is incapable of doing it. But it would have been nice if they had at least tried. Or even acknowledged the need exists instead of just shitting this product on us all and calling it "done".
-
If it had a good GUI, it would teach me those concepts. So no, I wouldn't have to expend effort to learn them, I'd learn them simply by using the product.
And, again, that is difficult to do. And, again, I'm sure the Git team is incapable of doing it. But it would have been nice if they had at least tried. Or even acknowledged the need exists instead of just shitting this product on us all and calling it "done".
DAGs are pretty intuitive. I'm sure a well-designed GUI/interactive tutorial could actually teach the user to view a repository as a DAG of commits.
Maybe, someday, I'm going to try to write a decent GUI for Git. It can't turn out worse than the existing ones, can it?
-
Git is much more complex than svn.
Use Git Flow and it's pretty much the same. Admittedly I've only used it through SourceTree on Windows.
-
a well-designed [...]interactive tutorial
How about this one: https://pcottle.github.io/learnGitBranching/
-
I'm sure a well-designed GUI/interactive tutorial could actually teach the user to view a repository as a DAG of commits.
It's not actually particularly difficult once you've got a non-misanthropic GUI in the first place. Here is an example; it's a project I'm working on with a friend (but don't sweat the subject matter in this thread). The display is done by colour coding the branches, making it relatively easy to see what is what, and there are arrows showing what was derived from what. It's all there, what was done by whom and when. (The code for drawing the graph of commits is an amazing piece of DOM abuse, but I didn't write it…)
I've not seen as accessible an interface as that in any CVCS (though I admit I've not looked as hard) or in any GUI for Git. I'm not sure about the Mercurial web interface; maybe I just don't know how to drive that so well.
-
How about this one: https://pcottle.github.io/learnGitBranching/
Well, I gave that a go, and I can't even get past the second tutorial (make a branch and switch to it) because they don't explain
you're supposed to do properly—I did git branch bugFix, then it doesn't recognisegit switch bugFixas a valid command; andgit commitirrevocably fucks up the whole tree and you have to start over (hey, actually, this tutorial does reflect my git experience...)
-
Wait, I have to
git branch <branchname>and thengit checkout <branchname>?!TDEMSYR
-
You can also do
git checkout -b <branchname>
-
Create a new branch and then immediately check it out?
Trying to glom two seperate branches onto the same working copy seems like a really error-prone way of working to me...
-
But why is it a two-step process at all? With Mercurial, I can create a new branch on commit; but then, with Mercurial, I don't have to check anything out after cloning a repo…
-
git cloneautomatically checks out the default branch (which is by default namedmaster)
-
I don't understand why they call it "check out". I'm not checking it out, is already in my pc. And everyone always talks about switching branches, not checking them out.
-
Git Koans, "One Thing Well": http://stevelosh.com/blog/2013/04/git-koans/
-
I don't understand why they call it "check out". I'm not checking it out, is already in my pc. And everyone always talks about switching branches, not checking them out.
This is one of Git's... terminology "weirdnesses", and I agree that it seems like it was chosen to be deliberately obtuse. But there is a logic behind it. "Checkout" to Git means to move stuff from the repository to the working copy. If you want to go to an old revision, that's moving stuff from the repository to the working copy (so you usegit checkout 32902bf). If you want to throw away the changes you made to a file in the working copy, that's moving stuff from from the repository to the working copy (so you usegit checkout foo.c). If you want to switch branches, that's moving stuff from the repository to the working copy (so you usegit checkout myfeature).To someone used to, say, Subversion, those are three separate things and get three separate commands (
svn up -r,svn revert,svn switch). To someone who buys into the Git mindset, the Subversion thing makes less sense because you have three names for the same kind of action.I'm not sure that I actually like the Git way of doing things, but I don't dislike it either. I'm not a fan of "checkout" as the name of the subcommand, but I'm also hard-pressed to come up with something I like better. (One term I do dislike a little is
git revert, which is made available by Git'scheckoutbehavior. Whatrevertdoes for Git makes perfect sense in a vaccuum, but every other VCS ever made1 uses the same command for the same different action, I think it's a mistake to use it as Git does.)1 This is probably hyperbole. Probably.
-
I think the fundamental problem I have with
gitis that I don't feel comfortable using it, and I don't trust myself not to screw up the repo entirely because I had the wrong flag on a command or I did aresetinstead of arevert(or vice versa, or whatever...).I did try using
egbecause it is supposed to make the commands and terminology sane to a normal VCS user, but IIRC there are some actions it simply can't do, so you're forced back to thegitcommandline anyway, and now you're trying to learn two new sets of terminology at the same time.And because I don't feel like my source code is safe with it (which is really the point of a VCS), I am disinclined to use it, so it will always feel strange and uncomfortable. It's a bit of a vicious cycle really...
-
And because I don't feel like my source code is safe with it (which is really the point of a VCS), I am disinclined to use it, so it will always feel strange and uncomfortable.
Yes. Seconded.
Also I don't feel comfortable using the CLI at all, because I'm always terrified I'm going to typo a letter and lose all my files, and there's no undo or any safety features whatsoever. So using Git in the CLI is like double-awful.
-
...and there's no undo or any safety features whatsoever.
IMO this is just patently false. In fact, it's true of every other VCS I've used (which is admittedly that many; basically CVS/SVN/Git/Hg) but not Git. There are only two destructive operations I know of in Git -- the revert use case ofgit checkout(which will throw away changes in your local copy) andgit gc("garbage collect", which will remove unreferenced commits from the repository. The first isn't undoable in any other VCS I know of, and the second doesn't have an equivalent in other VCSs (and is, in fact, what makes Git robust).(Disclaimer for the pedantic.
git gccan be run automatically, so technically you can experience that destruction for other commands; but this is rare and you can disable it if you want. In addition, you could argue that you can't undo changes to the index, and I'll grant that -- but very rarely is significant state in that.)Aside from those, basically everything else that looks destructive can be fixed by looking at the reflog, which holds a list of the revisions that you had checked out "recently". (For quite liberal definitions of "recently" in my experience.) Accidentally reset
masterto point to a bad commit? Just look at the reflog, find theresetcommand, and that line or the one after is highly likely to be what it was before your mistaken commit.
-
IMO this is just patently false. In fact, it's true of every other VCS I've used (which is admittedly that many; basically CVS/SVN/Git/Hg) but not Git. There are only two destructive operations I know of in Git -- the revert use case of git checkout (which will throw away changes in your local copy) and git gc ("garbage collect", which will remove unreferenced commits from the repository. The first isn't undoable in any other VCS I know of, and the second doesn't have an equivalent in other VCSs (and is, in fact, what makes Git robust).
Is there a
git undothat just reverses the last thing you did (provided it wasn't agit push)?
-
Is there a git undo that just reverses the last thing you did (provided it wasn't a git push)?
No, but that would be pretty awesome. (But there isn't in any other VCS I know of either, so... it's not quite fair to knock Git for it. I was more addressing the "safety features" part.)Edit: now I'm contemplating the feasibility of writing one and how it would work...
-
IMO this is just patently false.
Oh?
So I typo "rm -rf *", how do I undo it? Enlighten me.
In fact, it's true of every other VCS I've used (which is admittedly that many; basically CVS/SVN/Git/Hg) but not Git.
The sentence you quoted wasn't referring to VCS's, but to CLIs. Good reading comprehension, at this rate you'll graduate from the 2nd grade in no time at all.
... and in any case, Git specifically still has no way of undoing an operation, so.
Is there a git undo
No,
See? You tell me I'm "patently false", then literally 2 posts later you agree with what I said. WTF is wrong with people on this forum.
-
But there isn't in any other VCS I know of either
You need to widen your scope of known VCSs. :) This is one of the more awesome features of fossil: have an “oops, I didn't mean that!” moment? Almost everything can be reversed with
fossil undo(with the exception of things that change a remote repository, of course, and undoing a commit is awkward). It's saved my bacon a few times. It's also a lot stricter about making sure it doesn't lose things than git's slap-dash laissez faire approach, but then it was written by people who know what a real database is…
-
So I typo "rm -rf *", how do I undo it?
That's not a VCS operation, so recovering will be awkward at best. An undo mechanism also doesn't recover from slagging the drive with a few pounds of thermite but we shouldn't get rankled about that.
-
So I typo "rm -rf *", how do I undo it? Enlighten me.
I see, I read your post too quickly; I thought the "no way to undo and no safety features" was talking specifically about git, and not the CLI in general.You tell me I'm "patently false", then literally 2 posts later you agree with what I said.
For F's sake. I was talking about the safety features part (like I said in my reply), which the reflog definitely falls under.
-
For F's sake. I was talking about the safety features part (like I said in my reply), which the reflog definitely falls under.
Right but... it doesn't, because there's no way to simply undo an action. You said so yourself, so I don't know why you're contradicting yourself now.
From what dkf says, it sounds like Fossil was written by developers who weren't quite as incompetent as the Git developers.
-
OK, so what's a VCS that you like?
-
From what dkf says, it sounds like Fossil was written by developers who weren't quite as incompetent as the Git developers.
Yes. It's written by the same guy as wrote SQLite. He's one of these dangerously competent and balanced programmers. And a personal friend. :)
-
OK, so what's a VCS that you like?
TFS is barely acceptable when used inside Visual Studio. Especially since 2013 has adopted the few good features Git has that TFS (previously) did not.
I don't "like" any of them. They all have really, really shitty usability. The amazing thing is how Git could come into a product area like this, where the bar is already resting directly on the ground, and somehow LOWER the bar.
I mean, asking me this is like asking, "well if you don't like Verizon, which cell carrier do you like?" Well, no sane person likes any cell carrier, they're all shitty in different ways. Sure they use one, but they certainly don't like them. It's a ridiculous question.
-
The amazing thing is how Git could come into a product area like this, where the bar is already resting directly on the ground, and somehow LOWER the bar.
QFT
-
Almost everything can be reversed with
fossil undoI''m starting to feel that the time spent getting to grips with
gitwould be better spent onfossil(and/orhg)...
-
hg's pretty nice in my experience ;)
Never usedfossilthough
-
I''m starting to feel that the time spent getting to grips with git would be better spent on fossil (and/or hg)...
My preference is for Git over Hg, but I can understand the other way around. Hg is easier to use and definitely closer to other VCSs. Git better matches the workflow that I've always wanted from a VCS, though there are still a couple largish steps before it's perfect.I might have to play around with fossil a bit. Could be interesting. I'm somewhat skeptical I'll like it, but I'd like to at least try it.
-
I might have to play around with fossil a bit. Could be interesting. I'm somewhat skeptical I'll like it, but I'd like to at least try it.
The main things to be aware of, coming from git, are that:
- It starts in autosync mode, so it pulls and pushes changes close on automatically (supporting a workflow very much like a centralized VCS).
- You can make a private branch if you want, as an option during branch creation, but then that branch stays private; you'll have to merge changes from it to other branches for them to be visible to others.
- It propagates labels (branch names, tags) so you'd better want to used the same ones as your colleagues. (You usually do, so it's not a big deal, and on larger projects it's trivial to start the branch name with your username if it is mostly a private thing.)
- No true rebasing allowed, and there's nothing like
git gcat all. Commits are basically impossible to remove (unless you muck around with shunning) but you can hide a branch if you make a non-critical oopsie. Changes to commits (e.g., adding a label, hiding a branch) are done using a “correction” model, analogous to how corrections are handled in bookkeeping.
On the other hand, conflicting commits won't make it shit itself. You'll just end up with two branches with the same name (and just using the branch name will use the newest commit out of the two branch tips); the easiest way to fix that is to use the built-in web UI to change the name of one of the branches and then merge between them.
The other difference is that it is database-backed, and you can share the repository DB between many checkouts. I like to keep my databases in a single shared folder (in the directory
~/Library/fossil/since I'm on OSX). There'll also be a local database in each checkout (I think the current preferred name is.fslckout) which holds things like stashed files, the undo history, things like that.
-
No true rebasing allowed, and there's nothing like git gc at all. Commits are basically impossible to remove (unless you muck around with shunning) but you can hide a branch if you make a non-critical oopsie. Changes to commits (e.g., adding a label, hiding a branch) are done using a “correction” model, analogous to how corrections are handled in bookkeeping.
This is the part that worries me, because I don't really know what it means; the Git vs Fossil page doesn't give enough detail.Probably easiest to say what I mean by example. I make a series of commits that I'll call A, B, and C. Now I pull/fetch, and there are commits on the same branch.
In Gitland, because I am almost always a Rebaser instead of a Merger, I would rebase A, B, and C on top of the new head to get A', B', and C'. Then after I push, the history that I and everyone else would see is a linear history of old stuff -- A' -- B' -- C'.
Now, what I wouldn't object to (and, in fact, would like) is if the repository kept around the original A, B, and C commits, and had pointers to them from A', B', and C'. What I would object to is if the way in which those commits are kept around interferes with a reasonable way of seeing the old stuff -- A' -- B' -- C' view of history; the original commits should only be visible "on demand", so to speak.
Does that make sense?
(The other thing that would be close to a deal-breaker is if I can't reasonably get something like Git's index, or at least
commit --patch. Though I guess if worse came to worst I could adapt the script I wrote for SVN to get me something kind of like that...)
-
Does that make sense?
I'm keener on the merge workflow. I'd introduce a new commit, D, which is the merge of the head and the tip of A—B—C (with which branch this is on depending on what was going on). The braided commit pattern that this introduces doesn't bother me; I see it as being basically more honest as to what actually happened. I'm sure you could build a rebasing tool using the fossil API (and hiding the old branch, which is a newer feature than a quick google search indicates for the last discussion of rebasing with the fossil devs) but it's not the way I work.
The rebase/merge argument seems to be one of these that can only truly be appreciated when held in a bar after the first few beers have been drunk.
The other thing that would be close to a deal-breaker is if I can't reasonably get something like Git's index, or at least commit --patch.
I've never used that, so I'm not exactly sure what it does! :D
I'm a believer in getting things right before I commit at all; I usefossil diffandfossil statusextensively.
-
The braided commit pattern that this introduces doesn't bother me; I see it as being basically more honest as to what actually happened
It bothers me, because from what I can tell your commit D is often unreviewable and ununderstandable. If it solely consists of automatically merged changes it's probably OK, but beyond that it becomes very difficult to deal with. How did you fix textual merge conflicts? Are there other, non-textual conflicts that you had to change? Were there any other changes that you made by mistake while working on those that are getting committed? These are questions that are a PITA to answer after the fact. And then if you go to do the equivalent ofgit bisectafterwards (to figure out when something went bad) and wind up finding that a problem was introduced in a merge commit, then God help you.I've never used that, so I'm not exactly sure what it does!
I find they're amazing tools; both are helpful with dealing with the case where you have two things going on in your working copy at the same time; for example you're working on adding some feature, run across a bug partway through, and fix the bug. Depending on how this plays out, there are multiple ways of dealing with the situation:- If you have the foresight that "oh, I'm going to be working on this bug now", you can stash the feature changes, fix the bug, commit the bug fix, and unstash your changes. I think you mentioned fossil can stash, so that takes care of this use case.
- If the bug fix is only one or two files, then you can commit just those files. I figure this is supported by basically every VCS out there, so that's not a problem either.
- Where #2 gets annoying is if both the feature change and the bug fix have like half a dozen files spread around and intermixed, but they are still in independent files. This can be dealt with as in #2, but with most VCSs you have to explicitly name all of the files you want to commit in the
commitcommand. Git's index provides (IMO) a rather nicer way, letting you sort of split up what you want to commit into multipleaddcommands. I think this can be more convenient, e.g. by doingcd foo; git add foo.c; git add foo.h; cd ../bar; git add bar.c; git add bar.hinstead ofgit commit foo/foo.c foo/foo.h bar/bar.c bar/bar.hbecause it means you can do other things in between looking at the files, e.g. do diffs. And on top of that, the index somewhat enablesgit add --interactive,which is basically sort of an interactive status thing: it'll show you a list of the files that have been modified, and you can just type1, 2, 5, 7or something to select from that list. The index also enables... - Where #2 falls down completely with other VCSs is if you both your feature change and bug fix touch the same file.
git add --patchandgit commit --patchallow you to deal with this situation, by showing you each hunk of the diff and asking whether you want to commit that hunk. You can even edit hunks on the fly if changes are interwoven within a single hunk. This is what makes the index really shine, because you can do things likegit add foo.cto pick up all your changes tofoo.c, but then dogit add --patch bar.cto just commit parts of that file.
You say you like getting commits right, and I do to -- and in fact, that's exactly why I like these so much, because I think they give you an ability to get the commit right with less work than almost any other tool. (Supposedly Hg's patch queue extension gives an even more powerful version of this, but I haven't had the opportunity to play with it, and don't know what the "more powerful" part would be.) And the index is a large part of the reason I really like Git even in a centralized environment.
(To preempt another comment: I don't think "just try to fall into #1" is a good answer. I find that a lot of the time I don't realize that what I've done is really two separate logical changes until I've done a lot of both changes. I mean, sure, it's nice when you can do it, but I'd rather have a VCS where I almost don't have to worry about the problem at all because it's barely a problem.)
