Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Still hatin' on git: now with added Actual Reasons

reprog.wordpress.com

Post reply on HN
Print view View original

121–130 of 169 posts

Re: Still hatin' on git: now with added Actual Reasons

#121

Post by thenduks »

MikeTaylor wrote: post #117
pyre wrote: post #108

Earlier quoted context omitted.

> 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. 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…

Still, it can't be right that "get checkout foo" does one of two COMPLETELY different things depending on whether or not there is a file called foo in the current directory. Surely one of those two commands should have a different name.

I've always felt like `git branch` could be the one to switch branches (since it's used to create them too). But `git checkout -b` also creates branches... I think semantically checkout is the right command for this.

It's never come up as a problem because I tend to know what files are in my project and I also tend to know what it is I'm about to/want to do. I very rarely switch branches with a dirty working copy anyway and my branches are never named even remotely close to what files are named (by coincidence, I suppose, but I name branches after: 'releases' which have names like "2.2.2"; 'bug fixes' which have names like "bug2598" or 'features' which have names like "dashboard-rewrite" and "chunk-load-thumbnails").

Re: Still hatin' on git: now with added Actual Reasons

#122

Post by thenduks »

barrkel wrote: post #53
jrockway wrote: post #47

Earlier quoted context omitted.

"svn update" will randomly delete your work with no way to ever get it back. I don't think new git users migrating from svn actually understand that they can rollback any changes git makes. If a pull goes bad and you don't want to deal with it, just reset to your last head. All is forgotten until you feel like fixing it. And no data is ever lost. (svn loses data by merging everything it can with your uncommitted chan…

svn update has never randomly deleted my work, but then I never willingly do an svn update with local changes. svn update with local changes gives me this dialog: Conflict discovered in 'test.pas'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: However, I would normally just abort at this point, and make sure my local changes are packed up into a diff l…

Well, this begs the question, why not just let git do all that diff-packing and 99% of the conflict resolution crap for you?

As long as you don't mind spending a weekend or a few evenings reading about the new tool and how it works (like any new addition to your skillset), that is.

Re: Still hatin' on git: now with added Actual Reasons

#123

Post by lars512 »

pyre wrote: post #110
itistoday wrote: post #103

Earlier quoted context omitted.

> 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…

Issues that I've heard of with Bazaar: - 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…

The use case for numeric local revisions is pretty clear. How many global operations do you really do? In reality, nearly all operations are local. So would you rather write r37 or 0b090d7267df? Why wouldn't you want the choice?

Re: Still hatin' on git: now with added Actual Reasons

#124

Post by thenduks »

AngryParsley wrote: post #81
pyre wrote: post #37

Earlier quoted context omitted.

> I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout " is destructive without warning. From my point of view, that's like saying that 'rm -rf' is destructive 'without warning.' It does what it was meant to do, you can't expect everything to warn you all the time in an effort to save you from yourself. It would get really annoying, really fast if it asked you to confirm every t…

Git checkout also switches branches. "Checkout" sounds pretty safe, and svn has a checkout command (Which doesn't do anything but print an error message if you're in a working directory. It's the equivalent of git clone.). Finally, in most commands, git is paranoid about not destroying your changes. Combine all of these and you're in for a nasty surprise.

It's still being paranoid. You shouldn't be checking out anything while you have working copy changes unless you really, really mean to. This is why it's not a big deal that it's named the same.

Also, git defaults to working on a branch if the names conflict. If I have branch 'foo' and file 'foo' (both terrible names for files and branches) and try: `git checkout foo` it will switch to the foo branch and not checkout the file. Why would you ever do this with working copy changes except in very rare circumstances?

In short, I'm suggesting that if you have working copy changes then `checkout` means "restore this file to it's state in the index" and if you don't have working copy changes then it means "switch to this branch".

Since you always know if you have working copy changes or not, this is a pretty easy distinction to make.

Re: Still hatin' on git: now with added Actual Reasons

#125

Post by thenduks »

viraptor wrote: post #84
donaq wrote: post #80

Earlier quoted context omitted.

Linus didn't write git for you. He wrote it for himself. Git works exactly the way Linus (and his merry band of kernel hackers (and others, who thought DVCS was a cool idea when they heard about it and were prepared to relearn SCM to use it)) wants it to work. If you want to learn to use it, cool, welcome to the party. If you aren't prepared to invest the time, that's cool too. But don't try it for like a day expecti…

Git is gaining a lot of attention lately. It's becoming "the dvcs" now. And that means, if you start using it for your project, you should consider what does it mean for contributors / users. If it creates an additional step where someone will say - "it will take me more time to learn, than creating the patch itself", you've lost. If many people start using git, we can start expecting things from git. It's just not a…

I don't follow this at all. Taking time to learn a new and improved way of managing your source code is a deal breaker? These are exactly the people I'd hope to catch by doing phone interviews. "So, what's the last thing you picked up and learned for fun?... Oh, nothing? Ok, thank you for your time."

The creators of git have created/are creating a modern changeset management tool which, yes, you will have to learn to use effectively. This is a good thing.

Re: Still hatin' on git: now with added Actual Reasons

#126

Post by kuahyeow »

pyre wrote: post #109
d0mine wrote: post #41

Earlier quoted context omitted.

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.

'git gc' ? ;-)

http://www.kernel.org/pub/software/scm/git/docs/git-gc.html

"git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound)."

Re: Still hatin' on git: now with added Actual Reasons

#127

Post by viraptor »

thenduks wrote: post #125
viraptor wrote: post #84

Earlier quoted context omitted.

Git is gaining a lot of attention lately. It's becoming "the dvcs" now. And that means, if you start using it for your project, you should consider what does it mean for contributors / users. If it creates an additional step where someone will say - "it will take me more time to learn, than creating the patch itself", you've lost. If many people start using git, we can start expecting things from git. It's just not a…

I don't follow this at all. Taking time to learn a new and improved way of managing your source code is a deal breaker? These are exactly the people I'd hope to catch by doing phone interviews. "So, what's the last thing you picked up and learned for fun?... Oh, nothing? Ok, thank you for your time." The creators of git have created/are creating a modern changeset management tool which, yes , you will have to learn t…

New - definitely. Improved... it depends. If you think it's improved, fair enough, but this is your opinion. Not everyone has to agree. For example I think, it's got more features, but is lacking regarding the interface and usability. Overall, I don't consider it "improved" enough to adopt in everyday development.

Not spending time on completely learning how to deal with an inferior (imo) tool, gives me more time to learn things which matter to me. So it's the exact opposite of "learnt nothing".

Re: Still hatin' on git: now with added Actual Reasons

#129

Post by thenduks »

smallblacksun wrote: post #32
llimllib wrote: post #17

Earlier quoted context omitted.

just "git commit" after that, not "git commit README.md" edit: it's infuriating that yc won't let me reply to you, so I have to reply in this edit. Anyway. "git commit" says to git: "move anything in the index (i.e. things which I have 'git add'ed, or which have been merged) into the local repository". "git add FILE && git commit" says "put FILE in the index and then commit the whole index to the local repository" "g…

This is exactly the kind of unintuitive behavior that he was complaining about.

The thing is that it is intuitive if you only take some time to learn the new tool's features and how it is effectively used. Simply treating it like svn wont work. Yes you can 'get by' with some svn-like behaviors, but really dvcs is an entirely new thing you will have to learn to make sense of.

Here's an analogy. Svn is a horse and git is a car. You can imagine all these horse-riders (and there are tons of them) sitting around in a bar saying to each other "these new cars? What is up with them? It makes no sense that you change 'gears' and push pedals to stop and go! I just want to and I'll get to my destination!" -- Well, yea, horses work fine a lot of the time. But it's 2010 (1910? :)) and I have more eclectic needs in my change management. I'm willing to invest some time in learning it just like I was willing to invest time into learning vim, or Erlang, or anything else of value.

Re: Still hatin' on git: now with added Actual Reasons

#130

Post by viraptor »

donaq wrote: post #94
viraptor wrote: post #84

Earlier quoted context omitted.

Git is gaining a lot of attention lately. It's becoming "the dvcs" now. And that means, if you start using it for your project, you should consider what does it mean for contributors / users. If it creates an additional step where someone will say - "it will take me more time to learn, than creating the patch itself", you've lost. If many people start using git, we can start expecting things from git. It's just not a…

If many people start using git, we can start expecting things from git. Why? The author of a piece of software is under no obligation to satisfy the expectations of its incidental users, especially if he's not selling it to them.

If they get big enough... no they don't have an obligation, but the idea of many people depending on them should be enough. It's like MS had no obligation to satisfy expectations of IE5 users (not sold directly) - sure they didn't - but many got very annoyed because of that and because of the market share, we had internet-wide consequences for standard-compliant websites. Still - they had no obligation.
Post reply on HN