51–60 of 68 posts
Earlier quoted context omitted.
Best in what sense? Bitbucket does everything Github does, plus gives free private repos. GitHub is just more widely used.
Bitbucket crashes minimal browsers like Surf and github doesn't. So, in that regard, Github is better.
(When I saw the title, I was wondering if this does something beyond the basic rebase, like trying to brute force a commit such that all following commits are preserved (hash doesn't change), but that's essentially impossible.) I'm tempted to make the observation that there's nothing here you can't already do with a git rebase -i and: GIT_COMMITTER_NAME=a GIT_COMMITTER_EMAIL=a@a.com GIT_COMMITTER_DATE=2006-01-02T15:0…
> all following commits are preserved (hash doesn't change), but that's essentially impossible. Actually, you only need one brute-force (of the commit that you're changing); subsequent commits only refer to the parent hash, and here we're not changing the commit trees either. SHA1 is already considered broken, so git really should switch to SHA256 soon. This whole "sha1 commit hashes are not for security" argument is…
Earlier quoted context omitted.
You mean besides developing and operating one of the best services on the web?
Best in what sense? Bitbucket does everything Github does, plus gives free private repos. GitHub is just more widely used.
Earlier quoted context omitted.
But isn't it somewhat reasonable that I push someone else's commit? Say I want to rewrite an old commit, and then force push that, then all the commits after the rewritten commit by other people would effectively be pushed by me. Or consider the common case where the public repository on Github is just a mirror of an official repository somewhere else -- then commits from a bunch of people would all be pushed by whoe…
They do have a "committed by" feature that appears when you cherry-pick someone else's commit to a branch. It shows up as "Bob committed with Alice". I've only noticed it showing up for cherry-picks, I'm unsure if that's the only place it's used.
All one has to do to make it go away is change the committer field on the git, this isn't security added by GitHub.
It's been my experience, especially in the startup scene where business requirements change often, that `git blame` rarely shows you what you want. Files get renamed, moved, re-indented, etc, frequently. I wrote a tutorial on a more effective (at least for me) solution to find the true author of a change: http://blog.andrewray.me/a-better-git-blame/
Unfortunately, adding -M and -C will quite badly increases the time to compute the blame. Both take an adjustable parameter (min number of characters to match), but I found I actually had to reduce it to catch all the lines in an example of the A.cpp -> A-star.cpp move I did yesterday.
Earlier quoted context omitted.
There are so many things that GitHub could easily do, but don't... Makes me wonder what they actually do.
You mean besides developing and operating one of the best services on the web?
I really wonder what they do. I have some complicated feelings about them, also, that has to do with them becoming the central hub for open source.
Like, if the product itself were open source, it might be more obvious what they are working on. But I can't demand that kind of transparency... It would just be interesting to know.
With almost 500 employees, what happens? I've never even worked at such a large company myself.
Should GitHub users have some say in what the company builds? I mean, we're promoting them like hell, and the social network is a huge part of their value.
I often wonder what well-funded large product companies do with all their manpower. Feature development doesn't seem to scale. Nor innovative design. GitHub's mobile layout is pretty crippled. I dunno. Just curious.
Earlier quoted context omitted.
It's a bit worrying that GitHub will happily associate someone's face on a commit that they didn't write: https://github.com/jayphelps/git-blame-someone-else/commit/e... Perhaps GitHub should only do this for signed commits or commits to the author's own repository or something. GitHub also allows you to add anyone to a project without their consent (or has this changed?). This reminds me of the Facebook prank where…
Back when I was first learning to use git, I accidentally pushed a commit to my repo as the author of a set of dotfiles I'd cloned. It was a bit mortifying.
It's been my experience, especially in the startup scene where business requirements change often, that `git blame` rarely shows you what you want. Files get renamed, moved, re-indented, etc, frequently. I wrote a tutorial on a more effective (at least for me) solution to find the true author of a change: http://blog.andrewray.me/a-better-git-blame/
Nice tutorial, but aren't you aware that "git blame -w" ignores whitespace changes? git blame also always follows renames. git's rename detection isn't foolproof (if I edit and rename A.cpp to A-star.cpp at the same time as adding a new A.cpp file it won't detect it), however there are two more blame options for that: -C to follow lines copied between files, and -M to follow lines moved within a file. Unfortunately,…
Earlier quoted context omitted.
Um, mostly no. This can be trivially detected only when you are changing things already pushed. Being a dvcs, you create atleast one commit on your local repo before pushing to a remote. That one (or more) commit can be changed to point at anyone and pushed.
Mostly yes. You rewrite the whole history from the commit you changed authors on and onwards so git will let you know that you have two conflicting histories that needs to be merged. This is why the author needs to force push to master. The only exception to this is if someone else has not pulled into their private repo any changes at or before the commit you changed.