101–110 of 169 posts
He needs to spend less time typing and more time reading. I don't think git is something you can reason out just by throwing commands at it.
Earlier quoted context omitted.
Thank you. I suspect these folks were OK with spending hours learning about their DVCS, but for most others, this just seems like unnecessary tedium and frustration, "When can I get back to worrying about the code?" Someone needs to make the Mac of a DVCS, i.e. one that doesn't require a 20+ page tutorial to figure out, is completely intuitive and "just works." I currently use Mercurial, and while I don't think it qu…
Why yes, a lot of us are just fine spending "hours" learning something that we'll probably spend more than a few years using. Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. You're not going to come up with some solution that allows the user to "just do it"…
This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic.
One example of a DVCS with a good design and UI is a Bazaar. Sortof like the Mac a few years ago, no one uses it, but I wouldn't be surprised if it eventually gains in popularity. I see two things holding it back right now:
- Launchpad is terrible and needs to be at least as good as Github.
- In concert with having a terrible "hub", Bazaar has a small community of users.
To gain users, it will need to out-innovate like Apple did. That means on all fronts, not just bzr itself but the community, marketing, and the websites that support it.
Earlier quoted context omitted.
"svn update" will randomly delete your work with no way to ever get it back. No, it will not. You're left with a bunch of conflicted file, and a bunch of merged files, with no way to ever get the unmerged files again. Umm... no? Take a look at conflicted-filename.mine. Whenever there is a conflict, svn appends .mine to your copy of the file. After that, it creates conflicted-filename.r123 and conflicted-filename.r124…
No, it will not. Yes it will. Imagine you check out revision 1, which consists of two files: foo: a bar: b You do some hacking, and end up with: foo: a bar: b d While you were doing that, though, someone else committed, revision 2, which is: foo: a b bar: c You go to commit your changes, and svn tells you you can't, because you are out of date. So you have to svn update. Now you have: foo: a b bar: CONFLICT >>>> b d…
Also, your scenario is extremely unlikely. I've used svn for 5 years and I've encountered that problem once. It was for a binary file. Two versions of the same image. It's not very often that two developers create a new file with the same name at practically the same time. It's even less often that those files can be properly merged.
By your logic, "rm" is flawed because it doesn't ask for confirmation when you pass -f instead of -i. Well, yeah. Sorry.
$ git checkout blah
This command either switches to branch blah or it erases all uncommitted changes in a directory or file named blah. Without more information, you can't tell. I find that frustrating and annoying. Your analogy would be more accurate if rm somename was the equivalent of apt-get update, and rm othername was rm -fr othername. Oh, and somename is never tab-completed but othername is.
Also, unlike Git, Mercurial is coded in Python.. Git is a mesh-mash of half a dozen different languages. I'm guessing long-term, Mercurial will be maintained better (but might be wrong).
Earlier quoted context omitted.
"svn update" will randomly delete your work with no way to ever get it back. No, it will not. You're left with a bunch of conflicted file, and a bunch of merged files, with no way to ever get the unmerged files again. Umm... no? Take a look at conflicted-filename.mine. Whenever there is a conflict, svn appends .mine to your copy of the file. After that, it creates conflicted-filename.r123 and conflicted-filename.r124…
Here's another crazy idea: don't run 'git checkout ...' on a dirty work tree. Problem solved. Another one: don't reuse filenames as branch-names. To be honest: I have the same problem with careless invocations of 'rm' ruining my day but when I'm muttering curses it is at my lazyness/stupidity and not at bash completions or the behavior of 'rm'
Now that 1TB is like $70, we should just keep every filesystem state around. Maybe not forever, but so that "rm -rf *" is just a "gah, that's not what i wanted!" moment instead of a "the rest of my day is ruined" moment.
Premature optimization is the root of all data loss.
Earlier quoted context omitted.
I presume you haven't come across Hg-Git, then. http://hg-git.github.com/
I've seen things like this. I would be very wary about trusting them with my precious source code, wouldn't you? However good they are, they're an additional layer in which (A) things can go wrong, and (B) you're insulated from the reality that you need to access to fix problems. I fear that Hg-Git would be one of those things that is an absolute delight for as long as it Just Works, then abruptly transitions into an…
Earlier quoted context omitted.
No, it will not. Yes it will. Imagine you check out revision 1, which consists of two files: foo: a bar: b You do some hacking, and end up with: foo: a bar: b d While you were doing that, though, someone else committed, revision 2, which is: foo: a b bar: c You go to commit your changes, and svn tells you you can't, because you are out of date. So you have to svn update. Now you have: foo: a b bar: CONFLICT >>>> b d…
You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must be manually resolved. Unfortunately, making updates atomic across a branch has disadvantages. For example, svn lets you update individual files or directories instead of the whole branch. If you want to avoid this pitfall in the future, run "svn merge --dry-r…
I think that the point is that file 'foo' has already been merged, regardless of the conflict in file 'bar'. There is no way for you to revert to the pre-update state. In git, your previous commit still exists in the objects store even if it is no longer connected to the tree. And garbage collection won't even clean it out right away because it is still in the reflog ('git reflog'). The point being that once something is committed, it's permanently (barring garbage collection) in the repository. Whenever you make a change to a commit, a new commit is created, some pointers are changed, and the old commit still remains in the repository.
> Oh, and somename is never tab-completed but othername is.
Responsibility for the tab-completion falls squarely on your shell (or where ever you got the tab-completion setup from). Don't point your finger at git and say, "git sucks because bash tab-completion screwed me up." Neither rm nor git can control how your shell bothers to determine tab-completion.
I have read a fair amount of documentation on git. I still don't even know what most git commands do. When people recommend a rebase, I pretty much just pretend that my repository isn't going to die. I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout " is destructive without warning. I once destroyed a number of local files (I don't remember how) that were thankfully still ope…
Once files are added to git it is almost impossible to destroy them irrecoverably. So my impression of git is the opposite I perform any command without fear to lose anything. If the command doesn't do what I need I just rollback to the last known good state.
Earlier quoted context omitted.
Why yes, a lot of us are just fine spending "hours" learning something that we'll probably spend more than a few years using. Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. You're not going to come up with some solution that allows the user to "just do it"…
> Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic. One example of a DVCS with a good design and UI is a…
- Being pure Python it doesn't have the same performance that git does. This may not show up in day-to-day usage, but things like 'convert this svn repo to Bazaar' tend to bring the bottlenecks/performance issues into the light.
- Bazaar made this weird design decision to have two revision numbers. a 'r12345' type revision number that is similar to SVN, but only applies to your local checkout of the repo, and a checksum (SHA1 or MD5) which applies globally (across different checkouts). I think that choosing a revision scheme similar to SVN's but one that doesn't map 1-to-1 with SVN is just asking for confusion from newbies. (I'm not entirely sure why one needs to have local and global revision numbers...)