Re: [PATCH 0/6] Use time_t

Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: 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

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

[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: 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: Typesafer git hash patch

On Tue, Feb 28, 2017 at 12:19 PM, brian m. carlson wrote: > > The bigger issue is the assumptions in the code base that assume a given > hash size. Absolutely. And I think those are going to be the "real" patches. I actually saw your status report about "After

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

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: 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: [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: [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: 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

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: [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 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: 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: [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: [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

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: 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 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 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: 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: 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

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

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: 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: [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: [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: '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 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: [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

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: [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 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 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: [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] 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: 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 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 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] 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

[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:

[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 ---

[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

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 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 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 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

[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: 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.

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 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: '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

Re: [PATCH 0/6] Use time_t

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 >> standard time_t, but hopefully it would reduce the number of knobs

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:34 AM, Linus Torvalds wrote: > On Tue, Feb 28, 2017 at 11:07 AM, Junio C Hamano wrote: >> >> In a way similar to 8415558f55 ("sha1dc: avoid c99 >> declaration-after-statement", 2017-02-24), we would want this on >> top.

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:07 AM, Junio C Hamano wrote: > > In a way similar to 8415558f55 ("sha1dc: avoid c99 > declaration-after-statement", 2017-02-24), we would want this on > top. There's a few other simplifications that could be done: (1) make the symbols static that

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

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 Continuous Testing set up that includes a build and test run on 32-bit

Re: SHA1 collisions found

Junio C Hamano writes: >> [1/3]: add collision-detecting sha1 implementation >> [2/3]: sha1dc: adjust header includes for git >> [3/3]: Makefile: add USE_SHA1DC knob > > I was lazy so I fetched the above and then added this on top before > I start to play with it. > > --

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:07:37AM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > >> [1/3]: add collision-detecting sha1 implementation > >> [2/3]: sha1dc: adjust header includes for git > >> [3/3]: Makefile: add USE_SHA1DC knob > > > > I was lazy so I

Re: SHA1 collisions found

Jeff King writes: > The first one is 98K. Mail headers may bump it over vger's 100K barrier. > It's actually the _least_ interesting patch of the 3, because it just > imports the code wholesale from the other project. But if it doesn't > make it, you can fetch the whole series

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

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 very > very very very very very very very very very

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

On 02/28/2017 05:28 AM, Jeff King wrote: Right, your patch makes sense. A real HTTP error should take precedence over the url-update trickery. Acked-by: Jeff King Thanks! Running your included test, we get: fatal: unable to access 'http://127.0.0.1:5550/redir-to/502/':

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

On Tue, Feb 28, 2017 at 6:37 AM, Jeff King wrote: >> >> This would change the semantics of a config file as the attribute for >> each setting depends on the location (was attribute.FOO.read = >> {true, false} read before). > > I'm not enthused by this, just because there is a

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: 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 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: 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: [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 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 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: [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: 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 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: [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 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 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 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 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

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*

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"

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: 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

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 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: '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

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: [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

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' > >>> >

[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 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

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 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 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

[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

  1   2   >