![]() ![]() From GitHub’s perspective, individual commits become less valuable because the atomic unit is the pull request. From Git’s perspective - likely because of the ease of use inside a mailing list approach - a single atomic commit makes most sense. These are two extremes of viewing what the core unit of change is for the respective project. It effectively serves the same purpose as one of Peff’s individual commits. This would not get accepted in git-core.īut click up from the commit’s page and take a look at the pull request and the general format becomes immediately familiar: it’s an extremely well-written and accessible discussion of the changes in that pull, complete with the analysis of the performance impact it will have. It’s a fairly stereotypical commit for GitHubbers: hell, even the commit message itself is emoji. It’s an egregious example for the sake of illustration, but take a look at this particular commit on the Atom repository. Nathan Sobo ( is one of my favorite pull request authors. Every single change enters production via a pull request, and as such, the pull request is king… not necessarily the commit. On the flipside, GitHub is the best example of how to work within, and if you ask them, they’d probably defend their process with the exact same rationale: it allows them to move with speed, quality, and safety. They should know they’re the best example of working efficiently within Git. Git’s maintainers would say this commit process is designed to ensure speed, quality, and safety. This is a byproduct of their process: contributors are to use git format-patch and git send-email to send their patches to the mailing list so that changes can be efficiently reviewed, discussed, and merged to master. Each commit is designed to be a comprehensive, standalone measurement of the change introduced into the repository. This works for git-core because their unit of change is at the commit level. More often than not, the diff may only be a couple of lines but he’ll likely include a detailed, multi-page writeup with code examples and performance benchmarks in the commit message. ![]() He’s the number two committer to Git itself, and his commits are truly lovely to read. My favorite commit author of all time is Jeff King ( I like his commits so much that even if I were the Sepp Blatter of the Commit Olympic Committee, I wouldn’t need to be bribed to nominate him as a finalist. Why do developers take different approaches to repository histories? A tale of two changes Over the last five years, I’ve gotten a lot of questions along the lines of “should I rebase my branches or deal with a merge commit or maybe even squash all of my commits down into a single commit before merging?” Like most pedantic programmer debates, my answer is usually “I don’t care, I’m going to grab another slice of pizza, you do you”, but I’ve been thinking about this a lot recently and I think there’s a more interesting question to consider instead: I have no shame - okay, maybe a little shame - dropping these commits into my repositories: It's not clear how they would be useful, either.Look, I don’t give two shits about my Git commits. Of course this is all pure speculation until someone writes these. So this is more a theoretical exercise: it would theoretically be possible to save, and persist, "old tags" and "tag history" through special commits, probably pointed-to through a new reference name space such as refs/tagarchive/, if at least one Git plumbing command and several scripts were written. ![]() But Git is not built to do this, and has no tools for constructing such things, and it's possible that git fsck would consider them erroneous. (There's no fundamental reason a tree object could not point to tag objects, so it would be possible to have a commit object that pointed to a tree that keeps old annotated tags around. Only if some additional reference (usually another tag-name for another annotated tag) keeps the original annotated-tag object reachable is it guaranteed to remain in the repository. As an unreferenced object, though, it is subject to the usual garbage-collection rules. ![]() As long as the underlying object itself has not been removed, you can access it by ID. Deleting the reference deletes only the external tag-name reference to the annotated-tag object. Deleting a reference (any reference), however, deletes the reflog.Īnnotated tags use objects within the repository (in addition to the reference itself). If a tag is force-moved and force-pushed and you keep reflogs for tags, you can retrieve previous values from the tag's reflog, until those reflog entries expire. How do I see the entire history of a particular tag? (In other words, any time a tag with than name was created/deleted, and what commits each one pointed to) They can also be moved by force: git tag -f. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |