[TOPIC 05/11]: SHA 256 / Git 3.0

SHA-256 / Git 3.0 =================

(moderator: Patrick, notetaker: Taylor)

* Patrick: some of you may have seen some patches from a few months ago
  to start thinking about this, and we now have a "deprecations" doc of
  things that we plan to get rid of.
   * One thing going away is grafts
   * Another thing is git pack-redundant
* Patrick: SHA-256 will become the default object hash, but is
  contingent on major platforms supporting SHA-256.
* Emily: this helps us too, because it provides some motivation that
  this is going to happen.
* Patrick: having it in the 3.0 document makes it easier to push at
  large organizations.
* Jonathan: with partial clones if I understand correctly users were
  already trying it and complained to GitHub about it not being turned
  on.
   * Taylor: not really…
   * Peff: I was embarrassed, so I wrote the bitmap support for
     filtering objects
   * Taylor: yeah, and turning it on was easier, but didn't require
     updating database columns, etc. so the transition period here would
     be much more expensive.
   * brian: "can you put it in the customer feedback repo" is something
     customers can ask for
* Jonathan: could use interop as a way for Git to default to sha256 with
  the only harm to end users being that clones and fetches get slower
  until servers support it
* brian: not planning on working on it unless their employer pays for
  them to do it.
* Mark: customers wanting to start with SHA256 so they don't have to
  migrate later
* Patrick: GitLab never really wanted SHA-256 until it was done on the
  Gitaly side.
* brian: has definitely seen it on StackOverflow as something that
  customers want. Not a huge selling point right now, but will become a
  humongous selling point at some point (beyond >2030).
* Peff: if the proposal is to make SHA-256 the default, then we need to
  be developing with it now, and we're not because there is no interop.
* Taylor: we should do it via interop, (a) because GitHub could not host
  it, but (b) because we would introduce the same lack of testing just
  with the interop code, not the SHA-256 code. So it must be done via
  interop.
* Patrick: OK, but why do we care about SHA-256 locally if they're using
  SHA-1 on the remote? The remote could be compromised
* Jonathan: You can verify things locally. This is the core idea of
  distributed version control.
* Patrick: Oh, I see.
* brian: Signatures work with both hash functions, you can sign with
  both.
* Peff: It does not feel right to me to set the user default until we
  the project are using it, and that the interop code is a part of that
  story.  (back to Git 3.0, we combined the SHA-256 and Git 3.0
  discussions into one)
* Peff: I have a proposal for Git 3.0, maybe this has been discussed?
  Can we get rid of some of the older protocols (dumb HTTP)?
* Patrick: Lots of esoteric things, like show-branch, which apparently
  nobody uses.
* Elijah: not just removals, but changing defaults, etc.
* Emily: are we interested in non-backwards compatible changes, like
  adding multi-Author fields to commits?
* Peff: I think that's a bad example, it can be done without breaking
  compatibility, but it was decided to not to do it. You're welcome to
  resurrect the discussion.
* Patrick: … but it's a different question of whether or not that would
  end up in the document.
* brian: multi-signatures
* Jonathan: Two questions I'm hearing:
   * Should we include things that haven't been implemented yet?
     Probably not.
   * What do we think about this major version as a way to break
     interoperability with older versions of Git?
* Patrick: I would not be in favor of breaking something, at least in
  cases where we can add a protocol extension and/or new capabilities.
  Intentionally breaking interoperability with an older version does not
  seem like the right way to go.
* brian: I agree, but for the dumb HTTP protocol, C git uses it, Eric
  Wong is really into it (lore.kernel.org supports it), etc.
* Emily: Bundle URIs and resumable clones, could in theoretically work
  for resumable clones, but we don't have client-side support.
* Peff: Pretty sure that this isn't the case.
* Mark: can I ask a "dumb" question? What would it take to get a
  schedule for 3.0?
   * Patrick: Junio says not too often, maybe only breaking releases
     every 5-10 years, which means 3.0 would come in 1-2 years.
   * Peff: 1-2 years is what is in my mind.
   * Taylor: I think that whatever answer we come to agreement here will
     not be satisfying for you.
   * Taylor: the items on that document aren't a checkbox list of things
     to do before Git 3.0, but isn't a "let's get all of these things
     done and then we'll release Git 3.0".
      * More that we'll all wake up one day, realize that we've done all
        or enough of what would go into Git 3.0, then remove a bunch of
        code, and ship it.
* Jonathan: collecting breaking changes and aggregating them so users
  can prepare for them together is helpful, but it's not the only way
  that breaking changes will happen, especially if there is something
  that needs to go away.
* Patrick: I want three things from this document:
   * Reminder / documented intent.
   * User feedback to hear things like "this is important to me, what is
     (if any) the replacement?"
   * ???
* brian: changing the default branch name?
   * Taylor: I would be in favor of doing it sooner
   * (some discussion)
   * Taylor: We should consider doing it for git.git as well.
* Peff: we might write a bunch of those patches, move them into 'next'.
  Could we have a Git 3.0 pseudo-maintainer.
* Jonathan: I have a naive question: why wouldn't it look like turning
  on a single Makefile variable?
* Emily: and then we go and delete the code inside of the #ifdefs
* Taylor: whoever is the maintainer at that point in time could consider
  a double-wide release cycle, where we delete that code, implement new
  things, and then at the end of that cycle the artifact is called Git
  3.0.
* Peff: very few people run "next"
   * Jonathan: True. Could imagine some % of GitHub Actions runners
     automatically running "next", that's the kind of thing that gets a
     more representative workload.
* Toon: do we want to have maintenance releases?
* Emily: if we're dropping support for earlier versions, we should just
  do it.
* Taylor: we should probably have a few supported release tracks that we
  designate as LTS releases.
* Patrick: For security issues only, probably for a period of 1-2 years.
* Peff: Should we write this up as a plan for the person who actually
  does release engineering?
   * Taylor: I can write up that plan, and be the point person for the
     LTS releases.
   * Jonathan: the Linux kernel has dedicated maintainers for LTS
     releases, which seems to work well.
* brian: we can certainly tell that to Junio, but it's also ultimately
  their decision.