Re: [PATCH 0/6] Convert hash-object to struct object_id

"brian m. carlson" writes: > On Sun, Aug 20, 2017 at 10:09:25PM +0200, Patryk Obara wrote: >> This enabled conversion of few functions in sha1_file, which >> had almost all callers converted already. >> >> I hope I'm not stepping on anyone's toes with this patch

Re: [PATCH 2/2] rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved

Ramsay Jones writes: > On 19/08/17 21:30, Junio C Hamano wrote: > >> In the future, we may find other variables that only allow an >> integer that specifies "this many days" (or other unit of time) and >> allow them to also do the same, and at that point we probably

Re: [RFC PATCH 0/6] Hash Abstraction

"brian m. carlson" writes: > brian m. carlson (6): > vcs-svn: remove unused prototypes > vcs-svn: rename repo functions to "svn_repo" > setup: expose enumerated repo info > Add structure representing hash algorithm > Integrate hash algorithm support with

[RFC PATCH 3/6] setup: expose enumerated repo info

We enumerate several different items as part of struct repository_format, but then actually set up those values using the global variables we've initialized from them. Instead, let's pass a pointer to the structure down to the code where we enumerate these values, so we can later on use those

[RFC PATCH 5/6] Integrate hash algorithm support with repo setup

In future versions of Git, we plan to support an additional hash algorithm. Integrate the enumeration of hash algorithms with repository setup, and store a pointer to the enumerated data in struct repository. Of course, we currently only support SHA-1, so hard-code this value in

[RFC PATCH 4/6] Add structure representing hash algorithm

Since in the future we want to support an additional hash algorithm, add a structure that represents a hash algorithm and all the data that must go along with it. Add a constant to allow easy enumeration of hash algorithms. Implement function typedefs to create an abstract API that can be used

[RFC PATCH 2/6] vcs-svn: rename repo functions to "svn_repo"

There were several functions in the Subversion code that started with "repo_". This namespace is also used by the Git struct repository code. Rename these functions to start with "svn_repo" to avoid any future conflicts. Signed-off-by: brian m. carlson ---

[RFC PATCH 0/6] Hash Abstraction

= Overview This is an RFC series proposing a basic abstraction for hash functions. As we get closer to converting the remainder of the codebase to use struct object_id, we should think about the design we want our hash function abstraction to take. This series is a proposal for one idea to

[RFC PATCH 6/6] Switch empty tree and blob lookups to use hash abstraction

Switch the uses of empty_tree_oid and empty_blob_oid to use the current_hash abstraction that represents the current hash algorithm in use. Signed-off-by: brian m. carlson --- builtin/am.c | 2 +- builtin/checkout.c | 2 +- builtin/diff.c | 2 +-

[RFC PATCH 1/6] vcs-svn: remove unused prototypes

The Subversion code had prototypes for several functions which were not ever defined or used. These functions all had names starting with "repo_", some of which conflict with those in repository.h. To avoid the conflict, remove those unused prototypes. Signed-off-by: brian m. carlson

Re: Please fix the useless email prompts

Andrew Ardill writes: > Is there any reason `git pull` can't delay that check until the point > where it actually tries to create a new commit? It's fair enough to > error if a new commit needs to be made, and there is no user > configured, but for the use cases

Re: Please fix the useless email prompts

Hi Anatoli, On 21 August 2017 at 07:57, Anatolii Borodin wrote: > On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill > wrote: >> Maybe I am missing something obvious, but if that's the case then >> can't we just do the identity check when trying

Re: Please fix the useless email prompts

Hi Andrew, On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill wrote: > Maybe I am missing something obvious, but if that's the case then > can't we just do the identity check when trying to make new commits, > in which case you should be able to pull without setting your >

Re: Please fix the useless email prompts

Hi Jeffrey, On Sat, Aug 19, 2017 at 5:10 PM, Jeffrey Walton wrote: > *** Please tell me who you are. Which version of git do you use? Do you have user.useConfigOnly set to true anywhere in the config files? -- Mit freundlichen Grüßen, Anatolii Borodin

Re: [PATCH 2/2] rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved

On 19/08/17 21:30, Junio C Hamano wrote: > These two configuration variables are described in the documentation > to take an expiry period expressed in the number of days: > > gc.rerereResolved:: > Records of conflicted merge you resolved earlier are > kept for this many

Re: [PATCH 5/6] sha1_file: convert hash_sha1_file_literally to struct object_id

On Sun, Aug 20, 2017 at 10:09:30PM +0200, Patryk Obara wrote: > Convert all remaining callers as well. > > Signed-off-by: Patryk Obara > --- > builtin/hash-object.c | 2 +- > cache.h | 2 +- > sha1_file.c | 8 > 3 files changed, 6

Re: [PATCH 0/6] Convert hash-object to struct object_id

On Sun, Aug 20, 2017 at 10:09:25PM +0200, Patryk Obara wrote: > This enabled conversion of few functions in sha1_file, which > had almost all callers converted already. > > I hope I'm not stepping on anyone's toes with this patch series. > If I do - is there some email thread or document in which

[PATCH 5/6] sha1_file: convert hash_sha1_file_literally to struct object_id

Convert all remaining callers as well. Signed-off-by: Patryk Obara --- builtin/hash-object.c | 2 +- cache.h | 2 +- sha1_file.c | 8 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/builtin/hash-object.c

[PATCH 4/6] sha1_file: convert index_fd to struct object_id

Convert all remaining callers as well. Signed-off-by: Patryk Obara --- builtin/difftool.c| 2 +- builtin/hash-object.c | 2 +- builtin/replace.c | 2 +- cache.h | 2 +- read-cache.c | 2 +- sha1_file.c | 14 +++--- 6

[PATCH 2/6] read-cache: convert to struct object_id

Replace hashcmp with oidcmp. Signed-off-by: Patryk Obara --- read-cache.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/read-cache.c b/read-cache.c index acfb028..7285608 100644 --- a/read-cache.c +++ b/read-cache.c @@ -160,9 +160,9 @@ static

[PATCH 6/6] sha1_file: convert index_stream to struct object_id

Signed-off-by: Patryk Obara --- sha1_file.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 3e2ef4e..8d6960a 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -3655,11 +3655,11 @@ static int index_core(unsigned char

[PATCH 3/6] sha1_file: convert index_path to struct object_id

Convert all remaining callers as well. Signed-off-by: Patryk Obara --- builtin/update-index.c | 2 +- cache.h| 2 +- diff.c | 2 +- notes-merge.c | 2 +- read-cache.c | 2 +- sha1_file.c| 10 +-

[PATCH 1/6] builtin/hash-object: convert to struct object_id

Signed-off-by: Patryk Obara --- builtin/hash-object.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/builtin/hash-object.c b/builtin/hash-object.c index d04baf9..1c0f0f3 100644 --- a/builtin/hash-object.c +++ b/builtin/hash-object.c @@

[PATCH 0/6] Convert hash-object to struct object_id

This enabled conversion of few functions in sha1_file, which had almost all callers converted already. I hope I'm not stepping on anyone's toes with this patch series. If I do - is there some email thread or document in which I can coordinate with other developers, regarding which code regions

What does 'git blame --before -- ' supposed to mean?

Hello all, I tried to do a 'git blame' on a file and wanted to see the blame before a particular revision of that file. I initially didn't know that you could achieve that with, $ git blame I thought I need to pass the revision as a parameter so I tried (before looking into the

FREE DONATION

Hello, I, Elisabeth Mohn intend to give out a Portion of my Wealth as charity hoping it would be of help to you and others too. Respond for confirmation. elisabethmohnfoundat...@gmail.com Si avvisano i

Re: [PATCH] Add 'raw' blob_plain link in history overview

bump? On Wed, Aug 02, 2017 at 08:59:01PM +0200, Job Snijders wrote: > We often work with very large plain text files in our repositories and > found it friendlier to the users if we can click directly to the raw > version of such files. > > This patch adds a 'raw' blob_plain link in history

Re: git-svn: Handling of branches created from subfolders

> On 20. Aug 2017, at 12:27 , Andreas Heiduk wrote: > > Am 19.08.2017 um 14:45 schrieb Jan Teske: >> Is there any way to fix such branches from subfolders in a way that they >> integrate correctly with the converted git repository, without losing any >> (or at least too

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

Jeff King writes: > On Fri, Aug 18, 2017 at 02:26:14PM -0700, Junio C Hamano wrote: > >> * jk/trailers-parse (2017-08-15) 8 commits >> - pretty: support normalization options for %(trailers) >> - t4205: refactor %(trailers) tests >> - pretty: move trailer formatting to

Re: [PATCH 0/2] http: handle curl with vendor backports

Jeff King writes: > On Fri, Aug 11, 2017 at 03:15:06PM -0700, Junio C Hamano wrote: > >> "Tom G. Christensen" writes: >> >> > The curl packages provided by Red Hat for RHEL contain several >> > backports of features from later curl releases. >> > This

Re: git add -p breaks after split on change at the top of the file

Jeff King writes: > So that's one question I'm puzzled by: why does it work without an edit, > but fail with one. As this is the part of the system I long time ago declared a "works only some of the time" hack, I do not recall the exact details, but a key phrase "DIRTY" in the

Re: Add --ignore-missing to git-pack-objects?

Hi Jeff. Thanks a lot for your response. Jeff King wrote: So if I understand correctly, you are only using these for the negative side of the traversal? Yes. Jeff King wrote: rev-list should ignore missing objects in such a case even without --ignore-missing, and I think it may simply be

Re: git fetch with refspec does not include tags?

Jeff King writes: > On Sun, Aug 20, 2017 at 03:47:28AM -0400, Jeff King wrote: > >> Yeah, I don't think we want to go back to the original behavior. I agree >> that it is partially to blame for the inconsistency that started this >> thread, but I think on balance it has saved much

[PATCH v1] convert: display progress for filtered objects that have been delayed

In 2841e8f ("convert: add "status=delayed" to filter process protocol", 2017-06-30) we taught the filter process protocol to delayed responses. These responses are processed after the "Checking out files" phase. If the processing takes noticeable time, then the user might think Git is stuck.

Re: Please fix the useless email prompts

On 20 August 2017 at 19:18, Jeff King wrote: > On Sat, Aug 19, 2017 at 02:02:09PM -0400, Jeffrey Walton wrote: > >> > Hasn't this been asked and answered already? >> > >> > >> > https://public-inbox.org/git/cacbzzx4veod-4a-ek-ubxmfrb1glsvjkxhw51whcsbczdh7...@mail.gmail.com/ >>

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

On 20 August 2017 at 11:40, Jeff King wrote: > -- >8 -- > From: =?UTF-8?q?Martin=20=C3=85gren?= > Subject: [PATCH] doc/interpret-trailers: fix "the this" typo > > Signed-off-by: Jeff King > --- > I put Martin as the author since he noticed

Re: [PATCH/RFC 0/5] Some ThreadSanitizer-results

On 20 August 2017 at 12:06, Jeff King wrote: > On Tue, Aug 15, 2017 at 02:53:00PM +0200, Martin Ågren wrote: > >> I tried running the test suite on Git compiled with ThreadSanitizer >> (SANITIZE=thread). Maybe this series could be useful for someone else >> trying to do the same. I

Re: git-svn: Handling of branches created from subfolders

Am 19.08.2017 um 14:45 schrieb Jan Teske: > Is there any way to fix such branches from subfolders in a way that they > integrate correctly with the converted git repository, without losing any (or > at least too much) history? If this is not possible with git-svn directly, > maybe I could

Re: Please fix the useless email prompts

On Sun, 2017-08-20 at 05:18 -0400, Jeff King wrote: > Ironically, Git used to behave as you requested in 2005. After being > bombarded with complaints about how Git was too lax in creating commits > with bogus ident information, we changed it in 2012. So I don't think > "it's 2017" carries any

Re: Add --ignore-missing to git-pack-objects?

On Tue, Aug 15, 2017 at 12:51:01AM +0200, ch wrote: > Is it possible to add an option akin to git-rev-list's '--ignore-missing' to > git-pack-objects? > > I use git bundles to (incrementally) backup my repositories. My script > inspects > all bundles in the backup and passes their contained

Re: [PATCH/RFC 0/5] Some ThreadSanitizer-results

On Tue, Aug 15, 2017 at 02:53:00PM +0200, Martin Ågren wrote: > I tried running the test suite on Git compiled with ThreadSanitizer > (SANITIZE=thread). Maybe this series could be useful for someone else > trying to do the same. I needed the first patch to avoid warnings when > compiling,

Re: Git *accepts* a branch name, it can't identity in the future?

Thanks, but Johannes has already found the issue and given a solution. Regardless, replying to the questions just for the note. On Sun, 2017-08-20 at 04:33 -0400, Jeff King wrote: > What does "git for-each-ref" say about which branches you _do_ have? > > Also, what platform are you on? > I use

[PATCH] doc: fix typo in sendemail.identity

On Sun, Aug 20, 2017 at 05:40:09AM -0400, Jeff King wrote: > Subject: [PATCH] doc/interpret-trailers: fix "the this" typo Looks like this is a not-uncommon error. Here's another one (not part of the same patch since the interpret-trailers one isn't even in 'master' yet). -- >8 -- Subject:

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

On Fri, Aug 18, 2017 at 02:26:14PM -0700, Junio C Hamano wrote: > * jk/trailers-parse (2017-08-15) 8 commits > - pretty: support normalization options for %(trailers) > - t4205: refactor %(trailers) tests > - pretty: move trailer formatting to trailer.c > - interpret-trailers: add --parse

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

On Fri, Aug 18, 2017 at 02:26:14PM -0700, Junio C Hamano wrote: > * jk/drop-ancient-curl (2017-08-09) 5 commits > - http: #error on too-old curl > - curl: remove ifdef'd code never used with curl >=7.19.4 > - http: drop support for curl < 7.19.4 > - http: drop support for curl < 7.16.0 > -

Re: Please fix the useless email prompts

On Sat, Aug 19, 2017 at 02:02:09PM -0400, Jeffrey Walton wrote: > > Hasn't this been asked and answered already? > > > > > > https://public-inbox.org/git/cacbzzx4veod-4a-ek-ubxmfrb1glsvjkxhw51whcsbczdh7...@mail.gmail.com/ > > Its 2017. I'd like the tools to work for me instead of me working

Re: Git *accepts* a branch name, it can't identity in the future?

On Sun, 2017-08-20 at 10:20 +0200, Johannes Sixt wrote: > It is not Git's fault that your terminal converts an invalid UTF-8 > sequence (that your script produces) to �. Nor is it when you paste that > character onto the command line, that it is passed as a (correct) UTF-8 > character. >

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

On Sat, Aug 19, 2017 at 06:53:26PM +0200, René Scharfe wrote: > Am 19.08.2017 um 07:33 schrieb René Scharfe: > > When read_tree_recursive() encounters a directory excluded by a pathspec > > then it enters it anyway because it might contain included entries. It > > calls the callback function

Re: [PATCH 1/2] http: Fix handling of missing CURLPROTO_*

On Fri, Aug 11, 2017 at 05:30:34PM -0700, Junio C Hamano wrote: > > -#if LIBCURL_VERSION_NUM >= 0x071304 > > +#ifdef CURLPROTO_HTTP > > curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS, > > get_curl_allowed_protocols(0)); > > curl_easy_setopt(result,

Re: [PATCH 0/2] http: handle curl with vendor backports

On Fri, Aug 11, 2017 at 03:15:06PM -0700, Junio C Hamano wrote: > "Tom G. Christensen" writes: > > > The curl packages provided by Red Hat for RHEL contain several > > backports of features from later curl releases. > > This causes problems with current version based

Re: Git *accepts* a branch name, it can't identity in the future?

On Sun, Aug 20, 2017 at 01:21:29PM +0530, Kaartic Sivaraam wrote: > I made a small assumption in the script which turned out to be false. I > thought the unicode prefixes I used corresponded to only two bytes. > This lead to the issue. The unicode character '✓' corresponds to three > characters

Re: Git *accepts* a branch name, it can't identity in the future?

Am 20.08.2017 um 09:51 schrieb Kaartic Sivaraam: I made a small assumption in the script which turned out to be false. I thought the unicode prefixes I used corresponded to only two bytes. This lead to the issue. The unicode character '✓' corresponds to three characters and as a result instead

Re: git add -p breaks after split on change at the top of the file

On Thu, Aug 17, 2017 at 12:22:19PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Of course this is a pretty ridiculous input in the first place. In > > theory it _could_ be figured out, but overlapping hunks like this are > > always going to cause problems (in this case,

Re: git fetch with refspec does not include tags?

On Sun, Aug 20, 2017 at 03:47:28AM -0400, Jeff King wrote: > Yeah, I don't think we want to go back to the original behavior. I agree > that it is partially to blame for the inconsistency that started this > thread, but I think on balance it has saved much more confusion than it > has started.

Git *accepts* a branch name, it can't identity in the future?

Hello all, First of all, I would like to tell that this happened completely by accident and it's partly my mistake. Here's what happened. I recently started creating 'feature branches' a lot for the few patches that I sent to this mailing list. To identify the status of the patch corresponding

Re: git fetch with refspec does not include tags?

On Thu, Aug 17, 2017 at 10:43:12PM +0200, Kevin Daudt wrote: > > No, you are not misunderstanding anything. The "pretend that we > > immediately turned around and fetched" done by "git push" was > > already breaking the predictability, but the change in 1.8.4 made it > > even worse. I am saying

Re: [PATCH] progress: simplify "delayed" progress API

On Sat, Aug 19, 2017 at 10:39:41AM -0700, Junio C Hamano wrote: > We used to expose the full power of the delayed progress API to the > callers, so that they can specify, not just the message to show and > expected total amount of work that is used to compute the percentage > of work performed so

Re: [PATCH v3 00/23] Move exported packfile funcs to its own file

Junio C Hamano writes: > I have to say that this was a painful topic to integrate. > > As you may know, the mk/use-size-t-in-zlib topic is being retracted > and getting rerolled as a larger size_t series, most of which still > needs help in reviewing. > > The