On Sat, Jul 16, 2016 at 1:39 AM, Brandon McCaig <bamcc...@gmail.com> wrote: > [regarding Mercurial] > Combined with their failure to accomodate the distributed > development model properly you now have a bunch of incompatible > ideas for managing branches and history editing and they still > haven't gotten it all right yet (but they're getting closer the > more and more they model the design after Git).
I've never managed to get Mercurial's branching system into my head (and then you have the people saying "don't use hg branches at all, just use named tags" or somesuch), but the git branching system is extremely simple. In fact, all of git is very simple. To anyone who is having trouble with comprehending git, I strongly recommend this video. It assumes you have a basic understanding of git commands (or can pause the video and look up a git-hg Rosetta Stone), but you don't need expert-level knowledge. In fact, it's aimed at people ages 4 and up... https://www.youtube.com/watch?v=1ffBJ4sVUb4 >> To give you an idea of how screwed up things are, even though I'm not one of >> the developer team, and have never pushed a thing into the code >> repositories (I have pushed into documentation repos), somehow according >> to "git blame" I'm responsible for a bunch of code. > > The user name and email fields are not controlled in either Git > or Mercurial so anybody can commit code under your name without > you being involved. That would be pretty unprofessional though... If you're paranoid, you can have git sign your commits, in which case anyone could commit code under your name, but not using your private key. You can then tell people to be suspicious of any commits they can't cryptographically verify. > I can't imagine Git magically pulling your name out of nowhere > when it looks up the author of commits that are responsible for > lines of code... Maybe you should report that to the mailing list > and get to the bottom of it... I suspect that the explanation has > nothing to do with any bugs in Git. There are a few possibilities. If someone copied a slab of code from the documentation repo straight into the code repo (maybe you provided examples or something), git might detect that and recognize the copying. In that case, you'd be (correctly) responsible for that code, and the author would be a two-part "originally authored" pointing to your docs commit and "moved or copied here by" pointing to the commit that actually incorporated it. But if the repositories are completely separate, this is unlikely. More likely, someone might be able to cherry-pick the commit itself, if there is a corresponding file in code; again, this would have a two-part authorship marker "author" and "committer", because every git commit has this. (This is something Mercurial lacks. Every commit is blamed to the person with the commit-bit who pushed it, rather than the person who actually wrote the code. Obviously the committer is important, but so is the author.) If you want to get to the bottom of it, I would advise exploring the commits that are tagged with your name. Do they look like changes you made? Did you provide a patch file that someone else committed? And, who committed the changes - can you email that person to ask for clarification? The beauty of git is that all the information is right there, if you just look at it - 'git show 142857' will answer most of the above questions, and add "--format=full" or "--format=fuller" [1] to get the committer's info. Dig around... have fun! [1] I mean, not "fuller", just... more formatful. Wait, what? ChrisA -- https://mail.python.org/mailman/listinfo/python-list