* Re: [PATCH] grep: die gracefully when outside repository
From: Kristoffer Haugsbakk @ 2023-10-15 8:00 UTC (permalink / raw)
To: Jeff King; +Cc: git, ks1322 ks1322
In-Reply-To: <20231015032636.GC554702@coredump.intra.peff.net>
On Sun, Oct 15, 2023, at 05:26, Jeff King wrote:
> Is it even reasonable for "grep --no-index" to care about leaving the
> tree in the first place? That is, is there a reason we should not allow:
>
> git grep --no-index foo ../bar
>
> ?
On second thought yeah, it doesn't make sense. We are outside of any
repository already so what does it matter where the file is relative to
the current working directory?
It seems that `pathspec.c:init_pathspec_item` should let you through in
this case.
--
Kristoffer Haugsbakk
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Sebastian Thiel @ 2023-10-15 7:33 UTC (permalink / raw)
To: Elijah Newren; +Cc: Josh Triplett, Junio C Hamano, git
In-Reply-To: <CABPp-BEg6vxiUpcJAG_=KB_sTrVgCF19JZh-+ZGCTPXdbo9ekg@mail.gmail.com>
Thanks so much Elijah for your eye-opening response. Thus far I was both
naive and ignorant about the complexity of the matter, and also never
asked the question as to why it wasn't tackled earlier since it came up
already.
Since so many areas of git are affected by precious files, it seems that
rolling it out with everything working is unrealistic and I wonder if
it even had to be behind a feature toggle at first.
A particularly interesting question brought up here also was the question
of what's more important: untracked files, or precious files? Are they
effectively treated the same, or is there a difference?
In any case, it seems easiest to set the desired syntax for such a
feature and/or validate it, and then devise a plan for how it could all
come together.
On 15 Oct 2023, at 8:44, Elijah Newren wrote:
> Hi,
>
> On Fri, Oct 13, 2023 at 11:00 PM Josh Triplett <josh@joshtriplett.org> wrote:
>>
>> On Tue, Oct 10, 2023 at 10:02:20AM -0700, Junio C Hamano wrote:
>>> Sebastian Thiel <sebastian.thiel@icloud.com> writes:
>>>
>>>> I'd like to propose adding a new standard gitattribute "precious".
>>>
>>> ;-).
>>>
>>> Over the years, I've seen many times scenarios that would have been
>>> helped if we had not just "tracked? ignored? unignored?" but also
>>> the fourth kind [*]. The word "ignored" (or "excluded") has always
>>> meant "not tracked, not to be tracked, and expendable" to Git, and
>>> "ignored but unexpendable" class was missing. I even used the term
>>> "precious" myself in those discussions. At the concept level, I
>>> support the effort 100%, but as always, the devil will be in the
>>> details.
>>
>> "I've already wanted this for years" is, honestly, the best response we
>> could *possibly* have hoped for.
>>
>>> Scenarios that people wished for "precious" traditionally have been
>>>
>>> * You are working on 'master'. You have in your .gitignore or
>>> .git/info/exclude a line to ignore path A, and have random
>>> scribbles in a throw-away file there. There is another branch
>>> 'seen', where they added some tracked contents at path A/B. You
>>> do "git checkout seen" and your file A that is an expendable file,
>>> because it is listed as ignored in .git/info/exclude, is removed
>>> to make room for creating A/B.
>>
>> Ouch, I hadn't even thought about the issue of branch-switching
>> overwriting a file like that, but that's another great reason to have
>> "precious". (I've been thinking about "precious" as primarily to protect
>> files like `.config`, where they'd be unlikely to be checked in on any
>> branch because they have an established purpose in the project. Though,
>> of course, people *do* sometimes check in `.config` files in
>> special-purpose branches that aren't meant for upstreaming.)
>
> If we're going to implement precious files, I think we should take a
> step back and figure out what parts of the system are affected. It's
> way more than branch switching and `git clean`. Some notes (including
> some useful implementation pointers):
>
> A) You will probably learn a lot and get a leg up on the
> implementation by grepping for "preserve_ignored"; lots of the
> plumbing has already been created related to this.
>
> B) checkout has a --no-overwrite-ignore, which for checkout
> operations, essentially turns all ignored files into precious files.
> B1) The code behind --no-overwrite-ignore will probably be helpful in
> your implementation of precious files
> B2) What happens to this --no-overwrite-ignore option?
> Deprecate/remove it after adding precious files, since precious files
> now serve that purpose? Keep the flag anyway? What happens to the
> docs around the flag?
> B3) If we keep --no-overwrite-ignore, do we also need to add a
> --overwrite-precious option to allow those to be similarly tweaked?
>
> C) merge has a --no-overwrite-ignore option, which for supported merge
> operations (which are sadly very few), essentially turns all ignored
> files into precious files.
> C1) Same comments as A1-A3 but for merges
> C2) Sadly, merge's --no-overwrite-ignore is almost garbage.
> builtin/merge.c will only pass this option to the "fast-forward" merge
> backend, causing any other type of merge to overwrite ignored files
> despite any such flag.
> C3) most merge backends don't have logic to handle
> --no-overwrite-ignore even if they were passed it, and would need
> explicit support added.
> C4) merge-ort would only essentially need a one-liner; it basically
> has the code in place and a comment but the flag was never plumbed
> through
> C5) it'd be a herculean effort to support this with merge-recursive,
> and a sisyphean effort to attempt to maintain. Deprecating and
> removing merge-recursive is probably a better option
> C6) merge-resolve and merge-octopus could probably be handled
> automatically by ensuring `git read-tree` gained support for it.
> C7) there'd be no way to ensure user-written merge algorithms would
> support it, but that's kind of a general problem with user-written
> anythings
>
> D) git ls-files would need to have a way to query for precious files,
> much as it can currently be used to query for ignored files (or
> tracked files, or conflicted file, or skip-worktree files, or...).
> Backward compatibility questions arise about whether precious files
> should appear in `git ls-files -o` output.
>
> E) git status has an --ignored option, with multiple flags for
> controlling it. We'll likely need more flags to be able to pick out
> precious files.
>
> F) We'd probably need to look through several other commands and look
> at what they need for special handling. e.g., am, stash, reset. I
> suspect stash will be a particularly sore point, as its unfortunate
> design of implementing shell in C code and attempting to decompose the
> command in terms of other high-level commands is basically a leaky
> abstraction that is very likely to be susceptible to edge and corner
> cases here. (In fact, I think I may have left some of the issues for
> untracked/ignored files in stash broken when I was fixing such
> problems for other commands.)
>
> G) Documentation. Commands like `git reset --hard`, `git checkout
> -f`, and `read-tree --reset` are documented to nuke untracked files
> specifically because we expect most commands to preserve untracked
> files. These would need to mention that "precious" files are also
> nuked (or, if we don't nuke them, why precious-and-ignored files are
> more precious than untracked files).
>
> H) Design of `reset --hard`. As per
> https://lore.kernel.org/git/xmqqr1e2ejs9.fsf@gitster.g/, `git reset
> --hard` is a little funny and we have thought about changing it. Will
> the addition of "precious" objects provide more impetus to do so, and
> should a migration story be part of such a new feature?
>
> I) Although git's stated behavior was to nuke ignored files and
> protect untracked files, just a couple years ago we found _many_ bugs
> where Git didn't do that. A series was pushed to fix most of those[1]
> (incidentally, the same series the introduced the preserve_ignored
> flag I pointed you to earlier), but it left a few things
> commented/broken. The cover letter and some emails in the thread also
> discussed in more detail some of the ramifications around a "precious"
> setting. It may be worth reading to catch other things to cover and
> think about.
>
> J) To implement this feature, you're going to have to touch dir.c.
> Good luck with that. (Seriously, good luck. The more people that
> touch it that aren't me, the less I'll be pinged/queried about that
> monstrosity.)
>
>
>>> In any case, the "precious" paths are expected to be small minority
>>> of what people never want to "git add" or "git commit", so coming up
>>> with a special syntax to be used in .gitignore, even if that special
>>> syntax is ugly and cumbersome to type, would be perfectly OK.
>>
>> [Following up both to this and to Sebastian's response.]
>>
>> One potentially important question: should the behavior of old git be to
>> treat precious files as ignored, or as not-ignored? If the syntax were
>> something like
>>
>> $.config
>>
>> then old git would treat the file as not-ignored. If the syntax were
>> something like
>>
>> $precious
>> .config
>>
>> then old git would treat the file as ignored.
>>
>> Seems like it would be obtrusive if `git status` in old git showed the
>> file, and `git add .` in old git added it.
>
> A very good set of questions, along similar lines as the question
> about `git ls-files -o` handling.
>
>
> Anyway, I'm a bit worried after digging up and dumping all these
> concerns on you, that it'll sound like I'm trying to bury the feature
> and discourage folks. In the past I have been against this at times,
> but mostly because it looked like lots of work, I didn't want to touch
> dir.c anymore, and I was worried we'd add a bunch more edge & corner
> cases to the code (when we already had plenty with our more limited
> number of file types). In a way, the preserve_ignored stuff kind of
> made this a lot more reasonable for us to switch to. But I do still
> think it's a fair amount of work, and I am kind of worried about
> potential new edge and corner case.
>
>
> Hope that helps,
> Elijah
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Elijah Newren @ 2023-10-15 6:44 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, Sebastian Thiel, git
In-Reply-To: <ZSouSI_zPusOefsv@localhost>
Hi,
On Fri, Oct 13, 2023 at 11:00 PM Josh Triplett <josh@joshtriplett.org> wrote:
>
> On Tue, Oct 10, 2023 at 10:02:20AM -0700, Junio C Hamano wrote:
> > Sebastian Thiel <sebastian.thiel@icloud.com> writes:
> >
> > > I'd like to propose adding a new standard gitattribute "precious".
> >
> > ;-).
> >
> > Over the years, I've seen many times scenarios that would have been
> > helped if we had not just "tracked? ignored? unignored?" but also
> > the fourth kind [*]. The word "ignored" (or "excluded") has always
> > meant "not tracked, not to be tracked, and expendable" to Git, and
> > "ignored but unexpendable" class was missing. I even used the term
> > "precious" myself in those discussions. At the concept level, I
> > support the effort 100%, but as always, the devil will be in the
> > details.
>
> "I've already wanted this for years" is, honestly, the best response we
> could *possibly* have hoped for.
>
> > Scenarios that people wished for "precious" traditionally have been
> >
> > * You are working on 'master'. You have in your .gitignore or
> > .git/info/exclude a line to ignore path A, and have random
> > scribbles in a throw-away file there. There is another branch
> > 'seen', where they added some tracked contents at path A/B. You
> > do "git checkout seen" and your file A that is an expendable file,
> > because it is listed as ignored in .git/info/exclude, is removed
> > to make room for creating A/B.
>
> Ouch, I hadn't even thought about the issue of branch-switching
> overwriting a file like that, but that's another great reason to have
> "precious". (I've been thinking about "precious" as primarily to protect
> files like `.config`, where they'd be unlikely to be checked in on any
> branch because they have an established purpose in the project. Though,
> of course, people *do* sometimes check in `.config` files in
> special-purpose branches that aren't meant for upstreaming.)
If we're going to implement precious files, I think we should take a
step back and figure out what parts of the system are affected. It's
way more than branch switching and `git clean`. Some notes (including
some useful implementation pointers):
A) You will probably learn a lot and get a leg up on the
implementation by grepping for "preserve_ignored"; lots of the
plumbing has already been created related to this.
B) checkout has a --no-overwrite-ignore, which for checkout
operations, essentially turns all ignored files into precious files.
B1) The code behind --no-overwrite-ignore will probably be helpful in
your implementation of precious files
B2) What happens to this --no-overwrite-ignore option?
Deprecate/remove it after adding precious files, since precious files
now serve that purpose? Keep the flag anyway? What happens to the
docs around the flag?
B3) If we keep --no-overwrite-ignore, do we also need to add a
--overwrite-precious option to allow those to be similarly tweaked?
C) merge has a --no-overwrite-ignore option, which for supported merge
operations (which are sadly very few), essentially turns all ignored
files into precious files.
C1) Same comments as A1-A3 but for merges
C2) Sadly, merge's --no-overwrite-ignore is almost garbage.
builtin/merge.c will only pass this option to the "fast-forward" merge
backend, causing any other type of merge to overwrite ignored files
despite any such flag.
C3) most merge backends don't have logic to handle
--no-overwrite-ignore even if they were passed it, and would need
explicit support added.
C4) merge-ort would only essentially need a one-liner; it basically
has the code in place and a comment but the flag was never plumbed
through
C5) it'd be a herculean effort to support this with merge-recursive,
and a sisyphean effort to attempt to maintain. Deprecating and
removing merge-recursive is probably a better option
C6) merge-resolve and merge-octopus could probably be handled
automatically by ensuring `git read-tree` gained support for it.
C7) there'd be no way to ensure user-written merge algorithms would
support it, but that's kind of a general problem with user-written
anythings
D) git ls-files would need to have a way to query for precious files,
much as it can currently be used to query for ignored files (or
tracked files, or conflicted file, or skip-worktree files, or...).
Backward compatibility questions arise about whether precious files
should appear in `git ls-files -o` output.
E) git status has an --ignored option, with multiple flags for
controlling it. We'll likely need more flags to be able to pick out
precious files.
F) We'd probably need to look through several other commands and look
at what they need for special handling. e.g., am, stash, reset. I
suspect stash will be a particularly sore point, as its unfortunate
design of implementing shell in C code and attempting to decompose the
command in terms of other high-level commands is basically a leaky
abstraction that is very likely to be susceptible to edge and corner
cases here. (In fact, I think I may have left some of the issues for
untracked/ignored files in stash broken when I was fixing such
problems for other commands.)
G) Documentation. Commands like `git reset --hard`, `git checkout
-f`, and `read-tree --reset` are documented to nuke untracked files
specifically because we expect most commands to preserve untracked
files. These would need to mention that "precious" files are also
nuked (or, if we don't nuke them, why precious-and-ignored files are
more precious than untracked files).
H) Design of `reset --hard`. As per
https://lore.kernel.org/git/xmqqr1e2ejs9.fsf@gitster.g/, `git reset
--hard` is a little funny and we have thought about changing it. Will
the addition of "precious" objects provide more impetus to do so, and
should a migration story be part of such a new feature?
I) Although git's stated behavior was to nuke ignored files and
protect untracked files, just a couple years ago we found _many_ bugs
where Git didn't do that. A series was pushed to fix most of those[1]
(incidentally, the same series the introduced the preserve_ignored
flag I pointed you to earlier), but it left a few things
commented/broken. The cover letter and some emails in the thread also
discussed in more detail some of the ramifications around a "precious"
setting. It may be worth reading to catch other things to cover and
think about.
J) To implement this feature, you're going to have to touch dir.c.
Good luck with that. (Seriously, good luck. The more people that
touch it that aren't me, the less I'll be pinged/queried about that
monstrosity.)
> > In any case, the "precious" paths are expected to be small minority
> > of what people never want to "git add" or "git commit", so coming up
> > with a special syntax to be used in .gitignore, even if that special
> > syntax is ugly and cumbersome to type, would be perfectly OK.
>
> [Following up both to this and to Sebastian's response.]
>
> One potentially important question: should the behavior of old git be to
> treat precious files as ignored, or as not-ignored? If the syntax were
> something like
>
> $.config
>
> then old git would treat the file as not-ignored. If the syntax were
> something like
>
> $precious
> .config
>
> then old git would treat the file as ignored.
>
> Seems like it would be obtrusive if `git status` in old git showed the
> file, and `git add .` in old git added it.
A very good set of questions, along similar lines as the question
about `git ls-files -o` handling.
Anyway, I'm a bit worried after digging up and dumping all these
concerns on you, that it'll sound like I'm trying to bury the feature
and discourage folks. In the past I have been against this at times,
but mostly because it looked like lots of work, I didn't want to touch
dir.c anymore, and I was worried we'd add a bunch more edge & corner
cases to the code (when we already had plenty with our more limited
number of file types). In a way, the preserve_ignored stuff kind of
made this a lot more reasonable for us to switch to. But I do still
think it's a fair amount of work, and I am kind of worried about
potential new edge and corner case.
Hope that helps,
Elijah
^ permalink raw reply
* [PATCH v2 3/3] bugreport: don't create --diagnose zip w/o report
From: Jacob Stopak @ 2023-10-15 3:42 UTC (permalink / raw)
To: git; +Cc: Jacob Stopak
In-Reply-To: <20231015034238.100675-1-jacob@initialcommit.io>
Prevent the diagnostics zip file from being created when the bugreport
itself is not created due to an error.
Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
---
builtin/bugreport.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/builtin/bugreport.c b/builtin/bugreport.c
index 573d270677..91567806c9 100644
--- a/builtin/bugreport.c
+++ b/builtin/bugreport.c
@@ -161,21 +161,6 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
report_path.buf);
}
- /* Prepare diagnostics, if requested */
- if (diagnose != DIAGNOSE_NONE) {
- struct strbuf zip_path = STRBUF_INIT;
- strbuf_add(&zip_path, report_path.buf, output_path_len);
- strbuf_addstr(&zip_path, "git-diagnostics-");
- strbuf_addftime(&zip_path, option_suffix.buf, localtime_r(&now, &tm), 0, 0);
- if (i > 1) strbuf_addf(&zip_path, "+%d", i-1);
- strbuf_addstr(&zip_path, ".zip");
-
- if (create_diagnostics_archive(&zip_path, diagnose))
- die_errno(_("unable to create diagnostics archive %s"), zip_path.buf);
-
- strbuf_release(&zip_path);
- }
-
/* Prepare the report contents */
get_bug_template(&buffer);
@@ -202,6 +187,22 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
fprintf(stderr, _("Created new report at '%s'.\n"),
user_relative_path);
+ /* Prepare diagnostics, if requested */
+ if (diagnose != DIAGNOSE_NONE) {
+ struct strbuf zip_path = STRBUF_INIT;
+ strbuf_add(&zip_path, report_path.buf, output_path_len);
+ strbuf_addstr(&zip_path, "git-diagnostics-");
+ strbuf_addftime(&zip_path, option_suffix.buf, localtime_r(&now, &tm), 0, 0);
+ if (i > 1) strbuf_addf(&zip_path, "+%d", i-1);
+ strbuf_addstr(&zip_path, ".zip");
+
+ if (create_diagnostics_archive(&zip_path, diagnose))
+ die_errno(_("unable to create diagnostics archive %s"), zip_path.buf);
+
+ strbuf_release(&zip_path);
+ }
+
+
free(prefixed_filename);
strbuf_release(&buffer);
strbuf_release(&default_option_suffix);
--
2.42.0.298.gd89efca819.dirty
^ permalink raw reply related
* [PATCH v2 2/3] bugreport: match diagnostics filename with report
From: Jacob Stopak @ 2023-10-15 3:42 UTC (permalink / raw)
To: git; +Cc: Jacob Stopak
In-Reply-To: <20231015034238.100675-1-jacob@initialcommit.io>
When using the --diagnose flag, match the diagnostics zip filename with
the bugreport filename in the scenario where '+i' syntax is used.
Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
---
builtin/bugreport.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/bugreport.c b/builtin/bugreport.c
index 71ee7d7f4b..573d270677 100644
--- a/builtin/bugreport.c
+++ b/builtin/bugreport.c
@@ -112,6 +112,7 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
char *prefixed_filename;
size_t output_path_len;
int ret;
+ int i = 1;
const struct option bugreport_options[] = {
OPT_CALLBACK_F(0, "diagnose", &diagnose, N_("mode"),
@@ -142,7 +143,6 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
strbuf_addstr(&report_path, ".txt");
if (strbuf_cmp(&option_suffix, &default_option_suffix) == 0) {
- int i = 1;
int pos = report_path.len - 4;
while (file_exists(report_path.buf) && i < 10) {
if (i > 1)
@@ -167,6 +167,7 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
strbuf_add(&zip_path, report_path.buf, output_path_len);
strbuf_addstr(&zip_path, "git-diagnostics-");
strbuf_addftime(&zip_path, option_suffix.buf, localtime_r(&now, &tm), 0, 0);
+ if (i > 1) strbuf_addf(&zip_path, "+%d", i-1);
strbuf_addstr(&zip_path, ".zip");
if (create_diagnostics_archive(&zip_path, diagnose))
--
2.42.0.298.gd89efca819.dirty
^ permalink raw reply related
* [PATCH v2 1/3] bugreport: include +i in outfile suffix as needed
From: Jacob Stopak @ 2023-10-15 3:42 UTC (permalink / raw)
To: git; +Cc: Jacob Stopak
In-Reply-To: <20231015034238.100675-1-jacob@initialcommit.io>
When the -s flag is absent, git bugreport includes the current hour and
minute values in the default bugreport filename (and diagnostics zip
filename if --diagnose is supplied).
If a user runs the bugreport command more than once within a calendar
minute, a filename conflict with an existing file occurs and the program
errors, since the new output filename was already used for the previous
file. If the user waits anywhere from 1 to 60 seconds (depending on
_when during the calendar minute_ the first command was run) the command
works again with no error since the default filename is now unique, and
multiple bug reports are able to be created with default settings.
This is a minor thing but can cause confusion especially for first time
users of the bugreport command, who are likely to run it multiple times
in quick succession to learn how it works, (like I did).
Add a '+i' into the bugreport filename suffix to make the filename
unique, where 'i' is an integer starting at 1 and able to grow up to 9
in the unlikely event a user runs the command 9 times in a single
minute. This leads to default output filenames like:
git-bugreport-%Y-%m-%d-%H%M+1.txt
git-bugreport-%Y-%m-%d-%H%M+2.txt
...
git-bugreport-%Y-%m-%d-%H%M+9.txt
This means the user will end up with multiple bugreport files being
created if they run the command multiple times quickly, but that feels
more intuitive and consistent than an error arbitrarily occuring within
a calendar minute, especially given that the time window in which the
error currently occurs is variable as described above.
Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
---
builtin/bugreport.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/builtin/bugreport.c b/builtin/bugreport.c
index d2ae5c305d..71ee7d7f4b 100644
--- a/builtin/bugreport.c
+++ b/builtin/bugreport.c
@@ -3,7 +3,6 @@
#include "editor.h"
#include "gettext.h"
#include "parse-options.h"
-#include "strbuf.h"
#include "help.h"
#include "compat/compiler.h"
#include "hook.h"
@@ -11,6 +10,7 @@
#include "diagnose.h"
#include "object-file.h"
#include "setup.h"
+#include "dir.h"
static void get_system_info(struct strbuf *sys_info)
{
@@ -101,12 +101,13 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
{
struct strbuf buffer = STRBUF_INIT;
struct strbuf report_path = STRBUF_INIT;
+ struct strbuf option_suffix = STRBUF_INIT;
+ struct strbuf default_option_suffix = STRBUF_INIT;
int report = -1;
time_t now = time(NULL);
struct tm tm;
enum diagnose_mode diagnose = DIAGNOSE_NONE;
char *option_output = NULL;
- char *option_suffix = "%Y-%m-%d-%H%M";
const char *user_relative_path = NULL;
char *prefixed_filename;
size_t output_path_len;
@@ -118,11 +119,14 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
PARSE_OPT_OPTARG, option_parse_diagnose),
OPT_STRING('o', "output-directory", &option_output, N_("path"),
N_("specify a destination for the bugreport file(s)")),
- OPT_STRING('s', "suffix", &option_suffix, N_("format"),
+ OPT_STRING('s', "suffix", &option_suffix.buf, N_("format"),
N_("specify a strftime format suffix for the filename(s)")),
OPT_END()
};
+ strbuf_addstr(&default_option_suffix, "%Y-%m-%d-%H%M");
+ strbuf_addstr(&option_suffix, default_option_suffix.buf);
+
argc = parse_options(argc, argv, prefix, bugreport_options,
bugreport_usage, 0);
@@ -134,9 +138,20 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
output_path_len = report_path.len;
strbuf_addstr(&report_path, "git-bugreport-");
- strbuf_addftime(&report_path, option_suffix, localtime_r(&now, &tm), 0, 0);
+ strbuf_addftime(&report_path, option_suffix.buf, localtime_r(&now, &tm), 0, 0);
strbuf_addstr(&report_path, ".txt");
+ if (strbuf_cmp(&option_suffix, &default_option_suffix) == 0) {
+ int i = 1;
+ int pos = report_path.len - 4;
+ while (file_exists(report_path.buf) && i < 10) {
+ if (i > 1)
+ strbuf_remove(&report_path, pos, 2);
+ strbuf_insertf(&report_path, pos, "+%d", i);
+ i++;
+ }
+ }
+
switch (safe_create_leading_directories(report_path.buf)) {
case SCLD_OK:
case SCLD_EXISTS:
@@ -151,7 +166,7 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
struct strbuf zip_path = STRBUF_INIT;
strbuf_add(&zip_path, report_path.buf, output_path_len);
strbuf_addstr(&zip_path, "git-diagnostics-");
- strbuf_addftime(&zip_path, option_suffix, localtime_r(&now, &tm), 0, 0);
+ strbuf_addftime(&zip_path, option_suffix.buf, localtime_r(&now, &tm), 0, 0);
strbuf_addstr(&zip_path, ".zip");
if (create_diagnostics_archive(&zip_path, diagnose))
@@ -188,6 +203,7 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
free(prefixed_filename);
strbuf_release(&buffer);
+ strbuf_release(&default_option_suffix);
ret = !!launch_editor(report_path.buf, NULL, NULL);
strbuf_release(&report_path);
--
2.42.0.298.gd89efca819.dirty
^ permalink raw reply related
* [PATCH v2 0/3] bugreport: include +i in outfile suffix as needed
From: Jacob Stopak @ 2023-10-15 3:42 UTC (permalink / raw)
To: git; +Cc: Jacob Stopak, Junio C Hamano, Dragan Simic, Kristoffer Haugsbakk
In-Reply-To: <20231014040101.8333-1-jacob@initialcommit.io>
Update git bugreport to allow creation of multiple bugreports with
default settings during a given minute interval.
Address several edge cases where users might run git bugreport multiple
times within a minute and expect multiple reports to be created.
Handle these cases by checking to see if a file with the default
timestamped filename already exists, and if so, appending a '+1' value
to the filename suffix. Keep doing so until a unique filename is reached
or '+9' is reached. At this point, if uniqueness is still not found,
the previous error that a file with the given name already exists.
If the --diagnose flag is supplied, apply the same '+i' incremented
filename suffix to the diagnostics zip file.
Reorder the code block that creates the diagnostics zip file so it isn't
created in the event the bugreport itself isn't created due to an error.
Jacob Stopak (3):
bugreport: include +i in outfile suffix as needed
bugreport: match diagnostics filename with report
bugreport: don't create --diagnose zip w/o report
builtin/bugreport.c | 54 ++++++++++++++++++++++++++++++---------------
1 file changed, 36 insertions(+), 18 deletions(-)
base-commit: 493f4622739e9b64f24b465b21aa85870dd9dc09
--
2.42.0.298.gd89efca819.dirty
^ permalink raw reply
* Re: [PATCH] grep: die gracefully when outside repository
From: Jeff King @ 2023-10-15 3:26 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git, ks1322
In-Reply-To: <087c92e3904dd774f672373727c300bf7f5f6369.1697317276.git.code@khaugsbakk.name>
On Sat, Oct 14, 2023 at 11:02:38PM +0200, Kristoffer Haugsbakk wrote:
> Die gracefully when `git grep --no-index` is run outside of a Git
> repository and the path is outside the directory tree.
>
> If you are not in a Git repository and say:
>
> git grep --no-index search ..
>
> You trigger a `BUG`:
>
> BUG: environment.c:213: git environment hasn't been setup
> Aborted (core dumped)
>
> Because `..` is a valid path which is treated as a pathspec. Then
> `pathspec` figures out that it is not in the current directory tree. The
> `BUG` is triggered when `pathspec` tries to advice the user about the path
> to the (non-existing) repository.
Is it even reasonable for "grep --no-index" to care about leaving the
tree in the first place? That is, is there a reason we should not allow:
git grep --no-index foo ../bar
? And if we do want to care, there is a weirdness here that even with
your patch, we check to see if the file exists:
$ git grep --no-index foo ../does-exist
fatal: '../does-exist' is outside the directory tree
$ git grep --no-index foo ../does-not-exist
fatal: ../does-not-exist: no such path in the working tree.
If we want to avoid leaving the current directory, then I think we need
to be checking much sooner (but again, I would argue that it is not
worth caring about in no-index mode).
I do think your patch does not make anything worse (and indeed makes the
error output much better). So I do not mind it in the meantime. But I
have a feeling that we'd end up reverting it as part of the fix for the
larger issue.
-Peff
^ permalink raw reply
* Re: [PATCH 21/20] t5319: make corrupted large-offset test more robust
From: Jeff King @ 2023-10-15 3:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Taylor Blau
In-Reply-To: <xmqq4jitt2ie.fsf@gitster.g>
On Sat, Oct 14, 2023 at 12:42:01PM -0700, Junio C Hamano wrote:
> > The set of objects created in the test is deterministic. But the delta
> > selection seems not to be (which is not too surprising, as it is
> > multi-threaded).
>
> So, the offsets of the objects are also not deterministic?
Hmm, yeah, you're right. The pack clearly is not deterministic, and so
neither will its offsets be.
And thus...
> > b. The "objects64" setup could use --delta-base-offset. This would fix
> > our problem, but earlier tests have many hard-coded offsets. Using
> > OFS_DELTA would change the locations of objects in the pack (this
> > might even be OK because I think most of the offsets are within the
> > .idx file, but it seems brittle and I'm afraid to touch it).
>
> I am not sure I follow, as it does not sound a solution to anything
> if the offsets are not deterministic (and "earlier tests" that have
> hard coded offsets are broken no matter what, which is not a problem
> this patch introduces). Puzzled, but not curious enough to think
> about it further, as you have already rejected this approach ;-)
...yes, my "this might even be OK" is true. So it would work to solve
the problem by using --delta-base-offset. Those earlier tests are
actually OK (they munge only the idx and the midx, not the pack). And if
we have delta base offsets, then walking delta chains never requires
looking at the pack idx.
I'm not sure if that is any less subtle than the solution I did come up
with, though.
The most unsubtle thing is cleaning up the broken .idx immediately
after generating the midx. I didn't want to do that because it disrupts
the state of the objects64 directory. But we could always turn its setup
into a function or something. I dunno. It is probably not worth spending
too many brain cycles on. My hope is that nobody ever has to touch this
test ever again. ;)
> > @@ -1129,8 +1129,10 @@ test_expect_success 'reader bounds-checks large offset table' '
> > git multi-pack-index --object-dir=../objects64 write &&
> > midx=../objects64/pack/multi-pack-index &&
> > corrupt_chunk_file $midx LOFF clear &&
> > - test_must_fail git cat-file \
> > - --batch-check --batch-all-objects 2>err &&
> > + # using only %(objectsize) is important here; see the commit
> > + # message for more details
> > + test_must_fail git cat-file --batch-all-objects \
> > + --batch-check="%(objectsize)" 2>err &&
>
> A rather unfriendly message to readers, as it is unclear which
> commit you are talking about, and a fun thing is that you cannot
> say which one.
Yeah, I had a similar thought process. I sort of assume anybody working
on git.git is capable of turning to "git blame" in a situation like
this. But maybe:
# using only %(objectsize) is important here; run "git blame"
# on these lines for more details
would spell it out more clearly.
-Peff
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Dragan Simic @ 2023-10-15 3:13 UTC (permalink / raw)
To: Jacob Stopak; +Cc: Junio C Hamano, git
In-Reply-To: <ZStXbjgFTlO11Pp7.jacob@initialcommit.io>
On 2023-10-15 05:07, Jacob Stopak wrote:
> On Sat, Oct 14, 2023 at 07:52:32PM +0200, Dragan Simic wrote:
>>
>> Speaking in general, I somehow find "20220712" a bit more readable
>> than
>> "2022-07-12" as part of a filename, but that's of course just my
>> personal
>> preference.
>
> It's funny how we all have our own preferences for this kind of thing.
> Mine happens to be separating the date part from the rest of the
> filename with an underscore, but using a hyphen to separate individual
> date components like:
>
> filename_2022-07-12.ext
Yes, it's quite funny. I gave it some thought, and I think that my
preference is a result of dealing with many PDF files containing
schematics, for which some kind of a defacto standard is the "-20220712"
naming convention.
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Jacob Stopak @ 2023-10-15 3:07 UTC (permalink / raw)
To: Dragan Simic; +Cc: Junio C Hamano, git
In-Reply-To: <438a5edf1a17ffac201436a950ce50fa@manjaro.org>
On Sat, Oct 14, 2023 at 07:52:32PM +0200, Dragan Simic wrote:
>
> Speaking in general, I somehow find "20220712" a bit more readable than
> "2022-07-12" as part of a filename, but that's of course just my personal
> preference.
It's funny how we all have our own preferences for this kind of thing.
Mine happens to be separating the date part from the rest of the
filename with an underscore, but using a hyphen to separate individual
date components like:
filename_2022-07-12.ext
^ permalink raw reply
* Re: [PATCH 0/8] t7900: untangle test dependencies
From: Jeff King @ 2023-10-15 3:04 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
On Sat, Oct 14, 2023 at 11:45:51PM +0200, Kristoffer Haugsbakk wrote:
> § CI
>
> The CI failed but it didn't look relevant.
>
> https://github.com/LemmingAvalanche/git/actions/runs/6518415327/job/17703822606
From a brief look, I think it is that your branch is based on v2.42.0,
which does not contain 0763c3a2c4 (http: update curl http/2 info
matching for curl 8.3.0, 2023-09-15). And the macos CI image has since
been updated to a more recent version of curl.
So yeah, not anything to worry about for your series.
-Peff
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Jacob Stopak @ 2023-10-15 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq4jitw4nk.fsf@gitster.g>
On Sat, Oct 14, 2023 at 09:27:27AM -0700, Junio C Hamano wrote:
> Jacob Stopak <jacob@initialcommit.io> writes:
>
> Is "postfix" a verb that is commonly understood? I would say
> "append" would be understood by more readers.
It's probably true that "append" or "suffix" (which is used in the code)
would be more easily understood. I'll switch in my updated messages.
> Also, is "calendar"
> hour different from other kinds of hours, perhaps stopwatch hours
> and microwave-oven hours?
Lol! By saying "calendar" I mean "falling on the official boundaries
of", like 11:15:00 - 11:16:00. Unlike the time between 11:15:30 -
11:16:30 which is also a minute, but it's not a "calendar" minute
because it overlaps into the next minute. I guess in this case it's more
of a "clock" minute than a "calendar" minute though ':D... I guess
"calendar" terminology is used more for months/years...
> I personally do not think it is a problem, simply because a quality
> bug report that would capture information necessary to diagnose any
> issue concisely in a readable fashion would take at least 90 seconds
> or more to produce, though.
This is true, when the user intentionally opens the bugreport with the
intent to start filling it out immediately, I assume they would almost
always cross the minute barrier and avoid the issue.
However, there are edge cases like the one I outlined, where the user
might open and close the report quickly, followed by rerunning the
command. This could be someone learning to use the command for the first
time. Or the case where a user only fills in a small part of the report
before closing it and running the command again.
These cases are certainly "the exception" but it seems the program could
be a bit more consistent/intuitive when they do occur.
> Instead of lengthening the filename for all files by 2 digits, the
> command can retry by adding say "+1", "+2", etc. after the failed
> filename to find a unique suffix within the same minute. It would
> mean that after writing git-bugreport-2023-10-14-0920.txt and you
> start another one without spending enough time, the new one may
> become git-bugreport-2023-10-14-0920+1.txt or something unique. It
> would be really unlikely that you would run out after failing to
> find a vacant single digit suffix nine times, i.e. trying "+9". It
> would also help preserve existing user's workflow, e.g. they may
> have written automation that assumes the down-to-minute format and
> it would keep working on their bug reports without breaking.
I agree with all of this, and to me it's a better solution than
_appending_ the second value :). I have a patchset almost ready for this
so I'll try to submit it later tonight.
^ permalink raw reply
* [PATCH 9/8] t7900: fix register dependency
From: Kristoffer Haugsbakk @ 2023-10-14 23:00 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
The test `maintenance.auto config option` will fail if any preceding test
has run `git maintenance register` since that turns `maintenance.auto` off
for that repository and later calls to `unregister` will not turn it back
to the default `true` value.
Start with a fresh repository in this test.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
I found this after publishing the series.
t/t7900-maintenance.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index bc417b518b..dbc5e1eb44 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -55,6 +55,8 @@ test_expect_success 'run [--auto|--quiet]' '
'
test_expect_success 'maintenance.auto config option' '
+ rm -rf .git &&
+ git init &&
GIT_TRACE2_EVENT="$(pwd)/default" git commit --quiet --allow-empty -m 1 &&
test_subcommand git maintenance run --auto --quiet <default &&
GIT_TRACE2_EVENT="$(pwd)/true" \
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 8/8] t7900: factor out packfile dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Tests `'--schedule inheritance weekly -> daily -> hourly` and
`maintenance.strategy inheritance` depend on the packfile made in
`incremental-repack task`.
Factor out the packfile creation.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 99279e41787..bc417b518b5 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -257,13 +257,15 @@ test_expect_success 'maintenance.loose-objects.auto' '
test_subcommand git prune-packed --quiet <trace-loC
'
-test_expect_success 'incremental-repack task' '
+test_expect_success 'setup packfile' '
packDir=.git/objects/pack &&
for i in $(test_seq 1 5)
do
test_commit $i || return 1
- done &&
+ done
+'
+test_expect_success 'incremental-repack task' '
# Create three disjoint pack-files with size BIG, small, small.
echo HEAD~2 | git pack-objects --revs $packDir/test-1 &&
test_tick &&
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 7/8] t7900: fix `print-args` dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Test `use launchctl list to prevent extra work` depends on `print-args`
from `start and stop macOS maintenance`.
Duplicate the script writing.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 15a8653b583..99279e41787 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -709,6 +709,9 @@ test_expect_success 'start and stop macOS maintenance' '
'
test_expect_success 'use launchctl list to prevent extra work' '
+ write_script print-args <<-\EOF &&
+ echo $* | sed "s:gui/[0-9][0-9]*:gui/[UID]:" >>args
+ EOF
# ensure we are registered
GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start --scheduler=launchctl &&
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 6/8] t7900: fix `pfx` dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Test `start and stop when several schedulers are available` depends on
`pfx` from `start and stop macOS maintenance`.
Duplicate the behavior.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index ebde3e8a212..15a8653b583 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -794,6 +794,7 @@ test_expect_success 'start and stop Linux/systemd maintenance' '
'
test_expect_success 'start and stop when several schedulers are available' '
+ pfx=$(cd "$HOME" && pwd) &&
write_script print-args <<-\EOF &&
printf "%s\n" "$*" | sed "s:gui/[0-9][0-9]*:gui/[UID]:; s:\(schtasks /create .* /xml\).*:\1:;" >>args
EOF
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 5/8] t7900: factor out common schedule setup
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Tests `magic markers are correct` and `stop preserves surrounding
schedule` depend on some setup in `start preserves existing schedule`.
Factor out the setup code.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 6e3ee365ccd..ebde3e8a212 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -637,9 +637,12 @@ test_expect_success 'stop from existing schedule' '
test_must_be_empty cron.txt
'
-test_expect_success 'start preserves existing schedule' '
+test_expect_success 'setup important information for schedule' '
echo "Important information!" >cron.txt &&
- GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start --scheduler=crontab &&
+ GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start --scheduler=crontab
+'
+
+test_expect_success 'start preserves existing schedule' '
grep "Important information!" cron.txt
'
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 4/8] t7900: factor out inheritance test dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Factor out the dependency that test `maintenance.strategy inheritance` has
on test `--schedule inheritance weekly -> daily -> hourly`.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 4bfb4ec5cf6..6e3ee365ccd 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -408,14 +408,16 @@ test_expect_success 'invalid --schedule value' '
test_i18ngrep "unrecognized --schedule" err
'
-test_expect_success '--schedule inheritance weekly -> daily -> hourly' '
+test_expect_success 'setup for inheritance' '
git config maintenance.loose-objects.enabled true &&
git config maintenance.loose-objects.schedule hourly &&
git config maintenance.commit-graph.enabled true &&
git config maintenance.commit-graph.schedule daily &&
git config maintenance.incremental-repack.enabled true &&
- git config maintenance.incremental-repack.schedule weekly &&
+ git config maintenance.incremental-repack.schedule weekly
+'
+test_expect_success '--schedule inheritance weekly -> daily -> hourly' '
GIT_TRACE2_EVENT="$(pwd)/hourly.txt" \
git maintenance run --schedule=hourly 2>/dev/null &&
test_subcommand git prune-packed --quiet <hourly.txt &&
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 3/8] t7900: create commit so that branch is born
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
`pack-refs task` cannot be run in isolation but does pass if
`maintenance.auto config option` is run first.
Create a commit so that `HEAD` does not point to an unborn branch.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index ebc207f1a58..4bfb4ec5cf6 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -388,6 +388,7 @@ test_expect_success 'maintenance.incremental-repack.auto (when config is unset)'
'
test_expect_success 'pack-refs task' '
+ test_commit message &&
for n in $(test_seq 1 5)
do
git branch -f to-pack/$n HEAD || return 1
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 2/8] t7900: setup and tear down clones
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Test `loose-objects task` depends on the two clones setup in `prefetch
multiple remotes`.
Reuse the two clones setup and tear down the clones afterwards in both
tests.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index ca86b2ba687..ebc207f1a58 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -145,6 +145,12 @@ test_expect_success 'run --task=prefetch with no remotes' '
'
test_expect_success 'prefetch multiple remotes' '
+ test_when_finished rm -r clone1 &&
+ test_when_finished rm -r clone2 &&
+ test_when_finished git remote remove remote1 &&
+ test_when_finished git remote remove remote2 &&
+ test_when_finished git tag --delete one &&
+ test_when_finished git tag --delete two &&
git clone . clone1 &&
git clone . clone2 &&
git remote add remote1 "file://$(pwd)/clone1" &&
@@ -175,6 +181,22 @@ test_expect_success 'prefetch multiple remotes' '
'
test_expect_success 'loose-objects task' '
+ test_when_finished rm -r clone1 &&
+ test_when_finished rm -r clone2 &&
+ test_when_finished git remote remove remote1 &&
+ test_when_finished git remote remove remote2 &&
+ test_when_finished git tag --delete one &&
+ test_when_finished git tag --delete two &&
+ git clone . clone1 &&
+ git clone . clone2 &&
+ git remote add remote1 "file://$(pwd)/clone1" &&
+ git remote add remote2 "file://$(pwd)/clone2" &&
+ git -C clone1 switch -c one &&
+ git -C clone2 switch -c two &&
+ test_commit -C clone1 one &&
+ test_commit -C clone2 two &&
+ git fetch --all &&
+
# Repack everything so we know the state of the object dir
git repack -adk &&
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 1/8] t7900: remove register dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
`stop from existing schedule` depends on the preceding test `start from
empty cron table` because the preceding test registers the
repository. Without it, the “stop” test fails because `config` fails to
get the repository:
git config --get --global --fixed-value maintenance.repo "$(pwd)"
Remove this dependency by setting up the state and tearing it down
independently.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 487e326b3fa..ca86b2ba687 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -588,6 +588,7 @@ test_expect_success 'start --scheduler=<scheduler>' '
'
test_expect_success 'start from empty cron table' '
+ test_when_finished git maintenance unregister &&
GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start --scheduler=crontab &&
# start registers the repo
@@ -599,6 +600,8 @@ test_expect_success 'start from empty cron table' '
'
test_expect_success 'stop from existing schedule' '
+ test_when_finished git maintenance unregister &&
+ git maintenance register &&
GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance stop &&
# stop does not unregister the repo
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 0/8] t7900: untangle test dependencies
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
Untangle test dependencies so that all tests only need setup tests to have
been run.
For example:
```
./t7900-maintenance.sh --run=setup,31
```
Test with:
```
#!/bin/sh
cd t
# Every test run together with `setup` should pass
for i in $(seq 1 42)
do
./t7900-maintenance.sh --quiet --run=setup,$i || return 1
done &&
# Whole test suite should pass
./t7900-maintenance.sh --quiet &&
# The tests that used to depend on each other should still pass
# when run together
./t7900-maintenance.sh --quiet --run=setup,30,31 &&
./t7900-maintenance.sh --quiet --run=setup,11,12 &&
./t7900-maintenance.sh --quiet --run=setup,3,19 &&
./t7900-maintenance.sh --quiet --run=setup,23,24 &&
./t7900-maintenance.sh --quiet --run=setup,33,34,35 &&
./t7900-maintenance.sh --quiet --run=setup,36,40 &&
./t7900-maintenance.sh --quiet --run=setup,36,40 &&
./t7900-maintenance.sh --quiet --run=setup,36,37 &&
./t7900-maintenance.sh --quiet --run=setup,15,23,24 &&
printf "\nAll passed\n" ||
printf '\n***Failed***\n'
```
§ CI
The CI failed but it didn't look relevant.
https://github.com/LemmingAvalanche/git/actions/runs/6518415327/job/17703822606
Cheers
Kristoffer Haugsbakk (8):
t7900: remove register dependency
t7900: setup and tear down clones
t7900: create commit so that branch is born
t7900: factor out inheritance test dependency
t7900: factor out common schedule setup
t7900: fix `pfx` dependency
t7900: fix `print-args` dependency
t7900: factor out packfile dependency
t/t7900-maintenance.sh | 49 ++++++++++++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 6 deletions(-)
base-commit: 43c8a30d150ecede9709c1f2527c8fba92c65f40
--
2.42.0.2.g879ad04204
^ permalink raw reply
* [PATCH] grep: die gracefully when outside repository
From: Kristoffer Haugsbakk @ 2023-10-14 21:02 UTC (permalink / raw)
To: code; +Cc: git, ks1322
In-Reply-To: <6bb48aac-460c-4d7f-9057-40c3df0c807d@app.fastmail.com>
Die gracefully when `git grep --no-index` is run outside of a Git
repository and the path is outside the directory tree.
If you are not in a Git repository and say:
git grep --no-index search ..
You trigger a `BUG`:
BUG: environment.c:213: git environment hasn't been setup
Aborted (core dumped)
Because `..` is a valid path which is treated as a pathspec. Then
`pathspec` figures out that it is not in the current directory tree. The
`BUG` is triggered when `pathspec` tries to advice the user about the path
to the (non-existing) repository.
Reported-by: ks1322 ks1322 <ks1322@gmail.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
pathspec.c | 3 +++
t/t7810-grep.sh | 13 +++++++++++++
2 files changed, 16 insertions(+)
diff --git a/pathspec.c b/pathspec.c
index 3a3a5724c44..e115832f17a 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -468,6 +468,9 @@ static void init_pathspec_item(struct pathspec_item *item, unsigned flags,
&prefixlen, copyfrom);
if (!match) {
const char *hint_path = get_git_work_tree();
+ if (!have_git_dir())
+ die(_("'%s' is outside the directory tree"),
+ copyfrom);
if (!hint_path)
hint_path = get_git_dir();
die(_("%s: '%s' is outside repository at '%s'"), elt,
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 39d6d713ecb..b976f81a166 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -1234,6 +1234,19 @@ test_expect_success 'outside of git repository with fallbackToNoIndex' '
)
'
+test_expect_success 'outside of git repository with pathspec outside the directory tree' '
+ test_when_finished rm -fr non &&
+ rm -fr non &&
+ mkdir -p non/git/sub &&
+ (
+ GIT_CEILING_DIRECTORIES="$(pwd)/non" &&
+ export GIT_CEILING_DIRECTORIES &&
+ cd non/git &&
+ test_expect_code 128 git grep --no-index search .. 2>error &&
+ grep "is outside the directory tree" error
+ )
+'
+
test_expect_success 'inside git repository but with --no-index' '
rm -fr is &&
mkdir -p is/git/sub &&
base-commit: 43c8a30d150ecede9709c1f2527c8fba92c65f40
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* What's cooking in git.git (Oct 2023, #06; Fri, 13)
From: Junio C Hamano @ 2023-10-14 20:12 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
There are too many topics marked with "Needs review" label. I can
help reviewing some of them myself, but obviously it will not scale.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* ar/diff-index-merge-base-fix (2023-10-02) 1 commit
(merged to 'next' on 2023-10-06 at 0ff4dfc0e1)
+ diff: fix --merge-base with annotated tags
"git diff --merge-base X other args..." insisted that X must be a
commit and errored out when given an annotated tag that peels to a
commit, but we only need it to be a committish. This has been
corrected.
source: <20231001151845.3621551-1-hi@alyssa.is>
* ds/mailmap-entry-update (2023-10-12) 1 commit
(merged to 'next' on 2023-10-12 at 3de300ac62)
+ mailmap: change primary address for Derrick Stolee
Update mailmap entry for Derrick.
Will merge to 'master' immediately.
source: <pull.1592.git.1697131834003.gitgitgadget@gmail.com>
* jk/commit-graph-leak-fixes (2023-10-03) 10 commits
(merged to 'next' on 2023-10-06 at 5d202ef8b9)
+ commit-graph: clear oidset after finishing write
+ commit-graph: free write-context base_graph_name during cleanup
+ commit-graph: free write-context entries before overwriting
+ commit-graph: free graph struct that was not added to chain
+ commit-graph: delay base_graph assignment in add_graph_to_chain()
+ commit-graph: free all elements of graph chain
+ commit-graph: move slab-clearing to close_commit_graph()
+ merge: free result of repo_get_merge_bases()
+ commit-reach: free temporary list in get_octopus_merge_bases()
+ t6700: mark test as leak-free
Leakfix.
source: <20231003202504.GA7697@coredump.intra.peff.net>
* jk/decoration-and-other-leak-fixes (2023-10-05) 3 commits
(merged to 'next' on 2023-10-06 at 5fc05c94dc)
+ daemon: free listen_addr before returning
+ revision: clear decoration structs during release_revisions()
+ decorate: add clear_decoration() function
Leakfix.
source: <20231005212802.GA982892@coredump.intra.peff.net>
* js/submodule-fix-misuse-of-path-and-name (2023-10-03) 6 commits
(merged to 'next' on 2023-10-06 at 1054b6e752)
+ t7420: test that we correctly handle renamed submodules
+ t7419: test that we correctly handle renamed submodules
+ t7419, t7420: use test_cmp_config instead of grepping .gitmodules
+ t7419: actually test the branch switching
+ submodule--helper: return error from set-url when modifying failed
+ submodule--helper: use submodule_from_path in set-{url,branch}
In .gitmodules files, submodules are keyed by their names, and the
path to the submodule whose name is $name is specified by the
submodule.$name.path variable. There were a few codepaths that
mixed the name and path up when consulting the submodule database,
which have been corrected. It took long for these bugs to be found
as the name of a submodule initially is the same as its path, and
the problem does not surface until it is moved to a different path,
which apparently happens very rarely.
source: <0a0a157f88321d25fdb0be771a454b3410a449f3.camel@archlinux.org>
* la/trailer-test-and-doc-updates (2023-09-07) 13 commits
(merged to 'next' on 2023-10-06 at 69fef35819)
+ trailer doc: <token> is a <key> or <keyAlias>, not both
+ trailer doc: separator within key suppresses default separator
+ trailer doc: emphasize the effect of configuration variables
+ trailer --unfold help: prefer "reformat" over "join"
+ trailer --parse docs: add explanation for its usefulness
+ trailer --only-input: prefer "configuration variables" over "rules"
+ trailer --parse help: expose aliased options
+ trailer --no-divider help: describe usual "---" meaning
+ trailer: trailer location is a place, not an action
+ trailer doc: narrow down scope of --where and related flags
+ trailer: add tests to check defaulting behavior with --no-* flags
+ trailer test description: this tests --where=after, not --where=before
+ trailer tests: make test cases self-contained
Test coverage for trailers has been improved.
source: <pull.1564.v3.git.1694125209.gitgitgadget@gmail.com>
--------------------------------------------------
[New Topics]
* tb/format-pack-doc-update (2023-10-12) 2 commits
- Documentation/gitformat-pack.txt: fix incorrect MIDX documentation
- Documentation/gitformat-pack.txt: fix typo
Doc update.
Expecting a reroll.
cf. <xmqq5y3b4id2.fsf@gitster.g>
source: <cover.1697144959.git.me@ttaylorr.com>
* ps/do-not-trust-commit-graph-blindly-for-existence (2023-10-13) 1 commit
- commit: detect commits that exist in commit-graph but not in the ODB
(this branch is used by kn/rev-list-missing-fix.)
The codepath to traverse the commit-graph learned to notice that a
commit is missing (e.g., corrupt repository lost an object), even
though it knows something about the commit (like its parents) from
what is in commit-graph.
Comments?
source: <b0bf576c51a706367a758b8e30eca37edb9c2734.1697200576.git.ps@pks.im>
* tb/pair-chunk-expect-size (2023-10-13) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- midx: read `OIDF` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDF` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
(this branch uses jk/chunk-bounds.)
Code clean-up for jk/chunk-bounds topic.
Comments?
source: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
source: <cover.1697225110.git.me@ttaylorr.com>
--------------------------------------------------
[Stalled]
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* jc/fail-stash-to-store-non-stash (2023-10-11) 1 commit
- stash: be careful what we store
Feeding "git stash store" with a random commit that was not created
by "git stash create" now errors out.
Will merge to 'next'?
source: <xmqqbkd4lwj0.fsf_-_@gitster.g>
* jc/doc-unit-tests-fixup (2023-10-11) 1 commit
- SQUASH???
(this branch uses js/doc-unit-tests and js/doc-unit-tests-with-cmake.)
Quick fix for jc/doc-unit-tests topic to unbreak CI running on 'seen'.
source: <xmqqwmvskf8t.fsf@gitster.g>
* bc/racy-4gb-files (2023-10-13) 2 commits
- Prevent git from rehashing 4GiB files
- t: add a test helper to truncate files
The index file has room only for lower 32-bit of the file size in
the cached stat information, which means cached stat information
will have 0 in its sd_size member for a file whose size is multiple
of 4GiB. This is mistaken for a racily clean path. Avoid it by
storing a bogus sd_size value instead for such files.
Will merge to 'next'?
source: <20231012160930.330618-1-sandals@crustytoothpaste.net>
* jc/grep-f-relative-to-cwd (2023-10-12) 1 commit
- grep: -f <path> is relative to $cwd
"cd sub && git grep -f patterns" tried to read "patterns" file at
the top level of the working tree; it has been corrected to read
"sub/patterns" instead.
Needs review.
source: <xmqqedhzg37z.fsf@gitster.g>
* tb/path-filter-fix (2023-10-10) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Needs (hopefully final and quick) review.
source: <cover.1696969994.git.me@ttaylorr.com>
* ak/pretty-decorate-more-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-12 at 3cbb4c2268)
+ pretty: fix ref filtering for %(decorate) formats
Unlike "git log --pretty=%D", "git log --pretty="%(decorate)" did
not auto-initialize the decoration subsystem, which has been
corrected.
Will merge to 'master'.
source: <20231008202307.1568477-1-andy.koppe@gmail.com>
* en/docfixes (2023-10-09) 25 commits
- documentation: add missing parenthesis
- documentation: add missing quotes
- documentation: add missing fullstops
- documentation: add some commas where they are helpful
- documentation: fix whitespace issues
- documentation: fix capitalization
- documentation: fix punctuation
- documentation: use clearer prepositions
- documentation: add missing hyphens
- documentation: remove unnecessary hyphens
- documentation: add missing article
- documentation: fix choice of article
- documentation: whitespace is already generally plural
- documentation: fix singular vs. plural
- documentation: fix verb vs. noun
- documentation: fix adjective vs. noun
- documentation: fix verb tense
- documentation: employ consistent verb tense for a list
- documentation: fix subject/verb agreement
- documentation: remove extraneous words
- documentation: add missing words
- documentation: fix apostrophe usage
- documentation: fix typos
- documentation: fix small error
- documentation: wording improvements
Documentation typo and grammo fixes.
Needs review.
source: <pull.1595.git.1696747527.gitgitgadget@gmail.com>
* kn/rev-list-missing-fix (2023-10-13) 4 commits
- rev-list: add commit object support in `--missing` option
- rev-list: move `show_commit()` to the bottom
- revision: rename bit to `do_not_die_on_missing_objects`
- Merge branch 'ps/do-not-trust-commit-graph-blindly-for-existence' into kn/rev-list-missing-fix
(this branch uses ps/do-not-trust-commit-graph-blindly-for-existence.)
"git rev-list --missing" did not work for missing commit objects,
which has been corrected.
Needs review.
source: <20231009105528.17777-1-karthik.188@gmail.com>
* sn/cat-file-doc-update (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at 6719ba7bd4)
+ doc/cat-file: make synopsis and description less confusing
"git cat-file" documentation updates.
Will merge to 'master'.
source: <20231009175604.2361700-1-stepnem@smrk.net>
* xz/commit-title-soft-limit-doc (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at 0bf3d9ed51)
+ doc: correct the 50 characters soft limit (+)
Doc update.
Will merge to 'master'.
source: <pull.1585.v2.git.git.1696778367151.gitgitgadget@gmail.com>
* jk/chunk-bounds (2023-10-09) 20 commits
(merged to 'next' on 2023-10-10 at 21139603ce)
+ chunk-format: drop pair_chunk_unsafe()
+ commit-graph: detect out-of-order BIDX offsets
+ commit-graph: check bounds when accessing BIDX chunk
+ commit-graph: check bounds when accessing BDAT chunk
+ commit-graph: bounds-check generation overflow chunk
+ commit-graph: check size of generations chunk
+ commit-graph: bounds-check base graphs chunk
+ commit-graph: detect out-of-bounds extra-edges pointers
+ commit-graph: check size of commit data chunk
+ midx: check size of revindex chunk
+ midx: bounds-check large offset chunk
+ midx: check size of object offset chunk
+ midx: enforce chunk alignment on reading
+ midx: check size of pack names chunk
+ commit-graph: check consistency of fanout table
+ midx: check size of oid lookup chunk
+ commit-graph: check size of oid fanout chunk
+ midx: stop ignoring malformed oid fanout chunk
+ t: add library for munging chunk-format files
+ chunk-format: note that pair_chunk() is unsafe
(this branch is used by tb/pair-chunk-expect-size.)
The codepaths that read "chunk" formatted files have been corrected
to pay attention to the chunk size and notice broken files.
Will merge to 'master'.
source: <20231009205544.GA3281950@coredump.intra.peff.net>
* ps/rewritten-is-per-worktree-doc (2023-10-10) 1 commit
(merged to 'next' on 2023-10-12 at 501b960e8c)
+ doc/git-worktree: mention "refs/rewritten" as per-worktree refs
Doc update.
Will merge to 'master'.
source: <985ac850eb6e60ae76601acc8bfbcd56f99348b4.1696935657.git.ps@pks.im>
* jc/merge-ort-attr-index-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at b139b87502)
+ merge-ort: initialize repo in index state
Fix "git merge-tree" to stop segfaulting when the --attr-source
option is used.
Will merge to 'master'.
source: <pull.1583.v3.git.git.1696857660374.gitgitgadget@gmail.com>
* sn/typo-grammo-phraso-fixes (2023-10-05) 5 commits
- t/README: fix multi-prerequisite example
- doc/gitk: s/sticked/stuck/
- git-jump: admit to passing merge mode args to ls-files
- doc/diff-options: improve wording of the log.diffMerges mention
- doc: fix some typos, grammar and wording issues
Many typos, ungrammatical sentences and wrong phrasing have been
fixed.
Needs review.
source: <20231003082107.3002173-1-stepnem@smrk.net>
* so/diff-merges-dd (2023-10-09) 3 commits
- completion: complete '--dd'
- diff-merges: introduce '--dd' option
- diff-merges: improve --diff-merges documentation
"git log" and friends learned "--dd" that is a short-hand for
"--diff-merges=first-parent -p".
Will merge to 'next'?
source: <20231009160535.236523-1-sorganov@gmail.com>
* vd/loose-ref-iteration-optimization (2023-10-09) 4 commits
(merged to 'next' on 2023-10-12 at 99e2f83855)
+ files-backend.c: avoid stat in 'loose_fill_ref_dir'
+ dir.[ch]: add 'follow_symlink' arg to 'get_dtype'
+ dir.[ch]: expose 'get_dtype'
+ ref-cache.c: fix prefix matching in ref iteration
The code to iterate over loose references have been optimized to
reduce the number of lstat() system calls.
Will merge to 'master'.
source: <pull.1594.v2.git.1696888736.gitgitgadget@gmail.com>
* jc/update-list-references-to-lore (2023-10-06) 1 commit
- doc: update list archive reference to use lore.kernel.org
Doc update.
Needs review.
source: <xmqq7cnz741s.fsf@gitster.g>
* cc/git-replay (2023-10-10) 14 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: change rev walking options
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
Introduce "git replay", a tool meant on the server side without
working tree to recreate a history.
Needs (hopefully final and quick) review.
source: <20231010123847.2777056-1-christian.couder@gmail.com>
* tb/repack-max-cruft-size (2023-10-09) 5 commits
(merged to 'next' on 2023-10-09 at 38f039e880)
+ repack: free existing_cruft array after use
(merged to 'next' on 2023-10-06 at b3ca6df3b9)
+ builtin/repack.c: avoid making cruft packs preferred
+ builtin/repack.c: implement support for `--max-cruft-size`
+ builtin/repack.c: parse `--max-pack-size` with OPT_MAGNITUDE
+ t7700: split cruft-related tests to t7704
"git repack" learned "--max-cruft-size" to prevent cruft packs from
growing without bounds.
Will merge to 'master'.
source: <cover.1696293862.git.me@ttaylorr.com>
source: <20231007172031.GA1524950@coredump.intra.peff.net>
source: <035393935108d02aaf8927189b05102f4f74f340.1696370003.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-03) 1 commit
- decorate: add color.decorate.symbols config option
A new config for coloring.
Needs review.
source: <20231003205442.22963-1-andy.koppe@gmail.com>
* jc/attr-tree-config (2023-10-13) 2 commits
- attr: add attr.tree for setting the treeish to read attributes from
- attr: read attributes from HEAD when bare repo
The attribute subsystem learned to honor `attr.tree` configuration
that specifies which tree to read the .gitattributes files from.
Will merge to 'next'?
source: <pull.1577.v5.git.git.1697218770.gitgitgadget@gmail.com>
* js/update-urls-in-doc-and-comment (2023-09-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: update links to current pages
- doc: switch links to https
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Needs review.
source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-09-26) 4 commits
- trailer: only use trailer_block_* variables if trailers were found
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Needs review.
source: <pull.1563.v4.git.1695709372.gitgitgadget@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-10-04) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1696432593.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-10-04) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <cover.1696425168.git.zhiyou.jx@alibaba-inc.com>
* ty/merge-tree-strategy-options (2023-10-11) 2 commits
(merged to 'next' on 2023-10-12 at 9b873601df)
+ merge: introduce {copy|clear}_merge_options()
(merged to 'next' on 2023-09-29 at aa65b54416)
+ merge-tree: add -X strategy option
"git merge-tree" learned to take strategy backend specific options
via the "-X" option, like "git merge" does.
Will merge to 'master'.
source: <pull.1565.v6.git.1695522222723.gitgitgadget@gmail.com>
* js/config-parse (2023-09-21) 5 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
Needs review.
source: <cover.1695330852.git.steadmon@google.com>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* rs/parse-options-value-int (2023-09-18) 2 commits
- parse-options: use and require int pointer for OPT_CMDMODE
- parse-options: add int value pointer to struct option
A bit of type safety for the "value" pointer used in the
parse-options API.
Not ready yet.
cf. <4014e490-c6c1-453d-b0ed-645220e3e614@web.de>
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* js/doc-unit-tests (2023-10-09) 3 commits
- ci: run unit tests in CI
- unit tests: add TAP unit test framework
- unit tests: add a project plan document
(this branch is used by jc/doc-unit-tests-fixup and js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Expecting a reroll to address CI breakage.
source: <cover.1696889529.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-10-09) 7 commits
- cmake: handle also unit tests
- cmake: use test names instead of full paths
- cmake: fix typo in variable name
- artifacts-tar: when including `.dll` files, don't forget the unit-tests
- unit-tests: do show relative file paths
- unit-tests: do not mistake `.pdb` files for being executable
- cmake: also build unit tests
(this branch is used by jc/doc-unit-tests-fixup; uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Needs review.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-08-01) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
cf. <xmqqtttia3vn.fsf@gitster.g>
source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>
--------------------------------------------------
[Discarded]
* tb/ci-coverity (2023-09-21) 1 commit
. .github/workflows: add coverity action
GitHub CI workflow has learned to trigger Coverity check.
Superseded by the js/ci-coverity topic.
source: <b23951c569660e1891a7fb3ad2c2ea1952897bd7.1695332105.git.me@ttaylorr.com>
* cw/git-std-lib (2023-09-11) 7 commits
. SQUASH???
. git-std-lib: add test file to call git-std-lib.a functions
. git-std-lib: introduce git standard library
. parse: create new library for parsing strings and env values
. config: correct bad boolean env value error message
. wrapper: remove dependency to Git-specific internal file
. hex-ll: split out functionality from hex
Another libification effort.
Superseded by the cw/prelim-cleanup topic.
cf. <xmqqy1hfrk6p.fsf@gitster.g>
cf. <20230915183927.1597414-1-jonathantanmy@google.com>
source: <20230908174134.1026823-1-calvinwan@google.com>
* so/diff-merges-d (2023-09-11) 2 commits
- diff-merges: introduce '-d' option
- diff-merges: improve --diff-merges documentation
Superseded by the so/diff-merges-dd topic.
source: <20230909125446.142715-1-sorganov@gmail.com>
* kn/rev-list-ignore-missing-links (2023-09-20) 1 commit
. revision: add `--ignore-missing-links` user option
Surface the .ignore_missing_links bit that stops the revision
traversal from stopping and dying when encountering a missing
object to a new command line option of "git rev-list", so that the
objects that are required but are missing can be enumerated.
Superseded by kn/rev-list-missing-fix
source: <20230920104507.21664-1-karthik.188@gmail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox