kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Elijah Newren	3aca58045f	git-clean.txt: do not claim we will delete files with -n/--dry-run It appears that the wrong option got included in the list of what will cause git-clean to actually take action. Correct the list. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Sixt	0eb7c37a8a	diff, log doc: small grammer, format, and language fixes - Replace "SHA-1" by "object name", the modern name for hashes. - Correct a few grammar weaknesses. - Do not accidentally format a phrase in teletype font where quotes are intended. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Sixt	6fae6bd518	diff, log doc: say "patch text" instead of "patches" diff, log doc: say "patch text" instead of "patches" A poster on Stackoverflow was confused that the documentation of git-log promised to generate "patches" or "patch files" with -p, but there were none to be found. Rewrite the corresponding paragraph to talk about "patch text" to avoid the confusion. Shorten the language to say "X does Y" in place of "X does not Z, but Y". Cross-reference the referred-to commands like the rest of the file does. Enumerate git-show because it includes the description as well. Mention porcelain commands before plumbing commands because I guess that the paragraph is read more frequently in their context. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	83b0b8953e	doc-diff: replace --cut-header-footer with --cut-footer After the previous commit, AsciiDoc and Asciidoctor render the manpage headers identically, so we no longer need the "cut the header" part of our `--cut-header-footer` option. We do still need the "cut the footer" part, though. The previous commits improved the rendering of the footer in Asciidoctor by quite a bit, but the two programs still disagree on how to format the date in the footer: 01/01/1970 vs 1970-01-01. We could keep using `--cut-header-footer`, but it would be nice if we had a slightly smaller hammer `--cut-footer` that would be less likely to hide regressions. Rather than simply adding such an option, let's also drop `--cut-header-footer`, i.e., rework it to lose the "header" part of its name and functionality. `--cut-header-footer` is just a developer tool and it probably has no more than a handful of users, so we can afford to be aggressive. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	7a30134358	asciidoctor-extensions: provide `<refmiscinfo/>` As can be seen from the previous commit, there are three attributes that we provide to AsciiDoc through asciidoc.conf. Asciidoctor ignores that file. After that patch, newer versions of Asciidoctor pick up the `manmanual` and `mansource` attributes as we invoke `asciidoctor`, but they don't pick up `manversion`. ([1] says: "Not used by Asciidoctor.") Older versions (<1.5.7) don't handle these attributes at all. As a result, we are missing one or three `<refmiscinfo/>` tags in each xml-file produced when we build with Asciidoctor. Because of this, xmlto doesn't include the Git version number in the rendered manpages. And in particular, with versions <1.5.7, the manpage footers instead contain the fairly ugly "[FIXME: source]". That Asciidoctor ignores asciidoc.conf is nothing new. This is why we implement the `linkgit:` macro in asciidoc.conf and in asciidoctor-extensions.rb. Follow suit and provide these tags in asciidoctor-extensions.rb, using a "postprocessor" extension where we just search and replace in the XML, treated as text. We may consider a few alternatives: * Inject these lines into the xml-files from the Makefile, e.g., using `sed`. That would reduce repetition, but it feels wrong to impose another step and another risk on the AsciiDoc-processing only to benefit the Asciidoctor-one. * I tried providing a "docinfo processor" to inject these tags, but could not figure out how to "merge" the two <refmeta/> sections that resulted. To avoid xmlto barfing on the result, I needed to use `xmlto --skip-validation ...`, which seems unfortunate. Let's instead inject the missing tags using a postprocessor. We'll make it fairly obvious that we aim to inject the exact same three lines of `<refmiscinfo/>` that asciidoc.conf provides. We inject them in post-processing so we need to do the variable expansion ourselves. We do introduce the bug that asciidoc.conf already has in that we won't do any escaping, e.g., of funky versions like "some v <2.25, >2.20". The postprocessor we add here works on the XML as raw text and doesn't really use the full potential of XML to do a more structured injection. This is actually precisely what the Asciidoctor User Manual does in its postprocessor example [2]. I looked into two other approaches: 1. The nokogiri library is apparently the "modern" way of doing XML in ruby. I got it working fairly easily: require 'nokogiri' doc = Nokogiri::XML(output) doc.search("refmeta").each { \|n\| n.add_child(new_tags) } output = doc.to_xml However, this adds another dependency (e.g., the "ruby-nokogiri" package on Ubuntu). Using Asciidoctor is not our default, but it will probably need to become so soon. Let's avoid adding a dependency just so that we can say "search...add_child" rather than "sub(regex...)". 2. The older REXML is apparently always(?) bundled with ruby, but I couldn't even parse the original document: require 'rexml/document' doc = REXML::Document.new(output) ... The error was "no implicit conversion of nil into String" and I stopped there. I don't think it's unlikely that doing a plain old search-and-replace will work just as fine or better compared to parsing XML and worrying about libraries and library versions. [1] https://asciidoctor.org/docs/user-manual/#builtin-attributes [2] https://asciidoctor.org/docs/user-manual/#postprocessor-example Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	226daba280	Doc/Makefile: give mansource/-version/-manual attributes Rather than hardcoding "Git Manual" and "Git" as the manual and source in asciidoc.conf, provide them as attributes `manmanual` and `mansource`. Rename the `git_version` attribute to `manversion`. These new attribute names are not arbitrary, see, e.g., [1]. For AsciiDoc (8.6.10) and Asciidoctor <1.5.7, this is a no-op. Starting with Asciidoctor 1.5.7, `manmanual` and `mansource` actually end up in the xml-files and eventually in the rendered manpages. In particular, the manpage headers now render just as with AsciiDoc. No versions of Asciidoctor pick up the `manversion` [2], and older versions don't pick up any of these attributes. -- We'll fix that with a bit of a hack in the next commit. [1] https://asciidoctor.org/docs/user-manual/#man-pages [2] Note how [1] says "Not used by Asciidoctor". Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Denton Liu	40e747e89d	git-submodule.txt: fix AsciiDoc formatting error In `b57e8119e6` (submodule: teach set-branch subcommand, 2019-02-08), the `set-branch` subcommand was added for submodules. When the documentation was written, the syntax for a "index term" in AsciiDoc was accidentally used. This caused the documentation to be rendered as set-branch -d\|--default)\|(-b\|--branch <branch> [--] <path> instead of set-branch ((-d\|--default)\|(-b\|--branch <branch>)) [--] <path> In addition to this, the original documentation was possibly confusing as it made it seem as if the `-b` option didn't accept a `<branch>` argument. Break `--default` and `--branch` into their own separate invocations to make it obvious that these options are mutually exclusive. Also, this removes the surrounding parentheses so that the "index term" syntax is not triggered. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
brian m. carlson	f6461b82b9	Documentation: fix build with Asciidoctor 2 Our documentation toolchain has traditionally been built around DocBook 4.5. This version of DocBook is the last DTD-based version of DocBook. In 2009, DocBook 5 was introduced using namespaces and its syntax is expressed in RELAX NG, which is more expressive and allows a wider variety of syntax forms. Asciidoctor, one of the alternatives for building our documentation, moved support for DocBook 4.5 out of core in its recent 2.0 release and now only supports DocBook 5 in the main release. The DocBoook 4.5 converter is still available as a separate component, but this is not available in most distro packages. This would not be a problem but for the fact that we use xmlto, which is still stuck in the DocBook 4.5 era. xmlto performs DTD validation as part of the build process. This is not problematic for DocBook 4.5, which has a valid DTD, but it clearly cannot work for DocBook 5, since no DTD can adequately express its full syntax. In addition, even if xmlto did support RELAX NG validation, that wouldn't be sufficient because it uses the libxml2-based xmllint to do so, which has known problems with validating interleaves in RELAX NG. Fortunately, there's an easy way forward: ask Asciidoctor to use its DocBook 5 backend and tell xmlto to skip validation. Asciidoctor has supported DocBook 5 since v0.1.4 in 2013 and xmlto has supported skipping validation for probably longer than that. We also need to teach xmlto how to use the namespaced DocBook XSLT stylesheets instead of the non-namespaced ones it usually uses. Normally these stylesheets are interchangeable, but the non-namespaced ones have a bug that causes them not to strip whitespace automatically from certain elements when namespaces are in use. This results in additional whitespace at the beginning of list elements, which is jarring and unsightly. We can do this by passing a custom stylesheet with the -x option that simply imports the namespaced stylesheets via a URL. Any system with support for XML catalogs will automatically look this URL up and reference a local copy instead without us having to know where this local copy is located. We know that anyone using xmlto will already have catalogs set up properly since the DocBook 4.5 DTD used during validation is also looked up via catalogs. All major Linux distributions distribute the necessary stylesheets and have built-in catalog support, and Homebrew does as well, albeit with a requirement to set an environment variable to enable catalog support. On the off chance that someone lacks support for catalogs, it is possible for xmlto (via xmllint) to download the stylesheets from the URLs in question, although this will likely perform poorly enough to attract attention. People still have the option of using the prebuilt documentation that we ship, so happily this should not be an impediment. Finally, we need to filter out some messages from other stylesheets that occur when invoking dblatex in the CI job. This tool strips namespaces much like the unnamespaced DocBook stylesheets and prints similar messages. If we permit these messages to be printed to standard error, our documentation CI job will fail because we check standard error for unexpected output. Due to dblatex's reliance on Python 2, we may need to revisit its use in the future, in which case this problem may go away, but this can be delayed until a future patch. The final message we filter is due to libxslt on modern Debian and Ubuntu. The patch which they use to implement reproducible ID generation also prints messages about the ID generation. While this doesn't affect our current CI images since they use Ubuntu 16.04 which lacks this patch, if we upgrade to Ubuntu 18.04 or a modern Debian, these messages will appear and, like the above messages, cause a CI failure. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Cameron Steffen	4fd39c76e6	doc: minor formatting fix Move a closing backtick that was placed one character too soon. Signed-off-by: Cameron Steffen <cam.steffen94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	f1d4a28250	Second batch Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	4414e837fc	gitweb.conf.txt: switch pluses to backticks to help Asciidoctor This paragraph uses a lot of +pluses+ to render text as monospace. That works fine with AsciiDoc (8.6.10), and almost fine with Asciidoctor (1.5.5), which renders the third of these literally ("+$projname+"). The reason seems to be that Asciidoctor trips on the lone plus a bit earlier, even though it is escaped. Switch +$projname+ to `$projname`, and change the next, similar instance too (+$projname/+), because otherwise, we'd trip on /that one/ instead. If we would stop there, we would now start falling over on the escaped plus ('\+') mentioned earlier, rendering /it/ literally. So change that too... In other words, unescape the lone '+' and change all the pluses that follow it to backticks. AsciiDoc renders this paragraph identically before and after this commit, and Asciidoctor now renders this the same as AsciiDoc. I did try to switch the whole paragraph to using backticks rather than pluses. That worked great with Asciidoctor, but confused AsciiDoc... Let's go with this rather surgical change instead. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	b7e1ba5649	git-merge-index.txt: wrap shell listing in "----" The example output of `git merge-index` has been enriched by a second "column" of helpful comments. When Asciidoctor renders this, the cells in that second column aren't aligned. Fix this by marking the example shell session as a code listing by wrapping it in "----". Also drop some of the horizontal space between the two columns so that we fit into 80 columns. This changes the rendering with both AsciiDoc and Asciidoctor. They now render this identically, nicely aligned, and within 80 columns. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	38cadf9e47	git-receive-pack.txt: wrap shell [script] listing in "----" The indented lines in the example shell script listing are indented differently by AsciiDoc and Asciidoctor. Fix this by marking the example shell script as a code listing by wrapping it in "----". Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. For consistency, make the same change to the short example shell session further down. With AsciiDoc, this results in identical rendering before and after this commit. Asciidoctor now renders this the same as AsciiDoc does. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	5371813768	git-ls-remote.txt: wrap shell listing in "----" The second "column" in the output of `git ls-remote` is typeset differently by AsciiDoc and Asciidoctor, similar to various examples touched by the last few commits. Fix this by marking the example shell session as a code listing by wrapping it in "----". Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. With AsciiDoc, this results in identical rendering before and after this commit. Asciidoctor now renders this the same as AsciiDoc does. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	1925fe0c8a	Documentation: wrap config listings in "----" The indented lines in these example config-file listings are indented differently by AsciiDoc and Asciidoctor. Fix this by marking the example config-files as code listings by wrapping them in "----". Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. With AsciiDoc, this results in identical rendering before and after this commit. Asciidoctor now renders this the same as AsciiDoc does. git-config.txt pretty consistently uses twelve dashes rather than the minimum four to spell "----". Let's stick to the file-local convention there. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	922a2c93f5	git-merge-base.txt: render indentations correctly under Asciidoctor There are several graphs in this document. For most of them, we use a single leading tab to indent the whole graph, and then we use spaces (possibly eight or more) to align things within the graph. In the larger graph, we use a different strategy: We use 1-N tabs and just a small number of spaces (<8). This is how we usually prefer to do our indenting, but Asciidoctor ends up rendering this differently from AsciiDoc. Same thing for the if-then-fi examples where the conditional code is indented by two tabs, which renders differently under AsciiDoc and Asciidoctor. Similar to `379805051d` ("Documentation: render revisions correctly under Asciidoctor", 2018-05-06), use an explicit literal block to indicate that we want to keep the leading whitespace in the tables. Change not just the ones that render differently, but all of them for consistency. Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. With AsciiDoc, this results in identical rendering before and after this commit, both for git-merge-base.1 and git-merge-base.html. A less intrusive change would be to replace tabs 2-N on each line with eight spaces. But let's follow the example set by `379805051d`, so that we can use our preferred way of indenting. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	2017956a19	Documentation: wrap blocks with "--" The documentation for each of these options contains a list. After the list, AsciiDoc interprets the continuation as a continuation of the list, not as a continution of the larger block. As a result, we get too much indentation. Wrap the entire blocks in "--" to fix this. With Asciidoctor, this commit is a no-op, and the two programs now render these identically. These two files share the same problem and indeed, they both document `--untracked-files` in quite similar ways. I haven't checked to what extent that is intentional or warranted, and to what extent they have simply drifted apart. I consider such an investigation and possible cleanup as out of scope for this commit and this patch series. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	65edd96aec	treewide: rename 'exclude' methods to 'pattern' The first consumer of pattern-matching filenames was the .gitignore feature. In that context, storing a list of patterns as a 'struct exclude_list' makes sense. However, the sparse-checkout feature then adopted these structures and methods, but with the opposite meaning: these patterns match the files that should be included! It would be clearer to rename this entire library as a "pattern matching" library, and the callers apply exclusion/inclusion logic accordingly based on their needs. This commit renames several methods defined in dir.h to make more sense with the renamed 'struct exclude_list' to 'struct pattern_list' and 'struct exclude' to 'struct path_pattern': * last_exclude_matching() -> last_matching_pattern() * parse_exclude() -> parse_path_pattern() In addition, the word 'exclude' was replaced with 'pattern' in the methods below: * add_exclude_list() * add_excludes_from_file_to_list() * add_excludes_from_file() * add_excludes_from_blob_to_list() * add_exclude() * clear_exclude_list() A few methods with the word "exclude" remain. These will be handled seperately. In particular, the method "is_excluded()" is concretely about the .gitignore file relative to a specific directory. This is the important boundary between library and consumer: is_excluded() cares about .gitignore, but is_excluded() calls last_matching_pattern() to make that decision. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Elijah Newren	9df53c5de6	Recommend git-filter-repo instead of git-filter-branch filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Denton Liu	50094ca45f	config/format.txt: specify default value of format.coverLetter Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Denton Liu	c1a6f21cd4	Doc: add more detail for git-format-patch In git-format-patch.txt, we were missing some key user information. First of all, document the special value of `--base=auto`. Next, while we're at it, surround option arguments with <> and change existing names such as "Message-Id" to "message id", which conforms with how existing documentation is written. Finally, document the `format.outputDirectory` config and change `format.coverletter` to use camel case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	50f26bd035	fetch: add fetch.writeCommitGraph config setting The commit-graph feature is now on by default, and is being written during 'git gc' by default. Typically, Git only writes a commit-graph when a 'git gc --auto' command passes the gc.auto setting to actualy do work. This means that a commit-graph will typically fall behind the commits that are being used every day. To stay updated with the latest commits, add a step to 'git fetch' to write a commit-graph after fetching new objects. The fetch.writeCommitGraph config setting enables writing a split commit-graph, so on average the cost of writing this file is very small. Occasionally, the commit-graph chain will collapse to a single level, and this could be slow for very large repos. For additional use, adjust the default to be true when feature.experimental is enabled. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Elijah Newren	27fd1e4ea7	merge-options.txt: clarify meaning of various ff-related options As discovered on the mailing list, some of the descriptions of the ff-related options were unclear. Try to be more precise with what these options do. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
David Turner	0a8bc7068f	clarify documentation for remote helpers Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Denton Liu	414d924beb	rebase: teach rebase --keep-base A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This is useful when contributing a patch series to the Git mailing list, one often starts on top of the current 'master'. While developing the patches, 'master' is also developed further and it is sometimes not the best idea to keep rebasing on top of 'master', but to keep the base commit as-is. In addition to this, a user wishing to test individual commits in a topic branch without changing anything may run git rebase -x ./test.sh master... master Since rebasing onto the merge base of the branch and the upstream is such a common case, introduce the --keep-base option as a shortcut. This allows us to rewrite the above as git rebase -i --keep-base master and git rebase -x ./test.sh --keep-base master respectively. Add tests to ensure --keep-base works correctly in the normal case and fails when there are multiple merge bases, both in regular and interactive mode. Also, test to make sure conflicting options cause rebase to fail. While we're adding test cases, add a missing set_fake_editor call to 'rebase -i --onto master...side'. While we're documenting the --keep-base option, change an instance of "merge-base" to "merge base", which is the consistent spelling. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	745f681289	First batch after Git 2.23 Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Stephen Boyd	3c81760bc6	userdiff: add a builtin pattern for dts files The Linux kernel receives many patches to the devicetree files each release. The hunk header for those patches typically show nothing, making it difficult to figure out what node is being modified without applying the patch or opening the file and seeking to the context. Let's add a builtin 'dts' pattern to git so that users can get better diff output on dts files when they use the diff=dts driver. The regex has been constructed based on the spec at devicetree.org[1] and with some help from Johannes Sixt. [1] https://github.com/devicetree-org/devicetree-specification/releases/latest Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ben Milman	1c24a54ea4	repository-layout.txt: correct pluralization of 'object' In the description of 'objects/pack', 'object' should be pluralized to match the subject and agree with the rest of the sentence. Signed-off-by: Ben Milman <bpmilman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Corentin BOMPARD	24bc1a1292	pull, fetch: add --set-upstream option Add the --set-upstream option to git pull/fetch which lets the user set the upstream configuration (branch.<current-branch-name>.merge and branch.<current-branch-name>.remote) for the current branch. A typical use-case is: git clone http://example.com/my-public-fork git remote add main http://example.com/project-main-repo git pull --set-upstream main master or, instead of the last line: git fetch --set-upstream main master git merge # or git rebase This is mostly equivalent to cloning project-main-repo (which sets upsteam) and then "git remote add" my-public-fork, but may feel more natural for people using a hosting system which allows forking from the web UI. This functionality is analog to "git push --set-upstream". Signed-off-by: Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr> Signed-off-by: Nathan BERBEZIER <nathan.berbezier@etu.univ-lyon1.fr> Signed-off-by: Pablo CHABANNE <pablo.chabanne@etu.univ-lyon1.fr> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Patch-edited-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	64e5e1fba1	diff: 'diff.indentHeuristic' is no longer experimental The indent heuristic started out as experimental, but it's now our default diff heuristic since `33de716387` (diff: enable indent heuristic by default, 2017-05-08). Alas, that commit didn't update the documentation, and the description of the 'diff.indentHeuristic' configuration variable still implies that it's experimental and not the default. Update the description of 'diff.indentHeuristic' to make it clear that it's the default diff heuristic. The description of the related '--indent-heuristic' option has already been updated in `bab76141da` (diff: --indent-heuristic is no longer experimental, 2017-10-29). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	aaf633c2ad	repo-settings: create feature.experimental setting The 'feature.experimental' setting includes config options that are not committed to become defaults, but could use additional testing. Update the following config settings to take new defaults, and to use the repo_settings struct if not already using them: * 'pack.useSparse=true' * 'fetch.negotiationAlgorithm=skipping' In the case of fetch.negotiationAlgorithm, the existing logic would load the config option only when about to use the setting, so had a die() statement on an unknown string value. This is removed as now the config is parsed under prepare_repo_settings(). In general, this die() is probably misplaced and not valuable. A test was removed that checked this die() statement executed. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	c6cc4c5afd	repo-settings: create feature.manyFiles setting The feature.manyFiles setting is suitable for repos with many files in the working directory. By setting index.version=4 and core.untrackedCache=true, commands such as 'git status' should improve. While adding this setting, modify the index version precedence tests to check how this setting overrides the default for index.version is unset. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	31b1de6a09	commit-graph: turn on commit-graph by default The commit-graph feature has seen a lot of activity in the past year or so since it was introduced. The feature is a critical performance enhancement for medium- to large-sized repos, and does not significantly hurt small repos. Change the defaults for core.commitGraph and gc.writeCommitGraph to true so users benefit from this feature by default. There are several places in the test suite where the environment variable GIT_TEST_COMMIT_GRAPH is disabled to avoid reading a commit-graph, if it exists. The config option overrides the environment, so swap these. Some GIT_TEST_COMMIT_GRAPH assignments remain, and those are to avoid writing a commit-graph when a new commit is created. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Elijah Newren	d1387d3895	git-fast-import.txt: clarify that multiple merge commits are allowed The grammar for commits used a '?' rather than a '*' on the `merge` directive line, despite the fact that the code allows multiple `merge` directives in order to support n-way merges. In fact, elsewhere in git-fast-import.txt there is an explicit declaration that "an unlimited number of `merge` commands per commit are permitted by fast-import". Fix the grammar to match the intent and implementation. Reported-by: Joachim Klein <joachim.klein@automata.tools> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Mark Rushakoff	24966cd982	doc: fix repeated words Inspired by `21416f0a07` ("restore: fix typo in docs", 2019-08-03), I ran "git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases where words were duplicated, e.g. "the the", and in most cases removed one of the repeated words. There were many false positives by this grep command, including deliberate repeated words like "really really" or valid uses of "that that" which I left alone, of course. I also did not correct any of the legitimate, accidentally repeated words in old RelNotes. Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	75b2f01a0f	Git 2.22.1 Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Michael J Gruber	bc40ce4de6	merge: --no-verify to bypass pre-merge-commit hook Analogous to commit, introduce a '--no-verify' option which bypasses the pre-merge-commit hook. The shorthand '-n' is taken by '--no-stat' already. [js: * reworded commit message to reflect current state of --no-stat flag and new hook name * fixed flag documentation to reflect new hook name * cleaned up trailing whitespace * squashed test changes from the original series' patch 4/4 * modified tests to follow pattern from this series' patch 1/4 * added a test case for --no-verify with non-executable hook * when testing that the merge hook did not run, make sure we actually have a merge to perform (by resetting the "side" branch to its original state). ] Improved-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Michael J Gruber	6098817fd7	git-merge: honor pre-merge-commit hook git-merge does not honor the pre-commit hook when doing automatic merge commits, and for compatibility reasons this is going to stay. Introduce a pre-merge-commit hook which is called for an automatic merge commit just like pre-commit is called for a non-automatic merge commit (or any other commit). [js: * renamed hook from "pre-merge" to "pre-merge-commit" * only discard the index if the hook is actually present * expanded githooks documentation entry * clarified that hook should write messages to stderr * squashed test changes from the original series' patch 4/4 * modified tests to follow new pattern from this series' patch 1/4 * added a test case for non-executable merge hooks * added a test case for failed merges * when testing that the merge hook did not run, make sure we actually have a merge to perform (by resetting the "side" branch to its original state). * reworded commit message ] Improved-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Michael J Gruber	a1f3dd7eb3	merge: do no-verify like commit `f8b863598c` ("builtin/merge: honor commit-msg hook for merges", 2017-09-07) introduced the no-verify flag to merge for bypassing the commit-msg hook, though in a different way from the implementation in commit.c. Change the implementation in merge.c to be the same as in commit.c so that both do the same in the same way. This also changes the output of "git merge --help" to be more clear that the hook return code is respected by default. [js: * reworded commit message * squashed documentation changes from original series' patch 3/4 ] Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	67feca3b1c	gitcli: document --end-of-options Now that --end-of-options is available for any users of setup_revisions() or parse_options(), which should be effectively everywhere, we can guide people to use it for all their disambiguating needs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
William Chargin	21416f0a07	restore: fix typo in docs Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Mark Rushakoff	6d16922798	doc: typo: s/can not/cannot/ and s/is does/does/ "Can not" suggests one has the option to not do something, whereas "cannot" more strongly suggests something is disallowed or impossible. Noticed "can not", mistakenly used instead of "cannot" in git help glossary, then ran git grep 'can not' and found many other instances. Only files in the Documentation folder were modified. 'Can not' also occurs in some source code comments and some test assertion messages, and there is an error message and translation "can not move directory into itself" which I may fix and submit separately from the documentation change. Also noticed and fixed "is does" in git help fetch, but there are no other occurrences of that typo according to git grep. Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	7c20df84bd	Git 2.23-rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	f3eda90ffc	log: really flip the --mailmap default Update the docs, test the interaction between the new default, configuration and command line option, in addition to actually flipping the default. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	c43ab06259	tree-walk: add a strbuf wrapper for make_traverse_path() All but one of the callers of make_traverse_path() allocate a new heap buffer to store the path. Let's give them an easy way to write to a strbuf, which saves them from computing the length themselves (which is especially tricky when they want to add to the path). It will also make it easier for us to change the make_traverse_path() interface in a future patch to improve its bounds-checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	a45f531471	RelNotes/2.23.0: fix a few typos and other minor issues Fix the spelling of the new "--no-show-forced-updates" option that "git fetch/pull" learned. Similarly, spell "--function-context" correctly and fix a few typos, grammos and minor mistakes. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Martin Ågren	4d8ec15c66	RelNotes/2.21.1: typofix Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	7ed20f596b	log: flip the --mailmap default unconditionally It turns out that being cautious to warn against upcoming default change was an unpopular behaviour, and such a care can easily be defeated by distro packagers to render it ineffective anyway. Just flip the default, with only a mention in the release notes. Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	f36d08d72e	A few more last-minute fixes Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	947208b725	setup_traverse_info(): stop copying oid We assume that if setup_traverse_info() is passed a non-empty "base" string, that string is pointing into a tree object and we can read the object oid by skipping past the trailing NUL. As it turns out, this is not true for either of the two calls, and we may end up reading garbage bytes: 1. In git-merge-tree, our base string is either empty (in which case we'd never run this code), or it comes from our traverse_path() helper. The latter overallocates a buffer by the_hash_algo->rawsz bytes, but then fills it with only make_traverse_path(), leaving those extra bytes uninitialized (but part of a legitimate heap buffer). 2. In unpack_trees(), we pass o->prefix, which is some arbitrary string from the caller. In "git read-tree --prefix=foo", for instance, it will point to the command-line parameter, and we'll read 20 bytes past the end of the string. Interestingly, tools like ASan do not detect (2) because the process argv is part of a big pre-allocated buffer. So we're reading trash, but it's trash that's probably part of the next argument, or the environment. You can convince it to fail by putting something like this at the beginning of common-main.c's main() function: { int i; for (i = 0; i < argc; i++) argv[i] = xstrdup_or_null(argv[i]); } That puts the arguments into their own heap buffers, so running: make SANITIZE=address test will find problems when "read-tree --prefix" is used (e.g., in t3030). Doubly interesting, even with the hackery above, this does not fail prior to `ea82b2a085` (tree-walk: store object_id in a separate member, 2019-01-15). That commit switched setup_traverse_info() to actually copying the hash, rather than simply pointing to it. That pointer was always pointing to garbage memory, but that commit started actually dereferencing the bytes, which is what triggers ASan. That also implies that nobody actually cares about reading these oid bytes anyway (or at least no path covered by our tests). And manual inspection of the code backs that up (I'll follow this patch with some cleanups that show definitively this is the case, but they're quite invasive, so it's worth doing this fix on its own). So let's drop the bogus hashcpy(), along with the confusing oversizing in merge-tree. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago

1 2 3 4 5 ...

12222 Commits (b6d4d82bd5a49197d5d2f4f81c08da0d461cfcf1)