github "clones"?
category: code [glöplog]
kb_: I'm not a fanboy really.
Do I like working with git? Yes.
Am I wrong to believe everybody can do it? In case *you have to* work with git, is it that difficult to learn 5 commands? I don't think so. At least I tend to not put much trust into programmer coworkers who pretend they can't and blame the tool or the author instead
Do I like working with git? Yes.
Am I wrong to believe everybody can do it? In case *you have to* work with git, is it that difficult to learn 5 commands? I don't think so. At least I tend to not put much trust into programmer coworkers who pretend they can't and blame the tool or the author instead
Ah, you divide the world into "can use git or is too stupid to" but you're NO fanboy. Riiiight.
yet i did not read any example or comparison about what that "horrible interface" seems to be.
seriously, five commands that are almost interchangeable to equivalent svn commands and everything else left to do is to read up a little bit about the distributed design.
where is the breakage?
seriously, five commands that are almost interchangeable to equivalent svn commands and everything else left to do is to read up a little bit about the distributed design.
where is the breakage?
kb: never said "too stupid", but "too lazy"
Anyways, what can I say? you're focusing on "And calling Linus Torvalds names doesn't help..." in my post; ignoring the rest...
git might be as badly designed as one wants, it just doesn't do things behind your back nor mess with the commits when navigating the hidden ".git" directory
Anyways, what can I say? you're focusing on "And calling Linus Torvalds names doesn't help..." in my post; ignoring the rest...
git might be as badly designed as one wants, it just doesn't do things behind your back nor mess with the commits when navigating the hidden ".git" directory
mkay fanboys. commands. i wanna reset a project to a specific working version. right now it glitches. bad. i had to copy files back in that wen't loose after it messed up. i commit the changes and they don't dissappear. so i wanna download the .git structure and explicit state from a specifc version of the project, a cleaned history cause everything after the glitch has kinda bugs. and i can't get rid of it. it always merges with the glitch. i don't know what this is? D:
check out the reset and checkout commands. they do what you want.
How about this (and I know that wou will conjure up carefully crafted rebuttals for each of my points that all result in "you didn't drink the kool-aid, you're not worthy anyway"):
* Let's start at the beginning. Why do I need a full copy of the whole repository anyway? It's nice you can do that but for many cases the last pulled head would really be enough without breaking the ability to commit/branch/merge locally and push later, which is the most common use case. Unless, yeah, somebody upstream just rebased/garbagecollected that particular commit into oblivion (so much btw about "git never loses anything"). Too bad. So, everyone _does_ need the full repo locally. Which basically rules out every single project that's bigger than 0.1% of your hard disk. We had Perforce/SVN/AlienBrain repos in the past where the current version easily reached tens of gigabytes and there were lots of big binary files that were changed often. Minor hassle with the former, absolutely not doable with git.
* When I see "horrible interface", I mean "no interface at all". It's basically just the internals laid bare with a very thin CLI wrapper. All the names, all the parameters are an exact representation of what goes on internally. But guess what - as a mere user of a tool (and this is what git should be: a mere tool. That simplifies things.) I really couldn't care less. So what's so wrong about sitting down for a minute and then think of verbs that actually describe what happens? Function that adds stuff to the staging area? How about "stage"? And more generally, how about not using the same verb for tracking, staging and resolving conflicts? How about actually separating the three completely unrelated things "reset" does into three words that describe them? What exactly has "checkout" to do with reverting a local modification? And yes, all of the examples become clear when you know what's going on under the hood, but again, why should I give a damn?
* Every single command in git is as counterintuitive as possible. All stuff that should be optional is the default and vice versa (index vs commit -a, switching branches w/o switching the working dir, etc.) I bet it doesn't even fit Linus' workflow but hey, he of all people probably has the least problems remembering all the command line parameters you routinely need to make the thing fucking do what you want.
Again, I'm not saying git doesn't do what it's supposed to do. It actually does, and even though we use svn at our company (as said, lots of big binary files) this applies well to our centralized team structure but I really don't want to miss those DVCS features when at home and collaborating with other people all over the world. But it's 2013. To officially start the name calling: Many of us have grown up and have lives now. And we're also used to software where at least _someone_ has put a little thought into that newfangled redundant stuff called "user experience". And I'm fed up with this army of basement dwellers who apparently spend more time drooling over git than actually writing software and fanboying all over Linus like it's 1995 and he's John Carmack. Git's interface sucks, and no amount of Stockholm Syndrome and no elaborate ecosystem of people writing git tutorials/books (because, surprise, even git's man pages only make sense for people already knowing how it works) will change that.
* Let's start at the beginning. Why do I need a full copy of the whole repository anyway? It's nice you can do that but for many cases the last pulled head would really be enough without breaking the ability to commit/branch/merge locally and push later, which is the most common use case. Unless, yeah, somebody upstream just rebased/garbagecollected that particular commit into oblivion (so much btw about "git never loses anything"). Too bad. So, everyone _does_ need the full repo locally. Which basically rules out every single project that's bigger than 0.1% of your hard disk. We had Perforce/SVN/AlienBrain repos in the past where the current version easily reached tens of gigabytes and there were lots of big binary files that were changed often. Minor hassle with the former, absolutely not doable with git.
* When I see "horrible interface", I mean "no interface at all". It's basically just the internals laid bare with a very thin CLI wrapper. All the names, all the parameters are an exact representation of what goes on internally. But guess what - as a mere user of a tool (and this is what git should be: a mere tool. That simplifies things.) I really couldn't care less. So what's so wrong about sitting down for a minute and then think of verbs that actually describe what happens? Function that adds stuff to the staging area? How about "stage"? And more generally, how about not using the same verb for tracking, staging and resolving conflicts? How about actually separating the three completely unrelated things "reset" does into three words that describe them? What exactly has "checkout" to do with reverting a local modification? And yes, all of the examples become clear when you know what's going on under the hood, but again, why should I give a damn?
* Every single command in git is as counterintuitive as possible. All stuff that should be optional is the default and vice versa (index vs commit -a, switching branches w/o switching the working dir, etc.) I bet it doesn't even fit Linus' workflow but hey, he of all people probably has the least problems remembering all the command line parameters you routinely need to make the thing fucking do what you want.
Again, I'm not saying git doesn't do what it's supposed to do. It actually does, and even though we use svn at our company (as said, lots of big binary files) this applies well to our centralized team structure but I really don't want to miss those DVCS features when at home and collaborating with other people all over the world. But it's 2013. To officially start the name calling: Many of us have grown up and have lives now. And we're also used to software where at least _someone_ has put a little thought into that newfangled redundant stuff called "user experience". And I'm fed up with this army of basement dwellers who apparently spend more time drooling over git than actually writing software and fanboying all over Linus like it's 1995 and he's John Carmack. Git's interface sucks, and no amount of Stockholm Syndrome and no elaborate ecosystem of people writing git tutorials/books (because, surprise, even git's man pages only make sense for people already knowing how it works) will change that.
if you wanna reroll to a previous commit, do:
git reflog
git reset --hard <id>
where <id> can be any identifier of a corresponding commit listed by reflog. you can use either the short hash or even HEAD@{X} to reset the repo.
i recommend you also read up the manpage for further information on them. and really, just read any tutorial or watch the video g. posted.
also, i'm not sure whether placing an old .git history into a dirty directory is a good idea really. so i don't know if the above commands will do for you. reclone the repo do things right from the beginning.
git reflog
git reset --hard <id>
where <id> can be any identifier of a corresponding commit listed by reflog. you can use either the short hash or even HEAD@{X} to reset the repo.
i recommend you also read up the manpage for further information on them. and really, just read any tutorial or watch the video g. posted.
also, i'm not sure whether placing an old .git history into a dirty directory is a good idea really. so i don't know if the above commands will do for you. reclone the repo do things right from the beginning.
if the command line usage irritates you, you can also try using a gui, sourcetree works pretty decently for me. is it perfect? no. plenty usability quirks left to iron out. but it's pretty damn decent and at the end of the day way better then sending zips back and forth.
i did skip most of kb's arguments, the first post i hadn't even read before posting mine, these followups i just skimmed through them. maybe he makes a good case. at this point in time git works for me and i'm thankful someone made it what it is. if something else comes to replace it, that'll be cool aswell.
i did skip most of kb's arguments, the first post i hadn't even read before posting mine, these followups i just skimmed through them. maybe he makes a good case. at this point in time git works for me and i'm thankful someone made it what it is. if something else comes to replace it, that'll be cool aswell.
yeah. fine. i'll just throw it away and restart from zero. i guess the rep is kinda damaged. and that commands seriously don't make sense to me. what does reflog mean? i get that reset thing but i don't want to reset anything. i wanna "sync -download revision" that be great. with simple button or perhaps a context menu in that lil client.
@kb_:
to check out the head, do git clone --depth=1. i could add/commit to that clone without problems. from there you could start creating diffpatches. however i even could push it to origin and pull into other clones contrary to my knowledge. so there's that. (maybe there's a trapdoor i don't see).
arguing about verbs will end in a holy war. for me they are fine and do what they say (and i used svn before, too). sure you need to get used to new commands. it's a different tool. as for checkout: it checks out branches or files, optionally from a certain revision. so yeah, that can be an old one.
it always depends on what one expects from a tool, what projects are being worked on and how it goes with your workflow. it certainly fits mine.
@yumeji:
git reflog lists the commits with their hashes and HEAD references, so you can actually look up what revision you want to revert to. that's what i at least understood you wanted to do.
to check out the head, do git clone --depth=1. i could add/commit to that clone without problems. from there you could start creating diffpatches. however i even could push it to origin and pull into other clones contrary to my knowledge. so there's that. (maybe there's a trapdoor i don't see).
arguing about verbs will end in a holy war. for me they are fine and do what they say (and i used svn before, too). sure you need to get used to new commands. it's a different tool. as for checkout: it checks out branches or files, optionally from a certain revision. so yeah, that can be an old one.
it always depends on what one expects from a tool, what projects are being worked on and how it goes with your workflow. it certainly fits mine.
@yumeji:
git reflog lists the commits with their hashes and HEAD references, so you can actually look up what revision you want to revert to. that's what i at least understood you wanted to do.
I love git. I love that my workplace uses it.
funny how you could just replace svn and git by emacs and vi and have the exact same thread =) both suck in any case, so wth. real men use the original VSS anyway, hosted on windows server ofcourse.
My own experience from Git and Subversion: to use Subversion, I had to read the SVN Book. To use Git, I had to read the book, and do some trial-and-error... After using Svn (and a couple of other older revision control systems), Git's commands seemed a little bit counter-intuitive. But with more experienced colleagues, it's OK. And really, this might seem obvious, but UTFG...
@groepaz:
thats why you use vim. we all know:
vim > *
EOD
thats why you use vim. we all know:
vim > *
EOD
Git is pretty good when you learn it.
About the space consumed, don't worry about it. Git only stores deltas, so it is very efficient, and Github is probably only storing each concrete SHA logically once (for sure several times for redundancy, but that is other topic).
A great way to visualize Git trees is with Gitx. I'm not sure if there is a version for PC, but for Mac it is great.
About your question, the process is like this:
1) Create a fork of the project you want from Github. After clicking in "Fork", you will have it in your account.
2) Clone that fork, that will be at somewhere like: git@github.com:yourUsername/nameOfTheProject.git
3) Then you work on your fork. You can work in the master if you want as it is your fork. You don't need to branch it, except if you want to create a branch for your own purposes.
4) After doing some changes, commit them to your local, and then push the commits to your remote.
5) Finally, you can do a pull request to the original project were you forked it. The admins of that project will be able to review your pull request and accept it or reject it. Before doing a pull request, be sure to read the pull request indications by the project and try to follow all rules, from coding style, testing and commit style.
About the space consumed, don't worry about it. Git only stores deltas, so it is very efficient, and Github is probably only storing each concrete SHA logically once (for sure several times for redundancy, but that is other topic).
A great way to visualize Git trees is with Gitx. I'm not sure if there is a version for PC, but for Mac it is great.
About your question, the process is like this:
1) Create a fork of the project you want from Github. After clicking in "Fork", you will have it in your account.
2) Clone that fork, that will be at somewhere like: git@github.com:yourUsername/nameOfTheProject.git
3) Then you work on your fork. You can work in the master if you want as it is your fork. You don't need to branch it, except if you want to create a branch for your own purposes.
4) After doing some changes, commit them to your local, and then push the commits to your remote.
5) Finally, you can do a pull request to the original project were you forked it. The admins of that project will be able to review your pull request and accept it or reject it. Before doing a pull request, be sure to read the pull request indications by the project and try to follow all rules, from coding style, testing and commit style.
@texel:
git doesn't store deltas. git is storing snapshots of the files for each committed change.
git doesn't store deltas. git is storing snapshots of the files for each committed change.
I still find these source control things confusing sometimes and wish the time I was in quickbasic.
I am joking about qbasic of course :)
But all thes cvs thing, seems like an extra step to me, and sometimes we got some strange error and one "sollution" was to make a new repository and start from scratch :P
I don't know, why modern tutorials and geeks want tons of extra steps, tools and stuff.
But all thes cvs thing, seems like an extra step to me, and sometimes we got some strange error and one "sollution" was to make a new repository and start from scratch :P
I don't know, why modern tutorials and geeks want tons of extra steps, tools and stuff.
Git interface sucks, that's true, that's why you should normally use a gui client. We use smartgit, it's not perfect but much better than command line (especially on windows). You can still fall back to cli (and enjoy all that comes with it...) when you want something more complex.
Also git internals sucks, that's harder to fix. I prefer darcs, but git has gui and branches, while darcs does not (well technically a branch is the same thing as a repo, but git's branches are still convenient).
Also git internals sucks, that's harder to fix. I prefer darcs, but git has gui and branches, while darcs does not (well technically a branch is the same thing as a repo, but git's branches are still convenient).
Quote:
@groepaz:
thats why you use vim. we all know:
vim > *
EOD
please keep me out of that, i do not and will not use this pile of dung, ever.
also VSS > *
FACT
@nemesis: wow, I've been thinking the other way around all this time! Sorry for the confusion!