Re: [PATCH 2/2] refs_resolve_ref_unsafe: handle d/f conflicts for writes

On 10/06/2017 07:16 PM, Jeff King wrote: > On Fri, Oct 06, 2017 at 07:09:10PM +0200, Michael Haggerty wrote: > >> I do have one twinge of uneasiness at a deeper level, that I haven't had >> time to check... >> >> Does this patch make it easier to *set* HEAD to an unborn branch that >> d/f

Re: [PATCH 2/2] tests: fix diff order arguments in test_cmp

Stefan Beller writes: > diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh > index ec5f530102..42f584f8b3 100755 > --- a/t/t4205-log-pretty-formats.sh > +++ b/t/t4205-log-pretty-formats.sh > @@ -590,7 +590,7 @@ test_expect_success '%(trailers:unfold)

Re: [PATCH 1/2] tests: use shell negation instead of test_must_fail for test_cmp

Jeff King writes: > Hmph. "test_must_fail test_cmp" is a weird thing for somebody to write. > And your patch is obviously an improvement, but I have to wonder if some > of these make any sense. > > If we're expecting some outcome, then it's reasonable to say: > > 1. The output

Re: Regression in 'git branch -m'?

Jeff King writes: > Earlier I blamed Duy's 31824d180d. And that is the start of the > regression in v2.15, but only because it fixed another bug which was > papering over the one I'm fixing here. :) I haven't read Michael's reply, but 2/2 is very well explained and looks correct.

Re: [RFC PATCH v3 0/4] implement fetching of moved submodules

Heiko Voigt writes: > So the thing here is: If we want to make sure that we stay backwards > compatible by supporting the setup with gitlinks without configuration. > Then we also should keep tests around that have the plain manual setup > without .gitmodules files. Just

Re: [PATCH 2/2] tests: fix diff order arguments in test_cmp

Stefan Beller writes: >> How did you find these? E.g. is there a grep pattern that reviewers >> can use to repeat your results? > > The grunge work was done via scrolling through > > git -C t grep test_cmp > > However it occurred to me that checking for the completeness

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

Paolo Bonzini writes: > On 06/10/2017 14:33, Christian Couder wrote: >> Ok. I think you might want something called for example >> "replaceIfIdenticalClose" where "IdenticalClose" means: "there is a >> trailer with the same (, ) pair above or below the line >> where the

RE: [Question] Documenting platform implications on CVE to git

-Original Message- On October 6, 2017 7:45 PM Jonathan Nieder wrote: Cc: git@vger.kernel.org >Randall S. Becker wrote: >> The first one, mostly. When looking at CVE-2017-14867, there are >> places like >> https://nvd.nist.gov/vuln/detail/CVE-2017-14867 where the issue is >> discussed.

Re: [Question] Documenting platform implications on CVE to git

Hi, Randall S. Becker wrote: > The first one, mostly. When looking at CVE-2017-14867, there are places like > https://nvd.nist.gov/vuln/detail/CVE-2017-14867 where the issue is > discussed. It provides hyperlinks to various platform discussions. > Unfortunately for me, I am not an HPE employee -

RE: [Question] Documenting platform implications on CVE to git

-Original Message- On October 6, 2017 6:51 PM, Jonathan Nieder wrote >Randall S. Becker wrote: >> I wonder whether there is some mechanism for providing official >> responses from platform ports relating to security CVE reports, like CVE-2017-14867. >This question is too abstract for me.

Re: [RFC PATCH v3 0/4] implement fetching of moved submodules

On Fri, Oct 6, 2017 at 3:25 PM, Heiko Voigt wrote: > The last iteration can be found here: > > https://public-inbox.org/git/20170817105349.gc52...@book.hvoigt.net/ > > This is mainly a status update and to let people know that I am still > working on this. Cool. :) > I

Re: [Question] Documenting platform implications on CVE to git

Hi Randall, Randall S. Becker wrote: > I wonder whether there is some mechanism for providing official responses > from platform ports relating to security CVE reports, like CVE-2017-14867. This question is too abstract for me. Can you say more concretely what you are trying to do? E.g. are

[RFC PATCH v3 3/4] implement fetching of moved submodules

We store the changed submodules paths to calculate which submodule needs fetching. This does not work for moved submodules since their paths do not stay the same in case of a moved submodules. In case of new submodules we do not have a path in the current checkout, since they just appeared in this

[RFC PATCH v3 4/4] submodule: simplify decision tree whether to or not to fetch

To make extending this logic later easier. Signed-off-by: Heiko Voigt --- This should also be the same as in the previous version. submodule.c | 74 ++--- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git

[RFC PATCH 2/4] change submodule push test to use proper repository setup

NOTE: The argument in this message is not correct, see description in cover letter. The setup of the repositories in this test is using gitlinks without the .gitmodules infrastructure. It is however testing convenience features like --recurse-submodules=on-demand. These features are already not

[RFC PATCH 1/4] fetch: add test to make sure we stay backwards compatible

The current implementation of submodules supports on-demand fetch if there is no .gitmodules entry for a submodule. Let's add a test to document this behavior. Signed-off-by: Heiko Voigt --- t/t5526-fetch-submodules.sh | 42 +- 1 file

[RFC PATCH v3 0/4] implement fetching of moved submodules

The last iteration can be found here: https://public-inbox.org/git/20170817105349.gc52...@book.hvoigt.net/ This is mainly a status update and to let people know that I am still working on this. I struggled quite a bit with reviving my original test for the path based recursive fetch (first

Re: [PATCH 2/2] tests: fix diff order arguments in test_cmp

On Fri, Oct 6, 2017 at 3:01 PM, Jonathan Nieder wrote: > Stefan Beller wrote: > >> Fix the argument order for test_cmp. When given the expected >> result first the diff shows the actual output with '+' and the >> expectation with '-', which is the convention for our tests. >>

Re: [PATCH 2/2] tests: fix diff order arguments in test_cmp

Stefan Beller wrote: > Fix the argument order for test_cmp. When given the expected > result first the diff shows the actual output with '+' and the > expectation with '-', which is the convention for our tests. > > Signed-off-by: Stefan Beller > --- Yes, this should make

Re: [PATCH 1/2] tests: use shell negation instead of test_must_fail for test_cmp

Hi, Jeff King wrote: > On Fri, Oct 06, 2017 at 12:00:05PM -0700, Stefan Beller wrote: >> The `test_must_fail` should only be used to indicate a git command is >> failing. `test_cmp` is not a git command, such that it doesn't need the >> special treatment of `test_must_fail` (which e.g. includes

Re: [PATCH v7 2/3] submodule--helper: introduce for_each_listed_submodule()

Same disclaimer as in my review of patch 1/3: I didn't see a URL in the cover letter pointing at discussions of earlier iterations, so below comments may be at odds with what went on previously... On Fri, Oct 6, 2017 at 9:24 AM, Prathamesh Chavan wrote: > Introduce function

Re: [PATCH v7 1/3] submodule--helper: introduce get_submodule_displaypath()

I didn't find a URL in the cover letter pointing at previous iterations of this patch series and related discussions, so forgive me if comments below merely repeat what was said earlier... On Fri, Oct 6, 2017 at 9:24 AM, Prathamesh Chavan wrote: > Introduce function

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

> I might be naive in thinking that protocol.version could be removed or > redefined at our discretion just because it's marked as "experimental". Well the redefinition might very well occur, when we now say "set to v1 to test v1 and fallback to v0 otherwise", but long term we want a white or

Re: [PATCH 1/2] tests: use shell negation instead of test_must_fail for test_cmp

Stefan Beller wrote: > The `test_must_fail` should only be used to indicate a git command is > failing. `test_cmp` is not a git command, such that it doesn't need the > special treatment of `test_must_fail` (which e.g. includes checking for > segfault). > > Signed-off-by: Stefan Beller

[PATCH v3 07/12] apply: move lockfile into `apply_state`

We have two users of `struct apply_state` and the related functionality in apply.c. Each user sets up its `apply_state` by handing over a pointer to its static `lock_file`. (Before 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we could never free lockfiles, so making them

[PATCH v3 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag

`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`. At most one is allowed. But it is also possible to use no flag, i.e., `0`. But when `write_locked_index()` calls `do_write_index()`, the temporary file, a.k.a. the lockfile, will be closed. So passing `0` is effectively the

[PATCH v3 08/12] apply: remove `newfd` from `struct apply_state`

Similar to a previous patch, we do not need to use `newfd` to signal that we have a lockfile to clean up. We can just unconditionally call `rollback_lock_file`. If we do not hold the lock, it will be a no-op. Where we check `newfd` to decide whether we need to take the lock, we can instead use

[PATCH v3 12/12] read_cache: roll back lock in `update_index_if_able()`

`update_index_if_able()` used to always commit the lock or roll it back. Commit 03b866477 (read-cache: new API write_locked_index instead of write_index/write_cache, 2014-06-13) stopped rolling it back in case a write was not even attempted. This change in behavior is not motivated in the commit

[PATCH v3 09/12] cache.h: document `write_locked_index()`

The next patches will tweak the behavior of this function. Document it in order to establish a basis for those patches. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano --- cache.h | 16 1 file changed, 16 insertions(+) diff

[PATCH v3 01/12] sha1_file: do not leak `lock_file`

There is no longer any need to allocate and leak a `struct lock_file`. Initialize it on the stack instead. Before this patch, we set `lock = NULL` to signal that we have already rolled back, and that we should not do any more work. We need to take another approach now that we cannot assign NULL.

[PATCH v3 02/12] treewide: prefer lockfiles on the stack

There is no longer any need to allocate and leak a `struct lock_file`. The previous patch addressed an instance where we needed a minor tweak alongside the trivial changes. Deal with the remaining instances where we allocate and leak a struct within a single function. Change them to have the

[PATCH v3 06/12] cache-tree: simplify locking logic

After we have taken the lock using `LOCK_DIE_ON_ERROR`, we know that `newfd` is non-negative. So when we check for exactly that property before calling `write_locked_index()`, the outcome is guaranteed. If we write and commit successfully, we set `newfd = -1`, so that we can later avoid calling

[PATCH v3 05/12] checkout-index: simplify locking logic

`newfd` starts out negative. If we then take the lock, `newfd` will become non-negative. We later check for exactly that property before calling `write_locked_index()`. That is, we are simply using `newfd` as a boolean to keep track of whether we took the lock or not. (We always use `newfd` and

[PATCH v3 11/12] read-cache: leave lock in right state in `write_locked_index()`

If the original version of `write_locked_index()` returned with an error, it didn't roll back the lockfile unless the error occured at the very end, during closing/committing. See commit 03b866477 (read-cache: new API write_locked_index instead of write_index/write_cache, 2014-06-13). In commit

[PATCH v3 04/12] tempfile: fix documentation on `delete_tempfile()`

The function has always been documented as returning 0 or -1. It is in fact `void`. Correct that. As part of the rearrangements we lose the mention that `delete_tempfile()` might set `errno`. Because there is no return value, the user can't really know whether it did anyway. Signed-off-by: Martin

[PATCH v3 00/12] Re: various lockfile-leaks and -fixes

On 6 October 2017 at 21:44, Martin Ågren wrote: > Ok, thanks. I've got a rerolled series running through the final checks > right now. I did end up making this log message a bit more succinct. This is v3 of this series. All patches are identical to ma/lockfile-fixes in

[PATCH v3 03/12] lockfile: fix documentation on `close_lock_file_gently()`

Commit 83a3069a3 (lockfile: do not rollback lock on failed close, 2017-09-05) forgot to update the documentation by the function definition to reflect that the lock is not rolled back in case closing fails. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

Re: [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

On 6 October 2017 at 14:02, Junio C Hamano wrote: > Martin Ågren writes: > >> On 6 October 2017 at 04:01, Junio C Hamano wrote: >>> Martin Ågren writes: >>> v2: Except for the slightly different

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On 6 October 2017 at 14:09, Junio C Hamano wrote: > Martin Ågren writes: > >> Maybe I'm missing something Git-specific, but isn't the only thing that >> needs to be done now, to document/specify that 1) the client should send >> its list ordered by

Re: [PATCH 1/2] tests: use shell negation instead of test_must_fail for test_cmp

On Fri, Oct 6, 2017 at 12:22 PM, Jeff King wrote: > On Fri, Oct 06, 2017 at 12:00:05PM -0700, Stefan Beller wrote: > >> The `test_must_fail` should only be used to indicate a git command is >> failing. `test_cmp` is not a git command, such that it doesn't need the >> special

Re: [RFC] Reporting index properties

On Fri, 6 Oct 2017, Junio C Hamano wrote: > Yes, and I am saying that such logic should not live in standard > install outside developer tools ;-) Fair enough. It seems a little odd to me that git provides logic for _altering_ those bits, but not to report on the state that can be so altered.

Re: is there a truly compelling rationale for .git/info/exclude?

Hi, Robert P. J. Day wrote: > On Fri, 6 Oct 2017, Junio C Hamano wrote: >> Don't waste time by seeking a "compelling" reason. A mere "this is >> the most expedite way to gain convenience" back when something was >> introduced could be an answer, and it is way too late to complain >> about such

Re: [PATCH 1/2] tests: use shell negation instead of test_must_fail for test_cmp

On Fri, Oct 06, 2017 at 12:00:05PM -0700, Stefan Beller wrote: > The `test_must_fail` should only be used to indicate a git command is > failing. `test_cmp` is not a git command, such that it doesn't need the > special treatment of `test_must_fail` (which e.g. includes checking for > segfault)

[PATCH 1/2] tests: use shell negation instead of test_must_fail for test_cmp

The `test_must_fail` should only be used to indicate a git command is failing. `test_cmp` is not a git command, such that it doesn't need the special treatment of `test_must_fail` (which e.g. includes checking for segfault) Signed-off-by: Stefan Beller ---

[PATCH 2/2] tests: fix diff order arguments in test_cmp

Fix the argument order for test_cmp. When given the expected result first the diff shows the actual output with '+' and the expectation with '-', which is the convention for our tests. Signed-off-by: Stefan Beller --- t/t1004-read-tree-m-u-wf.sh | 2 +-

Re: Git config multiple values

Hi, Am 06.10.2017 um 19:25 schrieb Jonathan Nieder: > Hi, > > Jeff King wrote: >> On Fri, Oct 06, 2017 at 01:10:17PM +0200, aleksander.baranowski wrote: > >>> It's just an opinion, but this behaviour is no consistent for me. >>> >>> If it's not the bug it's a feature just let me know. >> >>

Re: git add --patch displays diff and exits

Sorry, please disregard---this is a duplicate of some other messages already sent to the list. Setting "color.ui = auto" fixed the issue for me. -- Jake > On Oct 6, 2017, at 1:13 PM, Jake Bell wrote: > > Sorry, please disregard---this is a duplicate of some other

Re: git add --patch displays diff and exits

On Fri, Oct 6, 2017 at 11:09 AM, Jake Bell wrote: > Hello, > > I'm not sure if this is the right place to report this issue, so apologies in > advance if it isn't. > > Recently, I upgraded from git 2.14.1 to 2.14.2, and noticed that "git add > --patch" does not work

git add --patch displays diff and exits

Hello, I'm not sure if this is the right place to report this issue, so apologies in advance if it isn't. Recently, I upgraded from git 2.14.1 to 2.14.2, and noticed that "git add --patch" does not work properly. It just prints a diff of what's changed and exits, instead of presenting the

[PATCH v2 1/1] completion: add --broken and --dirty to describe

When the flags for broken and dirty were implemented in b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21) and 9f67d2e827 (Teach "git describe" --dirty option, 2009-10-21) the completion was not updated, although these flags are useful completions. Add them. Signed-off-by: Thomas

Re: Line ending normalization doesn't work as expected

On Fri, Oct 06, 2017 at 09:33:31AM +0900, Junio C Hamano wrote: > Torsten Bögershausen writes: > > > Before we put this into stone: > > Does it make sense to say "renormalize" instead of "rehash" ? > > (That term does exist already for merge. > > And rehash is more a technical

Re: [PATCH 1/1] completion: Add forgotten describe options

> Stefan Beller hat am 6. Oktober 2017 um 00:17 > geschrieben: > On Thu, Oct 5, 2017 at 2:23 PM, Thomas Braun > wrote: Hi Stefan, > > completion: Add forgotten describe options > > When/Why was it forgotten? git-blame thinks it was me in

Re: is there a truly compelling rationale for .git/info/exclude?

On Fri, 6 Oct 2017, Junio C Hamano wrote: > rpj...@crashcourse.ca writes: > > > at the other end, users are certainly welcome to add extra > > patterns to be ignored, based purely on the way they work -- > > perhaps based on their choice of editor, they might want to > > exclude *.swp files, or

Re: Git config multiple values

Hi, Jeff King wrote: > On Fri, Oct 06, 2017 at 01:10:17PM +0200, aleksander.baranowski wrote: >> It's just an opinion, but this behaviour is no consistent for me. >> >> If it's not the bug it's a feature just let me know. > > It's a feature, though I agree that git-config is rather baroque.

Re: Git config multiple values

On Fri, Oct 06, 2017 at 10:25:30AM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > On Fri, Oct 06, 2017 at 01:10:17PM +0200, aleksander.baranowski wrote: > > >> It's just an opinion, but this behaviour is no consistent for me. > >> > >> If it's not the bug it's a feature just let me know. >

Re: [PATCH 2/2] refs_resolve_ref_unsafe: handle d/f conflicts for writes

On Fri, Oct 06, 2017 at 07:09:10PM +0200, Michael Haggerty wrote: > I do have one twinge of uneasiness at a deeper level, that I haven't had > time to check... > > Does this patch make it easier to *set* HEAD to an unborn branch that > d/f conflicts with an existing reference? If so, that might

Re: [PATCH 2/2] refs_resolve_ref_unsafe: handle d/f conflicts for writes

On 10/06/2017 04:42 PM, Jeff King wrote: > If our call to refs_read_raw_ref() fails, we check errno to > see if the ref is simply missing, or if we encountered a > more serious error. If it's just missing, then in "write" > mode (i.e., when RESOLVE_REFS_READING is not set), this is > perfectly

Re: Git config multiple values

Hi!, Thank you very much for descriptive answer. You are absolutely right. I should read manual more carefully! Still it's quite odd interface. Thank you for your time. Bests, Alex On 10/06/2017 04:32 PM, Jeff King wrote: > On Fri, Oct 06, 2017 at 01:10:17PM +0200, aleksander.baranowski

Re: [PATCH v2] fsck: handle NULL return of lookup_blob() and lookup_tree()

Am 06.10.2017 um 04:23 schrieb Junio C Hamano: > René Scharfe writes: >> +blob_bin=$(echo $blob | hex2oct) && >> +tree=$( >> +printf "4 dir\0${blob_bin}100644 file\0${blob_bin}" | > > Wow, that's ... cute. > >> +git hash-object -t tree --stdin

Re: git send-email does not work with Google anymore?!

On Thu, Oct 05 2017, Lars Schneider jotted: > Hi, > > I used to use the Google SMTP server to send my patches to the list with > the following config: > > [sendemail] > smtpencryption = tls > smtpserver = smtp.gmail.com > smtpuser = larsxschnei...@gmail.com >

Re: [bug] git add -p breaks, if color.ui is set to "always"

On Fri, Oct 06, 2017 at 02:47:30PM +0200, Alexander Gehrke wrote: > After an update to version 2.14.2 from 2.14.1 "git add --patch" stopped > working > for me, just producing the same output as "git diff", but not prompting to > stage > anything. > > I found that unsetting the config key

Re: git send-email does not work with Google anymore?!

Hi, On Thu, Oct 5, 2017 at 12:52 PM, Lars Schneider wrote: > Of couse I tried to log in via web browser etc. Does anyone else use > Google as SMTP server? If yes, does it work for you? As I wrote at the top of:

Re: git send-email does not work with Google anymore?!

On Thu, 2017-10-05 at 12:52 +0200, Lars Schneider wrote: > Apparently that stopped working today. I get this error: > > (mbox) Adding cc: Lars Schneider from line > 'From: Lars Schneider ' > Password for

[PATCH 2/2] refs_resolve_ref_unsafe: handle d/f conflicts for writes

If our call to refs_read_raw_ref() fails, we check errno to see if the ref is simply missing, or if we encountered a more serious error. If it's just missing, then in "write" mode (i.e., when RESOLVE_REFS_READING is not set), this is perfectly fine. However, checking for ENOENT isn't sufficient

Re: [PATCH] cleanup: fix possible overflow errors in binary search

On 10/6/2017 10:18 AM, Jeff King wrote: On Fri, Oct 06, 2017 at 09:52:31AM -0400, Derrick Stolee wrote: A common mistake when writing binary search is to allow possible integer overflow by using the simple average: mid = (min + max) / 2; Instead, use the overflow-safe version:

[PATCH 1/2] t3308: create a real ref directory/file conflict

A test in t3308 wants to make sure that we don't accidentally merge into "refs/notes/dir" when it exists as a directory, so it does: mkdir .git/refs/notes/dir git -c core.notesRef=refs/notes/dir merge ... and expects the second command to fail. But that understimates the refs code, which is

Re: Regression in 'git branch -m'?

On Thu, Oct 05, 2017 at 07:25:52PM +0200, Andreas Krey wrote: > I got something that looks like a regression somewhere since 2.11. > This script > > set -xe > rm -rf repo > git init repo > cd repo > git commit -m nix --allow-empty > git branch -m master/master > git rev-parse HEAD

[bug] git add -p breaks, if color.ui is set to "always"

After an update to version 2.14.2 from 2.14.1 "git add --patch" stopped working for me, just producing the same output as "git diff", but not prompting to stage anything. I found that unsetting the config key color.ui, which was set to "always" fixed the problem. >From the manpage, color.ui

Re: Git config multiple values

On Fri, Oct 06, 2017 at 01:10:17PM +0200, aleksander.baranowski wrote: > I'm currently using git version 2.14.2. There is possible to put > multiple values into same variable with git config. Yep, your examples should behave the same even with older versions. > Case 1: > # git config --global

Re: is there a truly compelling rationale for .git/info/exclude?

On Fri, 2017-10-06 at 06:14 -0400, rpj...@crashcourse.ca wrote: >and in this funny grey area in between, we have .git/info/exclude, > to be used for ... what, exactly? the one argument i've come up with > is the situation where you discover that a repo you've cloned has an > incomplete set of

Re: [PATCH] cleanup: fix possible overflow errors in binary search

On Fri, Oct 06, 2017 at 09:52:31AM -0400, Derrick Stolee wrote: > A common mistake when writing binary search is to allow possible > integer overflow by using the simple average: > > mid = (min + max) / 2; > > Instead, use the overflow-safe version: > > mid = min + (max - min) / 2;

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

On Thu, Oct 05, 2017 at 08:39:42AM -0400, Derrick Stolee wrote: > > Actually, I'd just as soon see timings for "git log --format=%h" or "git > > log --raw", as opposed to patches 1 and 2. > > > > You won't see a 90% speedup there, but you will see the actual > > improvement that real-world users

[PATCH] cleanup: fix possible overflow errors in binary search

A common mistake when writing binary search is to allow possible integer overflow by using the simple average: mid = (min + max) / 2; Instead, use the overflow-safe version: mid = min + (max - min) / 2; The included changes were found using the following two greps:

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

On 06/10/2017 15:19, Christian Couder wrote: > Now it would be strange to have "moveIfClosest" without having "move" > first and I don't see how "move" would be different from the existing > "replace". > Or maybe "move" means "replaceIfIdentical", in this case I think it > would help users to just

[Question] Documenting platform implications on CVE to git

Hi All, I wonder whether there is some mechanism for providing official responses from platform ports relating to security CVE reports, like CVE-2017-14867. For example, the Perl implementation on HPE NonStop does not include the SCM module so commands relating cvsserver may not be available -

[PATCH v7 1/3] submodule--helper: introduce get_submodule_displaypath()

Introduce function get_submodule_displaypath() to replace the code occurring in submodule_init() for generating displaypath of the submodule with a call to it. This new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder

[PATCH v7 0/3] Incremental rewrite of git-submodules

Changes in v7: * Instead of using cb_flags in the callback data's struct, 'flags' is used. * Similar changes were applied to the CB_OPT_QUIET and other bits. * The function compute_rev_name() was formatted in accordance with the "make style", into a compact version. * Call to

[PATCH v7 2/3] submodule--helper: introduce for_each_listed_submodule()

Introduce function for_each_listed_submodule() and replace a loop in module_init() with a call to it. The new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder Mentored-by: Stefan Beller

[PATCH v7 3/3] submodule: port submodule subcommand 'status' from shell to C

This aims to make git-submodule 'status' a built-in. Hence, the function cmd_status() is ported from shell to C. This is done by introducing four functions: module_status(), submodule_status_cb(), submodule_status() and print_status(). The function module_status() acts as the front-end of the

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

On Fri, Oct 6, 2017 at 2:39 PM, Paolo Bonzini wrote: > On 06/10/2017 14:33, Christian Couder wrote: >> Ok. I think you might want something called for example >> "replaceIfIdenticalClose" where "IdenticalClose" means: "there is a >> trailer with the same (, ) pair above or

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

On 06/10/2017 14:33, Christian Couder wrote: > Ok. I think you might want something called for example > "replaceIfIdenticalClose" where "IdenticalClose" means: "there is a > trailer with the same (, ) pair above or below the line > where the replaced trailer will be put when ignoring trailers

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

On Fri, Oct 6, 2017 at 12:40 PM, Paolo Bonzini wrote: > On 06/10/2017 12:30, Christian Couder wrote: >> Did you try using `--where end --if-exists replace --trailer "$sob"`? > > Yes, it's a different behavior; "--if-exists replace" matches on others' > SoB as well, so it

Re: is there a truly compelling rationale for .git/info/exclude?

rpj...@crashcourse.ca writes: > at the other end, users are certainly welcome to add extra patterns > to be ignored, based purely on the way they work -- perhaps based on > their choice of editor, they might want to exclude *.swp files, or > if working on a Mac, ignore .DS_Store, and so on,

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

Martin Ågren writes: > Maybe I'm missing something Git-specific, but isn't the only thing that > needs to be done now, to document/specify that 1) the client should send > its list ordered by preference, 2) how preference is signalled, and 3) > that the server gets to

Booking Flight !

Hello Dear, I would like to make a booking flight with you. Itinerary: From : Paris (CDG)- Casablanca (CMN)-Paris (CDG) Departing Date: 18/10/2017 Returning Date: 31/10/2017 Economic Class Informations for booking. Adult: Mr. First Name: Fréderic Lucien Last Name: PLAS Date of Birth:

Re: [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

Martin Ågren writes: > On 6 October 2017 at 04:01, Junio C Hamano wrote: >> Martin Ågren writes: >> >>> v2: Except for the slightly different documentation in cache.h, this is >>> a squash of the last two patches of v1. I hope

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On 6 October 2017 at 11:40, Junio C Hamano wrote: > Simon Ruderich writes: > >> Did you consider Stefan Beller's suggestion regarding a >> (white)list of allowed versions? >> >> On Mon, Sep 18, 2017 at 01:06:59PM -0700, Stefan Beller wrote: >>> Thinking

Git config multiple values

Hi, I'm currently using git version 2.14.2. There is possible to put multiple values into same variable with git config. Case 1: # git config --global user.name Foo - returns 0 # git config --global user.name Bar - returns 0 and replace Foo to Bar # git config --global user.name Foo - returns 0

Re: [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

On 6 October 2017 at 04:01, Junio C Hamano wrote: > Martin Ågren writes: > >> v2: Except for the slightly different documentation in cache.h, this is >> a squash of the last two patches of v1. I hope the commit message is >> better. > > Yeah, it is long

Re: [PATCH v2 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag

On 6 October 2017 at 03:39, Junio C Hamano wrote: > Martin Ågren writes: > >> diff --git a/read-cache.c b/read-cache.c >> index 65f4fe837..1c917eba9 100644 >> --- a/read-cache.c >> +++ b/read-cache.c >> @@ -2343,14 +2343,13 @@ static int

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

On 06/10/2017 12:30, Christian Couder wrote: > On Thu, Oct 5, 2017 at 3:22 PM, Paolo Bonzini wrote: >> The purpose of this action is for scripts to be able to keep the >> user's Signed-off-by at the end. For example say I have a script >> that adds a Reviewed-by tag: >> >>

Re: [RFC PATCH 0/4] interpret-trailers: introduce "move" action

On Thu, Oct 5, 2017 at 3:22 PM, Paolo Bonzini wrote: > The purpose of this action is for scripts to be able to keep the > user's Signed-off-by at the end. For example say I have a script > that adds a Reviewed-by tag: > > #! /bin/sh > them=$(git log -i -1

is there a truly compelling rationale for .git/info/exclude?

currently having a discussion with ben straub of "pro git" notoriety, and he and i seem to agree that there's not much value in registering ignore patterns in a repo-specific .git/info/exclude file. on the one hand, the .gitignore files that come with a repo would represent (in ben's

Re: Regression in 'git branch -m'?

On Fri, Oct 06, 2017 at 06:45:08PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > So this patch fixes the problem: > > > > diff --git a/refs.c b/refs.c > > index df075fcd06..2ba74720c8 100644 > > --- a/refs.c > > +++ b/refs.c > > @@ -1435,7 +1435,8 @@ const char

Re: Regression in 'git branch -m'?

Jeff King writes: > So this patch fixes the problem: > > diff --git a/refs.c b/refs.c > index df075fcd06..2ba74720c8 100644 > --- a/refs.c > +++ b/refs.c > @@ -1435,7 +1435,8 @@ const char *refs_resolve_ref_unsafe(struct ref_store > *refs, > if

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

Simon Ruderich writes: > Did you consider Stefan Beller's suggestion regarding a > (white)list of allowed versions? > > On Mon, Sep 18, 2017 at 01:06:59PM -0700, Stefan Beller wrote: >> Thinking about this, how about: >> >> If not configured, we do as we want. (i.e. Git has

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On Tue, Oct 03, 2017 at 01:15:00PM -0700, Brandon Williams wrote: > [snip] > > +protocol.version:: > + Experimental. If set, clients will attempt to communicate with a > + server using the specified protocol version. If unset, no > + attempt will be made by the client to communicate

RE: Enquête auprès de la table d'aide pour incident [INC0903501]

From: Tim Rhynes Sent: Friday, October 06, 2017 3:17 AM Subject: Enquête auprès de la table d'aide pour incident [INC0903501] Prenez-vous un moment pour compléter un sondage sur l'incident INC0903501 en ce qui concerne «l'enquête sur votre courrier

Re: Regression in 'git branch -m'?

On Fri, Oct 06, 2017 at 03:39:13AM -0400, Jeff King wrote: > I got a chance to look at this again. I think the root of the problem is > that resolve_ref() as it is implemented now is just totally unsuitable > for asking the question "what does this symbolic link point to?". > > Because you end

[PATCH v3] run-command: add hint when a hook is ignored

When an hook is present but the file is not set as executable then git will ignore the hook. For now this is silent which can be confusing. This commit adds this warning to improve the situation: hint: The 'pre-commit' hook was ignored because it's not set as executable. hint: You can

  1   2   >