41–50 of 69 posts
I really dislike the term chosen for this feature. “Blame”, assumes the code is broken or written improperly in some way. Most of the time I use it I’m just trying to find out who wrote it so I can find the original commit to understand it in more context. Should have named it “git who”
I was disappointed that git didn't have it, so I created myself one. I'm glad git has trivial support for aliases.
What is more, you can: 1. clone https://github.com/torvalds/linux into /linux" rel="nofollow">https://github.com/ /linux . 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA ( " rel="nofollow">https://github.com/torvalds/linux/commit/ ), with no indication whatsoever that this is coming from a differen…
> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.
I really dislike the term chosen for this feature. “Blame”, assumes the code is broken or written improperly in some way. Most of the time I use it I’m just trying to find out who wrote it so I can find the original commit to understand it in more context. Should have named it “git who”
This might have a serious use. I have a private repo that I worked on with my daughter. If I open source it, ideally I'd keep the chronological history but scrub her email address out of it. It's OK that all the commit hashes would change. Would I want to adapt this joke tool to that purpose, or is there an exiting tool for rewriting history that way?
The standard way to do that is with 'git filter-branch'. If your daughter’s email is megatron@example.com, git filter-branch --env-filter ' old_email=megatron@example.com new_email=redacted if [ "$GIT_COMMITTER_EMAIL" = "$old_email" ] ; then export GIT_COMMITTER_EMAIL="$new_email" fi if [ "$GIT_AUTHOR_EMAIL" = "$old_email" ] ; then export GIT_AUTHOR_EMAIL="$new_email" fi ' -- --all This is “safe” in the sense that yo…
git filter-branch is perfect for this kind of wholesale revision. filter-branch is essential for tasks like: open-sourcing repos that need some kind of cleanup, massaging repos generated by a VCS migration tool, etc. For example, years ago I participated in the move of a large CVS repo to git; there was significant filter-branch post-processing required to create an acceptable baseline)
What is more, you can: 1. clone https://github.com/torvalds/linux into /linux" rel="nofollow">https://github.com/ /linux . 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA ( " rel="nofollow">https://github.com/torvalds/linux/commit/ ), with no indication whatsoever that this is coming from a differen…
> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.
I don't see what optimization requires that. They already keep track of e.g. me pushing up someone else's commit after a rebase -- it indicates that I pushed but the commit originally came from someone else.
What is more, you can: 1. clone https://github.com/torvalds/linux into /linux" rel="nofollow">https://github.com/ /linux . 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA ( " rel="nofollow">https://github.com/torvalds/linux/commit/ ), with no indication whatsoever that this is coming from a differen…
Earlier quoted context omitted.
I've never really understood Torvalds' reason for not cryptographiclly signing commits. > Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable…
Cryptographically signing the commits makes rebasing impossible (or at least more difficult). In some cases the rebase is very clean, and none of the modified files had changed by other commits. I guess in this case, git can have a rule to keep a "link" to the old commit and accept the old signature as a signature of the new commit. In some cases there are trivial changes, like indentation because someone else added…
Earlier quoted context omitted.
> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.
GP isn't saying GitHub should copy the entire repo, only that there should be some indication that the code you're looking at isn't the repo owner's (despite being committed in their name and on a repo they "control"). I don't see what optimization requires that. They already keep track of e.g. me pushing up someone else's commit after a rebase -- it indicates that I pushed but the commit originally came from someone…
From a single commit ID you cannot tell which repo it came from. A "repo" is just a tree of commits.
Earlier quoted context omitted.
GP isn't saying GitHub should copy the entire repo, only that there should be some indication that the code you're looking at isn't the repo owner's (despite being committed in their name and on a repo they "control"). I don't see what optimization requires that. They already keep track of e.g. me pushing up someone else's commit after a rebase -- it indicates that I pushed but the commit originally came from someone…
> I don't see what optimization requires that. From a single commit ID you cannot tell which repo it came from. A "repo" is just a tree of commits.
Earlier quoted context omitted.
GP isn't saying GitHub should copy the entire repo, only that there should be some indication that the code you're looking at isn't the repo owner's (despite being committed in their name and on a repo they "control"). I don't see what optimization requires that. They already keep track of e.g. me pushing up someone else's commit after a rebase -- it indicates that I pushed but the commit originally came from someone…
> I don't see what optimization requires that. From a single commit ID you cannot tell which repo it came from. A "repo" is just a tree of commits.