pouët.net

anybody of the experienced devers here knows howto virtually clone a repository from a source on github?

i copied/downloaded one and just wanna upload the changes i made to that. does github actually support that? i just don't wanna reupload the whole codebase AGAIN. which is a complete duplicate and a waste. just for the sake of saving the space. i just wanna sync the diffed files from the source.

you know what i mean? does that work?

ugh. D:

fork the project, apply your changes, send pull request to upstream. that's the github idea. or become direct contributor in the upstream project.

yeah... i love it. it works great. lol. i have no idea who designed that concept. that is a MESS.

i forked it. created a branch (which should be the copy of the repository) and tried to commit changes to that. that's how it should work. but it does nothing. it just fails.

that's some BULLSHIT.

first questions first:
is it your repository? or is it someone elses and you just try to apply changes there? if so, maybe its as simple as its in need of a password ;)
my problem is, i used a lot of Subversion (SVN) so far, but never GIT, so i am just shooting a guess here and cant really help! ;)
Maybe try to start an own project on GitHub and see if you can commit to this repo and see if that works as you think it should.

I'm sure there are hundreds of tutorials out there to get started with git and github

this is basically everything you need to know apart from git add and git commit: https://help.github.com/articles/fork-a-repo

yumeji:It's not so much Github, but Git which was designed and developed by Linus Torvald. That might explain a few things :p

so as i used a lot of git and got some certificate saying that i am an expert, first things first:

the concept of git is quite different from that of svn.

first of all, when you do what's called check out in svn, you do a clone, which does exactly what it states, it creates a clone of the complete repository (and materializes a working copy of the branch indicated by HEAD in the actual repository, see .git/HEAD). so although you don't want to copy the complete source and duplicate it, you actually have to do it anyway when working with git.

second: in git a branch is just a commit. if the parent of a commit has two children you have a branch there. a commit is in turn just some diff (tbh, they use delta, that's why git can also deal with binaries pretty good) identified by an SHA-256 checksum. so what happens when you create a branch is that a file is created in .git/refs/heads/<branchname>. check out the contents of those files and you'll see that there are just SHA-256 keys in there. these branches are local until you explicitly push them (git push <remote> <branchname> in the simple case where the remote branch should have the exact same name as the local one).

so i don't know how the internals of github are implemented, but as the fork has the same commits (in respect to their checksums), i would suspect a fork to be a clone internal to github. when you clone it to your local, make changes, commit and push them, you will only transmit the commits on top of the head you checked out. what you also do is creating patches (git format-patch , see the help files for that, it simply has too many options). these patches are formatted as mail, one for each commit. the reason is that the whole linux kernel source and patches were solely managed over a mailing list, no version management was used. anyway, you can then for instance open an issue in the upstream project and put the diffs there.

if i were you, i would simply ask the upstream project contributors how they would like to receive contributions. for the rest: just google, there is so friggin many resources out there on how to contribute to github hosted projects (e.g., some docs by github). also here is a nice cheat sheet.

concept note: i think you did not understand the git concept, neither did you understand why github works the way it does. it has its up and downsides. leaning git is especially hard when you have a svn/cvs background and thought you knew something about version management. i was like that at first too, but after using git for some time and really learning it, i love it. admittedly it does not follow the "keep simple things simple" approach for newbies, but the "make impossible things possible".

also hardy: git is mostly bound to ssh, so it's more likely he didn't set his public key on github, given that he already created a key pair.

p01: check out the git sources. there are basically only curly braces and newlines left from torvalds code ;)

yo. i got it fixed. didn't recognise that lil text field somewhere in that GUI that asked for a bogus mail to attach to the commits. i thought that was already set when opening the account. quite simple error. all cool now.

skomp: No surprise; Git came out 8 years ago. At least later contributors didn't change his indentation thus completely removing him from the list of contributors to the current code base. Anyways, the point was that Torvalds laid down the design and principles. Which you illustrated nicely:

There is another quote I read somewhere on the net which is remarkable and correct:



This sums it up. You have to learn about git's special features before you can actually understand the concept and this leads to the fact that no newbie can understand why he should use git. also there exists no good graphical client that i'm aware of that actually exposes all of these special features and typically the ides can't deal properly with switching branches while the project is opened (at least visual studio fucks up big time. either the project is locked, then you can't switch or it has to deal with resources appearing and disappearing on switch).

Only that your talk of "newbies" is utter, complete bullshit.

Of course DVCS concepts are somewhat harder than one central SVN repo or even a "good" old lock based system (which coincidentally most non-coders I know still prefer because resolving conflicts in everything else than source code is near impossible). But seriously, we're talking about git. The one piece of software that is the poster child for horrible, absolutely unusable interface design, and host to a handful of very questionable design choices.

Its inner workings are absolutely elegant, and when you know a bit of graph theory everything in the .git dir becomes almost trivially clear after looking at the files. Still: I've been professionally writing software for almost 20 years now, I fully understand the concepts behind DVCS in general and git in particular, and I would rather write a fully data compatible replacement for git than having to USE that pile of misguided usability for more than 5 minutes.

It's not about newbies, it's about everyone who agrees that a VCS tool should get out of the fucking way and not be a science and religion in itself. All the "you need to properly learn git" bullshit is absolutely moot because there's so many better things programmers can do with their time. For example doing the stuff they're SUPPOSED to do (like, writing code) instead of needing to learn all of git's innards because it's fricking impossible to use otherwise.

And no, again, it's not "you're just too stupid for DVCS". That's a perfect strawman. It's all about Linus who in his live never before wrote software that came in contact with people not interested in its particular inner workings (The only people interfacing directly with the Linux kernel are other kernel devs and library authors, and those are pretty much expected to dig under the surface), and he wasn't willing to start doing so. So he hacked up git, said "good enough for me, live with it" and stopped giving the slightest fuck about usability before he even started.

so basically you agree. the (to use your words) misguided usability makes it non-intuitive to work with it. internally it's elegant and trivial, you only have to learn to deal with an interface to be able to use it. whatever rose your anger there, may it be the word newbie used by me which might sound arrogant... it was not meant to be like it, but what other word should i use there. git beginner? starter? as said, i had professional training for git and i would not have been able to learn that fast without it. this is a huge barrier. as you said: "it's about everyone who agrees that a VCS tool should get out of the fucking way and not be a science and religion in itself." yeah, it should and i would probably not have been using git if i didn't get that training, sponsored btw.

i don't get the hate some people seem to have here, linus did a great job with git, it simplifies a lot of the intrinsicly complex version control problems. it's not "for dummies" yet i give you that, but that's no reason to hate the 8 years of work invested.

like any other technology you will need to read some tutorials before you master it. i can recommend you this book. i found it quite enlightening atleast.

psenough: he already knows about git, he says ;)

is this bash Linus friday already?

ps: If you had been able to read, you might have realized that exactly the "not for dummies" thing is brainwash, because in fact Git is not for anyone who isn't a pro at using git. Not at using DVCS in general but at using git. And there is an appropriate word for this kind of software: Shit. Which rhymes. What a "coincidence".

Some observations.

I don't feel like being a pro at using git. Yet I like it.

What I observed in the company is those who stuck working from within Git Extensions are the only ones among us (coworkers) who hate git in the end. They're also the less capable at it but it's correlated I guess.

Some other people started small, learning git command line: clone, add, commit, push, pull commands. Those generally like git a lot. Later on, they started to appreciate pushing/pulling from/to they different workstations (e.g. linux, mac, windows) to iron things out before doing a final rebase -i then push to origin.

what i said: git is for git users. if you're masochistic and go through the hell of getting used to git it might in the end feel natural. if not you end up like kb, desperately hating git and all its users who can manage the interface... this reminds me of the good old "what is the best programming language/OS" fights. religious... if you don't wanna use it, then just don't.

yeah. you gotta be a githead to use that. just now it happened something glitched while i was exploring the git directory of my local rep a lil and it shot the last commit. lucky i synced that upwards before. so it's in the online rep. but where is the button to sync my local downwards from the online rep if something happens i delete a local file. do i really have to use that shell language and shit to get that synced back? it's fucked up unusable this way. *shakes head*

well, i'm not aware of any good GUI for git. the cheat sheet i posted above should be able to tell you how to undo accidental deletions (i.e. revert in svn terminology, everything is named differently in git...)

For me git makes stuff actually easier and much more consistent and trackable than svn. Also there's TortoiseGit and GitHub which help the dummies, like me.. ;)
I think git is a big step up from svn at least.

"i was exploring the git directory of my local rep a lil and it shot the last commit"

FFS it's not black magic. if you don't mess with files in the git directory, nothing "shoots the last commit"

And indeed if you don't like git just don't use it. If you don't understand git, you know what? that's allright too!

There is no need to pretend "it does things in your back" because it just doesn't. And calling Linus Torvalds names doesn't help...

Yay, fanboy alert \o/

(protip: nobody bashed Linus or called him names (except, well, Linus). But nice that you protect him so fervently <3)

Now if you really have to use git and github, invest 30 minutes of your next hours of frustration into reading few chapters of the Pro Git book

For those curious about Git internals, from 4min50 to 21min25 this video explains what's going on under the hood when you commit something into a repository.