Tags: tfidfwastaken/git
Tags
gitweb: redacted e-mail addresses feature. From: Georgios Kontaxis <[email protected]> Gitweb extracts content from the Git log and makes it accessible over HTTP. As a result, e-mail addresses found in commits are exposed to web crawlers and they may not respect robots.txt. This can result in unsolicited messages. Introduce an 'email-privacy' feature which redacts e-mail addresses from the generated HTML content. Specifically, obscure addresses retrieved from the the author/committer and comment sections of the Git log. The feature is off by default. This feature does not prevent someone from downloading the unredacted commit log, e.g., by cloning the repository, and extracting information from it. It aims to hinder the low- effort, bulk collection of e-mail addresses by web crawlers. Signed-off-by: Georgios Kontaxis <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
sequencer: fix edit handling for cherry-pick and revert messages From: Elijah Newren <[email protected]> save_opts() should save any non-default values. It was intended to do this, but since most options in struct replay_opts default to 0, it only saved non-zero values. Unfortunatley, this does not always work for options.edit. Roughly speaking, options.edit had a default value of 0 for cherry-pick but a default value of 1 for revert. Make save_opts() record a value whenever it differs from the default. options.edit was also overly simplistic; we had more than two cases. The behavior that previously existed was as follows: Non-conflict commits Right after Conflict revert Edit iff isatty(0) Edit (ignore isatty(0)) cherry-pick No edit See above Specify --edit Edit (ignore isatty(0)) See above Specify --no-edit (*) See above (*) Before stopping for conflicts, No edit is the behavior. After stopping for conflicts, the --no-edit flag is not saved so see the first two rows. However, the expected behavior is: Non-conflict commits Right after Conflict revert Edit iff isatty(0) Edit iff isatty(0) cherry-pick No edit Edit iff isatty(0) Specify --edit Edit (ignore isatty(0)) Edit (ignore isatty(0)) Specify --no-edit No edit No edit In order to get the expected behavior, we need to change options.edit to a tri-state: unspecified, false, or true. When specified, we follow what it says. When unspecified, we need to check whether the current commit being created is resolving a conflict as well as consulting options.action and isatty(0). While at it, add a should_edit() utility function that compresses options.edit down to a boolean based on the additional information for the non-conflict case. Make continue_single_pick() (which is the function responsible for resuming after conflict cases) stop assuming edit behavior in all cases, so that it can correctly handle !isatty(0) and specific requests to not edit the commit message. Reported-by: Renato Botelho <[email protected]> Signed-off-by: Elijah Newren <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
Describe Git's security policy On GitHub, SECURITY.md files are the recommended way to describe how to report vulnerabilities, and to set expectations how far back maintenance tracks are updated with security bug fixes. For example, when navigating to https://github.com/git/git/security/ users would be guided to that SECURITY.md file. If it exists. The purpose of this patch series is to add this file, describing Git's security policy. While at it, I also want to document the process how to coordinate the ensuing embargoed releases. This is what the second patch is all about. The reason for that is quite selfish, as I did two of them, and while I am happy that such embargoed releases do not happen all that often, the downside is that I keep forgetting all the details. So this document is not only meant for knowledge sharing, but in particular to help me the next time(s) I coordinate an embargoed release. Many thanks to Junio who reviewed the first draft of this patch series (where I had not yet separated out Documentation/howto/coordinate-embargoed-releases.txt). Johannes Schindelin (2): SECURITY: describe how to report vulnerabilities Document how we do embargoed releases Documentation/Makefile | 1 + .../howto/coordinate-embargoed-releases.txt | 131 ++++++++++++++++++ SECURITY.md | 51 +++++++ 3 files changed, 183 insertions(+) create mode 100644 Documentation/howto/coordinate-embargoed-releases.txt create mode 100644 SECURITY.md base-commit: e636282 Submitted-As: https://lore.kernel.org/git/[email protected]
Convert index writes to use hashfile API As I prepare some ideas on index v5, one thing that strikes me as an interesting direction to try is to use the chunk-format API. This would make our extension model extremely simple (they become optional chunks, easily identified by the table of contents). But there is a huge hurdle to even starting that investigation: the index uses its own hashing methods, separate from the hashfile API in csum-file.c! The internals of the algorithms are mostly identical. The only possible change is that the buffer sizes are different: 8KB for hashfile and 128KB in read-cache.c. I was unable to find a performance difference in these two implementations, despite testing on several repo sizes. There is a subtle point about how the EOIE extension works in that it needs a hash of just the previous extension data. This is solved by adding a new "nested hashfile" mechanism that computes the hash at one level and then passes the data below to another hashfile. (The good news is that this extension will not need to exist at all if we use the chunk-format API to manage extensions.) Thanks, -Stolee Derrick Stolee (3): csum-file: add nested_hashfile() read-cache: use hashfile instead of git_hash_ctx read-cache: delete unused hashing methods csum-file.c | 22 +++++++ csum-file.h | 9 +++ read-cache.c | 182 ++++++++++++++++----------------------------------- 3 files changed, 89 insertions(+), 124 deletions(-) base-commit: 1424303 Submitted-As: https://lore.kernel.org/git/[email protected]
cache-tree.c: remove implicit dependency on the_repository From: Chinmoy Chakraborty <[email protected]> This kills the_repository dependency in cache_tree_update(), but for unpack_trees(), they still assume the_repository (which also means the_index). Unfortunately the widespread use of unpack_trees() will make it hard to make the conversion now. The `update_main_cache_tree()` method uses `cache_tree_update(r, r->index, flags)`. `r->index` is easily deduced from `r` but the signature of `cache_tree_update()` is not changed to take `struct repository *` instead of `struct index_state *` because there can be temporary indexes. Therefore, one might want to update the cache tree for an index other than `r->index`. This commit also fixes the `sparse-index.c` file in which the `convert_to_sparse()` and `ensure_full_index()` method use `cache_tree_update()`. Signed-off-by: Chinmoy Chakraborty <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
csum-file: make hashwrite() more readable From: Derrick Stolee <[email protected]> The hashwrite() method takes an input buffer and updates a hashfile's hash function while writing the data to a file. To avoid overuse of flushes, the hashfile has an internal buffer and most writes will use memcpy() to transfer data from the input 'buf' to the hashfile's buffer of size 8 * 1024 bytes. Logic introduced by a8032d1 (sha1write: don't copy full sized buffers, 2008-09-02) reduces the number of memcpy() calls when the input buffer is sufficiently longer than the hashfile's buffer, causing nr to be the length of the full buffer. In these cases, the input buffer is used directly in chunks equal to the hashfile's buffer size. This method caught my attention while investigating some performance issues, but it turns out that these performance issues were noise within the variance of the experiment. However, during this investigation, I inspected hashwrite() and misunderstood it, even after looking closely and trying to make it faster. This change simply reorganizes some parts of the loop within hashwrite() to make it clear that each batch either uses memcpy() to the hashfile's buffer or writes directly from the input buffer. The previous code relied on indirection through local variables and essentially inlined the implementation of hashflush() to reduce lines of code. Helped-by: Jeff King <[email protected]> Helped-by: Junio C Hamano <[email protected]> Signed-off-by: Derrick Stolee <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
[GSOC]trailer: pass arg as positional parameter From: ZheNing Hu <[email protected]> The `trailer.<token>.command` configuration variable specifies a command (run via the shell, so it does not have to be a single name of or path to the command, but can be a shell script), and the first occurrence of substring $ARG is replaced with the value given to the `interpret-trailer` command for the token. This has two downsides: * The use of $ARG in the mechanism misleads the users that the value is passed in the shell variable, and tempt them to use $ARG more than once, but that would not work, as the second and subsequent $ARG are not replaced. * Because $ARG is textually replaced without regard to the shell language syntax, even '$ARG' (inside a single-quote pair), which a user would expect to stay intact, would be replaced, and worse, if the value had an unmatching single quote (imagine a name like "O'Connor", substituted into NAME='$ARG' to make it NAME='O'Connor), it would result in a broken command that is not syntactically correct (or worse). Introduce a new `trailer.<token>.cmd` configuration that takes higher precedence to deprecate and eventually remove `trailer.<token>.command`, which passes the value as a parameter to the command. Instead of "$ARG", the users will refer to the value as positional argument, $1, in their scripts. Helped-by: Junio C Hamano <[email protected]> Signed-off-by: ZheNing Hu <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
hooks: propose project configured hooks From: Albert Cui <[email protected]> Hooks today are configured at the repository level, making it difficult to share hooks across repositories. Configuration-based hook management, by moving hooks configuration to the config, makes this much easier. However, there is still no good way for project maintainers to encourage or enforce adoption of specific hook commands on specific hook events in a repository. As such, there are many tools that provide this functionality on top of Git. This patch documents the requirements we propose for this feature as well as a design sketch for implementation. Signed-off-by: Albert Cui <[email protected]> Helped-by: Emily Shaffer <[email protected]> Change-Id: I5f6747524b97c51dfe5fa28e48ea03981b2da5b8 Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
cache-tree.c: remove implicit dependency on the_repository From: Chinmoy Chakraborty <[email protected]> This kills the_repository dependency in cache_tree_update(), but for unpack_trees(), they still assume the_repository (which also means the_index). Unfortunately the widespread use of unpack_trees() will make it hard to make the conversion now. The `update_main_cache_tree()` method uses `cache_tree_update(r, r->index, flags)`. `r->index` is easily deduced from `r` but the signature of `cache_tree_update()` is not changed to take `struct repository *` instead of `struct index_state *` because there can be temporary indexes. Therefore, one might want to update the cache tree for an index other than `r->index`. Signed-off-by: Chinmoy Chakraborty <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
PreviousNext