'git submodules update' ignores credential.helper config of the parent repository

I'm checking out a repository in a non-interactive environment and would like to disable interactive credential helpers. According to [1] it can be done by specifying an empty helper in a local config: [credential] helper = But the submodule update command ignores the helper specified in

[PATCH] gitweb tests: Skip tests when we don't have Time::HiRes

Change the gitweb tests to skip when we can't load the Time::HiRes module. This module has bee in perl core since v5.8, which is the oldest version we support, however CentOS (and perhaps some other distributions) carve it into its own non-core-perl package that's not installed along with

Re: SHA1 collisions found

Am 25.02.2017 um 20:04 schrieb brian m. carlson: >>> So I think that the current scope left is best estimated by the >>> following command: >>> >>> git grep -P 'unsigned char\s+(\*|.*20)' | grep -v '^Documentation' >>> >>> So there are approximately 1200 call sites left, which is quite a bit of

Re: show all merge conflicts

G. Sylvie Davies venit, vidit, dixit 29.01.2017 07:45: > On Sat, Jan 28, 2017 at 6:28 AM, Jeff King wrote: >> On Fri, Jan 27, 2017 at 09:42:41PM -0800, G. Sylvie Davies wrote: >> >>> Aside from the usual "git log -cc", I think this should work (replace >>> HEAD with whichever

Re: [PATCH v2] convert: add "status=delayed" to filter process protocol

On Mon, Feb 27, 2017 at 11:32:47AM +0100, Lars Schneider wrote: > I completely agree - I need to change that. However, the goal of the v2 > iteration was to get the "convert" interface in an acceptable state. > That's what I intended to say in the patch comment section: > > "Please ignore

Re: SHA1 collisions found

Just swap in md5 in place of sha1. Pad with '0'. That'll give you all the collisions you want and none of those you don't want. On Mon, Feb 27, 2017 at 5:43 AM, Jeff King wrote: > On Mon, Feb 27, 2017 at 10:57:37AM +0100, Geert Uytterhoeven wrote: > >> > Yeah, that is a lot more

[PATCH] cvs tests: When root, skip tests that call "cvs commit"

Change the tests that fail to when we run the test suite as root, due to calling "cvs commit". The GNU cvs package has an optional compile-time CVS_BADROOT flag. When compiled with this flag "cvs commit" will refuse to commit anything as root. On my Debian box this isn't compiled in[1] in, but on

Transition plan for git to move to a new hash function

I said I was working on a transition plan. Here it is. This is obviously a draft for review, and I have no official status in the git project. But I have extensive experience of protocol compatibility engineering, and I hope this will be helpful. Ian. Subject: Transition plan for git to move

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 2:28 PM, Junio C Hamano wrote: > Jeff King writes: > >> I guess something like the patch below works, but I wonder if there is a >> less-horrible way to accomplish the same thing. > > I suspect that a less-horrible would be a lot more

Re: [PATCH] strbuf: add strbuf_add_real_path()

Am 27.02.2017 um 19:22 schrieb Brandon Williams: On 02/25, René Scharfe wrote: +void strbuf_add_real_path(struct strbuf *sb, const char *path) +{ + if (sb->len) { + struct strbuf resolved = STRBUF_INIT; + strbuf_realpath(, path, 1); +

[PATCH 1/2] wrapper.c: remove unused git_mkstemp() function

The last caller of git_mkstemp() was removed in commit 6fec0a89 ("verify_signed_buffer: use tempfile object", 16-06-2016). Since the introduction of the 'tempfile' APIs, along with git_mkstemp_mode, it is unlikely that new callers will materialize. Remove the dead code. Signed-off-by: Ramsay

[PATCH 0/2] remove unused 'mkstemp(s)' code

I promised the first of these patches on 18th June last year! ;-) (In response to Jeff's 'jk/gpg-interface-cleanup' branch). Ramsay Jones (2): wrapper.c: remove unused git_mkstemp() function wrapper.c: remove unused gitmkstemps() function Makefile | 5 - cache.h |

Re: [PATCH 4/4] ident: do not ignore empty config name/email

On Mon, Feb 27, 2017 at 9:42 PM, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > >> On Thu, 2017-02-23 at 23:18 -0500, Jeff King wrote: >>> On Thu, Feb 23, 2017 at 08:11:11PM -0800, Junio C Hamano wrote: >>> >>> > > So I dunno. I could really go

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 04:33:36PM -0800, Junio C Hamano wrote: > A flag to affect the behaviour (as opposed to as a secondary > return value, like Peff's patch does) can be made to work. Perhaps > a flag that says "keep the input as is if the result is not a local > branch name" would pass an

[RFC] - url-safe base64 commit-id's

Is there any appetite for base64'd commit-id's, using the url-safe variant (e.g. RFC 4648 [1] with padding removed)? And so this: 712bad335dfa9c410a83f9873614a19726acb3a8 Becomes this: cSutM136nEEKg_mHNhShlyass6g Under the hood things cannot change (e.g., ".git/objects/71/") because file

[PATCH] http: attempt updating base URL only if no error

http.c supports HTTP redirects of the form http://foo/info/refs?service=git-upload-pack -> http://anything -> http://bar/info/refs?service=git-upload-pack (that is to say, as long as the Git part of the path and the query string is preserved in the final redirect destination, the

What's cooking in git.git (Feb 2017, #09; Mon, 27)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The first batch post 2.12 is

[PATCH 2/2] wrapper.c: remove unused gitmkstemps() function

The last call to the mkstemps() function was removed in commit 659488326 ("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order to support platforms without mkstemps(), this functionality was provided, along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps()

Typesafer git hash patch

So because of the whole SHA1 discussion, I started looking at what it would involve to turn unsigned char *sha1 style arguments (and various structure members) in the git source into typedef struct { ... } hash_t; hash_t *hash; The answer is that it's pretty painful - more so than I

Git has been accepted as a GSoC 2017 mentor organization!

Hi everyone, I am happy to let you know that Git has been accepted as a GSoC mentor organization again this year. https://summerofcode.withgoogle.com/organizations/ I invited Dscho and Stefan as potential mentors for Git. I also invited Junio to give him access to students proposals and the

Re: [RFC] - url-safe base64 commit-id's

On Mon, Feb 27, 2017 at 6:27 PM, G. Sylvie Davies wrote: > Is there any appetite for base64'd commit-id's, using the url-safe > variant (e.g. RFC 4648 [1] with padding removed)? > > And so this: > 712bad335dfa9c410a83f9873614a19726acb3a8 > > Becomes this: >

Re: [PATCH 4/4] ident: do not ignore empty config name/email

On Thu, 2017-02-23 at 23:18 -0500, Jeff King wrote: > On Thu, Feb 23, 2017 at 08:11:11PM -0800, Junio C Hamano wrote: > > > > So I dunno. I could really go either way on it. Feel free to drop it, or > > > even move it into a separate topic to be cooked longer. > > > > If it were 5 years ago, it

Re: 'git submodules update' ignores credential.helper config of the parent repository

On Mon, Feb 27, 2017 at 5:33 AM, Dmitry Neverov wrote:> > git -c credential.helper= submodule update > > Is it by design? A similar question came up w.r.t. submodule configuration recently. It is about url..insteadOf[1] that is set in the super project and is expected

Re: [PATCH] cvs tests: When root, skip tests that call "cvs commit"

Thanks, makes sense.

Re: [PATCH 2/2] apply: handle assertion failure gracefully

René Scharfe writes: >> diff --git a/apply.c b/apply.c >> index cbf7cc7f2..9219d2737 100644 >> --- a/apply.c >> +++ b/apply.c >> @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, >> if (!old_name) >> return 0; >> >> -

Re: [PATCH] gitweb tests: Skip tests when we don't have Time::HiRes

W dniu 27.02.2017 o 13:37, Ævar Arnfjörð Bjarmason pisze: > Change the gitweb tests to skip when we can't load the Time::HiRes > module. Could you tell us in the commit message why this module is needed? Is it because gitweb loads it unconditionally, or does that at least in the default

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King writes: > This comes originally from Junio's 84679d470. I cannot see how naming > the new branch HEAD would make any difference to the test, but perhaps I > am missing something. Nah, I think it was just a random string that came to mind and the topic being "ah we

Re: [PATCH 1/2] commit: be more precise when searching for headers

René Scharfe writes: > Search for a space character only within the current line in > read_commit_extra_header_lines() instead of searching in the whole > buffer (and possibly beyond, if it's not NUL-terminated) and then > discarding any results after the end of the current line. >

Re: [PATCH] interpret_branch_name(): handle auto-namelen for @{-1}

Jeff King writes: > On Mon, Feb 27, 2017 at 04:25:40AM -0500, Jeff King wrote: > >> However, before we do that auto-namelen magic, we call >> interpret_nth_prior_checkout(), which gets fed the bogus >> "0". This was broken by 8cd4249c4 (interpret_branch_name: >> always respect

RE: Unconventional roles of git

> -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of ankostis > Sent: February 26, 2017 6:52 AM > To: Git Mailing List > Cc: Jason Cooper > Subject: Unconventional roles of git > > On 26

Re: show all merge conflicts

Michael J Gruber writes: > If you're curious, I kept rebasing Thomas' remerge-diff (on top of our > next) so far. You can find it at > > https://github.com/mjg/git/tree/remerge-diff ;-). Yes, this was a good one. > if you're interested. I don't know what problems

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

René Scharfe writes: > Would it make sense to mirror the previously existing condition and > check for is_new instead? I.e.: > > if ((!patch->is_delete && !patch->new_name) || > (!patch->is_new&& !patch->old_name)) { > Yes,

Re: Why BLAKE2?

Markus Trippelsdorf writes ("Re: Why BLAKE2?"): > On 2017.02.27 at 13:00 +, Ian Jackson wrote: > > For brevity I will write `SHA' for hashing with SHA-1, using current > > unqualified object names, and `BLAKE' for hasing with BLAKE2b, using > > H object names. > > Why do you choose BLAKE2?

Re: [ANNOUNCE] Git v2.12.0

On Fri, Feb 24, 2017 at 8:28 PM, Junio C Hamano wrote: > The latest feature release Git v2.12.0 is now available at the > usual places. It is comprised of 517 non-merge commits since > v2.11.0, contributed by 80 people, 24 of which are new faces. Yay, some explanations /

[PATCH v4 02/22] t1700: change here document style

This improves test indentation by getting rid of the outdated here document style. Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 170 - 1 file changed, 85 insertions(+), 85 deletions(-) diff --git

[PATCH v4 11/22] read-cache: regenerate shared index if necessary

When writing a new split-index and there is a big number of cache entries in the split-index compared to the shared index, it is a good idea to regenerate the shared index. By default when the ratio reaches 20%, we will push back all the entries from the split-index into a new shared index file

[PATCH v4 00/22] Add configuration options for split-index

Goal We want to make it possible to use the split-index feature automatically by just setting a new "core.splitIndex" configuration variable to true. This can be valuable as split-index can help significantly speed up `git rebase` especially along with the work to libify `git apply` that

[PATCH v4 10/22] config: add git_config_get_max_percent_split_change()

This new function will be used in a following commit to get the value of the "splitIndex.maxPercentChange" config variable. Signed-off-by: Christian Couder --- cache.h | 1 + config.c | 15 +++ 2 files changed, 16 insertions(+) diff --git a/cache.h

[PATCH v4 06/22] update-index: warn in case of split-index incoherency

When users are using `git update-index --(no-)split-index`, they may expect the split-index feature to be used or not according to the option they just used, but this might not be the case if the new "core.splitIndex" config variable has been set. In this case let's warn about what will happen and

[PATCH v4 03/22] config: add git_config_get_split_index()

This new function will be used in a following commit to know if we want to use the split index feature or not. Signed-off-by: Christian Couder --- cache.h | 1 + config.c | 10 ++ 2 files changed, 11 insertions(+) diff --git a/cache.h b/cache.h index

[PATCH v4 05/22] read-cache: add and then use tweak_split_index()

This will make us use the split-index feature or not depending on the value of the "core.splitIndex" config variable. Signed-off-by: Christian Couder --- read-cache.c | 17 + 1 file changed, 17 insertions(+) diff --git a/read-cache.c b/read-cache.c

[PATCH v4 08/22] Documentation/config: add information for core.splitIndex

Signed-off-by: Christian Couder --- Documentation/config.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 015346c417..61a863adeb 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@

[PATCH v4 07/22] t1700: add tests for core.splitIndex

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 37 + 1 file changed, 37 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index cb68b8dc1e..1659986d8d 100755 --- a/t/t1700-split-index.sh +++

[PATCH v4 09/22] Documentation/git-update-index: talk about core.splitIndex config var

Signed-off-by: Christian Couder --- Documentation/git-update-index.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 7386c93162..e091b2a409 100644 ---

[PATCH v4 01/22] config: mark an error message up for translation

Signed-off-by: Christian Couder --- config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config.c b/config.c index c6b874a7bf..2ac1aa19b0 100644 --- a/config.c +++ b/config.c @@ -1728,8 +1728,8 @@ int git_config_get_untracked_cache(void)

[PATCH v4 04/22] split-index: add {add,remove}_split_index() functions

Also use the functions in cmd_update_index() in builtin/update-index.c. These functions will be used in a following commit to tweak our use of the split-index feature depending on the setting of a configuration variable. Signed-off-by: Christian Couder ---

Bug: "git worktree add" Unable to checkout a branch with no local ref

git version 2.10.2.windows.1: If a remote branch has never been checked out locally (its ref only exists in remotes// directory), "git worktree add" command is unable to check it out by its normal short name (not prefixed by remotes/), while "git checkout" command has been able to handle such

Re: Why BLAKE2?

On 2017.02.27 at 13:00 +, Ian Jackson wrote: > > For brevity I will write `SHA' for hashing with SHA-1, using current > unqualified object names, and `BLAKE' for hasing with BLAKE2b, using > H object names. Why do you choose BLAKE2? SHA-2 is generally considered still fine and would be the

[PATCH v4 22/22] Documentation/git-update-index: explain splitIndex.*

Signed-off-by: Christian Couder --- Documentation/config.txt | 2 +- Documentation/git-update-index.txt | 37 + 2 files changed, 30 insertions(+), 9 deletions(-) diff --git a/Documentation/config.txt

[PATCH v4 16/22] config: add git_config_get_expiry() from gc.c

This function will be used in a following commit to get the expiration time of the shared index files from the config, and it is generic enough to be put in "config.c". Signed-off-by: Christian Couder --- builtin/gc.c | 15 ++- cache.h | 3 +++

[PATCH v4 20/22] read-cache: use freshen_shared_index() in read_index_from()

This way a share index file will not be garbage collected if we still read from an index it is based from. As we need to read the current index before creating a new one, the tests have to be adjusted, so that we don't expect an old shared index file to be deleted right away when we create a new

[PATCH v4 18/22] t1700: test shared index file expiration

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 44 1 file changed, 44 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index 21f43903f8..480d3a8dc3 100755 --- a/t/t1700-split-index.sh

[PATCH v4 21/22] Documentation/config: add splitIndex.sharedIndexExpire

Signed-off-by: Christian Couder --- Documentation/config.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8e745bda52..0e9982c5e3 100644 --- a/Documentation/config.txt +++

Re: [PATCH] http: add an "auto" mode for http.emptyauth

Jeff King writes: > The auto mode may incur an extra round-trip over setting > http.emptyauth=true, because part of the emptyauth hack is > to feed this blank password to curl even before we've made a > single request. IOW, people who care about an extra round-trip have this

[PATCH v4 12/22] t1700: add tests for splitIndex.maxPercentChange

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 72 ++ 1 file changed, 72 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index df19b812fd..21f43903f8 100755 ---

[PATCH v4 14/22] sha1_file: make check_and_freshen_file() non static

This function will be used in a commit soon, so let's make it available globally. Signed-off-by: Christian Couder --- cache.h | 3 +++ sha1_file.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index 955e80913e..6b25b50aab

Re: [PATCH] strbuf: add strbuf_add_real_path()

On 02/25, René Scharfe wrote: > Add a function for appending the canonized absolute pathname of a given > path to a strbuf. It keeps the existing contents intact, as expected of > a function of the strbuf_add() family, while avoiding copying the result > if the given strbuf is empty. It's more

Re: [PATCH 10/10] submodule--helper clone: check for configured submodules using helper

On 02/23, Stefan Beller wrote: > On Thu, Feb 23, 2017 at 3:47 PM, Brandon Williams wrote: > > > @@ -795,14 +794,11 @@ static int prepare_to_clone_next_submodule(const > > struct cache_entry *ce, > > } > > > > /* > > -* Looking up the url in

Re: [PATCH] gitweb tests: Skip tests when we don't have Time::HiRes

On Mon, Feb 27, 2017 at 6:48 PM, Jakub Narębski wrote: > W dniu 27.02.2017 o 13:37, Ævar Arnfjörð Bjarmason pisze: >> Change the gitweb tests to skip when we can't load the Time::HiRes >> module. > > Could you tell us in the commit message why this module is needed? > Is it

Re: [PATCH 0/5] recursing submodules with relative pathspec (grep and ls-files)

On 02/24, Brandon Williams wrote: > It was discovered that when using the --recurse-submodules flag with `git > grep` > and `git ls-files` and specifying a relative path when not at the root causes > the child processes spawned to error out with an error like: > > fatal: ..: '..' is outside

[PATCH v4 19/22] read-cache: refactor read_index_from()

It looks better and is simpler to review when we don't compute the same things many times in the function. It will also help make the following commit simpler. Signed-off-by: Christian Couder --- read-cache.c | 14 -- 1 file changed, 8 insertions(+), 6

Re: [PATCH 1/5] grep: illustrate bug when recursing with relative pathspec

On 02/26, Duy Nguyen wrote: > On Sat, Feb 25, 2017 at 6:50 AM, Brandon Williams wrote: > > When using the --recurse-submodules flag with a relative pathspec which > > includes "..", an error is produced inside the child process spawned for > > a submodule. When creating the

Re: [PATCH v5 1/1] config: add conditional include

Jeff King writes: > I don't think driving that with a two-entry table is the right thing > here. We are as likely to add another "foobar:" entry as we are to add > another modifier "/i" modifier to "gitdir:", and it is unclear whether > that modifier would be mutually exclusive

[PATCH v4 13/22] Documentation/config: add splitIndex.maxPercentChange

Signed-off-by: Christian Couder --- Documentation/config.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 61a863adeb..8e745bda52 100644 --- a/Documentation/config.txt +++

[PATCH v4 15/22] read-cache: touch shared index files when used

When a split-index file is created, let's update the mtime of the shared index file that the split-index file is referencing. In a following commit we will make shared index file expire depending on their mtime, so updating the mtime makes sure that the shared index file will not be deleted soon.

[PATCH v4 17/22] read-cache: unlink old sharedindex files

Everytime split index is turned on, it creates a "sharedindex." file in the git directory. This change makes sure that shared index files that haven't been used for a long time are removed when a new shared index file is created. The new "splitIndex.sharedIndexExpire" config variable is

Re: git-clone --config order & fetching extra refs during initial clone

Jeff King writes: > [Re-sending, as I used an old address for Gábor on the original] > > On Sat, Feb 25, 2017 at 07:12:38PM +, Robin H. Johnson wrote: > >> TL;DR: git-clone ignores any fetch specs passed via --config. > > I agree that this is a bug. There's some previous

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 02:49:15AM -0500, Jeff King wrote: > > > $ git branch -m -f orig @ > [...] > > Regardless of the original intent, I think it is wrong to convert "@" to > a branch named "HEAD". I think the bug is in strbuf_check_branch_ref(), > which blindly sticks "refs/heads/"

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 11:43:46AM +0530, Karthik Nayak wrote: > On Mon, Feb 27, 2017 at 10:22 AM, Luc Van Oostenryck > wrote: > > Hi, > > > > I just discover something which very much seems a bug to me > > while making an error in renaming a branch. > > The scenario

Re: [PATCH v2] convert: add "status=delayed" to filter process protocol

W dniu 27.02.2017 o 11:32, Lars Schneider pisze: > >> On 27 Feb 2017, at 10:58, Jeff King wrote: >> >> On Sun, Feb 26, 2017 at 07:48:16PM +0100, Lars Schneider wrote: >> >>> +If the request cannot be fulfilled within a reasonable amount of time >>> +then the filter can respond

Re: [BUG] branch renamed to 'HEAD'

Jeff King writes: > I guess something like the patch below works, but I wonder if there is a > less-horrible way to accomplish the same thing. I suspect that a less-horrible would be a lot more intrusive. It would go like "interpret-branch-name only gives local branch name, and

Re: [PATCH 05/10] submodule--helper: add is_active command

On 02/23, Stefan Beller wrote: > On Thu, Feb 23, 2017 at 3:47 PM, Brandon Williams wrote: > > There are a lot of places where an explicit check for > > submodule."".url is done to see if a submodule exists. In order > > to more easily facilitate the use of the submodule.active

Re: Reference for quote "creating branch is not the issue, merging is", in context of Subversion/Git

W dniu 26.02.2017 o 16:19, Igor Djordjevic pisze: > Hello Michael, > > On 26/02/2017 12:40, Michael Hüttermann wrote: >> Linus Torvalds made a statement regarding merging/branching and stated >> (as far as I know) that "creating branch is not the issue, merge is", in >> context of Subversion/Git.

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

Thomas Gummerer writes: > if test -z "$patch_mode" > then > - git reset --hard ${GIT_QUIET:+-q} > + if test $# != 0 > + then > + git reset ${GIT_QUIET:+-q} -- "$@" > + git checkout

Re: [PATCH 2/6] Specify explicitly where we parse timestamps

Johannes Schindelin writes: > Currently, Git's source code represents all timestamps as `unsigned > long`. In preparation for using `time_t` instead, let's introduce a > symbol `parse_timestamp` (currently being defined to `strtoul`) where > appropriate, so that we

Re: [PATCH 2/6] Specify explicitly where we parse timestamps

Junio C Hamano writes: >> -unsigned long number = strtoul(date, , 10); >> +time_t number = parse_timestamp(date, , 10); > > This hunk does not belong to this step. Everybody else in this step obviously I meant "the left half of this hunk" ;-) > still receives

Re: Transition plan for git to move to a new hash function

Ian Jackson wrote: A few questions and one or two suggestions... > TEXTUAL SYNTAX > == > > We also reserve the following syntax for private experiments: > E[A-Z]+[0-9a-z]+ > We declare that public releases of git will never accept such > object

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Junio C Hamano writes: > ... I suspect that calling interpret_empty_at() from > that function is fundamentally flawed. The "@" end user types never > means refs/heads/HEAD, and HEAD@{either reflog or -1} would not mean > anything that should be taken as a branch_name,

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King writes: > The "other" stuff could sometimes be useful, I guess. It's not _always_ > wrong to do: > > git branch -f @{upstream} foo > > It depends on what your @{upstream} resolves to. Switching to just using > interpret_nth_prior_checkout() would break the case when it

Re: [PATCH 2/2] apply: handle assertion failure gracefully

Am 27.02.2017 um 21:04 schrieb Junio C Hamano: René Scharfe writes: diff --git a/apply.c b/apply.c index cbf7cc7f2..9219d2737 100644 --- a/apply.c +++ b/apply.c @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, if (!old_name)

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

Am 27.02.2017 um 21:10 schrieb Junio C Hamano: René Scharfe writes: Would it make sense to mirror the previously existing condition and check for is_new instead? I.e.: if ((!patch->is_delete && !patch->new_name) ||

[PATCH 1/6] t0006 & t5000: prepare for 64-bit time_t

Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers.

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

W dniu 25.02.2017 o 20:27, René Scharfe pisze: > Both standard_header_field() and excluded_header_field() check if > there's a space after the buffer that's handed to them. We already > check in the caller if that space is present. Don't bother calling > the functions if it's missing, as they

Re: [PATCH 2/2] apply: handle assertion failure gracefully

René Scharfe writes: > Am 27.02.2017 um 21:04 schrieb Junio C Hamano: >> René Scharfe writes: >> diff --git a/apply.c b/apply.c index cbf7cc7f2..9219d2737 100644 --- a/apply.c +++ b/apply.c @@ -3652,7 +3652,6 @@ static int

Re: [PATCH 1/6] t0006 & t5000: prepare for 64-bit time_t

Johannes Schindelin writes: > This quick fix, however, tests for *long* to be 64-bit or not. What we > need, though, is a test that says whether *whatever data type we use for > timestamps* is 64-bit or not. > > The same quick fix was used to handle the similar

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

Am 27.02.2017 um 23:27 schrieb Jakub Narębski: W dniu 25.02.2017 o 20:27, René Scharfe pisze: Both standard_header_field() and excluded_header_field() check if there's a space after the buffer that's handed to them. We already check in the caller if that space is present. Don't bother calling

Re: [PATCH 4/4] ident: do not ignore empty config name/email

Dennis Kaarsemaker writes: > On Thu, 2017-02-23 at 23:18 -0500, Jeff King wrote: >> On Thu, Feb 23, 2017 at 08:11:11PM -0800, Junio C Hamano wrote: >> >> > > So I dunno. I could really go either way on it. Feel free to drop it, or >> > > even move it into a separate

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King writes: > I suspect there are a lot of other places that are less clear cut. E.g., > I think just: > > git branch foo bar > > will put "foo" through the same interpretation. So you could do: > > git branch -f @{-1} bar > > Is that insane? Maybe. But it does work now.

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

Thomas Gummerer writes: > + test -n "$untracked" || git ls-files --error-unmatch -- "$@" >/dev/null > || exit 1 This silent "exit 1" made me scratch my head, but --error-unmatch would have already given an error message, like error: pathspec 'no such' did not

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

On 02/27, Junio C Hamano wrote: > Thomas Gummerer writes: > > > + test -n "$untracked" || git ls-files --error-unmatch -- "$@" >/dev/null > > || exit 1 > > This silent "exit 1" made me scratch my head, but --error-unmatch > would have already given an error message,

[PATCH 5/6] ref-filter: avoid using `unsigned long` for catch-all data type

In its `atom_value` struct, the ref-filter source code wants to store different values in a field called `ul` (for `unsigned long`), e.g. timestamps. However, as we are about to switch the data type of timestamps away from `unsigned long` (because it may be 32-bit even when `time_t` is 64-bit),

[PATCH 3/6] Introduce a new "printf format" for timestamps

Currently, Git's source code treats all timestamps as if they were unsigned longs. Therefore, it is okay to write "%lu" when printing them. There is a substantial problem with that, though: at least on Windows, time_t is *larger* than unsigned long, and hence we will want to switch to using

[PATCH 4/6] Prepare for timestamps to use 64-bit signed types

Currently, Git's source code uses the unsigned long type to represent timestamps. However, this type is limited to 32-bit e.g. on 64-bit Windows. Hence it is a suboptimal type for this use case. In any case, we need to use the time_t type to represent timestamps since we often send those values

[PATCH 2/6] Specify explicitly where we parse timestamps

Currently, Git's source code represents all timestamps as `unsigned long`. In preparation for using `time_t` instead, let's introduce a symbol `parse_timestamp` (currently being defined to `strtoul`) where appropriate, so that we can later easily switch to use `strtoull()` instead. Signed-off-by:

[PATCH 0/6] Use time_t

Git v2.9.2 was released in a hurry to accomodate for platforms like Windows, where the `unsigned long` data type is 32-bit even for 64-bit setups. The quick fix was to simply disable all the testing with "absurd" future dates. However, we can do much better than that, as `time_t` exists, and at

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

On Mon, Feb 27, 2017 at 01:19:29PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I suspect there are a lot of other places that are less clear cut. E.g., > > I think just: > > > > git branch foo bar > > > > will put "foo" through the same interpretation. So you could

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

On 02/27, Junio C Hamano wrote: > Thomas Gummerer writes: > > > if test -z "$patch_mode" > > then > > - git reset --hard ${GIT_QUIET:+-q} > > + if test $# != 0 > > + then > > + git reset ${GIT_QUIET:+-q} -- "$@" > > +

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

On Mon, Feb 27, 2017 at 11:33:23AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > This comes originally from Junio's 84679d470. I cannot see how naming > > the new branch HEAD would make any difference to the test, but perhaps I > > am missing something. > > Nah, I think

Re: git-clone --config order & fetching extra refs during initial clone

On Mon, Feb 27, 2017 at 11:16:35AM -0800, Junio C Hamano wrote: > >> TL;DR: git-clone ignores any fetch specs passed via --config. > > > > I agree that this is a bug. There's some previous discussion and an RFC > > patch from lat March (author cc'd): > > > > > >

Re: show all merge conflicts

On Mon, Feb 27, 2017 at 11:45:31AM -0800, Junio C Hamano wrote: > Michael J Gruber writes: > > > If you're curious, I kept rebasing Thomas' remerge-diff (on top of our > > next) so far. You can find it at > > > > https://github.com/mjg/git/tree/remerge-diff > > ;-).

  1   2   >