1099 lines
32 KiB
HTML
1099 lines
32 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
|
|
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
|
|
<meta name="generator" content="AsciiDoc 10.2.0" />
|
|
<title>Upcoming breaking changes</title>
|
|
<style type="text/css">
|
|
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
|
|
|
|
/* Default font. */
|
|
body {
|
|
font-family: Georgia,serif;
|
|
}
|
|
|
|
/* Title font. */
|
|
h1, h2, h3, h4, h5, h6,
|
|
div.title, caption.title,
|
|
thead, p.table.header,
|
|
#toctitle,
|
|
#author, #revnumber, #revdate, #revremark,
|
|
#footer {
|
|
font-family: Arial,Helvetica,sans-serif;
|
|
}
|
|
|
|
body {
|
|
margin: 1em 5% 1em 5%;
|
|
}
|
|
|
|
a {
|
|
color: blue;
|
|
text-decoration: underline;
|
|
}
|
|
a:visited {
|
|
color: fuchsia;
|
|
}
|
|
|
|
em {
|
|
font-style: italic;
|
|
color: navy;
|
|
}
|
|
|
|
strong {
|
|
font-weight: bold;
|
|
color: #083194;
|
|
}
|
|
|
|
h1, h2, h3, h4, h5, h6 {
|
|
color: #527bbd;
|
|
margin-top: 1.2em;
|
|
margin-bottom: 0.5em;
|
|
line-height: 1.3;
|
|
}
|
|
|
|
h1, h2, h3 {
|
|
border-bottom: 2px solid silver;
|
|
}
|
|
h2 {
|
|
padding-top: 0.5em;
|
|
}
|
|
h3 {
|
|
float: left;
|
|
}
|
|
h3 + * {
|
|
clear: left;
|
|
}
|
|
h5 {
|
|
font-size: 1.0em;
|
|
}
|
|
|
|
div.sectionbody {
|
|
margin-left: 0;
|
|
}
|
|
|
|
hr {
|
|
border: 1px solid silver;
|
|
}
|
|
|
|
p {
|
|
margin-top: 0.5em;
|
|
margin-bottom: 0.5em;
|
|
}
|
|
|
|
ul, ol, li > p {
|
|
margin-top: 0;
|
|
}
|
|
ul > li { color: #aaa; }
|
|
ul > li > * { color: black; }
|
|
|
|
.monospaced, code, pre {
|
|
font-family: "Courier New", Courier, monospace;
|
|
font-size: inherit;
|
|
color: navy;
|
|
padding: 0;
|
|
margin: 0;
|
|
}
|
|
pre {
|
|
white-space: pre-wrap;
|
|
}
|
|
|
|
#author {
|
|
color: #527bbd;
|
|
font-weight: bold;
|
|
font-size: 1.1em;
|
|
}
|
|
#email {
|
|
}
|
|
#revnumber, #revdate, #revremark {
|
|
}
|
|
|
|
#footer {
|
|
font-size: small;
|
|
border-top: 2px solid silver;
|
|
padding-top: 0.5em;
|
|
margin-top: 4.0em;
|
|
}
|
|
#footer-text {
|
|
float: left;
|
|
padding-bottom: 0.5em;
|
|
}
|
|
#footer-badges {
|
|
float: right;
|
|
padding-bottom: 0.5em;
|
|
}
|
|
|
|
#preamble {
|
|
margin-top: 1.5em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
div.imageblock, div.exampleblock, div.verseblock,
|
|
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
|
|
div.admonitionblock {
|
|
margin-top: 1.0em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
div.admonitionblock {
|
|
margin-top: 2.0em;
|
|
margin-bottom: 2.0em;
|
|
margin-right: 10%;
|
|
color: #606060;
|
|
}
|
|
|
|
div.content { /* Block element content. */
|
|
padding: 0;
|
|
}
|
|
|
|
/* Block element titles. */
|
|
div.title, caption.title {
|
|
color: #527bbd;
|
|
font-weight: bold;
|
|
text-align: left;
|
|
margin-top: 1.0em;
|
|
margin-bottom: 0.5em;
|
|
}
|
|
div.title + * {
|
|
margin-top: 0;
|
|
}
|
|
|
|
td div.title:first-child {
|
|
margin-top: 0.0em;
|
|
}
|
|
div.content div.title:first-child {
|
|
margin-top: 0.0em;
|
|
}
|
|
div.content + div.title {
|
|
margin-top: 0.0em;
|
|
}
|
|
|
|
div.sidebarblock > div.content {
|
|
background: #ffffee;
|
|
border: 1px solid #dddddd;
|
|
border-left: 4px solid #f0f0f0;
|
|
padding: 0.5em;
|
|
}
|
|
|
|
div.listingblock > div.content {
|
|
border: 1px solid #dddddd;
|
|
border-left: 5px solid #f0f0f0;
|
|
background: #f8f8f8;
|
|
padding: 0.5em;
|
|
}
|
|
|
|
div.quoteblock, div.verseblock {
|
|
padding-left: 1.0em;
|
|
margin-left: 1.0em;
|
|
margin-right: 10%;
|
|
border-left: 5px solid #f0f0f0;
|
|
color: #888;
|
|
}
|
|
|
|
div.quoteblock > div.attribution {
|
|
padding-top: 0.5em;
|
|
text-align: right;
|
|
}
|
|
|
|
div.verseblock > pre.content {
|
|
font-family: inherit;
|
|
font-size: inherit;
|
|
}
|
|
div.verseblock > div.attribution {
|
|
padding-top: 0.75em;
|
|
text-align: left;
|
|
}
|
|
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
|
|
div.verseblock + div.attribution {
|
|
text-align: left;
|
|
}
|
|
|
|
div.admonitionblock .icon {
|
|
vertical-align: top;
|
|
font-size: 1.1em;
|
|
font-weight: bold;
|
|
text-decoration: underline;
|
|
color: #527bbd;
|
|
padding-right: 0.5em;
|
|
}
|
|
div.admonitionblock td.content {
|
|
padding-left: 0.5em;
|
|
border-left: 3px solid #dddddd;
|
|
}
|
|
|
|
div.exampleblock > div.content {
|
|
border-left: 3px solid #dddddd;
|
|
padding-left: 0.5em;
|
|
}
|
|
|
|
div.imageblock div.content { padding-left: 0; }
|
|
span.image img { border-style: none; vertical-align: text-bottom; }
|
|
a.image:visited { color: white; }
|
|
|
|
dl {
|
|
margin-top: 0.8em;
|
|
margin-bottom: 0.8em;
|
|
}
|
|
dt {
|
|
margin-top: 0.5em;
|
|
margin-bottom: 0;
|
|
font-style: normal;
|
|
color: navy;
|
|
}
|
|
dd > *:first-child {
|
|
margin-top: 0.1em;
|
|
}
|
|
|
|
ul, ol {
|
|
list-style-position: outside;
|
|
}
|
|
ol.arabic {
|
|
list-style-type: decimal;
|
|
}
|
|
ol.loweralpha {
|
|
list-style-type: lower-alpha;
|
|
}
|
|
ol.upperalpha {
|
|
list-style-type: upper-alpha;
|
|
}
|
|
ol.lowerroman {
|
|
list-style-type: lower-roman;
|
|
}
|
|
ol.upperroman {
|
|
list-style-type: upper-roman;
|
|
}
|
|
|
|
div.compact ul, div.compact ol,
|
|
div.compact p, div.compact p,
|
|
div.compact div, div.compact div {
|
|
margin-top: 0.1em;
|
|
margin-bottom: 0.1em;
|
|
}
|
|
|
|
tfoot {
|
|
font-weight: bold;
|
|
}
|
|
td > div.verse {
|
|
white-space: pre;
|
|
}
|
|
|
|
div.hdlist {
|
|
margin-top: 0.8em;
|
|
margin-bottom: 0.8em;
|
|
}
|
|
div.hdlist tr {
|
|
padding-bottom: 15px;
|
|
}
|
|
dt.hdlist1.strong, td.hdlist1.strong {
|
|
font-weight: bold;
|
|
}
|
|
td.hdlist1 {
|
|
vertical-align: top;
|
|
font-style: normal;
|
|
padding-right: 0.8em;
|
|
color: navy;
|
|
}
|
|
td.hdlist2 {
|
|
vertical-align: top;
|
|
}
|
|
div.hdlist.compact tr {
|
|
margin: 0;
|
|
padding-bottom: 0;
|
|
}
|
|
|
|
.comment {
|
|
background: yellow;
|
|
}
|
|
|
|
.footnote, .footnoteref {
|
|
font-size: 0.8em;
|
|
}
|
|
|
|
span.footnote, span.footnoteref {
|
|
vertical-align: super;
|
|
}
|
|
|
|
#footnotes {
|
|
margin: 20px 0 20px 0;
|
|
padding: 7px 0 0 0;
|
|
}
|
|
|
|
#footnotes div.footnote {
|
|
margin: 0 0 5px 0;
|
|
}
|
|
|
|
#footnotes hr {
|
|
border: none;
|
|
border-top: 1px solid silver;
|
|
height: 1px;
|
|
text-align: left;
|
|
margin-left: 0;
|
|
width: 20%;
|
|
min-width: 100px;
|
|
}
|
|
|
|
div.colist td {
|
|
padding-right: 0.5em;
|
|
padding-bottom: 0.3em;
|
|
vertical-align: top;
|
|
}
|
|
div.colist td img {
|
|
margin-top: 0.3em;
|
|
}
|
|
|
|
@media print {
|
|
#footer-badges { display: none; }
|
|
}
|
|
|
|
#toc {
|
|
margin-bottom: 2.5em;
|
|
}
|
|
|
|
#toctitle {
|
|
color: #527bbd;
|
|
font-size: 1.1em;
|
|
font-weight: bold;
|
|
margin-top: 1.0em;
|
|
margin-bottom: 0.1em;
|
|
}
|
|
|
|
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
|
|
margin-top: 0;
|
|
margin-bottom: 0;
|
|
}
|
|
div.toclevel2 {
|
|
margin-left: 2em;
|
|
font-size: 0.9em;
|
|
}
|
|
div.toclevel3 {
|
|
margin-left: 4em;
|
|
font-size: 0.9em;
|
|
}
|
|
div.toclevel4 {
|
|
margin-left: 6em;
|
|
font-size: 0.9em;
|
|
}
|
|
|
|
span.aqua { color: aqua; }
|
|
span.black { color: black; }
|
|
span.blue { color: blue; }
|
|
span.fuchsia { color: fuchsia; }
|
|
span.gray { color: gray; }
|
|
span.green { color: green; }
|
|
span.lime { color: lime; }
|
|
span.maroon { color: maroon; }
|
|
span.navy { color: navy; }
|
|
span.olive { color: olive; }
|
|
span.purple { color: purple; }
|
|
span.red { color: red; }
|
|
span.silver { color: silver; }
|
|
span.teal { color: teal; }
|
|
span.white { color: white; }
|
|
span.yellow { color: yellow; }
|
|
|
|
span.aqua-background { background: aqua; }
|
|
span.black-background { background: black; }
|
|
span.blue-background { background: blue; }
|
|
span.fuchsia-background { background: fuchsia; }
|
|
span.gray-background { background: gray; }
|
|
span.green-background { background: green; }
|
|
span.lime-background { background: lime; }
|
|
span.maroon-background { background: maroon; }
|
|
span.navy-background { background: navy; }
|
|
span.olive-background { background: olive; }
|
|
span.purple-background { background: purple; }
|
|
span.red-background { background: red; }
|
|
span.silver-background { background: silver; }
|
|
span.teal-background { background: teal; }
|
|
span.white-background { background: white; }
|
|
span.yellow-background { background: yellow; }
|
|
|
|
span.big { font-size: 2em; }
|
|
span.small { font-size: 0.6em; }
|
|
|
|
span.underline { text-decoration: underline; }
|
|
span.overline { text-decoration: overline; }
|
|
span.line-through { text-decoration: line-through; }
|
|
|
|
div.unbreakable { page-break-inside: avoid; }
|
|
|
|
|
|
/*
|
|
* xhtml11 specific
|
|
*
|
|
* */
|
|
|
|
div.tableblock {
|
|
margin-top: 1.0em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
div.tableblock > table {
|
|
border: 3px solid #527bbd;
|
|
}
|
|
thead, p.table.header {
|
|
font-weight: bold;
|
|
color: #527bbd;
|
|
}
|
|
p.table {
|
|
margin-top: 0;
|
|
}
|
|
/* Because the table frame attribute is overridden by CSS in most browsers. */
|
|
div.tableblock > table[frame="void"] {
|
|
border-style: none;
|
|
}
|
|
div.tableblock > table[frame="hsides"] {
|
|
border-left-style: none;
|
|
border-right-style: none;
|
|
}
|
|
div.tableblock > table[frame="vsides"] {
|
|
border-top-style: none;
|
|
border-bottom-style: none;
|
|
}
|
|
|
|
|
|
/*
|
|
* html5 specific
|
|
*
|
|
* */
|
|
|
|
table.tableblock {
|
|
margin-top: 1.0em;
|
|
margin-bottom: 1.5em;
|
|
}
|
|
thead, p.tableblock.header {
|
|
font-weight: bold;
|
|
color: #527bbd;
|
|
}
|
|
p.tableblock {
|
|
margin-top: 0;
|
|
}
|
|
table.tableblock {
|
|
border-width: 3px;
|
|
border-spacing: 0px;
|
|
border-style: solid;
|
|
border-color: #527bbd;
|
|
border-collapse: collapse;
|
|
}
|
|
th.tableblock, td.tableblock {
|
|
border-width: 1px;
|
|
padding: 4px;
|
|
border-style: solid;
|
|
border-color: #527bbd;
|
|
}
|
|
|
|
table.tableblock.frame-topbot {
|
|
border-left-style: hidden;
|
|
border-right-style: hidden;
|
|
}
|
|
table.tableblock.frame-sides {
|
|
border-top-style: hidden;
|
|
border-bottom-style: hidden;
|
|
}
|
|
table.tableblock.frame-none {
|
|
border-style: hidden;
|
|
}
|
|
|
|
th.tableblock.halign-left, td.tableblock.halign-left {
|
|
text-align: left;
|
|
}
|
|
th.tableblock.halign-center, td.tableblock.halign-center {
|
|
text-align: center;
|
|
}
|
|
th.tableblock.halign-right, td.tableblock.halign-right {
|
|
text-align: right;
|
|
}
|
|
|
|
th.tableblock.valign-top, td.tableblock.valign-top {
|
|
vertical-align: top;
|
|
}
|
|
th.tableblock.valign-middle, td.tableblock.valign-middle {
|
|
vertical-align: middle;
|
|
}
|
|
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
|
|
vertical-align: bottom;
|
|
}
|
|
|
|
|
|
/*
|
|
* manpage specific
|
|
*
|
|
* */
|
|
|
|
body.manpage h1 {
|
|
padding-top: 0.5em;
|
|
padding-bottom: 0.5em;
|
|
border-top: 2px solid silver;
|
|
border-bottom: 2px solid silver;
|
|
}
|
|
body.manpage h2 {
|
|
border-style: none;
|
|
}
|
|
body.manpage div.sectionbody {
|
|
margin-left: 3em;
|
|
}
|
|
|
|
@media print {
|
|
body.manpage div#toc { display: none; }
|
|
}
|
|
|
|
|
|
</style>
|
|
<script type="text/javascript">
|
|
/*<+'])');
|
|
// Function that scans the DOM tree for header elements (the DOM2
|
|
// nodeIterator API would be a better technique but not supported by all
|
|
// browsers).
|
|
var iterate = function (el) {
|
|
for (var i = el.firstChild; i != null; i = i.nextSibling) {
|
|
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
|
|
var mo = re.exec(i.tagName);
|
|
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
|
|
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
|
|
}
|
|
iterate(i);
|
|
}
|
|
}
|
|
}
|
|
iterate(el);
|
|
return result;
|
|
}
|
|
|
|
var toc = document.getElementById("toc");
|
|
if (!toc) {
|
|
return;
|
|
}
|
|
|
|
// Delete existing TOC entries in case we're reloading the TOC.
|
|
var tocEntriesToRemove = [];
|
|
var i;
|
|
for (i = 0; i < toc.childNodes.length; i++) {
|
|
var entry = toc.childNodes[i];
|
|
if (entry.nodeName.toLowerCase() == 'div'
|
|
&& entry.getAttribute("class")
|
|
&& entry.getAttribute("class").match(/^toclevel/))
|
|
tocEntriesToRemove.push(entry);
|
|
}
|
|
for (i = 0; i < tocEntriesToRemove.length; i++) {
|
|
toc.removeChild(tocEntriesToRemove[i]);
|
|
}
|
|
|
|
// Rebuild TOC entries.
|
|
var entries = tocEntries(document.getElementById("content"), toclevels);
|
|
for (var i = 0; i < entries.length; ++i) {
|
|
var entry = entries[i];
|
|
if (entry.element.id == "")
|
|
entry.element.id = "_toc_" + i;
|
|
var a = document.createElement("a");
|
|
a.href = "#" + entry.element.id;
|
|
a.appendChild(document.createTextNode(entry.text));
|
|
var div = document.createElement("div");
|
|
div.appendChild(a);
|
|
div.className = "toclevel" + entry.toclevel;
|
|
toc.appendChild(div);
|
|
}
|
|
if (entries.length == 0)
|
|
toc.parentNode.removeChild(toc);
|
|
},
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////
|
|
// Footnotes generator
|
|
/////////////////////////////////////////////////////////////////////
|
|
|
|
/* Based on footnote generation code from:
|
|
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
|
|
*/
|
|
|
|
footnotes: function () {
|
|
// Delete existing footnote entries in case we're reloading the footnodes.
|
|
var i;
|
|
var noteholder = document.getElementById("footnotes");
|
|
if (!noteholder) {
|
|
return;
|
|
}
|
|
var entriesToRemove = [];
|
|
for (i = 0; i < noteholder.childNodes.length; i++) {
|
|
var entry = noteholder.childNodes[i];
|
|
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
|
|
entriesToRemove.push(entry);
|
|
}
|
|
for (i = 0; i < entriesToRemove.length; i++) {
|
|
noteholder.removeChild(entriesToRemove[i]);
|
|
}
|
|
|
|
// Rebuild footnote entries.
|
|
var cont = document.getElementById("content");
|
|
var spans = cont.getElementsByTagName("span");
|
|
var refs = {};
|
|
var n = 0;
|
|
for (i=0; i<spans.length; i++) {
|
|
if (spans[i].className == "footnote") {
|
|
n++;
|
|
var note = spans[i].getAttribute("data-note");
|
|
if (!note) {
|
|
// Use [\s\S] in place of . so multi-line matches work.
|
|
// Because JavaScript has no s (dotall) regex flag.
|
|
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
|
|
spans[i].innerHTML =
|
|
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
|
|
"' title='View footnote' class='footnote'>" + n + "</a>]";
|
|
spans[i].setAttribute("data-note", note);
|
|
}
|
|
noteholder.innerHTML +=
|
|
"<div class='footnote' id='_footnote_" + n + "'>" +
|
|
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
|
|
n + "</a>. " + note + "</div>";
|
|
var id =spans[i].getAttribute("id");
|
|
if (id != null) refs["#"+id] = n;
|
|
}
|
|
}
|
|
if (n == 0)
|
|
noteholder.parentNode.removeChild(noteholder);
|
|
else {
|
|
// Process footnoterefs.
|
|
for (i=0; i<spans.length; i++) {
|
|
if (spans[i].className == "footnoteref") {
|
|
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
|
|
href = href.match(/#.*/)[0]; // Because IE return full URL.
|
|
n = refs[href];
|
|
spans[i].innerHTML =
|
|
"[<a href='#_footnote_" + n +
|
|
"' title='View footnote' class='footnote'>" + n + "</a>]";
|
|
}
|
|
}
|
|
}
|
|
},
|
|
|
|
install: function(toclevels) {
|
|
var timerId;
|
|
|
|
function reinstall() {
|
|
asciidoc.footnotes();
|
|
if (toclevels) {
|
|
asciidoc.toc(toclevels);
|
|
}
|
|
}
|
|
|
|
function reinstallAndRemoveTimer() {
|
|
clearInterval(timerId);
|
|
reinstall();
|
|
}
|
|
|
|
timerId = setInterval(reinstall, 500);
|
|
if (document.addEventListener)
|
|
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
|
|
else
|
|
window.onload = reinstallAndRemoveTimer;
|
|
}
|
|
|
|
}
|
|
asciidoc.install();
|
|
/*]]>*/
|
|
</script>
|
|
</head>
|
|
<body class="article">
|
|
<div id="header">
|
|
<h1>Upcoming breaking changes</h1>
|
|
<span id="revdate"></span>
|
|
</div>
|
|
<div id="content">
|
|
<div id="preamble">
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>The Git project aims to ensure backwards compatibility to the best extent
|
|
possible. Minor releases will not break backwards compatibility unless there is
|
|
a very strong reason to do so, like for example a security vulnerability.</p></div>
|
|
<div class="paragraph"><p>Regardless of that, due to the age of the Git project, it is only natural to
|
|
accumulate a backlog of backwards-incompatible changes that will eventually be
|
|
required to keep the project aligned with a changing world. These changes fall
|
|
into several categories:</p></div>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
Changes to long established defaults.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Concepts that have been replaced with a superior design.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Concepts, commands, configuration or options that have been lacking in major
|
|
ways and that cannot be fixed and which will thus be removed without any
|
|
replacement.
|
|
</p>
|
|
</li>
|
|
</ul></div>
|
|
<div class="paragraph"><p>Explicitly not included in this list are fixes to minor bugs that may cause a
|
|
change in user-visible behavior.</p></div>
|
|
<div class="paragraph"><p>The Git project irregularly releases breaking versions that deliberately break
|
|
backwards compatibility with older versions. This is done to ensure that Git
|
|
remains relevant, safe and maintainable going forward. The release cadence of
|
|
breaking versions is typically measured in multiple years. We had the following
|
|
major breaking releases in the past:</p></div>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
Git 1.6.0, released in August 2008.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Git 2.0, released in May 2014.
|
|
</p>
|
|
</li>
|
|
</ul></div>
|
|
<div class="paragraph"><p>We use <major>.<minor> release numbers these days, starting from Git 2.0. For
|
|
future releases, our plan is to increment <major> in the release number when we
|
|
make the next breaking release. Before Git 2.0, the release numbers were
|
|
1.<major>.<minor> with the intention to increment <major> for "usual" breaking
|
|
releases, reserving the jump to Git 2.0 for really large backward-compatibility
|
|
breaking changes.</p></div>
|
|
<div class="paragraph"><p>The intent of this document is to track upcoming deprecations for future
|
|
breaking releases. Furthermore, this document also tracks what will <em>not</em> be
|
|
deprecated. This is done such that the outcome of discussions document both
|
|
when the discussion favors deprecation, but also when it rejects a deprecation.</p></div>
|
|
<div class="paragraph"><p>Items should have a clear summary of the reasons why we do or do not want to
|
|
make the described change that can be easily understood without having to read
|
|
the mailing list discussions. If there are alternatives to the changed feature,
|
|
those alternatives should be pointed out to our users.</p></div>
|
|
<div class="paragraph"><p>All items should be accompanied by references to relevant mailing list threads
|
|
where the deprecation was discussed. These references use message-IDs, which
|
|
can visited via</p></div>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre><code>https://lore.kernel.org/git/$message_id/</code></pre>
|
|
</div></div>
|
|
<div class="paragraph"><p>to see the message and its surrounding discussion. Such a reference is there to
|
|
make it easier for you to find how the project reached consensus on the
|
|
described item back then.</p></div>
|
|
<div class="paragraph"><p>This is a living document as the environment surrounding the project changes
|
|
over time. If circumstances change, an earlier decision to deprecate or change
|
|
something may need to be revisited from time to time. So do not take items on
|
|
this list to mean "it is settled, do not waste our time bringing it up again".</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_procedure">Procedure</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>Discussing the desire to make breaking changes, declaring that breaking
|
|
changes are made at a certain version boundary, and recording these
|
|
decisions in this document, are necessary but not sufficient.
|
|
Because such changes are expected to be numerous, and the design and
|
|
implementation of them are expected to span over time, they have to
|
|
be deployable trivially at such a version boundary, prepared over long
|
|
time.</p></div>
|
|
<div class="paragraph"><p>The breaking changes MUST be guarded with the a compile-time switch,
|
|
WITH_BREAKING_CHANGES, to help this process. When built with it,
|
|
the resulting Git binary together with its documentation would
|
|
behave as if these breaking changes slated for the next big version
|
|
boundary are already in effect. We also have a CI job to exercise
|
|
the work-in-progress version of Git with these breaking changes.</p></div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_git_3_0">Git 3.0</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>The following subsections document upcoming breaking changes for Git 3.0. There
|
|
is no planned release date for this breaking version yet.</p></div>
|
|
<div class="paragraph"><p>Proposed changes and removals only include items which are "ready" to be done.
|
|
In other words, this is not supposed to be a wishlist of features that should
|
|
be changed to or replaced in case the alternative was implemented already.</p></div>
|
|
<div class="sect2">
|
|
<h3 id="_changes">Changes</h3>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
The default hash function for new repositories will be changed from "sha1"
|
|
to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
|
|
recommended against in FIPS 140-2 and similar certifications. Furthermore,
|
|
there are practical attacks on SHA-1 that weaken its cryptographic properties:
|
|
</p>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
The SHAppening (2015). The first demonstration of a practical attack
|
|
against SHA-1 with 2^57 operations.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Birthday-Near-Collision (2019). This attack allows for chosen prefix
|
|
attacks with 2^68 operations.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Shambles (2020). This attack allows for chosen prefix attacks with 2^63
|
|
operations.
|
|
</p>
|
|
<div class="paragraph"><p>While we have protections in place against known attacks, it is expected
|
|
that more attacks against SHA-1 will be found by future research. Paired
|
|
with the ever-growing capability of hardware, it is only a matter of time
|
|
before SHA-1 will be considered broken completely. We want to be prepared
|
|
and will thus change the default hash algorithm to "sha256" for newly
|
|
initialized repositories.</p></div>
|
|
<div class="paragraph"><p>An important requirement for this change is that the ecosystem is ready to
|
|
support the "sha256" object format. This includes popular Git libraries,
|
|
applications and forges.</p></div>
|
|
<div class="paragraph"><p>There is no plan to deprecate the "sha1" object format at this point in time.</p></div>
|
|
<div class="paragraph"><p>Cf. <<a href="mailto:2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com">2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com</a>>,
|
|
<<a href="mailto:20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain">20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain</a>>,
|
|
<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+<a href="mailto:DiUQ@mail.gmail.com">DiUQ@mail.gmail.com</a>>.</p></div>
|
|
</li>
|
|
</ul></div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The default storage format for references in newly created repositories will
|
|
be changed from "files" to "reftable". The "reftable" format provides
|
|
multiple advantages over the "files" format:
|
|
</p>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
It is impossible to store two references that only differ in casing on
|
|
case-insensitive filesystems with the "files" format. This issue is common
|
|
on Windows and macOS platforms. As the "reftable" backend does not use
|
|
filesystem paths to encode reference names this problem goes away.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Similarly, macOS normalizes path names that contain unicode characters,
|
|
which has the consequence that you cannot store two names with unicode
|
|
characters that are encoded differently with the "files" backend. Again,
|
|
this is not an issue with the "reftable" backend.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Deleting references with the "files" backend requires Git to rewrite the
|
|
complete "packed-refs" file. In large repositories with many references
|
|
this file can easily be dozens of megabytes in size, in extreme cases it
|
|
may be gigabytes. The "reftable" backend uses tombstone markers for
|
|
deleted references and thus does not have to rewrite all of its data.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Repository housekeeping with the "files" backend typically performs
|
|
all-into-one repacks of references. This can be quite expensive, and
|
|
consequently housekeeping is a tradeoff between the number of loose
|
|
references that accumulate and slow down operations that read references,
|
|
and compressing those loose references into the "packed-refs" file. The
|
|
"reftable" backend uses geometric compaction after every write, which
|
|
amortizes costs and ensures that the backend is always in a
|
|
well-maintained state.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Operations that write multiple references at once are not atomic with the
|
|
"files" backend. Consequently, Git may see in-between states when it reads
|
|
references while a reference transaction is in the process of being
|
|
committed to disk.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Writing many references at once is slow with the "files" backend because
|
|
every reference is created as a separate file. The "reftable" backend
|
|
significantly outperforms the "files" backend by multiple orders of
|
|
magnitude.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The reftable backend uses a binary format with prefix compression for
|
|
reference names. As a result, the format uses less space compared to the
|
|
"packed-refs" file.
|
|
</p>
|
|
<div class="paragraph"><p>Users that get immediate benefit from the "reftable" backend could continue to
|
|
opt-in to the "reftable" format manually by setting the "init.defaultRefFormat"
|
|
config. But defaults matter, and we think that overall users will have a better
|
|
experience with less platform-specific quirks when they use the new backend by
|
|
default.</p></div>
|
|
<div class="paragraph"><p>A prerequisite for this change is that the ecosystem is ready to support the
|
|
"reftable" format. Most importantly, alternative implementations of Git like
|
|
JGit, libgit2 and Gitoxide need to support it.</p></div>
|
|
</li>
|
|
</ul></div>
|
|
</li>
|
|
</ul></div>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_removals">Removals</h3>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
Support for grafting commits has long been superseded by git-replace(1).
|
|
Grafts are inferior to replacement refs:
|
|
</p>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
Grafts are a local-only mechanism and cannot be shared across
|
|
repositories.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Grafts can lead to hard-to-diagnose problems when transferring objects
|
|
between repositories.
|
|
</p>
|
|
<div class="paragraph"><p>The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
|
|
info/grafts as outdated, 2014-03-05) and will be removed.</p></div>
|
|
<div class="paragraph"><p>Cf. <<a href="mailto:20140304174806.GA11561@sigill.intra.peff.net">20140304174806.GA11561@sigill.intra.peff.net</a>>.</p></div>
|
|
</li>
|
|
</ul></div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The git-pack-redundant(1) command can be used to remove redundant pack files.
|
|
The subcommand is unusably slow and the reason why nobody reports it as a
|
|
performance bug is suspected to be the absence of users. We have nominated
|
|
the command for removal and have started to emit a user-visible warning in
|
|
c3b58472be (pack-redundant: gauge the usage before proposing its removal,
|
|
2020-08-25) whenever the command is executed.
|
|
</p>
|
|
<div class="paragraph"><p>So far there was a single complaint about somebody still using the command, but
|
|
that complaint did not cause us to reverse course. On the contrary, we have
|
|
doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
|
|
escalate deprecation warning to an error, 2023-03-23), the command dies unless
|
|
the user passes the <code>--i-still-use-this</code> option.</p></div>
|
|
<div class="paragraph"><p>There have not been any subsequent complaints, so this command will finally be
|
|
removed.</p></div>
|
|
<div class="paragraph"><p>Cf. <<a href="mailto:xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com">xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com</a>>,
|
|
<CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=<a href="mailto:KAKhtpDNTvHJFuX1NA@mail.gmail.com">KAKhtpDNTvHJFuX1NA@mail.gmail.com</a>>,
|
|
<<a href="mailto:20230323204047.GA9290@coredump.intra.peff.net">20230323204047.GA9290@coredump.intra.peff.net</a>>,</p></div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Support for storing shorthands for remote URLs in "$GIT_COMMON_DIR/branches/"
|
|
and "$GIT_COMMON_DIR/remotes/" has been long superseded by storing remotes in
|
|
the repository configuration.
|
|
</p>
|
|
<div class="paragraph"><p>The mechanism has originally been introduced in f170e4b39d ([PATCH] fetch/pull:
|
|
short-hand notation for remote repositories., 2005-07-16) and was superseded by
|
|
6687f8fea2 ([PATCH] Use .git/remote/origin, not .git/branches/origin.,
|
|
2005-08-20), where we switched from ".git/branches/" to ".git/remotes/". That
|
|
commit already mentions an upcoming deprecation of the ".git/branches/"
|
|
directory, and starting with a1d4aa7424 (Add repository-layout document.,
|
|
2005-09-01) we have also marked this layout as deprecated. Eventually we also
|
|
started to migrate away from ".git/remotes/" in favor of config-based remotes,
|
|
and we have marked the directory as legacy in 3d3d282146 (Documentation:
|
|
Grammar correction, wording fixes and cleanup, 2011-08-23)</p></div>
|
|
<div class="paragraph"><p>As our documentation mentions, these directories are unlikely to be used in
|
|
modern repositories and most users aren’t even aware of these mechanisms. They
|
|
have been deprecated for almost 20 years and 14 years respectively, and we are
|
|
not aware of any active users that have complained about this deprecation.
|
|
Furthermore, the ".git/branches/" directory is nowadays misleadingly named and
|
|
may cause confusion as "branches" are almost exclusively used in the context of
|
|
references.</p></div>
|
|
<div class="paragraph"><p>These features will be removed.</p></div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Support for "--stdin" option in the "name-rev" command was
|
|
deprecated (and hidden from the documentation) in the Git 2.40
|
|
timeframe, in preference to its synonym "--annotate-stdin". Git 3.0
|
|
removes the support for "--stdin" altogether.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The git-whatchanged(1) command has outlived its usefulness more than
|
|
10 years ago, and takes more keystrokes to type than its rough
|
|
equivalent <code>git</code> <code>log</code> <code>--raw</code>. We have nominated the command for
|
|
removal, have changed the command to refuse to work unless the
|
|
<code>--i-still-use-this</code> option is given, and asked the users to report
|
|
when they do so. So far there hasn’t been a single complaint.
|
|
</p>
|
|
<div class="paragraph"><p>The command will be removed.</p></div>
|
|
</li>
|
|
</ul></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_superseded_features_that_will_not_be_deprecated">Superseded features that will not be deprecated</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph"><p>Some features have gained newer replacements that aim to improve the design in
|
|
certain ways. The fact that there is a replacement does not automatically mean
|
|
that the old way of doing things will eventually be removed. This section tracks
|
|
those features with newer alternatives.</p></div>
|
|
<div class="ulist"><ul>
|
|
<li>
|
|
<p>
|
|
The features git-checkout(1) offers are covered by the pair of commands
|
|
git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
|
|
widespread, and it is not expected that this will change anytime soon, all
|
|
three commands will stay.
|
|
</p>
|
|
<div class="paragraph"><p>This decision may get revisited in case we ever figure out that there are
|
|
almost no users of any of the commands anymore.</p></div>
|
|
<div class="paragraph"><p>Cf. <<a href="mailto:xmqqttjazwwa.fsf@gitster.g">xmqqttjazwwa.fsf@gitster.g</a>>,
|
|
<<a href="mailto:xmqqleeubork.fsf@gitster.g">xmqqleeubork.fsf@gitster.g</a>>,
|
|
<<a href="mailto:112b6568912a6de6672bf5592c3a718e@manjaro.org">112b6568912a6de6672bf5592c3a718e@manjaro.org</a>>.</p></div>
|
|
</li>
|
|
</ul></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div id="footnotes"><hr /></div>
|
|
<div id="footer">
|
|
<div id="footer-text">
|
|
Last updated
|
|
2025-08-18 02:18:23 CEST
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|