On Mon, Jan 7, 2019 at 11:25 PM Anthony Sottile wrote:
> Even `git reset --intent-to-add -- a` or `git checkout -- a` don't
> seem to clear the `intent-to-add` state
>
> How do I reset the intent-to-add status in this case?
>
> Anthony
Pressed send too quickly, it appears I can use `git rm --cach
Le mar. 8 janv. 2019 à 07:34, Jeff King a écrit :
>
> On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:
>
> > One of my users reported a strange problem: a simple HTTPS clone did
> > not work with Git 1.8.3.1 on RedHat 7.
> > I did many tests and I was not able to understand why
```
git --version
rm -rf t
git init t
cd t
touch a
git add a
git commit -m "add a"
git rm a
touch a
git add --intent-to-add a
git status --short
git reset -- a
git status --short
```
(the git version below is compiled from
ecbdaf0899161c067986e9d9d564586d4b045d62)
```
$ bash -x t.sh
+ git --versi
Hi git folks, i've hitted the issues around "git svn" command.
I've installed git from git-scm.com and found that the git hangs on
almost any "git svn" command. In mine case it is "git svn init" and "git svn
fetch".
Example: git svn init "https://svn.code.sf.net/p/blabla/blabla"; --stdlayou
On 1/7/19 6:41 PM, Philip Oakley wrote:
On 06/01/2019 22:51, Jacob Kroon wrote:
Hi,
Not sure if this has already been reported, but I observe this odd
behaviour in gitk from master:
git status
gitk # everything looks good
touch
gitk # gitk shows "local uncomitted changes" on the file I touche
On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:
> One of my users reported a strange problem: a simple HTTPS clone did
> not work with Git 1.8.3.1 on RedHat 7.
> I did many tests and I was not able to understand why his clone don't
> work while I'm able to do it on other simila
This tests GIT_CURL_VERBOSE shows an error when an URL returns 500. This
exercises the code in remote_curl.
Signed-off-by: Masaya Suzuki
---
t/lib-httpd/apache.conf | 1 +
t/t5581-http-curl-verbose.sh | 28
2 files changed, 29 insertions(+)
create mode 100755
curl stops parsing a response when it sees a bad HTTP status code and it
has CURLOPT_FAILONERROR set. This prevents GIT_CURL_VERBOSE to show HTTP
headers on error.
keep_error is an option to receive the HTTP response body for those
error responses. By enabling this option, curl will process the HT
By not setting CURLOPT_FAILONERROR, curl parses the HTTP response
headers even if the response is an error. This makes GIT_CURL_VERBOSE to
show the HTTP headers, which is useful for debugging.
Signed-off-by: Masaya Suzuki
---
remote-curl.c | 10 ++
1 file changed, 10 insertions(+)
diff
HTTP_KEEP_ERROR makes it easy to debug HTTP transport errors. In order
to make HTTP_KEEP_ERROR enabled for all requests, file handles need to
be supported.
Signed-off-by: Masaya Suzuki
---
http.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/http.c b/http.c
index 0
Diff from v2[1]:
* Remove http_resonse_dest
This was introduced to have a filename for freopen. Jeff King proposed [2]
using fflush and ftruncate and this makes this struct not needed.
* Unset CURLOPT_FAILONERROR only when it's necessary.
Previously, CURLOPT_FAILONERROR was unse
In order to pass more values for rpc_in, define a struct and pass it as
an additional value.
Signed-off-by: Masaya Suzuki
---
remote-curl.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index d8eda2380a..d4673b6e8c 100644
--
> -static void filter_trees_update_omits(
> +static int filter_trees_update_omits(
> struct object *obj,
> struct filter_trees_depth_data *filter_data,
> int include_it)
> {
> if (!filter_data->omits)
> - return;
> + return 1;
>
> if (include
Thanks - as stated in your commit message, this adds quite a useful
piece of functionality.
> - case LOFS_BEGIN_TREE:
> - case LOFS_BLOB:
> - if (filter_data->omits) {
> - oidset_insert(filter_data->omits, &obj->oid);
> - /* _MARK_SEEN bu
On 2018/12/11 0:45, Junio C Hamano wrote:
This seems to require at least two topics still not in 'master';
I've bookmarked the topic by merging sb/more-repo-in-api and
nd/the-index into 'master' and then queueing these two patches on
top, to be able to merge it into 'pu' to see if there are bad
> git-p4 can map a "git move" operation to a Perforce "move" operation.
> But by default this is disabled. You then end up with a P4 commit
> where the file is deleted, and a fresh file is created with the same
> contents at the new location at revision #1.
>
> Rename detection gets enabled either
When communicating with a remote server or a subprocess, use expanded
numbers rather than abbreviated numbers in the object filter spec (e.g.
"limit:blob=1k" becomes "limit:blob=1024").
Update the protocol docs to note that clients should always perform this
expansion, to allow for more compatibil
NOTE: this patch is based on top of md/list-objects-filter-by-depth
Currently, git clients pass filter specs verbatim over the network and
to subprocesses. We support various scaling suffixes for parameters on
these limits (via git_parse_ulong()), but other implementations may not
support the same
On Sun, 6 Jan 2019 at 22:48, Peter Osterlund wrote:
> Hi,
>
> When I use "git p4 sync" to update a git repository from a perforce depot,
> the operation fails with error message:
>
> failure accessing depot: unknown error code info
>
I guess, this got broken in
commit 0ef67acdd78 ("git-p4
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 'master' branch now has the fi
On Fri, Jan 4, 2019 at 2:49 AM Jeff King wrote:
>
> On Sat, Dec 29, 2018 at 11:44:47AM -0800, Masaya Suzuki wrote:
>
> > When GIT_CURL_VERBOSE is set, libcurl produces request/response headers
> > to stderr. However, if the response is an error response and
> > CURLOPT_FAILONERROR is set, libcurl
Barret Rhoden writes:
> Commits that make formatting changes or renames are often not
> interesting when blaming a file. This commit, similar to
> git-hyper-blame, allows one to specify certain revisions to ignore during
> the blame process.
>
> To ignore a revision, put its committish in a file
+us...@cvs2svn.tigris.org
paduarte wrote:
Hi,
> How did the complete command work?
>
> cvs2git --encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin
>
> or
>
> cvs2git --encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin
> *+ parameters of git*
>
> ?
Cc-ing the cvs2gi
On 2018.12.29 13:19, Masaya Suzuki wrote:
> In the Git pack protocol definition, an error packet may appear only in
> a certain context. However, servers can face a runtime error (e.g. I/O
> error) at an arbitrary timing. This patch changes the protocol to allow
> an error packet to be sent instead
On 2018.12.29 13:19, Masaya Suzuki wrote:
> By using and sharing a packet_reader while handling a Git pack protocol
> request, the same reader option is used throughout the code. This makes
> it easy to set a reader option to the request parsing code.
>
> Signed-off-by: Masaya Suzuki
> ---
> bui
+jgit-dev
Hi Robin,
Robin Shen wrote:
> Dear git users,
>
> OneDev is an open source git server with interesting features such
> as language aware code search/navigation, issue workflow
> customization, free source/diff comment and discussion, etc.
>
> It is using MIT license and hope it can be u
Luke Diamand writes:
> On Mon, 7 Jan 2019 at 20:51, Peter Osterlund
> wrote:
>>
>> In a perforce setup where login is not required, communication fails
>> because p4_check_access does not understand the response from the p4
>> client. Fixed by detecting and ignoring the "info" response.
>
> Thi
Junio C Hamano writes:
> Josh Steadmon writes:
>
>>> > - `rev-list` for possible "filter-spec" values.
>>> > + `rev-list` for possible "filter-spec" values. Clients MUST
>>> > + translate abbreviated numbers (e.g. "1k") into fully-expanded
>>> > + numbers (e.g. "1024") on the client side, so tha
Josh Steadmon writes:
>> > - `rev-list` for possible "filter-spec" values.
>> > + `rev-list` for possible "filter-spec" values. Clients MUST
>> > + translate abbreviated numbers (e.g. "1k") into fully-expanded
>> > + numbers (e.g. "1024") on the client side, so that the server
>> > + does no
On Mon, 7 Jan 2019 at 20:51, Peter Osterlund wrote:
>
> In a perforce setup where login is not required, communication fails
> because p4_check_access does not understand the response from the p4
> client. Fixed by detecting and ignoring the "info" response.
This is caused by my earlier change in
Commits that make formatting changes or renames are often not
interesting when blaming a file. This commit, similar to
git-hyper-blame, allows one to specify certain revisions to ignore during
the blame process.
To ignore a revision, put its committish in a file specified by
--ignore-file= or use
On 2019.01.02 15:15, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > When communicating with a remote server or a subprocess, use expanded
> > numbers rather than abbreviated numbers in the object filter spec (e.g.
> > "limit:blob=1k" becomes "limit:blob=1024").
> >
> > Update the protocol do
Junio C Hamano wrote:
> Thomas Gummerer writes:
>>> From: Thomas Gummerer
>>> Date: Fri, 12 Oct 2018 19:40:37 +0100
>>> Subject: [PATCH] config.mak.dev: add -Wformat
>
> Thanks. I noticed, before merging the topic to 'next', that I
> needed to retitle this further. I'd use something like this.
It sounds good!
I was using git version 2.7.4 all the time. I should have checked
before posting here :)
Now trying 2.20.1
>From "git help rebase":
By default, or when no-rebase-cousins was specified,
commits which do not have as direct ancestor will keep
their
original bra
In a perforce setup where login is not required, communication fails
because p4_check_access does not understand the response from the p4
client. Fixed by detecting and ignoring the "info" response.
Signed-off-by: Peter Osterlund
---
git-p4.py | 2 ++
1 file changed, 2 insertions(+)
diff --g
Dear fellow translators,
I'm trying to put up a longstanding project of providing translated manual
pages for Git. After several experiments, the best choice seemed to be the use
of po4a[1] to convert the asciidoc[2] sources of git manpages into po files
that could be processed the same way we
Hi,
On Mon, Jan 7, 2019 at 12:11 PM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > Elijah Newren writes:
> >
> >> On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren wrote:
> >>>
> >>> This series continues the work of making rebase more self-consistent
> >>> by removing inconsistencies betw
Junio C Hamano writes:
> Elijah Newren writes:
>
>> On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren wrote:
>>>
>>> This series continues the work of making rebase more self-consistent
>>> by removing inconsistencies between different backends. In
>>> particular, this series focuses on making the
Elijah Newren writes:
> On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren wrote:
>>
>> This series continues the work of making rebase more self-consistent
>> by removing inconsistencies between different backends. In
>> particular, this series focuses on making the merge machinery behave
>> like t
Alyssa Ross writes:
> If I detach my head, then use `git subtree add` to generate a commit,
> the output from `git status` changes from "detached at SHA" to
> "detached from SHA". The sha doesn't change, but HEAD has updated.
This is expected, and there is nothing to "recover from". Use of
"git
First of all, there was some discussion [1] about its relation with
js/smart-http-detect-remote-error. I noticed that
js/smart-http-detect-remote-error has all tests passing even if I remove
Masaya's patch, so I'm reviewing these patches independently, directly on
master.
[1]
https://public-inbox
René Scharfe writes:
> Inline odb_load_loose_cache() into its only remaining caller,
> odb_loose_cache(). The latter offers a nicer interface for loading the
> cache, as it doesn't require callers to deal with fanout directory
> numbers directly.
>
> Signed-off-by: Rene Scharfe
> ---
OK, that'
Jean-Noël AVILA writes:
>> The idea is to use $(filter PATTERN..., TEXT) that removes words in
>> TEXT that do not match any of the words in PATTERN, and for normal
>> build, MAN_FILTER is set identical to TMP_MAN_TXT (which is the
>> original MAN_TXT), so there is no filtering happen, but in a b
René Scharfe writes:
> Am 28.12.2018 um 19:04 schrieb Junio C Hamano:
>> * jk/loose-object-cache (2018-11-24) 10 commits
> ...
> So this has hit master in the meantime. We discussed a sort performance
> fix in [1]; I'll reply with a short series containing a cleaned-up and
> rebased version as a
Changes are described in CHANGES.
Contributions-by: Matthieu Moy
Contributions-by: William Stewart
Contributions-by: Ville Skyttä
Contributions-by: Dirk Olmes
Contributions-by: Björn Kautler
Contributions-by: Konstantin Ryabitsev
Contributions-by: Gareth Pye
Contributions-by: David Lazar
S
From: Jean-Noel Avila
The standard doc lists can be filtered to allow using the compilation
rules with translated manpages where all the pages of the original
version may not be present.
The install variable are reused in the secondary repo so that the
configured paths can be used for translated
nbelakov...@gmail.com writes:
> From: Nickolai Belakovski
>
> ---
All three patches lack sign off.
I am fairly negative on 2/3, but I think this one makes sense
without introducing a new verbosity level. We do not promise
stability of Porcelain command output and update the UI if we
have usefu
nbelakov...@gmail.com writes:
> From: Nickolai Belakovski
>
> In order to more clearly display which branches are active, the output
> of git branch is modified to mark branches checkout out in a linked
> worktree with a "+" and color them in cyan (in contrast to the current
> branch, which will
> By using and sharing a packet_reader while handling a Git pack protocol
> request, the same reader option is used throughout the code. This makes
> it easy to set a reader option to the request parsing code.
I see that packet_read() and packet_read_line_buf() invocations are also
removed, so it
nbelakov...@gmail.com writes:
> +static struct hashmap ref_to_worktree_map;
> +static struct worktree **worktrees = NULL;
> +
> /*
> * An atom is a valid field atom listed below, possibly prefixed with
> * a "*" to denote deref_tag().
> @@ -420,6 +438,34 @@ static int head_atom_parser(const s
On 06/01/2019 22:51, Jacob Kroon wrote:
Hi,
Not sure if this has already been reported, but I observe this odd
behaviour in gitk from master:
git status
gitk # everything looks good
touch
gitk # gitk shows "local uncomitted changes" on the file I touched
git status
gitk # gitk is back to norma
Am 07.01.2019 um 14:26 schrieb René Scharfe:
> Yes, the functions are arranged so that odb_load_loose_cache() can be
> inlined easily. I meant to include a patch for that but then quibbled
> about keeping the BUG check (which is probably optimized out) or not,
> and dropped it for now to get the p
Inline odb_load_loose_cache() into its only remaining caller,
odb_loose_cache(). The latter offers a nicer interface for loading the
cache, as it doesn't require callers to deal with fanout directory
numbers directly.
Signed-off-by: Rene Scharfe
---
object-store.h | 7 ---
sha1-file.c|
Junio C Hamano writes:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
>> While the scripted `git rebase` still has to rely on the
>> `git-rebase--am.sh` script to implement the glue between the `rebase`
>> and the `am` commands, we can go a more direct route in the built-in
>> rebase and a
Jean-Noël Avila writes:
> +ifdef MAN_FILTER
> +MAN_TXT = $(filter $(MAN_FILTER),$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
> +else
> MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
> +MAN_FILTER = $(MAN_TXT)
> +endif
OK.
> OBSOLETE_HTML += everyday.html
> OBSOLETE_HTML += git-remote-helpers.html
> -
On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren wrote:
>
> This series continues the work of making rebase more self-consistent
> by removing inconsistencies between different backends. In
> particular, this series focuses on making the merge machinery behave
> like the interactive machinery (thoug
Hi Dscho,
On Thu, Jan 3, 2019 at 5:27 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
...
> > I was going to re-ping in early January. Anyway, it may be worth at
> > least updating your note to "reroll exists".
>
> It is early January! ;-)
Indeed...ping incoming. :-)
>
> Ciao,
> Dscho
Thomas Gummerer writes:
> I agree with the choice of adding -Wall to the CFLAGS here, so even if
> it is not added to the CFLAGS generated by autoconf (or in mnually set
> up CFLAGS such as in my original case), we still get a complete set of
> warnings when DEVELOPER=YesPlease is set.
>
>> -- >8
Thomas Gummerer writes:
> Maybe it would be enough to say "... `git checkout` never removes
> files, that are not in the tree being checked out, from the index or
> the working tree"? It is more technically correct, but dunno making
> the sentence harder to read is worth it.
Yeah, I share the s
map_sha1_file_1() checks if the file it is about to mmap() is empty and
errors out in that case and explains the situation in an error message.
It leaks the private handle to that empty file, though.
Have the function clean up after itself and close the file descriptor
before exiting early.
Signe
Andreas Hennings writes:
> This means we need a rebase operation where:
> - The commits of the acceptance branch itself are being replaced.
> - The commits of the feature branches remain as they are.
>
> A "git rebase --preserve-merges" almost does this, but not really.
This wished-for feature s
If I detach my head, then use `git subtree add` to generate a commit,
the output from `git status` changes from "detached at SHA" to
"detached from SHA". The sha doesn't change, but HEAD has updated.
I don't understand why `git status` doesn't tell me that I'm
"detached at" the sha of the new comm
On 22/12/2018 23:12, brian m. carlson wrote:
Thanks Brian, you helped me make some progress. I'm stuck again trying
to understand git behaviour though and wondering if there are better
ways of me seeing into git (source, debug o/p etc) than posting here.
As a reminder, I'm doing the following to c
Jeff King writes:
> Yep, this looks good to me. Thanks for being extra careful with the
> read/printf bits!
>
> Looks like Junio already queued a99653a9b6 (Revert "t/lib-git-daemon:
> record daemon log", 2018-12-28) on the tip of tg/t5570-drop-racy-test,
> but that's a pure revert. I think we can
Hi supadhyay
How did the complete command work?
cvs2git --encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin
or
cvs2git --encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin
*+ parameters of git*
?
Tks
:)
--
Sent from: http://git.661346.n2.nabble.com/
Hello,
(this is my first message on this list, so hello everybody. I hope I
found the correct channel.)
I recently discovered the --preserve-merges option in git rebase,
I think it is nice, but it does not always do what I intend.
I am proposing a variation of this option which would behave diffe
Am 07.01.2019 um 09:27 schrieb Jeff King:
> On Sun, Jan 06, 2019 at 05:45:30PM +0100, René Scharfe wrote:
>> diff --git a/object-store.h b/object-store.h
>> index 60758efad8..7236c571c0 100644
>> --- a/object-store.h
>> +++ b/object-store.h
>> @@ -54,6 +54,13 @@ void add_to_alternates_memory(const
On Sat, Jan 5, 2019 at 9:34 PM Martin Ågren wrote:
>
> On Sat, 5 Jan 2019 at 07:07, Nguyễn Thái Ngọc Duy wrote:
> >
> > hold_locked_index() assumes the index path at $GIT_DIR/index. This is
> > not good for places that take an arbitrary index_state instead of
> > the_index, which is basically eve
Am 07.01.2019 um 13:30 schrieb Jeff King:
> On Mon, Jan 07, 2019 at 11:27:06AM +, Philip Oakley wrote:
>
>> On 06/01/2019 16:45, René Scharfe wrote:
>>> Add and use a function for loading the entries if a loose object
>>> subdirectory for a given object ID.
>>
>> The second part of the sentenc
On Sun, Jan 6, 2019 at 10:46 PM Christian Couder
wrote:
>
> It looks like it is a copy-paste error made in 80f2a6097c
> (t/helper: add test-ref-store to test ref-store functions,
> 2017-03-26) to pass "old-sha1" instead of "new-sha1" to
> notnull() when we get the new sha1 argument from
> const c
git-p4 can map a "git move" operation to a Perforce "move" operation.
But by default this is disabled. You then end up with a P4 commit
where the file is deleted, and a fresh file is created with the same
contents at the new location at revision #1.
Rename detection gets enabled either with the "-
On Mon, Jan 07, 2019 at 11:27:06AM +, Philip Oakley wrote:
> On 06/01/2019 16:45, René Scharfe wrote:
> > Add and use a function for loading the entries if a loose object
> > subdirectory for a given object ID.
>
> The second part of the sentence 'a loose object subdirectory for a given
> obj
Dear git users,
OneDev is an open source git server with interesting features such as language
aware code search/navigation, issue workflow customization, free source/diff
comment and discussion, etc.
It is using MIT license and hope it can be useful to someone. Learn more at
https://onede
On 06/01/2019 16:45, René Scharfe wrote:
Add and use a function for loading the entries if a loose object
subdirectory for a given object ID.
The second part of the sentence 'a loose object subdirectory for a given
object ID' does not scan for me. Is there a word missing?
It frees caller
On Sun, 6 Jan 2019 at 22:48, Peter Osterlund wrote:
>
> Hi,
>
> When I use "git p4 sync" to update a git repository from a perforce depot,
> the operation fails with error message:
>
> failure accessing depot: unknown error code info
>
> When I run "p4 login -s" from a shell it reports:
>
>
Reply to my private email: alicewalt...@protonmail.com
Yes, you are right. I will revert this back.
On Fri, Jan 4, 2019 at 8:08 PM Ramsay Jones wrote:
>
>
>
> On 02/01/2019 15:38, Tanushree Tumane via GitGitGadget wrote:
> [snip]
> > base-commit: 7f4e64169352e03476b0ea64e7e2973669e491a2
> > Published-As:
> > https://github.com/gitgitgadget/git/relea
On Sat, Jan 05, 2019 at 02:08:51AM +0100, SZEDER Gábor wrote:
> To recap: this patch series tries to make reproducing rare failures in
> flaky tests easier: it adds the '--stress' option to our test library
> to run the test script repeatedly in multiple parallel jobs, in the
> hope that the incre
To future-proof ourselves against a change in the hash, let's use the
more generic "hash mismatch" to refer to integrity problems. Note that
we do advertise this exact string in git-fsck(1). However, the message
itself is marked for translation, meaning we do not expect it to be
machine-readable.
There are no callers left of has_sha1_file() or its with_flags()
variant. Let's drop them, and convert has_object_file() from a wrapper
into the "real" function. Ironically, the sha1 variant was just copying
into an object_id internally, so the resulting code is actually shorter!
We can also drop
When we're reporting an error for a loose object, let's use that term.
It's more consistent with other parts of Git, and it is future-proof
against changes to the hash function.
Signed-off-by: Jeff King
---
sha1-file.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sha
These error messages say "sha1 file", which is vague and not common in
user-facing documentation. Unlike the conversions from the previous
commit, these do not always refer to loose objects.
In finalize_object_file() we could be dealing with a packfile. Let's
just say "unable to write file" instea
The only remaining callers of has_sha1_file() actually have an object_id
already. They can use the "object" variant, rather than dereferencing
the hash themselves.
The code changes here were completely generated by the included
coccinelle patch.
Signed-off-by: Jeff King
---
apply.c
These two static functions, read_object() and quick_has_loose(), both
have to hashcpy() their bare-sha1 arguments into object_id structs to
pass them along. Since all of their callers actually have object_id
structs in the first place, we can eliminate the copying by adjusting
their input parameter
As with the open/map/close functions for loose objects that were
recently converted, the functions for parsing the loose object stream
use the name "sha1" and a bare "unsigned char *". Let's fix that so that
unpack_sha1_header() becomes unpack_loose_header(), etc.
These conversions are less clear-
The loose object access code in sha1-file.c is some of the oldest in
Git, and could use some modernizing. It mostly uses "unsigned char *"
for object ids, which these days should be "struct object_id".
It also uses the term "sha1_file" in many functions, which is confusing.
The term "loose_objects
The dumb-http walker code still passes around and stores object ids as
"unsigned char *sha1". Let's modernize it.
There's probably still more work to be done to handle dumb-http fetches
with a new, larger hash. But that can wait; this is enough that we can
now convert some of the low-level object
Commit 17e65451e3 (sha1_file: convert check_sha1_signature to struct
object_id, 2018-03-12) switched to using the name "oid", but forgot to
update the variable name in the comment.
Likewise, b4f5aca40e (sha1_file: convert read_sha1_file to struct
object_id, 2018-03-12) dropped the name read_sha1_f
Commit abef9020e3 (sha1_file: convert sha1_object_info* to object_id,
2018-03-12) renamed the function to oid_object_info(), but missed some
comments which mention it.
Signed-off-by: Jeff King
---
builtin/cat-file.c | 6 +++---
builtin/pack-objects.c | 4 ++--
cache.h| 2 +-
On Sun, Jan 06, 2019 at 05:39:14PM +0100, René Scharfe wrote:
> Am 28.12.2018 um 19:04 schrieb Junio C Hamano:
> > * jk/loose-object-cache (2018-11-24) 10 commits
> > (merged to 'next' on 2018-12-28 at 5a5faf384e)
> > + odb_load_loose_cache: fix strbuf leak
> > + fetch-pack: drop custom loose
On Sun, Jan 06, 2019 at 05:45:30PM +0100, René Scharfe wrote:
> Add and use a function for loading the entries if a loose object
> subdirectory for a given object ID. It frees callers from deriving the
> fanout key; they can use the returned oid_array reference for lookups or
> forward range scan
On Sun, Jan 06, 2019 at 05:53:10PM +, Thomas Gummerer wrote:
> This reverts commit 314a73d658 (t/lib-git-daemon: record daemon log,
> 2018-01-25), which let tests use the output of git-daemon.
>
> The previous commit removed the last user of deamon.log in the tests,
> there's no good way to m
92 matches
Mail list logo
