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.
