There are still some more possible improvements around this code but
they are orthogonal to this change :
* migrate to approxidate_careful or parse_expiry_date
* maybe make sure only approxidate are used for expiration
Changes in v2:
* improved commit message as suggested by Eric
* failsafe
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>>> On the other hand, for a file-scope static that is likely to stay as a
>>> non-API function but a local helper, it may not be worth it.
>>
>> Oh, do you think that `reset_head()` is likely to stay as non-API
>> function? I found myself
Rafael Ascensão writes:
> The documentation of `--exclude=` option from rev-list and rev-parse
> explicitly states that exclude patterns *should not* start with 'refs/'
> when used with `--branches`, `--tags` or `--remotes`.
>
> However, following this advice results in refereces not being
Fredi Fowler writes:
Here is a space for you to justify the change and sign off your
patch (see Documentation/SubmittingPatches).
> ---
> Subject: Re: [RFC PATCH] Using no- for options instead of duplication
Try to see if you can format the title in ": "
form first, please. I'll come back to
Hello ,
My name is Sgt Major John Dailey. I am here in Afghanistan , I came
upon a project I think we can work together on. I and my partner (1st
Lt. Daniel Farkas ) have the sum of $15 Million United State Dollars
which we got from a Crude Oil Deal in Iraq before he was killed by an
explosion
stead...@google.com writes:
> Currently the client advertises that it supports the wire protocol
> version set in the protocol.version config. However, not all services
> support the same set of protocol versions. When connecting to
> git-receive-pack, the client automatically downgrades to v0 if
Stefan Beller writes:
>> + if (have_advertised_versions_already)
>> + BUG(_("attempting to register an allowed protocol version
>> after advertisement"));
>
> If this is a real BUG (due to wrong program flow) instead of bad user input,
> we would not want to burden the
stead...@google.com writes:
> OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in
> CFLAGS causes lots of build warnings. Using separate CXXFLAGS avoids
> this.
We are not a C++ shop, so allow me to show ignorance about how
projects that are OSS-Fuzz-enabled work. Do they use
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
> messages, as well
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
> messages, as well
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When calling `merge` on a branch that has already been merged, that
> `merge` is skipped quietly, but currently a MERGE_HEAD file is being
> left behind and will then be grabbed by the next `pick` (that did
> not
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The scripted version of the rebase used to execute `git reset --hard`
> when skipping or aborting. When we ported this to C, we did update the
> worktree and some reflogs, but we failed to imitate `git reset
Dear
Good day. This is Kevin from Future Mould and Plastic Technology Co.,Ltd.
We supply plastic products for SUZUKI with high quality and competitive price.
For instance, Dashboard panel, Steering wheel cover, Control Panel, Air
conditioner outlet, Seat fitting, Cup holder, Gloves box, Rear
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Every once in a while, the interactive rebase makes sure that no stale
> files are lying around. These days, we need to include MERGE_HEAD into
> that set of files, as the `merge` command will generate them.
>
>
Jeff King writes:
>> You mean something like
>>
>> v->s = xstrfmt("%"PRIdMAX, (intmax_t)oi->disk_size);
>
> I think elsewhere we simply use PRIuMAX for printing large sizes via
> off_t; we know this value isn't going to be negative.
>
> I'm not opposed to PRIdMAX, which
Johannes Schindelin writes:
>> On the other hand, for a file-scope static that is likely to stay as a
>> non-API function but a local helper, it may not be worth it.
>
> Oh, do you think that `reset_head()` is likely to stay as non-API
> function? I found myself in the need of repeating this
Rafael Ascensão writes:
> But I can see where personal preference starts to play a role here, as
> the logical solution isn't good enough. Which makes the case for being
> able to configure a bit stronger.
Yeah, our preference over time has always been "do not add to our
default color palette
Jeff King writes:
>> I wonder if "The worktree at /local/src/wt1 has this branch checked
>> out" is something the user of %(worktree) atom, or a variant thereof
>> e.g. "%(worktree:detailed)", may want to learn, but because that
>> information is lost when this function returns, such an
Johan Herland writes:
> On Sun, Nov 11, 2018 at 10:49 AM Carlo Marcelo Arenas Belón
> wrote:
>>
>> 511726e4b1 ("builtin/notes: fix premature failure when trying to add
>> the empty blob", 2014-11-09) removed the check for !len but left a
>> call to free the buffer that will be otherwise NULL
Junio C Hamano wrote:
> How about
>
> hint: ignoring an optional IEOT extension
>
> to make it clear that it is totally harmless?
>
> With that, we can add advise.unknownIndexExtension=false to turn all
> of them off with a single switch.
I like it. Expect a patch soon (tonight or
Jonathan Nieder writes:
> We almost obey that convention, but there is a problem: when
> encountering an unrecognized optional extension, we write
>
> ignoring FNCY extension
>
> to stderr, which alarms users.
Then the same comment as 2/3 applies to this step.
Jonathan Nieder writes:
> As with EOIE, popular versions of Git do not support the new IEOT
> extension yet. When accessing a Git repository written by a more
> modern version of Git, they correctly ignore the unrecognized section,
> but in the process they loudly warn
>
> ignoring IEOT
Jonathan Nieder writes:
> Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
> 2018-10-10) Git defaults to writing the new EOIE section when writing
> out an index file. Usually that is a good thing because it improves
> threaded performance, but when a Git repository is shared with
> +index.recordOffsetTable::
> + Specifies whether the index file should include an "Index Entry
> + Offset Table" section. This reduces index load time on
> + multiprocessor machines but produces a message "ignoring IEOT
> + extension" when reading the index using Git versions
On Mon, 12 Nov 2018 at 13:31, Jeff King wrote:
> On Mon, Nov 12, 2018 at 12:47:42AM +0100, Mateusz Loskot wrote:
> >
> > TL;TR: Is this normal a repository migrated to Git LFS inflates multiple
> > times
> > and how to deal with it?
>
> That does sound odd to me. People with more LFS experience
Documentation/technical/index-format explains:
4-byte extension signature. If the first byte is 'A'..'Z' the
extension is optional and can be ignored.
This allows gracefully introducing a new index extension without
having to rely on all readers having support for it. Mandatory
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
ignoring IEOT extension
resulting in confusion
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git repository is shared with older
versions of Git, it
Hi,
Ben Peart wrote:
> Ben Peart (6):
> read-cache: clean up casting and byte decoding
> eoie: add End of Index Entry (EOIE) extension
> config: add new index.threads config setting
> read-cache: load cache extensions on a worker thread
> ieot: add Index Entry Offset Table (IEOT)
From: Johannes Schindelin
When we detect that a `merge` can be skipped because the merged commit
is already an ancestor of HEAD, we do not need to commit, therefore
writing the MERGE_HEAD file is useless.
It is actually worse than useless: a subsequent `git commit` will pick
it up and think
From: Johannes Schindelin
Every once in a while, the interactive rebase makes sure that no stale
files are lying around. These days, we need to include MERGE_HEAD into
that set of files, as the `merge` command will generate them.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 2 ++
1
From: Johannes Schindelin
Since `git rebase -r` was introduced, that is possible. But our
machinery did not think that possible, and failed to say anything about
the rebase in progress when in the middle of a merge.
Let's work around that in the minimal fashion.
Signed-off-by: Johannes
From: Johannes Schindelin
When calling `merge` on a branch that has already been merged, that
`merge` is skipped quietly, but currently a MERGE_HEAD file is being
left behind and will then be grabbed by the next `pick` (that did
not want to create a *merge* commit).
Demonstrate this.
From: Johannes Schindelin
The scripted version of the rebase used to execute `git reset --hard`
when skipping or aborting. When we ported this to C, we did update the
worktree and some reflogs, but we failed to imitate `git reset --hard`'s
behavior regarding files in .git/ such as MERGE_HEAD.
I noticed a couple of weeks ago that I had bogus merge commits after my
rebases, where the original commits had been regular commits.
This set me out on the adventure that is reflected in this patch series.
Of course, the thing I wanted to fix is demonstrated by 1/5 and fixed in
2/5. But while
On Sun, Nov 11, 2018 at 01:33:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
> The users who need protection against git deleting their files the most
> are exactly the sort of users who aren't expert-level enough to
> understand the nuances of how the semantics of .gitignore and "precious"
> are
On 2018.11.12 12:54, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> When editing patches e.g. in `git add -e`, it is quite common that a
> hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing.
>
> This use case was broken by ad6e8ed37bc1 (apply:
On Fri, Nov 09, 2018 at 02:43:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
> As noted in
> https://public-inbox.org/git/87bm7clf4o@evledraar.gmail.com/ and
> https://public-inbox.org/git/87h8gq5zmc@evledraar.gmail.com/ I think
> it's regardless of Jeff's optimization is. O(nothing) is
On Mon, Nov 12, 2018 at 2:45 PM wrote:
>
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
>
On Sun, Nov 11, 2018 at 01:44:43AM -0500, Jeff King wrote:
> > + git fast-export --tag-of-filtered-object=rewrite --all -- bar
> > >output &&
> > + grep -A 1 refs/tags/v0.0.0.0.0.0.1 output | grep -E ^from.0{40}
>
> I don't think "grep -A" is portable (and we don't seem to
On Mon, Nov 12, 2018 at 2:03 PM wrote:
>
> OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in
> CFLAGS causes lots of build warnings. Using separate CXXFLAGS avoids
> this.
>
That makes sense in this context,
> CFLAGS = -g -O2 -Wall
> +CXXFLAGS ?= $(CFLAGS)
... but
On Mon, Nov 12, 2018 at 11:21:51AM -0500, Jeff King wrote:
> No, but they don't even really need to be actual objects. So I suspect
> something like:
>
> git init
> for i in $(seq 256); do
> i=$(printf %02x $i)
> mkdir -p .git/objects/$i
> for j in $(seq --format=%038g 1000); do
When a smart HTTP server sends an error message via pkt-line,
remote-curl will fail to detect the error (which usually results in
incorrectly falling back to dumb-HTTP mode).
This patch adds a check in discover_refs() for server-side error
messages, as well as a test case for this issue.
On Mon, Nov 12, 2018 at 1:49 PM wrote:
>
> Currently the client advertises that it supports the wire protocol
> version set in the protocol.version config. However, not all services
> support the same set of protocol versions. When connecting to
> git-receive-pack, the client automatically
On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 12 2018, Jeff King wrote:
>
>> On Mon, Nov 12, 2018 at 05:01:02PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>>> > There's some obvious hand-waving in the paragraphs above. I would love
>>> > it if somebody with an NFS system could
On Mon, Nov 12 2018, Jeff King wrote:
> On Mon, Nov 12, 2018 at 05:01:02PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > There's some obvious hand-waving in the paragraphs above. I would love
>> > it if somebody with an NFS system could do some before/after timings
>> > with various numbers of
OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in
CFLAGS causes lots of build warnings. Using separate CXXFLAGS avoids
this.
Signed-off-by: Josh Steadmon
---
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index
Currently the client advertises that it supports the wire protocol
version set in the protocol.version config. However, not all services
support the same set of protocol versions. When connecting to
git-receive-pack, the client automatically downgrades to v0 if
config.protocol is set to v2, but
This is a minor iteration on v2, to change an error message to a BUG.
Josh Steadmon (1):
protocol: advertise multiple supported versions
builtin/archive.c | 3 ++
builtin/clone.c| 4 ++
builtin/fetch-pack.c | 4 ++
builtin/fetch.c| 5 ++
builtin/ls-remote.c|
On 2018.11.09 16:10, Stefan Beller wrote:
> From: SZEDER Gábor
>
> Teach `make coccicheck` to avoid patches named "*.pending.cocci" and
> handle them separately in a new `make coccicheck-pending` instead.
> This means that we can separate "critical" patches from "FYI" patches.
> The former
From: Johannes Schindelin
When editing patches e.g. in `git add -e`, it is quite common that a
hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing.
This use case was broken by ad6e8ed37bc1 (apply: reject a hunk that does
not do anything, 2015-06-01) with the good intention
I use git add -e frequently. Often there are multiple hunks and I end up
deleting the + lines and converting the - lines to context lines, as I like
to stage massive changes in an incremental fashion (and commit those staged
changes incrementally, too).
Some time after I invented git add -e, this
On Mon, Nov 12, 2018 at 08:24:59PM +0100, René Scharfe wrote:
> > +void odb_load_loose_cache(struct object_directory *odb, int subdir_nr)
> > +{
> > + struct strbuf buf = STRBUF_INIT;
> > +
> > + if (subdir_nr < 0 ||
>
> Why not make subdir_nr unsigned (like in
Duy Nguyen writes:
> Another thing I'm going to change (if this v1 is in the right
> direction): print different messages for "git checkout -- foo" and
> "git checkout foo -- bar". The first one is "%d paths have been
> reverted" but the second one does different things and probably should
> say
Am 12.11.2018 um 20:32 schrieb Ævar Arnfjörð Bjarmason:
>
> On Mon, Nov 12 2018, René Scharfe wrote:
>> This removes the only user of OBJECT_INFO_IGNORE_LOOSE. #leftoverbits
>
> With this series applied there's still a use of it left in
> oid_object_info_extended()
OK, rephrasing: With that
On Mon, Nov 12, 2018 at 08:32:43PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >>for (ref = *refs; ref; ref = ref->next) {
> >>struct object *o;
> >> - unsigned int flags = OBJECT_INFO_QUICK;
> >>
> >> - if (use_oidset &&
> >> -
Dear Respectfully,
Greetings to you and how are you doing today!
My name is Dr Christian Allione, I am a medical practitioner from Damascus,
Syria. I write to seek for your assistance to help me and my two young
daughters achieve our aim of relocating out of Syria to your country. We are
very
Duy Nguyen writes:
> Is it that different between an exact path name and a pathspec?
> Suppose it is a pathspec (with wildcards) that matches some paths, and
> we happen to have the remote branch origin/, then it is
> still ambiguous whether we should go create branch
> "" or go check out the
On 12/11/2018 15:36, Jeff King wrote:
> On Mon, Nov 12, 2018 at 10:30:55AM -0500, Derrick Stolee wrote:
>
>> On 11/12/2018 9:48 AM, Jeff King wrote:
>>> In preparation for unifying the handling of alt odb's and the normal
>>> repo object directory, let's use a more neutral name. This patch is
On Mon, Nov 12 2018, René Scharfe wrote:
> Am 12.11.2018 um 15:55 schrieb Jeff King:
>> Commit 024aa4696c (fetch-pack.c: use oidset to check existence of loose
>> object, 2018-03-14) added a cache to avoid calling stat() for a bunch of
>> loose objects we don't have.
>>
>> Now that
Am 12.11.2018 um 15:50 schrieb Jeff King:
> --- a/sha1-file.c
> +++ b/sha1-file.c
> @@ -2125,6 +2125,32 @@ int for_each_loose_object(each_loose_object_fn cb,
> void *data,
> return 0;
> }
>
> +static int append_loose_object(const struct object_id *oid, const char *path,
> +
Am 12.11.2018 um 15:55 schrieb Jeff King:
> Commit 024aa4696c (fetch-pack.c: use oidset to check existence of loose
> object, 2018-03-14) added a cache to avoid calling stat() for a bunch of
> loose objects we don't have.
>
> Now that OBJECT_INFO_QUICK handles this caching itself, we can drop the
On Mon, Nov 12, 2018 at 8:02 AM Derrick Stolee wrote:
> This cleanup is actually really valuable, and affects much more than
> this application.
I second this. I'd value this series more for the cleanup than its
application. ;-)
On Mon, Nov 12, 2018 at 8:09 AM Jeff King wrote:
>
> On Mon, Nov 12, 2018 at 10:48:36AM -0500, Derrick Stolee wrote:
>
> > > If the "the first one is the main store, the rest are alternates" bit is
> > > too subtle, we could mark each "struct object_directory" with a bit for
> > > "is_local".
> >
---
Documentation/merge-options.txt | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 63a3fc09548ab..fc1122ded51a0 100644
--- a/Documentation/merge-options.txt
+++
On Mon, Nov 12, 2018 at 7:48 AM Derrick Stolee wrote:
>
[... lots of quoted text...]
Some email readers are very good at recognizing unchanged quoted
text and collapse it, not so at
https://public-inbox.org/git/421d3b43-3425-72c9-218e-facd86e28...@gmail.com/
which I use to read through this
Hi Fredi,
Fredi Fowler wrote:
> Is there any way to create pull request to git man (https://git-scm.com/docs)?
>
> I found there some inconsistencies. For example, almost in all pages
> are using [no-], but at https://git-scm.com/docs/git-merge each
> command (with [no-] or without) write
I've just tried running
bin-wrappers/git rebase -C1 @^
and I get
error: unknown switch `1'
usage: git rebase [-i] [options] [--exec ] [--onto ]
[] []
or: git rebase [-i] [options] [--exec ] [--onto ]
--root []
or: git rebase --continue | --abort | --skip | --edit-todo
...
On Mon, Nov 12, 2018 at 6:47 AM Jeff King wrote:
>
> Using strip_suffix() lets us avoid repeating ourselves. It also makes
> the handling of "/" a bit less subtle (we strip one less character than
> we matched in order to leave it in place, but we can just as easily
> include the "/" when we add
Hi Elijah
It's good to see these patches progressing, I've just got a couple of
comments related to Johannes' points below
On 12/11/2018 16:21, Johannes Schindelin wrote:
> Hi Elijah,
>
> On Wed, 7 Nov 2018, Elijah Newren wrote:
>
>> Interactive rebases are implemented in terms of cherry-pick
On Mon, Nov 12, 2018 at 4:58 AM Jeff King wrote:
> On Sun, Nov 11, 2018 at 12:42:58AM -0800, Elijah Newren wrote:
>
> Maybe I don't understand what you're trying to accomplish. I was
> thinking specifically of your "cat-file can tell you the large objects,
> but you don't know their
On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
> just adding a bunch of color variants. It would be nice if we could just
> do this with a run-time parse_color("bold red") or whatever, but we use
> these as static initializers.
I suggested those colors, but now, I think this needs to
On Mon, Nov 12, 2018 at 7:44 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > @@ -1079,9 +1079,15 @@ static int parse_branchname_arg(int argc, const char
> > **argv,
> >*/
> > int recover_with_dwim = dwim_new_local_branch_ok;
> >
> > -
Hi Ævar,
On Mon, 12 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 12 2018, Johannes Schindelin wrote:
>
> > On Fri, 2 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> Move a 37 line for-loop mess out of "install" and into a helper
> >> script. This started out fairly innocent but over
On Mon, Nov 12, 2018 at 07:46:14AM -0800, Elijah Newren wrote:
> So maybe my commit message should have been something
> more like:
>
> """
> Knowing the original names (hashes) of commits can sometimes enable
> post-filtering that would otherwise be difficult or impossible. In
> particular,
On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > Since the purpose of printing this is to help disambiguate. Only do it
> > when "--" is missing (the actual reason though is many tests check
> > empty stderr to see that no error is raised and I'm too
On Mon, Nov 12, 2018 at 05:01:02PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > There's some obvious hand-waving in the paragraphs above. I would love
> > it if somebody with an NFS system could do some before/after timings
> > with various numbers of loose objects, to get a sense of where the
> >
Hi Elijah,
On Wed, 7 Nov 2018, Elijah Newren wrote:
> Interactive rebases are implemented in terms of cherry-pick rather than
> the merge-recursive builtin, but cherry-pick also calls into the recursive
> merge machinery by default and can accept special merge strategies and/or
> special
On Sun, Nov 11, 2018 at 2:06 PM Ævar Arnfjörð Bjarmason
wrote:
> +Trashable files
> +~~~
> +
> +`trashable`
> +^^
> +
> +Provides an escape hatch for re-enabling a potentially data destroying
> +feature which was enabled by default between Git versions 1.5.2 and
> +2.20. See
On Mon, Nov 12, 2018 at 10:48:36AM -0500, Derrick Stolee wrote:
> > If the "the first one is the main store, the rest are alternates" bit is
> > too subtle, we could mark each "struct object_directory" with a bit for
> > "is_local".
>
> This is probably a good thing to do proactively. We have
On Mon, Nov 12, 2018 at 10:09 AM Matthieu Moy wrote:
> May I remind an idea I sugested in an old thread: add an intermediate level
> where ignored files to be overwritten are renamed (eg. foo -> foo~ like Emacs'
> backup files):
>
> https://public-inbox.org/git/vpqd3t9656k@bauges.imag.fr/
>
>
On 11/12/2018 9:46 AM, Jeff King wrote:
Here's the series I mentioned earlier in the thread to cache loose
objects when answering has_object_file(..., OBJECT_INFO_QUICK). For
those just joining us, this makes operations that look up a lot of
missing objects (like "index-pack" looking for
On Mon, Nov 12 2018, Jeff King wrote:
> In cases where we expect to ask has_sha1_file() about a lot of objects
> that we are not likely to have (e.g., during fetch negotiation), we
> already use OBJECT_INFO_QUICK to sacrifice accuracy (due to racing with
> a simultaneous write or repack) for
On 11/12/2018 9:54 AM, Jeff King wrote:
In cases where we expect to ask has_sha1_file() about a lot of objects
that we are not likely to have (e.g., during fetch negotiation), we
already use OBJECT_INFO_QUICK to sacrifice accuracy (due to racing with
a simultaneous write or repack) for speed (we
On 11/12/2018 10:46 AM, Jeff King wrote:
On Mon, Nov 12, 2018 at 10:38:28AM -0500, Derrick Stolee wrote:
We could go either direction here, but this patch moves the alternates
struct over to the main directory style (rather than vice-versa).
Technically the alternates style is more
On 11/12/2018 9:50 AM, Jeff King wrote:
Our handling of alternate object directories is needlessly different
from the main object directory. As a result, many places in the code
basically look like this:
do_something(r->objects->objdir);
for (odb = r->objects->alt_odb_list; odb; odb =
On Mon, Nov 12, 2018 at 4:53 AM Jeff King wrote:
> On Sun, Nov 11, 2018 at 12:32:22AM -0800, Elijah Newren wrote:
>
> > > > Documentation/git-fast-export.txt | 7 +++
> > > > builtin/fast-export.c | 20 +++-
> > > > fast-import.c | 17
On Mon, Nov 12, 2018 at 10:38:28AM -0500, Derrick Stolee wrote:
> > We could go either direction here, but this patch moves the alternates
> > struct over to the main directory style (rather than vice-versa).
> > Technically the alternates style is more efficient, as it avoids
> > rewriting the
On 11/12/2018 9:49 AM, Jeff King wrote:
When we generate loose file paths for the main object directory, the
caller provides a buffer to loose_object_path (formerly sha1_file_name).
The callers generally keep their own static buffer to avoid excessive
reallocations.
But for alternate
On Mon, Nov 12, 2018 at 4:45 AM Jeff King wrote:
> On Sun, Nov 11, 2018 at 12:01:43AM -0800, Elijah Newren wrote:
>
> > > It does seem funny that the behavior for the earlier case (bounded
> > > commits) and this case (skipping some commits) are different. Would you
> > > ever want to keep
On Mon, Nov 12, 2018 at 10:30:55AM -0500, Derrick Stolee wrote:
> On 11/12/2018 9:48 AM, Jeff King wrote:
> > In preparation for unifying the handling of alt odb's and the normal
> > repo object directory, let's use a more neutral name. This patch is
> > purely mechanical, swapping the type name,
On Mon, Nov 12, 2018 at 1:17 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Thu, Nov 01 2018, Elijah Newren wrote:
>
> > On Wed, Oct 31, 2018 at 12:16 PM Lars Schneider
> > wrote:
> >> > On Sep 24, 2018, at 7:24 PM, Elijah Newren wrote:
> >> > On Sun, Sep 23, 2018 at 6:08 AM Lars Schneider
> >> >
On 11/12/2018 9:48 AM, Jeff King wrote:
Since we're changing the semantics, let's take the opportunity to give
it a more hash-neutral name (which will also catch any callers from
topics in flight).
THANK YOU! This method name confused me so much when I was first looking
at the code, but the
On 11/12/2018 9:48 AM, Jeff King wrote:
In preparation for unifying the handling of alt odb's and the normal
repo object directory, let's use a more neutral name. This patch is
purely mechanical, swapping the type name, and converting any variables
named "alt" to "odb". There should be no
On 11/12/2018 9:46 AM, Jeff King wrote:
The run-command API makes no promises about what is left in a struct
child_process after a command finishes, and it's not safe to simply
reuse it again for a similar command. In particular:
- if you use child->args or child->env_array, they are cleared
Hi Elijah,
On Wed, 7 Nov 2018, Elijah Newren wrote:
> While 'quiet' and 'interactive' may sound like antonyms, the interactive
> machinery actually has logic that implements several
> interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
> which won't pop up an editor. The
Johannes Schindelin writes:
>> Given that the function returns the value obtained from
>> approxidate(), which is approxidate_careful() in disguise, time_t is
>> not as appropriate as timestamp_t, no?
>>
>> IOW, what if time_t were narrower than timestamp_t?
>
> Rght. From the patch, I had
Commit 024aa4696c (fetch-pack.c: use oidset to check existence of loose
object, 2018-03-14) added a cache to avoid calling stat() for a bunch of
loose objects we don't have.
Now that OBJECT_INFO_QUICK handles this caching itself, we can drop the
custom solution.
Note that this might perform
In cases where we expect to ask has_sha1_file() about a lot of objects
that we are not likely to have (e.g., during fetch negotiation), we
already use OBJECT_INFO_QUICK to sacrifice accuracy (due to racing with
a simultaneous write or repack) for speed (we avoid re-scanning the pack
directory).
Hi,
On Mon, 12 Nov 2018, Junio C Hamano wrote:
> Carlo Marcelo Arenas Belón writes:
>
> > b968372279 ("read-cache: unlink old sharedindex files", 2017-03-06)
> > introduced get_shared_index_expire_date using unsigned long to track
> > the modification times of a shared index.
> >
> >
1 - 100 of 167 matches
Mail list logo
