3 ms·
This is really cool! However, I would be remiss to not mention that I would love for Github to focus more on Git. I have been using git for about two years, but
by monkmartinez 13y ago
This is really cool! However, I would be remiss to not mention that I would love for Github to focus more on Git. I have been using git for about two years, but I am far, far, far from being a git ninja. I suspect that I am not alone based on what I see at stackoverflow with questions tagged "git."
What if they spent their time improving:
1. Github Pulls - Have you seen the hoops one needs to jump through to submit a single-commit pull request? One needs to be extra careful about the workflow.
2. Let me determine the Project/Repo language - How many repos do you have that are labeled Javascript when its really a Python, Ruby or something else Project? Not critical, but seems really silly that I have to wade into the src to determine something like base lang.
3. Make git, itself, more intuitive - Surely if they can add the crazy cool features they've added, making the management of git repos DEAD simple should be a priority. Look at the questions tagged with "git" on stackoverflow and see how many you could devine an answer from using github.
4. Git fast forward - Could github provide an way to see what is going to happen to a repo when issuing git commands? All these cool visualizations online and we have to experiment with git locally seems a bit odd.
Free idea; Gitfiddle. See what your crazy ass commands will do to your repo before you spend the next 4 hours figuring out why you didn't want to do that.
Ie. Find the merge base between your branch and master: ‘git merge-base master yourbranch’
Assuming you’ve already committed your changes, rebased your commit onto the merge base, then create a new branch:
git rebase –onto <basecommit> HEAD~1 HEAD
git checkout -b my-new-branch
Checkout your ruggedisation branch, and remove the commit you just rebased: ‘git reset –hard HEAD~1′
Merge your new branch back into ruggedisation: ‘git merge my-new-branch’
Checkout master (‘git checkout master’), merge your new branch in (‘git merge my-new-branch’), and check it works when merged, then remove the merge (‘git reset –hard HEAD~1′).
Push your new branch (‘git push origin my-new-branch’) and log a pull request.
the above from: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ http://steveko.wordpress.com/2012/02/24/10-things-i-hate-abo...
- gkop 13y ago> Free idea; Gitfiddle. See what your crazy ass commands will do to your repo before you spend the next 4 hours figuring out why you didn't want to do that. It's really hard to screw things up that badly with git, you can nearly always go back using $ git reflog and $ git reset --hard .
- monkmartinez 13y agoYou can't screw it up they says, it so easy they says... well then why this: http://stackoverflow.com/questions/134882/undoing-a-git-rebase http://stackoverflow.com/questions/134882/undoing-a-git-reba... and this: http://ocpsoft.org/tutorials/git/use-reflog-and-cherry-pick-to-restore-lost-commits/ http://ocpsoft.org/tutorials/git/use-reflog-and-cherry-pick-... and a gazillion more just for that one command; 'reflog'... type --rebase vs --merge and let your head explode with the rest of us n00bs. The truth; Git is hard. My opinion, I want to write code and keep it somewhere. I'm not a professional developer and I want to contribute to open source in my free time. That means git || hub, generally. It would be awesome for Github to make git exploration from the browser easier. Yes, I pay github every month and I am happy to do it.
- gkop 13y agoAgree that the git command-line API is harder than it ought to be. My comment was meant to help git beginners that are afraid of exploring for fear of wasting many hours fixing their mistakes; you should consider learning the commands to undo your mistakes before learning other crazy commands.
- monkmartinez 13y agoHow do you learn to fix a mistake before you make one? You may have a weak notion of what you need to do... but you don't know until it happens and have a need to git dirty. Further, In my opinion of course, these features are great... but someone is going to make git easy while retaining its power. Git is a nacent technology and while Github is dominating now... there is always room for disruption. They, the people who make git easy, will be the winners. Don't make me think.
- dualogy 13y agoYeah, esp. #2 bugs me SO much. I wish if in a multi-language project, JS would at least be "only 0.1 priority" or something for GitHub when guessing languages. Even cooler would be if they showed the 2-4 top languages in a repo (depending on screen space), but again preferably with JS/CSS only counting at 10% or something..
- deleted 13y ago[deleted]
- monkmartinez 13y agoHow about; they add a text field, I add the project lang and they can run the machine learning against my (human) input? That would solve my problem and make the classifier better, no? When every file in the main dir of the project is *.py and the repo says JavaScript... something is wrong. Further, you may have a JS heavy application that is powered by Python|Ruby... should that project be called JavaScript? It certainly would not run without Python|Ruby on its own.