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 separat
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 serie
---
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
+++ b/Documentation/merge
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".
> >
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. ;-)
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
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,
> +
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 OBJECT_INFO_Q
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
>
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 pat
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
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 &&
> >> - !oidset_contains(&loose_oi
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 pat
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
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 for_each_file_in_obj_subdir()),
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 of
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 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 target
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|
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 thi
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 bbfbb4292
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 lo
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 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 downgra
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.
Signed-o
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 out
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 oth
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
> messa
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 always
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: re
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 going
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 at
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.
Le
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 Schindel
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.
Signed-off
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 that
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 fil
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) extens
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 produces
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 for
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
extensi
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 c
> +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 befo
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
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 ex
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.
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 tomorrow
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
Wo
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 enhanceme
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 to
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 tedi
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 _is_
"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.
>
> Signe
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 mirr
"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 --hard`'s
"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 want
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
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
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 transl
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
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 wh
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
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 exclud
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 i
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 again
101 - 167 of 167 matches
Mail list logo
