[HN Gopher] Theodore Ts'o on how he uses Git when working on Lin...
___________________________________________________________________
Theodore Ts'o on how he uses Git when working on Linux (2017)
Author : nativecoinc
Score : 35 points
Date : 2023-03-05 15:59 UTC (7 hours ago)
(HTM) web link (lore.kernel.org)
(TXT) w3m dump (lore.kernel.org)
| gumby wrote:
| There are two competing needs to be considered when figuring out
| what your workflow should be in regard to history.
|
| Both come from the fundamental question: "When (if) we look back
| in history, what are we looking for?" Keeping everything as it
| was reduces the risk of deleting something that will later be
| important; consolidating is supposed to reduce the risk of
| missing the needle in the haystack or discouraging looking back
| at all.
|
| Curating the past is 99% wasted effort since looking back is
| rare. I think the best compromise is to add some automation if
| you really care, as Ted suggested.
| nativecoinc wrote:
| There's another concern: repository bloat.[1] Ts'o does not
| want this link to be a mandatory part of the final commit which
| everyone needs to get on every pull.[2]
|
| His own proposal does not necessitate keeping "history blobs"
| around: just use Git commit metadata (trailers) and leave the
| pointed-at data (beyond the cherry-pick backlinks) in an
| external store like Gerrit.
|
| I think other commenters who suggested no-changes-to-core-git
| solutions might have mentioned git-notes, which is similar to
| the external store point since git-notes are completely
| optional refs (i.e. if you have notes on your commits in your
| tree then no one else needs to know about it; those who want
| the metadata can fetch it, those who don't can save their
| bandwidth).
|
| [1]:
|
| > If the complaint about Gerrit is that it's not a core part of
| Git, the challenge is (a) how to carry the code review comments
| in the git repository, and (b) do so in a while that it doesn't
| bloat the core repository, since most of the time, you _don 't_
| want or need to keep a local copy of all of the code review
| comments going back since the beginning of the project.
|
| [2]: I'm guessing that people who want a "replaces" link would
| also want to make it optional. Keeping in line with the best-
| of-both-worlds mantra.
| nativecoinc wrote:
| The OP[1] wants the best of git-merge and git-rebase: to be able
| to rewrite history as well as to have a new "replaces" pointer
| which points back to the commit before the rebase happened
| (basically).
|
| > I've been calling this proposal `git replay` or `git replace`
| but I'd like to hear other suggestions for what to name it. It
| works like rebase except with one very important difference.
| Instead of orphaning the original commit, it keeps a pointer to
| it in the commit just like a `parent` entry but calls it
| `replaces` instead to distinguish it from regular history. In the
| resulting commit history, following `parent` pointers shows
| exactly the same history as if the commit had been rebased.
| Meanwhile, the history of iterating on the change itself is
| available by following `replaces` pointers. The new commit
| replaces the old one but keeps it around to record how the change
| evolved.
|
| Ts'o thinks[1] that this is too simplistic, citing some workflows
| that he has experience with from working on Linux. He says that
| they use metadata in the form of key-value pairs in the commit
| messages in order to track cherry-picks across trees, how to test
| the commit, and even the fact that a commit has been dropped in
| the current tree.[3]
|
| > My experience, from seeing these much more complex use cases
| --- starting with something as simple as the Linux Kernel Stable
| Kernel Series, and extending to something much more complex such
| as the workflow that is used to support a Google Kernel Rebase,
| is that using just a simple extra "Replaces" pointer in the
| commit header is not nearly expressive enough. And, if you make
| it a core part of the commit data structure, there are all sorts
| of compatibility headaches with older versions of git that
| wouldn't know about it. And if it then turns out it's not
| sufficient more the more complex workflows _anyway_ , maybe
| adding a new "replace" pointer in the core git data structures
| isn't worth it. It might be that just keeping such things as
| trailers in the commit body might be the better way to go
|
| [1]
| https://lore.kernel.org/git/CALiLy7pBvyqA+NjTZHOK9t0AFGYbwqw...
|
| [2] Submission link
|
| [3] How? By making an "empty commit" (I presume: a commit which
| doesn't change the tree) and adding the "dropped" metadata to the
| commit message.
___________________________________________________________________
(page generated 2023-03-05 23:02 UTC)