schacon

24 ms·

241.
by schacon 17y ago
if you are the _only_ person with push access to your repo, then that's fine. i just don't want other people reading this that collaborate with people on repos that multiple devs have push access to thinking that --force is fine to use, be
242.
by schacon 17y ago
it's funny how some people hate merges and want to do everything with rebasing and fast-forwarding (like this) and others hate ff-ing and think everything should be done with merges to maintain branch history ( http://nvie.com/archives/323
243.
by schacon 17y ago
please don't "git push --force" unless you know what it's doing, people - you will lose work and people will get really confused. the --force should never be necessary, even when using 'pull --rebase'. the push command normally will refus
244.
by schacon 17y ago
Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, th
245.
by schacon 17y ago
btw, if you just run 'git fetch', it will just grab any new commits - it won't modify your working directory or try to merge automatically. i believe 'hg pull' is the same - it just gets the new heads, it doesn't try to merge. you shouldn
246.
by schacon 17y ago
I think the major and very important difference is that the internet is basically totally free. For every Facebook group spewing some idiotic nazi crap there are three condemning it. If you let anyone stand on their little soapbox and say
247.
by schacon 17y ago
if you want to help, don't forget that it's open source : http://github.com/opencongress/opencongress
248.
by schacon 17y ago
You can also run 'git mergetool' and choose the 'emerge' option, which is also emacs based but I believe can take the common ancestor of the merge into account to help you out as well.
249.
by schacon 17y ago
You can link Git up to use any mergetool you want, if you have a specific one in mind. I've seen it used with Perforce visual merge tool, opendiff, kdiff3, etc. If you have a tool you like, it's not too difficult to get it setup. See: ht
250.
by schacon 17y ago
Just to be clear, this slideshow was done at RailsConf 08, about a year and a half ago. Although all the internals stuff is still relevant, the 150 commands thing is no longer an issue. The only binary in your path since 1.6 is 'git', not
251.
by schacon 17y ago
I apologize for that - at the time I misunderstood Mercurial internals. It confused me that Hg does store all it's files this way - and importantly it stores its file revisions under the file name, so renames have to be tracked explicitly
252.
by schacon 17y ago
figuring out the answers is actually not that hard - we're using data that is publicly available through our API. in the rules we state that your entry will be disqualified if you do this sort of thing, though.
253.
by schacon 17y ago
Though much of GitHub is open-sourced, the core app itself is not (yet). We just don't want to not be able to use the winning entry to best improve the site for the 150,000 open source projects we provide free hosting for because the winni
254.
by schacon 17y ago
I think the reason I don't like the GPL is that it is aggressively pessimistic. If you release your code under MIT or BSD and _ask_ people to contribute back if they improve it, most people actually will - I don't think I've ever used GPL a
255.
by schacon 17y ago
I just fixed the css for this - should look better for you now.
256.
by schacon 17y ago
This should be available as an electronic book from Apress, too - all formatted and pretty and whatnot. When the book is shipping, you'll be able to get a professional digital version if you wish. Of course, if you want to take this markd
257.
by schacon 17y ago
I agree with the superficial things for the most part, though it should be pointed out that 'hg revert .' and 'git checkout .' do basically the same thing - the 'git reset --hard ORIG_HEAD' example is way more complex than it needs to be an
258.
by schacon 17y ago
I think the fact that a lot of people feel driven to take their time to write about a tool is much more indicative that it is an incredibly helpful tool, not that it is difficult to use. If you used some tool and it was really hard and bar
259.
by schacon 17y ago
I got a lot of feedback on these videos (they are a year old now) and started on a new site that incorporates those suggestions at http://learn.github.com Once I get all the same material covered, I'll probably start redirecting this site
260.
by schacon 17y ago
I grew up in Ventura, maybe a mile from this library and I went there pretty often as a kid. It has been in danger of shutting down and has had fewer open hours for probably over a decade now - it's really pretty sad. I agree that librarie
261.
by schacon 17y ago
There is a mapping from Git SHAs to Hg SHAs. Technically we could add a command to run an Hg log from a Git SHA since we have a one to one mapping, but it's generally easier to not have to really know what the Git stuff is. You should be
262.
by schacon 17y ago
It is not related. I happened to really get going on this project at roughly the same time as the GSOC stuff came out, but the student that was working on that seems to have stopped.
263.
by schacon 17y ago
Yes, you can push to a Git repository and hg-git will convert the hg commits you did in the meantime to Git objects and push them upstream. The tool is losslessly bi-directional. Developers using Git or Hg clients can push and pull from a
264.
by schacon 17y ago
First of all, you can lose local history in Hg too, by running 'hg rollback' and I _believe_ you can also do it with the 'rebase' extension (which was implemented because developers find that functionality in Git so useful). However, these
265.
by schacon 17y ago
That makes more sense on some of the stuff, but the auto gc and non-fast-forward server options are both older than that. If it was done that long ago, I can't find any mention of it in the paper, and people will use this, being from an au
266.
by schacon 17y ago
Other than the 'Mercurial Advantages' section, which is nearly entirely incorrect, this is a pretty good overview of both systems. I can definitely see the HTTP transport support being a deciding factor for them, and the ability to hack in
267.
GitLondon - Git Workshop by GitHub and Codebase(github.com)
6 points by schacon 18y ago|1 comments
268.
by schacon 18y ago
Yes, that would be the suggested workflow - to use this to easily cherry-pick patches into an integration branch that you want and ignore the ones that don't look ready yet. Then pull that one branch down locally and merge it into your mas
269.
Free Guide to GitHub Screencast(github.com)
3 points by schacon 18y ago|0 comments
270.
by schacon 18y ago
Disclaimer: I'm a git fan. Just to be clear - this does not have identical capabilities and benefits to gits branching model. For one, it does not appear that you can push these branches, which means that you can't work on topic branches wi

More ›