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

Am 27.02.2017 um 23:33 schrieb Junio C Hamano: > 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

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

Hi, On Mon, 27 Feb 2017, Junio C Hamano wrote: > 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. > >

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 4:53 PM, Jeff King wrote: > 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

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

On Mon, Feb 27, 2017 at 9:22 PM, Alexander Grigoriev wrote: > 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

[PATCH 1/2] docs/diffcore: fix grammar in diffcore-rename header

Signed-off-by: Patrick Steinhardt --- Documentation/gitdiffcore.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt index 46bc6d077..cf009a187 100644 --- a/Documentation/gitdiffcore.txt +++

[PATCH 2/2] docs/diffcore: unquote "Complete Rewrites" in headers

The gitdiffcore documentation quotes the term "Complete Rewrites" in headers for no real gain. This would make sense if the term could be easily confused if not properly grouped together. But actually, the term is quite obvious and thus does not really need any quoting, especially regarding that

Re: [PATCH 0/6] Use time_t

On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: > One notable fallout of this patch series is that on 64-bit Linux (and > other platforms where `unsigned long` is 64-bit), we now limit the range > of dates to LONG_MAX (i.e. the *signed* maximum value). This needs to be > done

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 07:53:02PM -0500, Jeff King wrote: > 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

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

On Mon, Feb 27, 2017 at 11:09:12AM -0800, Stefan Beller wrote: > For worktrees these multiple config files sounded like > the obvious solution, but I wonder if there was also > some bike shedding about other solutions? > > I could imagine that we would want to have attributes > for specific

[PATCH 2/8] strbuf_branchname: drop return value

The return value from strbuf_branchname() is confusing and useless: it's 0 if the whole name was consumed by an @-mark, but otherwise is the length of the original name we fed. No callers actually look at the return value, so let's just get rid of it. Signed-off-by: Jeff King ---

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

Hi Junio, On Mon, 27 Feb 2017, Junio C Hamano wrote: > 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 > >

[PATCH 7/8] strbuf_check_ref_format(): expand only local branches

This function asks strbuf_branchname() to expand any @-marks in the branchname, and then we blindly stick refs/heads/ in front of the result. This is obviously nonsense if the expansion is "HEAD" or a ref in refs/remotes/. The most obvious end-user effect is that creating or renaming a branch

RE: Unconventional roles of git

>From: ankostis [mailto:ankos...@gmail.com] >Sent: February 28, 2017 8:01 AM >To: Randall S. Becker >Cc: Git Mailing List ; Jason Cooper >Subject: Re: Unconventional roles of git >On 27 February 2017 at 20:16, Randall S. Becker

gpg verify git sub modules useful?

When using git submodules, is there value in iterating about the git submodules running "git verfiy-commit HEAD" or would that be already covered by the git submodule verification? Cheers, Patrick

Re: [PATCH 0/6] Use time_t

Hi Peff, On Tue, 28 Feb 2017, Jeff King wrote: > On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: > > > One notable fallout of this patch series is that on 64-bit Linux (and > > other platforms where `unsigned long` is 64-bit), we now limit the > > range of dates to LONG_MAX

[PATCH 1/8] interpret_branch_name: move docstring to header file

We generally put docstrings with function declarations, because it's the callers who need to know how the function works. Let's do so for interpret_branch_name(). Signed-off-by: Jeff King --- cache.h | 21 + sha1_name.c | 21 - 2 files

[PATCH 6/8] branch: restrict @-expansions when deleting

We use strbuf_branchname() to expand the branch name from the command line, so you can delete the branch given by @{-1}, for example. However, we allow other nonsense like "@", and we do not respect our "-r" flag (so we may end up deleting an oddly-named local ref instead of a remote one). We

Re: [PATCH 0/6] Use time_t

Hi Junio, On Mon, 27 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > One notable fallout of this patch series is that on 64-bit Linux (and > > other platforms where `unsigned long` is 64-bit), we now limit the > > range of dates to LONG_MAX (i.e.

Re: [PATCH 4/8] interpret_branch_name: allow callers to restrict expansions

On Tue, Feb 28, 2017 at 07:14:34AM -0500, Jeff King wrote: > However, out-parameters make calling interface somewhat > cumbersome. Instead, let's do the opposite: let the caller > tell us which elements to expand. That's easier to pass in, > and none of the callers give more precise error

[PATCH 5/8] t3204: test git-branch @-expansion corner cases

git-branch feeds the branch names from the command line to strbuf_branchname(), but we do not yet tell that function which kinds of expansions should be allowed. Let's create a set of tests that cover both the allowed and disallowed cases. That shows off some breakages where we currently create

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

On Mon, Feb 27, 2017 at 06:53:11PM -0800, Jonathan Tan wrote: > 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

[PATCH 8/8] checkout: restrict @-expansions when finding branch

When we parse "git checkout $NAME", we try to interpret $NAME as a local branch-name. If it is, then we point HEAD to that branch. Otherwise, we detach the HEAD at whatever commit $NAME points to. We do the interpretation by calling strbuf_branchname(), and then blindly sticking "refs/heads/" on

Re: [PATCH 2/2] docs/diffcore: unquote "Complete Rewrites" in headers

On Tue, Feb 28, 2017 at 09:59:05AM +0100, Patrick Steinhardt wrote: > The gitdiffcore documentation quotes the term "Complete Rewrites" in > headers for no real gain. This would make sense if the term could be > easily confused if not properly grouped together. But actually, the term > is quite

Re: [PATCH 4/8] interpret_branch_name: allow callers to restrict expansions

On Tue, Feb 28, 2017 at 07:23:38AM -0500, Jeff King wrote: > > -int interpret_branch_name(const char *name, int namelen, struct strbuf > > *buf) > > +int interpret_branch_name(const char *name, int namelen, struct strbuf > > *buf, > > + unsigned allowed) > > { > > char

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

On Tue, Feb 28, 2017 at 01:24:10AM +, Ramsay Jones wrote: > 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

[PATCH 3/8] strbuf_branchname: add docstring

This function and its companion, strbuf_check_branch_ref(), did not have their purpose or semantics explained. Let's do so. Signed-off-by: Jeff King --- strbuf.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/strbuf.h b/strbuf.h index 47df0500d..6b51b2604

[PATCH 4/8] interpret_branch_name: allow callers to restrict expansions

The original purpose of interpret_branch_name() was to be used by get_sha1() in resolving refs. As such, some of its expansions may point to refs outside of the local "refs/heads" namespace. Over time, the function has been picked up by other callers who want to use the ref-expansion to give the

Re: SHA1 collisions found

On Mon, Feb 27, 2017 at 02:29:18PM +0100, René Scharfe wrote: > 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' > >>> >

Re: [PATCH v5 04/24] files-backend: convert git_path() to strbuf_git_path()

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > git_path() and friends are going to be killed in files-backend.c in near > future. And because there's a risk with overwriting buffer in > git_path(), let's convert them all to strbuf_git_path(). We'll have > easier time killing/converting

format-patch subject-prefix gets truncated when using the --numbered flag

Hello, I noticed that the --subject-prefix string gets truncated sometimes, but only when using the --numbered flat. Here's an example: addu@sestofb11:/data/fb/addu/git$ export longm="very very very very very very very very very very very very very very long prefix"

Re: [PATCH 0/6] Use time_t

Am 28.02.2017 um 15:28 schrieb Jeff King: On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: One notable fallout of this patch series is that on 64-bit Linux (and other platforms where `unsigned long` is 64-bit), we now limit the range of dates to LONG_MAX (i.e. the *signed*

Re: [PATCH v5 07/24] files-backend: add and use files_refname_path()

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > Keep repo-related path handling in one place. This will make it easier > to add submodule/multiworktree support later. > > This automatically adds the "if submodule then use the submodule version > of git_path" to other call sites too. But it

Re: [PATCH v5 09/24] refs.c: introduce get_main_ref_store()

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > refs.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/refs.c b/refs.c > index 81b64b4ed..dab1a21ac 100644 > --- a/refs.c > +++

Re: [PATCH v5 13/24] refs.c: make get_main_ref_store() public and use it

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > get_ref_store() will soon be renamed to get_submodule_ref_store(). > Together with future get_worktree_ref_store(), the three functions > provide an appropriate ref store for different operation modes. New APIs > will be added to operate

Re: [PATCH v5 05/24] files-backend: move "logs/" out of TMP_RENAMED_LOG

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > This makes reflog path building consistent, always in the form of > > strbuf_git_path(sb, "logs/%s", refname); > > It reduces the mental workload a bit in the next patch when that > function call is converted. > > Signed-off-by: Nguyễn

Re: [PATCH v5 24/24] t1406: new tests for submodule ref store

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > t/t1406-submodule-ref-store.sh (new +x) | 95 > + > 1 file changed, 95 insertions(+) > create mode 100755 t/t1406-submodule-ref-store.sh > >

Re: [PATCH 1/2] docs/diffcore: fix grammar in diffcore-rename header

Patrick Steinhardt writes: > Signed-off-by: Patrick Steinhardt > --- > Documentation/gitdiffcore.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt > index

Re: gpg verify git sub modules useful?

Patrick Schleizer writes: > When using git submodules, is there value in iterating about the git > submodules running "git verfiy-commit HEAD" or would that be already > covered by the git submodule verification? That depends on what you are referring to with

Re: [PATCH v5 08/24] files-backend: remove the use of git_path()

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of > deciding what goes where (*). The end goal is to pass $GIT_DIR only. A > refs "view" of a linked worktree is a logical ref store that combines > two files backends

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

On 2017-02-27 21:17, Junio C Hamano wrote: > Torsten, you've been quite active in fixing various glitches around > the EOL conversion in the latter half of last year. Have any > thoughts to share on this topic? > > Thanks. Sorry for the delay, being too busy with other things. I followed the

RE: HELLO VERY URGENT.

Hello, Hello, how are you doing? I want to inform you that, we have an inheritance of a deceased client with your surname. Reply via email: andrsi...@yandex.com with your full names for info. Regards. Miss. Melissa. -- Correo Corporativo Hospital

Re: [PATCH 0/6] Use time_t

Jeff King writes: > I do not just agree, but I think the move to a signed timestamp is a big > improvement. Git's object format is happy to represent times before > 1970, but the code is not. I know this has been a pain for people who > import ancient histories into Git. > > It

Re: [PATCH v5 12/24] refs.c: kill register_ref_store(), add register_submodule_ref_store()

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > This is the last function in this code (besides public API) that takes > submodule argument and handles both main/submodule cases. Break it down, > move main store registration in get_main_ref_store() and keep the rest > in

Re: [PATCH v5 00/24] Remove submodule from files-backend.c

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > v5 goes a bit longer than v4, basically: I've read through patch 14/24 so far, and they all look good except for the mostly superficial comments that I have sent so far. I like the way this is heading! I'll try to continue tomorrow. Michael

Re: [PATCH v5 14/24] path.c: move some code out of strbuf_git_path_submodule()

On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: > refs is learning to avoid path rewriting that is done by > strbuf_git_path_submodule(). Factor out this code so it could be reused > by refs* > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > path.c | 34

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 10:55:49AM -0800, Junio C Hamano wrote: > > Glibc will get a way to enable 64-bit time_t on 32-bit platforms > > eventually > > (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign). Can > > platforms that won't provide a 64-bit time_t by 2038 be actually used > > at

Re: [PATCH 4/8] interpret_branch_name: allow callers to restrict expansions

On Tue, Feb 28, 2017 at 12:27:45PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > The original purpose of interpret_branch_name() was to be used by > > get_sha1() in resolving refs. As such, some of its expansions may > > point to refs outside of the local "refs/heads"

Re: format-patch subject-prefix gets truncated when using the --numbered flag

Junio C Hamano writes: > Adrian Dudau writes: > >> I noticed that the --subject-prefix string gets truncated sometimes, >> but only when using the --numbered flat. Here's an example: >> >> addu@sestofb11:/data/fb/addu/git$ export longm="very very very

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

On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote: > > I have a feeling that something like this would create unwelcome corner > > cases in the config-writer, which is otherwise does not have to care > > about which existing section of a file it adds a key to. > > Yeah the writer

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 09:26:23AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I do not just agree, but I think the move to a signed timestamp is a big > > improvement. Git's object format is happy to represent times before > > 1970, but the code is not. I know this

[PATCH v8 6/6] stash: allow pathspecs in the no verb form

Now that stash_push is used in the no verb form of stash, allow specifying the command line for this form as well. Always use -- to disambiguate pathspecs from other non-option arguments. Also make git stash -p an alias for git stash push -p. This allows users to use git stash -p .

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

While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano wrote: > Linus Torvalds writes: >> >> Having the hashes be more encapsulated does seem to make things better >> in many ways. What I did was to also just unify the notion of "hash_t" >> and "struct

[PATCH v8 0/6] stash: support pathspec argument

Thanks Junio for the review and the squashable diff with the fix for my errors. I changed it a tiny bit, to use git stash push instead of git stash, so the complete diff could go into 4/6, where I think I think the test fits best. Interdiff below: diff --git a/git-stash.sh b/git-stash.sh index

[PATCH v8 2/6] stash: add test for the create command line arguments

Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. Signed-off-by: Thomas Gummerer ---

Re: [PATCH 0/6] Use time_t

Hi Junio, On Tue, 28 Feb 2017, Junio C Hamano wrote: > René Scharfe writes: > > > Am 28.02.2017 um 15:28 schrieb Jeff King: > > > >> It looks from the discussion like the sanest path forward is our own > >> signed-64bit timestamp_t. That's unfortunate compared to using the > >>

RE: SHA1 collisions found

[Responses inline] No need to keep me "bcc'd" (though thanks for the consideration) -- I'm happy to ignore anything I don't want to be pulled into ;-) Here's a rollup of what needs to be done based on the discussion below: 1) Remove extraneous exports from sha1.h 2) Remove "safe mode" support.

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

Thomas Gummerer writes: > + git reset ${GIT_QUIET:+-q} -- "$@" > + git ls-files -z --modified -- "$@" | > + git checkout-index -z --force --stdin > + git checkout ${GIT_QUIET:+-q} HEAD -- $(git

Re: [PATCH 4/8] interpret_branch_name: allow callers to restrict expansions

Jeff King writes: > The original purpose of interpret_branch_name() was to be used by > get_sha1() in resolving refs. As such, some of its expansions may > point to refs outside of the local "refs/heads" namespace. I am not sure the reference to "get_sha1()" is entirely correct.

Re: [BUG] branch renamed to 'HEAD'

On Tue, Feb 28, 2017 at 4:06 AM, Jeff King wrote: > On Mon, Feb 27, 2017 at 07:53:02PM -0500, Jeff King wrote: > >> 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

Re: [PATCH v5 00/24] Remove submodule from files-backend.c

Michael Haggerty writes: > On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote: >> v5 goes a bit longer than v4, basically: > > I've read through patch 14/24 so far, and they all look good except for > the mostly superficial comments that I have sent so far. I like the way >

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

On Tue, Feb 28, 2017 at 10:48:52AM -0800, Jonathan Tan wrote: > > Running your included test, we get: > > > > fatal: unable to access 'http://127.0.0.1:5550/redir-to/502/': The > > requested URL returned error: 502 > > > > but the error really happened in the intermediate step. I wonder if

Re: [PATCH] strbuf: add strbuf_add_real_path()

On 02/27, René Scharfe wrote: > 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; > >>+

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 08:33:13PM +, brian m. carlson wrote: > On Tue, Feb 28, 2017 at 03:26:34PM -0500, Jeff King wrote: > > Yeah, a lot of brian's patches have been focused around the fixing the > > related size assumptions. We've got GIT_SHA1_HEXSZ which doesn't solve > > the problem, but

Re: Typesafer git hash patch

On Mon, Feb 27, 2017 at 10:59:15PM -0800, Linus Torvalds wrote: > I saw that somebody is actually looking at doing this "well" - by > doing it in many smaller steps. I tried. I gave up. The "unsigned char > *sha1" model is so ingrained that doing it incrementally just seemed > like a lot of pain.

[PATCH v8 1/6] stash: introduce push verb

Introduce a new git stash push verb in addition to git stash save. The push verb is used to transition from the current command line arguments to a more conventional way, in which the message is given as an argument to the -m option. This allows us to have pathspecs at the end of the command

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 03:26:34PM -0500, Jeff King wrote: > Yeah, a lot of brian's patches have been focused around the fixing the > related size assumptions. We've got GIT_SHA1_HEXSZ which doesn't solve > the problem, but at least makes it easy to find. And a big improvement > in the most recent

[PATCH v8 3/6] stash: refactor stash_create

Refactor the internal stash_create function to use a -m flag for specifying the message and -u flag to indicate whether untracked files should be added to the stash. This makes it easier to pass a pathspec argument to stash_create in the next patch. The user interface for git stash create stays

Re: [ANNOUNCE] Git for Windows 2.12.0

Hi, On Tue, 28 Feb 2017, w...@cornell.edu wrote: > I have attempted to download the new version but on 2/28/2016 starting > at 12:00PM EST I have been unable to download GIT 2.12. The error > message that is returned is: > > Make sure you’ve got the right web address: >

Re: [PATCH 3/5] grep: fix bug when recuring with relative pathspec

Brandon Williams writes: > /* Add super prefix */ > + quote_path_relative(name, opt->prefix, ); Hmph, do you want a quoted version here, not just relative_path()? Perhaps add a test with an "unusual" byte (e.g. a double-quote) in the path? >

Re: [PATCH] Travis: also test on 32-bit Linux

Hi, On Tue, 28 Feb 2017, Johannes Schindelin wrote: > When Git v2.9.1 was released, it had a bug that showed only on Windows > and on 32-bit systems: our assumption that `unsigned long` can hold > 64-bit values turned out to be wrong. > > This could have been caught earlier if we had a

Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath

Am 28.02.2017 um 21:51 schrieb Junio C Hamano: > Andreas Heiduk writes: > >> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt >> index e6215c3..7c28e73 100644 >> --- a/Documentation/diff-options.txt >> +++ b/Documentation/diff-options.txt >> @@

Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath

Andreas Heiduk writes: > I'll fix the "munged" and, unless there are objections, I will also > replace the remaining ones in the vicinity. These are the last > occurrences of "munged". I'd rather see the "we do not munge" to stay the same. "we do not quote" still allows us

Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath

Am 24.02.2017 um 22:54 schrieb Jakub Narębski: > W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze: >> Linking the description for pathname quoting to the configuration >> variable "core.quotePath" removes inconstistent and incomplete >> sections while also giving two hints how to deal with it:

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 09:54:58PM +0100, Johannes Schindelin wrote: > > Right now, they may be able to have future timestamps ranging to > > year 2100 and switching to time_t would limit their ability to > > express future time to 2038 but they would be able to express > > timestamp in the past

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 12:25:20PM -0800, Linus Torvalds wrote: > On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano wrote: > > Sorry, but at this point in your description, you completely lost > > me. I thought "struct object_id" was what you call "hash_t" in the > > above. >

Re: [PATCH 2/3] revision: exclude trees/blobs given commit

Jonathan Tan writes: > When the --objects argument is given to rev-list, an argument of the > form "^$tree" can be given to exclude all blobs and trees reachable from > that tree, but an argument of the form "^$commit" only excludes that > commit, not any blob or tree

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

On Tue, Feb 28, 2017 at 01:42:44PM -0800, Junio C Hamano wrote: > Jonathan Tan writes: > > > It could be argued that in the future, Git might need to distinguish > > tree_objects from blob_objects - in particular, a user might want > > rev-list to print the trees but

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

Torsten Bögershausen writes: > On 2017-02-27 21:17, Junio C Hamano wrote: > >> Torsten, you've been quite active in fixing various glitches around >> the EOL conversion in the latter half of last year. Have any >> thoughts to share on this topic? >> >> Thanks. > > Sorry for the

Re: [PATCH v2 1/2] Documentation: Improve description for core.quotePath

Am 24.02.2017 um 22:43 schrieb Jakub Narębski: > W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze: >> Signed-off-by: Andreas Heiduk > > Thanks. This is good work. :-) > >> --- >> Documentation/config.txt | 24 ++-- >> 1 file changed, 14 insertions(+),

Re: [PATCH 2/3] revision: exclude trees/blobs given commit

On Fri, Feb 24, 2017 at 05:18:37PM -0800, Jonathan Tan wrote: > When the --objects argument is given to rev-list, an argument of the > form "^$tree" can be given to exclude all blobs and trees reachable from > that tree, but an argument of the form "^$commit" only excludes that > commit, not any

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

On Tue, Feb 28, 2017 at 12:08 PM, Jeff King wrote: > On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote: > >> > I have a feeling that something like this would create unwelcome corner >> > cases in the config-writer, which is otherwise does not have to care >> > about

Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath

Andreas Heiduk writes: > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt > index e6215c3..7c28e73 100644 > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -192,10 +192,9 @@ ifndef::git-log[] > given, do not

Re: [PATCH 5/5] ls-files: fix bug when recuring with relative pathspec

Brandon Williams writes: > Fix a bug which causes a child process for a submodule to error out when a > relative pathspec with a ".." is provided in the superproject. > > While at it, correctly construct the super-prefix to be used in a submodule > when not at the root of the

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

On Tue, Feb 28, 2017 at 12:21:57PM -0800, Stefan Beller wrote: > > I'm still open to the idea that we simply improve the documentation to > > make it clear that per-repo config really is per-repo, and is not shared > > between super-projects and submodules. And then something like Duy's > >

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

Jonathan Tan writes: > It could be argued that in the future, Git might need to distinguish > tree_objects from blob_objects - in particular, a user might want > rev-list to print the trees but not the blobs. That was exactly why these bits were originally made to

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

On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote: > 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

[PATCH v8 5/6] stash: use stash_push for no verb form

Now that we have stash_push, which accepts pathspec arguments, use it instead of stash_save in git stash without any additional verbs. Previously we allowed git stash -- -message, which is no longer allowed after this patch. Messages starting with a hyphen was allowed since 3c2eb80f, ("stash:

Re: format-patch subject-prefix gets truncated when using the --numbered flag

On Tue, Feb 28, 2017 at 03:59:16PM +, Adrian Dudau wrote: > This is happening on the latest master branch, so I dug through the > code and tracked the issue to this piece of code in log-tree.c: > > if (opt->total > 0) { > static char buffer[64]; >

Re: [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

On Fri, Feb 24, 2017 at 05:18:36PM -0800, Jonathan Tan wrote: > Whenever tree_objects is set to 1 in revision.h's struct rev_info, > blob_objects is likewise set, and vice versa. Combine those two fields > into one. > > Some of the existing code does not handle tree_objects being different >

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 02:27:22PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > ... We can certainly stick with it for now (it's awkward if you > > really do have an entry on Jan 1 1970, but other than that it's an OK > > marker). I agree that the most negatively value

[PATCH] Put sha1dc on a diet

From: Linus Torvalds Date: Tue, 28 Feb 2017 16:12:32 -0800 Subject: [PATCH] Put sha1dc on a diet This removes the unnecessary parts of the sha1dc code, shrinking things from [torvalds@i7 git]$ size sha1dc/*.o textdata bss dec

Re: [PATCH 0/6] Use time_t

Jeff King writes: > ... We can certainly stick with it for now (it's awkward if you > really do have an entry on Jan 1 1970, but other than that it's an OK > marker). I agree that the most negatively value is probably a saner > choice, but we can switch to it after the dust

Re: format-patch subject-prefix gets truncated when using the --numbered flag

On Tue, Feb 28, 2017 at 11:33:55AM -0800, Junio C Hamano wrote: > And having said all that, if we really want to allow overlong > subject prefix that would end up hiding the real title of the patch, > a modern way to do so would be to use xstrfmt() like the attached > toy-patch does. If you are

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:52 AM, Shawn Pearce wrote: > >> and from what I can tell, the 'maski' value is always 0, so the >> looping over 80 state masks is really just a loop over two. > > Actually, look closer at that loop: No, sorry, I wasn't clear and took some shortcuts

Re: [PATCH 0/6] Use time_t

Hi René, On Tue, 28 Feb 2017, René Scharfe wrote: > Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: > > > > On Tue, 28 Feb 2017, Junio C Hamano wrote: > > > > > René Scharfe writes: > > > > > > > Am 28.02.2017 um 15:28 schrieb Jeff King: > > > > > > > > > It looks from the

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 11:53:28AM -0800, Junio C Hamano wrote: > Linus Torvalds writes: > > > That > > actually can clean up some code, because right now we have duplicate > > interfaces for some things that take an oid pointer and others take a > > "const

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 2:50 PM, Marc Stevens wrote: > > Because we only have 32 disturbance vectors to check, we have DVMASKSIZE > equal to 1 and maski always 0. > In the more general case when we add disturbance vectors this will not > remain the case. Ok, I didn't get why

Re: [PATCH 0/6] Use time_t

Am 01.03.2017 um 00:10 schrieb Johannes Schindelin: Hi René, On Tue, 28 Feb 2017, René Scharfe wrote: Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: On Tue, 28 Feb 2017, Junio C Hamano wrote: René Scharfe writes: Am 28.02.2017 um 15:28 schrieb Jeff King: It looks

Re: SHA1 collisions found

You can also keep me in this thread, so we can help or answer any further questions, but I also appreciate the feedback on our project. Like Dan Shumow said, our main focus on the library has been correctness and then performance. The entire files ubc_check.c and ubc_check.h are generated based

  1   2   >