Skip to content
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: msysgit/git
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: master
Choose a base ref
...
head repository: dscho/git
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: main
Choose a head ref
Can’t automatically merge. Don’t worry, you can still create the pull request.

Commits on Mar 21, 2024

  1. The tenth batch

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Mar 21, 2024
    Copy the full SHA
    11c821f View commit details
  2. config: minor addition of whitespace

    In general, binary operators should be enclosed in a pair of leading and
    trailing space (SP) characters.  Thus, clean up one spotted expression that
    for some reason had a "bunched up" operator.
    
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Dragan Simic authored and gitster committed Mar 21, 2024

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    0d49b1e View commit details
  3. config: really keep value-internal whitespace verbatim

    Fix a bug in function parse_value() that prevented whitespace characters
    (i.e. spaces and horizontal tabs) found inside configuration option values
    from being parsed and returned in their original form.  The bug caused any
    number of consecutive whitespace characters to be wrongly "squashed" into
    the same number of space characters.
    
    This bug was introduced back in July 2009, in commit ebdaae3 ("config:
    Keep inner whitespace verbatim").
    
    Further investigation showed that setting a configuration value, by invoking
    git-config(1), converts value-internal horizontal tabs into "\t" escape
    sequences, which the buggy value-parsing logic in function parse_value()
    didn't "squash" into spaces.  That's why the test included in the ebdaae3
    commit passed, which presumably made the bug remain undetected for this long.
    On the other hand, value-internal literal horizontal tab characters, found in
    a configuration file edited by hand, do get "squashed" by the value-parsing
    logic, so the right choice was to fix this bug by making the value-internal
    whitespace characters preserved verbatim.
    
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Dragan Simic authored and gitster committed Mar 21, 2024

    Verified

    This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
    Copy the full SHA
    f0b8944 View commit details
  4. t1300: add more tests for whitespace and inline comments

    Add a handful of additional tests, to improve the coverage of the handling
    of configuration file entries whose values contain internal whitespace,
    leading and/or trailing whitespace, which may or may not be enclosed within
    quotation marks, or which contain an additional inline comment.
    
    At the same time, rework one already existing whitespace-related test a bit,
    to ensure its consistency with the newly added tests.  This change introduced
    no functional changes to the already existing test.
    
    Helped-by: Eric Sunshine <sunshine@sunshineco.com>
    Helped-by: Junio C Hamano <gitster@pobox.com>
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Dragan Simic authored and gitster committed Mar 21, 2024
    Copy the full SHA
    d71bc1b View commit details
  5. config.txt: describe handling of whitespace further

    Make it more clear what the whitespace characters are in the context of git
    configuration files, and significantly improve the description of the leading
    and trailing whitespace handling, especially how it works out together with
    the presence of inline comments.
    
    Helped-by: Junio C Hamano <gitster@pobox.com>
    Helped-by: Eric Sunshine <sunshine@sunshineco.com>
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Dragan Simic authored and gitster committed Mar 21, 2024
    Copy the full SHA
    e6895c3 View commit details

Commits on Mar 22, 2024

  1. t7800: improve test descriptions with empty arguments

    Some of the tests in t7800 are executed repeatedly in a loop with
    different arguments. To distinguish these tests, the value of that
    variable is rendered into the test title. But given that one of the
    values is the empty string, it results in a somewhat awkward test name:
    
        difftool  ignores exit code
    
    Improve this by printing "without options" in case the value is empty.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 22, 2024
    Copy the full SHA
    ac45f68 View commit details
  2. t7800: use single quotes for test bodies

    In eb84c8b (git-difftool--helper: honor `--trust-exit-code` with
    `--dir-diff`, 2024-02-20) we have started to loop around some of the
    tests in t7800 so that they are reexecuted with slightly different
    arguments. As part of that refactoring the quoting of test bodies was
    changed from single quotes (') to double quotes (") so that the value of
    the loop variable is accessible to the body.
    
    As the test body is later on passed to eval this change was not required
    though. Let's revert it back to use single quotes as usual in our tests.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 22, 2024
    Copy the full SHA
    c559677 View commit details
  3. t/README: document how to loop around test cases

    In some cases it makes sense to loop around test cases so that we can
    execute the same test with slightly different arguments. There are some
    gotchas around quoting here though that are easy to miss and that may
    lead to easy-to-miss errors and portability issues.
    
    Document the proper way to do this in "t/README".
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 22, 2024
    Copy the full SHA
    7c4449e View commit details
  4. format-patch: fix leak of empty header string

    The log_write_email_headers() function recently learned to return the
    "extra_headers_p" variable to the caller as an allocated string. We
    start by copying rev_info.extra_headers into a strbuf, and then detach
    the strbuf at the end of the function. If there are no extra headers, we
    leave the strbuf empty. Likewise, if there are no headers to return, we
    pass back NULL.
    
    This misses a corner case which can cause a leak. The "do we have any
    headers to copy" check is done by looking for a NULL opt->extra_headers.
    But the "do we have a non-empty string to return" check is done by
    checking the length of the strbuf. That means if opt->extra_headers is
    the empty string, we'll "copy" it into the strbuf, triggering an
    allocation, but then leak the buffer when we return NULL from the
    function.
    
    We can solve this in one of two ways:
    
      1. Rather than checking headers->len at the end, we could check
         headers->alloc to see if we allocated anything. That retains the
         original behavior before the recent change, where an empty
         extra_headers string is "passed through" to the caller. In practice
         this doesn't matter, though (the code which eventually looks at the
         result treats NULL or the empty string the same).
    
      2. Only bother copying a non-empty string into the strbuf. This has
         the added bonus of avoiding a pointless allocation.
    
         Arguably strbuf_addstr() could do this optimization itself, though
         it may be slightly dangerous to do so (some existing callers may
         not get a fresh allocation when they expect to). In theory callers
         are all supposed to use strbuf_detach() in such a case, but there's
         no guarantee that this is the case.
    
    This patch uses option 2. Without it, building with SANITIZE=leak shows
    many errors in t4021 and elsewhere.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    peff authored and gitster committed Mar 22, 2024
    Copy the full SHA
    1c10b8e View commit details
  5. rebase: use child_process_clear() to clean

    In the run_am() function, we set up a child_process struct to run
    "git-am", allocating memory for its args and env strvecs. These are
    normally cleaned up when we call run_command(). But if we encounter
    certain errors, we exit the function early and try to clean up ourselves
    by clearing the am.args field. This leaks the "env" strvec.
    
    We should use child_process_clear() instead, which covers both. And more
    importantly, it future proofs us against the struct ever growing more
    allocated fields.
    
    These are unlikely errors to happen in practice, so they don't actually
    trigger the leak sanitizer in the tests. But we can add a new test which
    does exercise one of the paths (and fails SANITIZE=leak without this
    patch).
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    peff authored and gitster committed Mar 22, 2024
    Copy the full SHA
    647e870 View commit details

Commits on Mar 23, 2024

  1. editorconfig: add Makefiles to "text files"

    The Makefile and makefile fragments use the same indent style than the
    rest of the code (with some inconsistencies).
    
    Add them to the relevant .editorconfig section to make life easier for
    editors and reviewers.
    
    Signed-off-by: Max Gautier <mg@max.gautier.name>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    VannTen authored and gitster committed Mar 23, 2024
    Copy the full SHA
    b45602e View commit details

Commits on Mar 25, 2024

  1. reftable/stack: fix error handling in reftable_stack_init_addition()

    In `reftable_stack_init_addition()` we call `stack_uptodate()` after
    having created the lockfile to check whether the stack was modified
    concurrently, which is indicated by a positive return code from the
    latter function. If so, we return a `REFTABLE_LOCK_ERROR` to the caller
    and abort the addition.
    
    The error handling has an off-by-one though because we check whether the
    error code is `> 1` instead of `> 0`. Thus, instead of returning the
    locking error, we would return a positive value. One of the callers of
    `reftable_stack_init_addition()` works around this bug by repeating the
    error code check without the off-by-one. But other callers are subtly
    broken by this bug.
    
    Fix this by checking for `err > 0` instead. This has the consequence
    that `reftable_stack_init_addition()` won't ever return a positive error
    code anymore, but will instead return `REFTABLE_LOCK_ERROR` now. Thus,
    we can drop the check for a positive error code in `stack_try_add()`
    now.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    630942a View commit details
  2. reftable/error: discern locked/outdated errors

    We currently throw two different errors into a similar-but-different
    error code:
    
      - Errors when trying to lock the reftable stack.
    
      - Errors when trying to write to the reftable stack which has been
        modified concurrently.
    
    This results in unclear error handling and user-visible error messages.
    
    Create a new `REFTABLE_OUTDATED_ERROR` so that those error conditions
    can be clearly told apart from each other. Adjust users of the old
    `REFTABLE_LOCK_ERROR` to use the new error code as required.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    af18098 View commit details
  3. reftable/stack: use error codes when locking fails during compaction

    Compaction of a reftable stack may fail gracefully when there is a
    concurrent process that writes to the reftable stack and which has thus
    locked either the "tables.list" file or one of the tables. This is
    expected and can be handled gracefully by some of the callers which
    invoke compaction. Thus, to indicate this situation to our callers, we
    return a positive return code from `stack_compact_range()` and bubble it
    up to the caller.
    
    This kind of error handling is somewhat awkward though as many callers
    in the call chain never even think of handling positive return values.
    Thus, the result is either that such errors are swallowed by accident,
    or that we abort operations with an unhelpful error message.
    
    Make the code more robust by always using negative error codes when
    compaction fails, with `REFTABLE_LOCK_ERROR` for the described benign
    error case.
    
    Note that only a single callsite knew to handle positive error codes
    gracefully in the first place. Subsequent commits will touch up some of
    the other sites to handle those errors better.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    3335835 View commit details
  4. reftable/stack: gracefully handle failed auto-compaction due to locks

    Whenever we commit a new table to the reftable stack we will end up
    invoking auto-compaction of the stack to keep the total number of tables
    at bay. This auto-compaction may fail though in case at least one of the
    tables which we are about to compact is locked. This is indicated by the
    compaction function returning `REFTABLE_LOCK_ERROR`. We do not handle
    this case though, and thus bubble that return value up the calling
    chain, which will ultimately cause a failure.
    
    Fix this bug by ignoring `REFTABLE_LOCK_ERROR`.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    a2f711a View commit details
  5. refs/reftable: print errors on compaction failure

    When git-pack-refs(1) fails in the reftable backend we end up printing
    no error message at all, leaving the caller puzzled as to why compaction
    has failed. Fix this.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    4ccf706 View commit details
  6. t/helper: drop pack-refs wrapper

    The test helper provides a "ref-store <store> pack-refs" wrapper that
    more or less directly invokes `refs_pack_refs()`. This helper is only
    used in a single test with the "PACK_REFS_PRUNE" and "PACK_REFS_ALL"
    flags. Both of these flags can directly be accessed via git-pack-refs(1)
    though via the `--all` and `--prune` flags, which makes the helper
    superfluous.
    
    Refactor the test to use git-pack-refs(1) instead of the test helper.
    Drop the now-unused test helper command.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    ed12124 View commit details
  7. refs: move struct pack_refs_opts to where it's used

    The declaration of `struct pack_refs_opts` is in a seemingly random
    place. Move it so that it's located right next to its flags and
    functions that use it.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    0f65c7a View commit details
  8. refs: remove PACK_REFS_ALL flag

    The intent of the `PACK_REFS_ALL` flag is to ask the backend to compact
    all refs instead of only a subset of them. Thus, this flag gets passed
    down to `refs_pack_refs()` via `struct pack_refs_opts::flags`.
    
    But starting with 4fe42f3 (pack-refs: teach pack-refs --include
    option, 2023-05-12), the flag's semantics have changed. Instead of being
    handled by the respective backends, this flag is now getting handled by
    the callers of `refs_pack_refs()` which will add a single glob ("*") to
    the list of refs-to-be-packed. Thus, the flag serves no purpose to the
    ref backends anymore.
    
    Remove the flag and replace it with a local variable.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    35aeabd View commit details
  9. refs/reftable: expose auto compaction via new flag

    Under normal circumstances, the "reftable" backend will automatically
    perform compaction after appending to the stack. It is thus not
    necessary and may even be considered wasteful to run git-pack-refs(1) in
    "reftable"-backed repositories as it will cause the backend to compact
    all tables into a single one. We do exactly that though when running
    `git maintenance run --auto` or `git gc --auto`, which gets spawned by
    Git after running some specific commands.
    
    The `--auto` mode is typically only executing optimizations as needed.
    To do so, we already use several heuristics for the various different
    data structures in Git to determine whether to optimize them or not.
    We do not use any heuristics for refs though and instead always optimize
    them.
    
    Introduce a new `PACK_REFS_AUTO` flag that can be passed to the backend.
    When not handled by the backend we will continue to behave the exact
    same as we do right now, that is we optimize refs unconditionally. This
    is done for the "files" backend for now to retain current behaviour,
    even though we may eventually also want to introduce heuristics here.
    For the "reftable" backend though we already do have auto-compaction, so
    we can easily reuse that logic to implement the new auto-packing flag.
    
    Note that under normal circumstances, this should always end up being a
    no-op. After all, we already invoke the code for every single addition
    to the stack. But there are special cases where it can still be helpful
    to execute the auto-compaction code explicitly:
    
      - Concurrent writers may cause compaction to not run due to locks.
    
      - Callers may decide to disable compaction altogether and then pack
        refs at a later point due to various reasons.
    
      - Other implementations of the reftable format may do compaction
        differently or even not at all.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    f89356d View commit details
  10. builtin/pack-refs: release allocated memory

    Some of the command line options in `cmd_pack_refs()` require us to
    allocate memory. This memory is never released and thus leaking, but we
    paper over this leak by declaring the respective variables as `static`
    function-level variables, which is somewhat awkward.
    
    Refactor the code to release the allocated memory and drop the `static`
    declaration. While at it, remove the useless `flags` variable.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    a75dc71 View commit details
  11. builtin/pack-refs: introduce new "--auto" flag

    Calling git-pack-refs(1) will unconditionally cause it to pack all
    requested refs regardless of the current state of the ref database. For
    example:
    
      - With the "files" backend we will end up rewriting the complete
        "packed-refs" file even if only a single ref would require
        compaction.
    
      - With the "reftable" backend we will end up always compacting all
        tables into a single table.
    
    This behaviour can be completely unnecessary depending on the backend
    and is thus wasteful.
    
    With the introduction of the `PACK_REFS_AUTO` flag in the preceding
    commit we can improve this and let the backends decide for themselves
    whether to pack refs in the first place. Expose this functionality via a
    new "--auto" flag in git-pack-refs(1), which mirrors the same flag in
    both git-gc(1) and git-maintenance(1).
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    6dcffc6 View commit details
  12. builtin/gc: move struct maintenance_run_opts

    We're about to start using `struct maintenance_run_opts` in
    `maintenance_task_pack_refs()`. Move its definition up to prepare for
    this.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    0e05d53 View commit details
  13. t6500: extract objects with "17" prefix

    The ".git/obects/17/" shard is somewhat special because it is used by
    git-gc(1) to estimate how many objects there are by extrapolating the
    number of objects in that shard, only. In t6500 we thus have a hard
    coded set of data that, when written to the object database, result in
    blobs starting with that prefix.
    
    We are about to need such "17"-prefixed objects in another test suite.
    Extract them into "t/oid-info/hash-info" so that they can be reused by
    other tests.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    77257e3 View commit details
  14. builtin/gc: forward git-gc(1)'s --auto flag when packing refs

    Forward the `--auto` flag to git-pack-refs(1) when it has been invoked
    with this flag itself. This does not change anything for the "files"
    backend, which will continue to eagerly pack refs. But it does ensure
    that the "reftable" backend only compacts refs as required.
    
    This change does not impact git-maintenance(1) because this command will
    in fact never run the pack-refs task when run with `--auto`. This issue
    will be addressed in a subsequent commit.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    bfc2f9e View commit details
  15. builtin/gc: pack refs when using git maintenance run --auto

    When running `git maintenance run --auto`, then the various subtasks
    will only run as needed. Thus, we for example end up only packing loose
    objects if we hit a certain threshold.
    
    Interestingly enough, the "pack-refs" task is actually _never_ executed
    when the auto-flag is set because it does not have a condition at all.
    As 41abfe1 (maintenance: add pack-refs task, 2021-02-09) mentions:
    
        The 'auto_condition' function pointer is left NULL for now. We could
        extend this in the future to have a condition check if pack-refs
        should be run during 'git maintenance run --auto'.
    
    It is not quite clear from that quote whether it is actually intended
    that the task doesn't run at all in this mode. Also, no test was added
    to verify this behaviour. Ultimately though, it feels quite surprising
    that `git maintenance run --auto --task=pack-refs` would quietly never
    do anything at all.
    
    In any case, now that we do have the logic in place to let ref backends
    decide whether or not to repack refs, it does make sense to wire it up
    accordingly. With the "reftable" backend we will thus now perform
    auto-compaction, which optimizes the refdb as needed.
    
    But for the "files" backend we now unconditionally pack refs as it does
    not yet know to handle the "auto" flag. Arguably, this can be seen as a
    bug fix given that previously the task never did anything at all.
    Eventually though we should amend the "files" backend to use some
    heuristics for auto compaction, as well.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pks-t authored and gitster committed Mar 25, 2024
    Copy the full SHA
    9f6714a View commit details
  16. grep: improve errors for unmatched ( and )

    Imagine you want to grep for (. Easy:
    
      $ git grep '('
      fatal: unmatched parenthesis
    
    uhoh. This is plainly wrong. Unless you know specifically that
    
     (a) git grep has expression groups and '(' ... ')' are used for them.
     (b) you can use -e '(' to explicitly say '(' is what you are looking
         for, not the beginning of a group.
    
    Similarly,
    
      $ git grep ')'
      fatal: incomplete pattern expression: )
    
    is somehow worse. ")" is a complete regular expression pattern.
    Of course, the error wants to say "group" here.
    In this case it is also not "incomplete", it is unmatched.
    
    Make them say
    
      $ ./git grep '('
      fatal: unmatched ( for expression group
      $ ./git grep ')'
      fatal: incomplete pattern expression group: )
    
    which are clearer in indicating that it is not the expression that
    is wrong (since no pattern had been parsed at all), but rather that
    it is been misconstrued as a grouping operator.
    
    Link: https://bugs.debian.org/1051205
    Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    nabijaczleweli authored and gitster committed Mar 25, 2024
    Copy the full SHA
    0d52784 View commit details
  17. factor out strbuf_expand_bad_format()

    Extract a function for reporting placeholders that are not enclosed in a
    parenthesis or are unknown.  This reduces the number of strings to
    translate and improves consistency across commands.  Call it at the end
    of the if/else chain, after exhausting all accepted possibilities.
    
    Signed-off-by: René Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    rscharfe authored and gitster committed Mar 25, 2024
    Copy the full SHA
    e36091a View commit details
  18. cat-file: use strbuf_expand_bad_format()

    Report unknown format elements and missing closing parentheses with
    consistent and translated messages by calling strbuf_expand_bad_format()
    at the very end of the combined if/else chain of expand_format() and
    expand_atom().
    
    Signed-off-by: René Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    rscharfe authored and gitster committed Mar 25, 2024
    Copy the full SHA
    7c43bdf View commit details
  19. t/README: mention test files are make targets

    Since 23fc63b (make tests ignorable with "make -i", 2005-11-08), each
    test file defines a target in the test Makefile, such that one can
    invoke:
    
    	make *checkout*
    
    to run all tests with 'checkout' in their filename. This is useful to
    run a subset of tests when you have a good idea of what part of the code
    is touched by the changes your are testing.
    
    Document that in t/README to help new (or more seasoned) contributors
    that might not be aware.
    
    Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    phil-blain authored and gitster committed Mar 25, 2024
    Copy the full SHA
    8d38380 View commit details
  20. midx: use strvec_pushf() for pack-objects base name

    Build the pack base name argument directly using strvec_pushf() instead
    of with an intermediate strbuf.  This is shorter, simpler and avoids the
    need for explicit cleanup.
    
    Signed-off-by: René Scharfe <l.s.r@web.de>
    Reviewed-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    rscharfe authored and gitster committed Mar 25, 2024
    Copy the full SHA
    4d45e79 View commit details
  21. pretty: update tests to use test_config

    These tests use raw `git config` calls, which is an older style that can
    cause config to bleed between tests if not manually unset. `test_config`
    ensures that config is unset at the end of each test automatically.
    
    `test_config` is chosen over `git -c` since `test_config` still ends up
    calling `git config` which seems slightly more realistic to how pretty
    formats would be defined normally.
    
    Suggested-by: Jeff King <peff@peff.net>
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    2cd134f View commit details
  22. pretty: find pretty formats case-insensitively

    User-defined pretty formats are stored in config, which is meant to use
    case-insensitive matching for names as noted in config.txt's 'Syntax'
    section:
    
        All the other lines [...] are recognized as setting variables, in
        the form 'name = value' [...]. The variable names are
        case-insensitive, [...].
    
    When a user specifies one of their format aliases with an uppercase in
    it, however, it is not found.
    
        $ git config pretty.testAlias %h
        $ git config --list | grep pretty
        pretty.testalias=%h
        $ git log --format=testAlias -1
        fatal: invalid --pretty format: testAlias
        $ git log --format=testalias -1
        3c2a3fd
    
    This is true whether the name in the config file uses any uppercase
    characters or not.
    
    Use case-insensitive comparisons when identifying format aliases.
    
    Co-authored-by: Jeff King <peff@peff.net>
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    2 people authored and gitster committed Mar 25, 2024
    Copy the full SHA
    f999d51 View commit details
  23. grep docs: describe --recurse-submodules further and improve formatti…

    …ng a bit
    
    Clarify that --recurse-submodules cannot be used together with --untracked,
    and improve the formatting in a couple of places, to make it visually clear
    that those are the commands or the names of configuration options.
    
    While there, change a couple of "<tree>" placeholders to "_<tree>_", to help
    with an ongoing translation improvement effort. [1]
    
    [1] https://lore.kernel.org/git/CAPig+cQc8W4JOpB+TMP=czketU1U7wcY_x9bsP5T=3-XjGLhRQ@mail.gmail.com/
    
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Dragan Simic authored and gitster committed Mar 25, 2024
    Copy the full SHA
    4a9357a View commit details
  24. grep docs: describe --no-index further and improve formatting a bit

    Improve the description of --no-index, to make it more clear to the users
    what this option actually does under the hood, and what's its purpose.
    Describe the dependency between --no-index and either of the --cached and
    --untracked options, which cannot be used together.
    
    As part of that, shuffle a couple of the options, to make the documentation
    flow a bit better, because it makes more sense to describe first the options
    that have something in common, and to after that describe an option that does
    something differently.  In more detail, --cached and --untracked both leave
    git-grep(1) in the usual state, in which it treats the directory as a local
    git repository, unlike --no-index that makes git-grep(1) treat the directory
    not as a git repository.
    
    While there, improve the descriptions of grep worker threads a bit, to give
    them better context.  Adjust the language a bit, to avoid addressing the
    reader directly, which is in general preferred in technical documentation,
    because it eliminates the possible element of persuading the user to do
    something.  In other words, we should be telling the user what our software
    can do, instead of telling the user what to do.
    
    Also perform some minor formatting improvements, to make it clear it's the
    git commands, command parameters, and configuration option names.
    
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Dragan Simic authored and gitster committed Mar 25, 2024
    Copy the full SHA
    6e9ef29 View commit details
  25. Merge branch 'rj/restore-plug-leaks'

    Leaks from "git restore" have been plugged.
    
    * rj/restore-plug-leaks:
      checkout: plug some leaks in git-restore
    gitster committed Mar 25, 2024
    Copy the full SHA
    199074f View commit details
  26. Merge branch 'js/bugreport-no-suffix-fix'

    "git bugreport --no-suffix" was not supported and instead
    segfaulted, which has been corrected.
    
    * js/bugreport-no-suffix-fix:
      bugreport.c: fix a crash in `git bugreport` with `--no-suffix` option
    gitster committed Mar 25, 2024
    Copy the full SHA
    d921c36 View commit details
  27. Merge branch 'jc/index-pack-fsck-levels'

    Test fix.
    
    * jc/index-pack-fsck-levels:
      t5300: fix test_with_bad_commit()
    gitster committed Mar 25, 2024
    Copy the full SHA
    46d8bf3 View commit details
  28. Merge branch 'bb/sh-scripts-cleanup'

    Shell scripts clean-up.
    
    * bb/sh-scripts-cleanup: (22 commits)
      git-quiltimport: avoid an unnecessary subshell
      contrib/coverage-diff: avoid redundant pipelines
      t/t9*: merge "grep | sed" pipelines
      t/t8*: merge "grep | sed" pipelines
      t/t5*: merge a "grep | sed" pipeline
      t/t4*: merge a "grep | sed" pipeline
      t/t3*: merge a "grep | awk" pipeline
      t/t1*: merge a "grep | sed" pipeline
      t/t9*: avoid redundant uses of cat
      t/t8*: avoid redundant use of cat
      t/t7*: avoid redundant use of cat
      t/t6*: avoid redundant uses of cat
      t/t5*: avoid redundant uses of cat
      t/t4*: avoid redundant uses of cat
      t/t3*: avoid redundant uses of cat
      t/t1*: avoid redundant uses of cat
      t/t0*: avoid redundant uses of cat
      t/perf: avoid redundant use of cat
      t/annotate-tests.sh: avoid redundant use of cat
      t/lib-cvs.sh: avoid redundant use of cat
      ...
    gitster committed Mar 25, 2024
    Copy the full SHA
    a7f0fcb View commit details
  29. Merge branch 'ja/doc-formatting-fix'

    Documentation mark-up fix.
    
    * ja/doc-formatting-fix:
      doc: fix some placeholders formating
      doc: format alternatives in synopsis
    gitster committed Mar 25, 2024
    Copy the full SHA
    0cb25d1 View commit details
  30. Merge branch 'bl/doc-config-fixes'

    A few typoes in "git config --help" have been corrected.
    
    * bl/doc-config-fixes:
      docs: fix typo in git-config `--default`
      docs: clarify file options in git-config `--edit`
    gitster committed Mar 25, 2024
    Copy the full SHA
    b58cc6a View commit details
  31. Merge branch 'bl/doc-key-val-sep-fix'

    The documentation for "%(trailers[:options])" placeholder in the
    "--pretty" option of commands in the "git log" family has been
    updated.
    
    * bl/doc-key-val-sep-fix:
      docs: adjust trailer `separator` and `key_value_separator` language
      docs: correct trailer `key_value_separator` description
    gitster committed Mar 25, 2024
    Copy the full SHA
    03658df View commit details
  32. The eleventh batch

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Mar 25, 2024
    Copy the full SHA
    c75fd8d View commit details
  33. docs: address inaccurate --empty default with --exec

    The documentation for git-rebase(1) indicates that using the `--exec`
    option will use `--empty=drop`. This is inaccurate: when `--interactive`
    is not explicitly provided, `--exec` results in `--empty=keep`
    behaviors.
    
    Correctly indicate the behavior of `--exec` using `--empty=keep` when
    `--interactive` is not specified.
    
    Reported-by: Phillip Wood <phillip.wood@dunelm.org.uk>
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    0af3889 View commit details
  34. docs: clean up --empty formatting in git-rebase(1) and git-am(1)

    Both of these pages document very similar `--empty` options, but with
    different styles. The exact behavior of these `--empty` options differs
    somewhat, but consistent styling in the docs is still beneficial. This
    commit aims to make them more consistent.
    
    Break the possible values for `--empty` into separate sections for
    readability. Alphabetical order is chosen for consistency.
    
    In a future commit, we'll be documenting a new `--empty` option for
    git-cherry-pick(1), making the consistency even more relevant.
    
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    64a443e View commit details
  35. rebase: update --empty=ask to --empty=stop

    When git-am(1) got its own `--empty` option in 7c096b8 (am: support
    --empty=<option> to handle empty patches, 2021-12-09), `stop` was used
    instead of `ask`. `stop` is a more accurate term for describing what
    really happens, and consistency is good.
    
    Update git-rebase(1) to also use `stop`, while keeping `ask` as a
    deprecated synonym. Update the tests to primarily use `stop`, but also
    ensure that `ask` is still allowed.
    
    In a future commit, we'll be adding a new `--empty` option for
    git-cherry-pick(1) as well, making the consistency even more relevant.
    
    Reported-by: Elijah Newren <newren@gmail.com>
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    c282eba View commit details
  36. sequencer: handle unborn branch with --allow-empty

    When using git-cherry-pick(1) with `--allow-empty` while on an unborn
    branch, an error is thrown. This is inconsistent with the same
    cherry-pick when `--allow-empty` is not specified.
    
    Detect unborn branches in `is_index_unchanged`. When on an unborn
    branch, use the `empty_tree` as the tree to compare against.
    
    Add a new test to cover this scenario. While modelled off of the
    existing 'cherry-pick on unborn branch' test, some improvements can be
    made:
    
    - Use `git switch --orphan unborn` instead of `git checkout --orphan
      unborn` to avoid the need for a separate `rm -rf *` call
    - Avoid using `--quiet` in the `git diff` call to make debugging easier
      in the event of a failure. Use simply `--exit-code` instead.
    
    Make these improvements to the existing test as well as the new test.
    
    Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
    Helped-by: Junio C Hamano <gitster@pobox.com>
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    1b90588 View commit details
  37. sequencer: do not require allow_empty for redundant commit options

    A consumer of the sequencer that wishes to take advantage of either the
    `keep_redundant_commits` or `drop_redundant_commits` feature must also
    specify `allow_empty`. However, these refer to two distinct types of
    empty commits:
    
    - `allow_empty` refers specifically to commits which start empty
    - `keep_redundant_commits` refers specifically to commits that do not
      start empty, but become empty due to the content already existing in
      the target history
    
    Conceptually, there is no reason that the behavior for handling one of
    these should be entangled with the other. It is particularly unintuitive
    to require `allow_empty` in order for `drop_redundant_commits` to have
    an effect: in order to prevent redundant commits automatically,
    initially-empty commits would need to be kept automatically as well.
    
    Instead, rewrite the `allow_empty()` logic to remove the over-arching
    requirement that `allow_empty` be specified in order to reach any of the
    keep/drop behaviors. Only if the commit was originally empty will
    `allow_empty` have an effect.
    
    Note that no behavioral changes should result from this commit -- it
    merely sets the stage for future commits. In one such future commit, an
    `--empty` option will be added to git-cherry-pick(1), meaning that
    `drop_redundant_commits` will be used by that command.
    
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    661b671 View commit details
  38. cherry-pick: enforce --keep-redundant-commits incompatibility

    When `--keep-redundant-commits` was added in  b27cfb0
    (git-cherry-pick: Add keep-redundant-commits option, 2012-04-20), it was
    not marked as incompatible with the various operations needed to
    continue or exit a cherry-pick (`--continue`, `--skip`, `--abort`, and
    `--quit`).
    
    Enforce this incompatibility via `verify_opt_compatible` like we do for
    the other various options.
    
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    bd2f9fd View commit details
  39. cherry-pick: add --empty for more robust redundant commit handling

    As with git-rebase(1) and git-am(1), git-cherry-pick(1) can result in a
    commit being made redundant if the content from the picked commit is
    already present in the target history. However, git-cherry-pick(1) does
    not have the same options available that git-rebase(1) and git-am(1) have.
    
    There are three things that can be done with these redundant commits:
    drop them, keep them, or have the cherry-pick stop and wait for the user
    to take an action. git-rebase(1) has the `--empty` option added in commit
    e98c426 (rebase (interactive-backend): fix handling of commits that
    become empty, 2020-02-15), which handles all three of these scenarios.
    Similarly, git-am(1) got its own `--empty` in 7c096b8 (am: support
    --empty=<option> to handle empty patches, 2021-12-09).
    
    git-cherry-pick(1), on the other hand, only supports two of the three
    possiblities: Keep the redundant commits via `--keep-redundant-commits`,
    or have the cherry-pick fail by not specifying that option. There is no
    way to automatically drop redundant commits.
    
    In order to bring git-cherry-pick(1) more in-line with git-rebase(1) and
    git-am(1), this commit adds an `--empty` option to git-cherry-pick(1). It
    has the same three options (keep, drop, and stop), and largely behaves
    the same. The notable difference is that for git-cherry-pick(1), the
    default will be `stop`, which maintains the current behavior when the
    option is not specified.
    
    Like the existing `--keep-redundant-commits`, `--empty=keep` will imply
    `--allow-empty`.
    
    The `--keep-redundant-commits` option will be documented as a deprecated
    synonym of `--empty=keep`, and will be supported for backwards
    compatibility for the time being.
    
    Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    zivarah authored and gitster committed Mar 25, 2024
    Copy the full SHA
    ec79d76 View commit details
Showing 4,157 changed files with 1,093,966 additions and 251,212 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
22 changes: 22 additions & 0 deletions .cirrus.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
env:
CIRRUS_CLONE_DEPTH: 1

freebsd_task:
env:
GIT_PROVE_OPTS: "--timer --jobs 10"
GIT_TEST_OPTS: "--no-chain-lint --no-bin-wrappers"
MAKEFLAGS: "-j4"
DEFAULT_TEST_TARGET: prove
DEVELOPER: 1
freebsd_instance:
image_family: freebsd-13-4
memory: 2G
install_script:
pkg install -y gettext gmake perl5
create_user_script:
- pw useradd git
- chown -R git:git .
build_script:
- su git -c gmake
test_script:
- su git -c 'gmake DEFAULT_UNIT_TEST_TARGET=unit-tests-prove test unit-tests'
225 changes: 225 additions & 0 deletions .clang-format
Original file line number Diff line number Diff line change
@@ -0,0 +1,225 @@
# This file is an example configuration for clang-format 5.0.
#
# Note that this style definition should only be understood as a hint
# for writing new code. The rules are still work-in-progress and does
# not yet exactly match the style we have in the existing code.

# Use tabs whenever we need to fill whitespace that spans at least from one tab
# stop to the next one.
#
# These settings are mirrored in .editorconfig. Keep them in sync.
UseTab: Always
TabWidth: 8
IndentWidth: 8
ContinuationIndentWidth: 8
ColumnLimit: 80

# C Language specifics
Language: Cpp

# Align parameters on the open bracket
# someLongFunction(argument1,
# argument2);
AlignAfterOpenBracket: Align

# Don't align consecutive assignments
# int aaaa = 12;
# int b = 14;
AlignConsecutiveAssignments: false

# Don't align consecutive declarations
# int aaaa = 12;
# double b = 3.14;
AlignConsecutiveDeclarations: false

# Align consecutive macro definitions.
AlignConsecutiveMacros: true

# Align escaped newlines as far left as possible
# #define A \
# int aaaa; \
# int b; \
# int cccccccc;
AlignEscapedNewlines: Left

# Align operands of binary and ternary expressions
# int aaa = bbbbbbbbbbb +
# cccccc;
AlignOperands: true

# Don't align trailing comments
# int a; // Comment a
# int b = 2; // Comment b
AlignTrailingComments: false

# By default don't allow putting parameters onto the next line
# myFunction(foo, bar, baz);
AllowAllParametersOfDeclarationOnNextLine: false

# Don't allow short braced statements to be on a single line
# if (a) not if (a) return;
# return;
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: false
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false

# By default don't add a line break after the return type of top-level functions
# int foo();
AlwaysBreakAfterReturnType: None

# Pack as many parameters or arguments onto the same line as possible
# int myFunction(int aaaaaaaaaaaa, int bbbbbbbb,
# int cccc);
BinPackArguments: true
BinPackParameters: true

# Add no space around the bit field
# unsigned bf:2;
BitFieldColonSpacing: None

# Attach braces to surrounding context except break before braces on function
# definitions.
# void foo()
# {
# if (true) {
# } else {
# }
# };
BreakBeforeBraces: Linux

# Break after operators
# int value = aaaaaaaaaaaaa +
# bbbbbb -
# ccccccccccc;
BreakBeforeBinaryOperators: None
BreakBeforeTernaryOperators: false

# Don't break string literals
BreakStringLiterals: false

# Use the same indentation level as for the switch statement.
# Switch statement body is always indented one level more than case labels.
IndentCaseLabels: false

# Indents directives before the hash. Each level uses a single space for
# indentation.
# #if FOO
# # include <foo>
# #endif
IndentPPDirectives: AfterHash
PPIndentWidth: 1

# Don't indent a function definition or declaration if it is wrapped after the
# type
IndentWrappedFunctionNames: false

# Align pointer to the right
# int *a;
PointerAlignment: Right

# Don't insert a space after a cast
# x = (int32)y; not x = (int32) y;
SpaceAfterCStyleCast: false

# No space is inserted after the logical not operator
SpaceAfterLogicalNot: false

# Insert spaces before and after assignment operators
# int a = 5; not int a=5;
# a += 42; a+=42;
SpaceBeforeAssignmentOperators: true

# Spaces will be removed before case colon.
# case 1: break; not case 1 : break;
SpaceBeforeCaseColon: false

# Put a space before opening parentheses only after control statement keywords.
# void f() {
# if (true) {
# f();
# }
# }
SpaceBeforeParens: ControlStatements

# Don't insert spaces inside empty '()'
SpaceInEmptyParentheses: false

# No space before first '[' in arrays
# int a[5][5]; not int a [5][5];
SpaceBeforeSquareBrackets: false

# No space will be inserted into {}
# while (true) {} not while (true) { }
SpaceInEmptyBlock: false

# The number of spaces before trailing line comments (// - comments).
# This does not affect trailing block comments (/* - comments).
SpacesBeforeTrailingComments: 1

# Don't insert spaces in casts
# x = (int32) y; not x = ( int32 ) y;
SpacesInCStyleCastParentheses: false

# Don't insert spaces inside container literals
# var arr = [1, 2, 3]; not var arr = [ 1, 2, 3 ];
SpacesInContainerLiterals: false

# Don't insert spaces after '(' or before ')'
# f(arg); not f( arg );
SpacesInParentheses: false

# Don't insert spaces after '[' or before ']'
# int a[5]; not int a[ 5 ];
SpacesInSquareBrackets: false

# Insert a space after '{' and before '}' in struct initializers
Cpp11BracedListStyle: false

# A list of macros that should be interpreted as foreach loops instead of as
# function calls. Taken from:
# git grep -h '^#define [^[:space:]]*for_\?each[^[:space:]]*(' |
# sed "s/^#define / - '/; s/(.*$/'/" | sort | uniq
ForEachMacros:
- 'for_each_builtin'
- 'for_each_string_list_item'
- 'for_each_ut'
- 'for_each_wanted_builtin'
- 'hashmap_for_each_entry'
- 'hashmap_for_each_entry_from'
- 'kh_foreach'
- 'kh_foreach_value'
- 'list_for_each'
- 'list_for_each_dir'
- 'list_for_each_prev'
- 'list_for_each_prev_safe'
- 'list_for_each_safe'
- 'strintmap_for_each_entry'
- 'strmap_for_each_entry'
- 'strset_for_each_entry'

# A list of macros that should be interpreted as conditionals instead of as
# function calls.
IfMacros:
- 'if_test'

# The maximum number of consecutive empty lines to keep.
MaxEmptyLinesToKeep: 1

# No empty line at the start of a block.
KeepEmptyLinesAtTheStartOfBlocks: false

# Penalties
# This decides what order things should be done if a line is too long
PenaltyBreakAssignment: 5
PenaltyBreakBeforeFirstCallParameter: 5
PenaltyBreakComment: 5
PenaltyBreakFirstLessLess: 0
PenaltyBreakOpenParenthesis: 300
PenaltyBreakString: 5
PenaltyExcessCharacter: 10
PenaltyReturnTypeOnItsOwnLine: 300

# Don't sort #include's
SortIncludes: false
16 changes: 16 additions & 0 deletions .editorconfig
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
[*]
charset = utf-8
insert_final_newline = true

# The settings for C (*.c and *.h) files are mirrored in .clang-format. Keep
# them in sync.
[{*.{c,h,sh,perl,pl,pm,txt},config.mak.*,Makefile}]
indent_style = tab
tab_width = 8

[*.py]
indent_style = space
indent_size = 4

[COMMIT_EDITMSG]
max_line_length = 72
20 changes: 18 additions & 2 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -1,3 +1,19 @@
* whitespace=!indent,trail,space
*.[ch] whitespace=indent,trail,space
*.sh whitespace=indent,trail,space
*.[ch] whitespace=indent,trail,space diff=cpp
*.sh whitespace=indent,trail,space text eol=lf
*.perl text eol=lf diff=perl
*.pl text eof=lf diff=perl
*.pm text eol=lf diff=perl
*.py text eol=lf diff=python
*.bat text eol=crlf
*.png binary
CODE_OF_CONDUCT.md -whitespace
/Documentation/**/*.txt text eol=lf
/command-list.txt text eol=lf
/GIT-VERSION-GEN text eol=lf
/mergetools/* text eol=lf
/t/oid-info/* text eol=lf
/Documentation/git-merge.txt conflict-marker-size=32
/Documentation/gitk.txt conflict-marker-size=32
/Documentation/user-manual.txt conflict-marker-size=32
/t/t????-*.sh conflict-marker-size=32
22 changes: 22 additions & 0 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
## Contributing to Git

Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code
reviews, and bug reports.

Nevertheless, you can use [GitGitGadget](https://gitgitgadget.github.io/) to
conveniently send your Pull Requests commits to our mailing list.

Please read ["A note from the maintainer"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)
to learn how the Git project is managed, and how you can work with it.
In addition, we highly recommend you to read [our submission guidelines](../Documentation/SubmittingPatches).

If you prefer video, then [this talk](https://www.youtube.com/watch?v=Q7i_qQW__q4&feature=youtu.be&t=6m4s)
might be useful to you as the presenter walks you through the contribution
process by example.

Or, you can follow the ["My First Contribution"](https://git-scm.com/docs/MyFirstContribution)
tutorial for another example of the contribution process.

Your friendly Git community!
64 changes: 64 additions & 0 deletions .github/ISSUE_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
- [ ] I was not able to find an [open](https://github.com/git-for-windows/git/issues?q=is%3Aopen) or [closed](https://github.com/git-for-windows/git/issues?q=is%3Aclosed) issue matching what I'm seeing

### Setup

- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

```
$ git --version --build-options
** insert your machine's response here **
```

- Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

```
$ cmd.exe /c ver
** insert your machine's response here **
```

- What options did you set as part of the installation? Or did you choose the
defaults?

```
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
** insert your machine's response here **
```

- Any other interesting things about your environment that might be related
to the issue you're seeing?

** insert your response here **

### Details

- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

** insert your response here **

- What commands did you run to trigger this issue? If you can provide a
[Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve)
this will help us understand the issue.

```
** insert your commands here **
```
- What did you expect to occur after running these commands?

** insert here **

- What actually happened instead?

** insert here **

- If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?

** insert URL here **
22 changes: 22 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
Thanks for taking the time to contribute to Git!

Those seeking to contribute to the Git for Windows fork should see
http://gitforwindows.org/#contribute on how to contribute Windows specific
enhancements.

If your contribution is for the core Git functions and documentation
please be aware that the Git community does not use the github.com issues
or pull request mechanism for their contributions.

Instead, we use the Git mailing list (git@vger.kernel.org) for code and
documentation submissions, code reviews, and bug reports. The
mailing list is plain text only (anything with HTML is sent directly
to the spam folder).

Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.

For a single-commit pull request, please *leave the pull request description
empty*: your commit message itself should describe your changes.

Please read the "guidelines for contributing" linked above!
Loading