On Tue, Oct 01, 2019 at 04:16:26AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
Good idea, now that 'make hdr-check' runs clean this will help to keep
it that way.
I think adding it to the static analysis job makes sense, as opposed
to the
On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
> Commits 404ebceda01c ("dir: also check directories for matching
> pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
> match files under a dir, recurse into it", 2019-09-17) added ca
On Tue, Oct 1, 2019 at 12:39 PM Elijah Newren wrote:
>
> On Tue, Oct 1, 2019 at 12:35 PM Denton Liu wrote:
> >
> > Hi Elijah,
> >
> > Sorry for dragging out this thread for so long...
> >
> > On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
> >
> > [...]
> >
> > > diff --git a/t/t00
t; + sudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \
> > + libexpat-dev gettext
> > ;;
> > Documentation)
> > sudo apt-get -q update
> > diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh
> > index a19aa7ebbc..65bcebda41 100755
> > --- a/ci/run-static-analysis.sh
> > +++ b/ci/run-static-analysis.sh
> > @@ -26,4 +26,7 @@ then
> > exit 1
> > fi
> >
> > +make hdr-check ||
> > +exit 1
> > +
> > save_good_tree
>
/ci/run-static-analysis.sh
> index a19aa7ebbc..65bcebda41 100755
> --- a/ci/run-static-analysis.sh
> +++ b/ci/run-static-analysis.sh
> @@ -26,4 +26,7 @@ then
> exit 1
> fi
>
> +make hdr-check ||
> +exit 1
> +
> save_good_tree
On Tue, Oct 1, 2019 at 12:35 PM Denton Liu wrote:
>
> Hi Elijah,
>
> Sorry for dragging out this thread for so long...
>
> On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
>
> [...]
>
> > diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> > index 192c94eccd..a840919967 1007
Hi Elijah,
Sorry for dragging out this thread for so long...
On Tue, Oct 01, 2019 at 11:55:24AM -0700, Elijah Newren wrote:
[...]
> diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> index 192c94eccd..a840919967 100755
> --- a/t/t0050-filesystem.sh
> +++ b/t/t0050-filesystem.sh
> @@ -
Commits 404ebceda01c ("dir: also check directories for matching
pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
match files under a dir, recurse into it", 2019-09-17) added calls to
match_pathspec() and do_match_pathspec() passing along their paths
On Tue, Oct 1, 2019 at 11:41 AM Denton Liu wrote:
>
> Hi Elijah,
>
> On Tue, Oct 01, 2019 at 11:30:05AM -0700, Elijah Newren wrote:
>
> [...]
>
> > diff --git a/dir.c b/dir.c
> > index 7ff79170fc..bd39b86be4 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -1962,8 +1962,9 @@ static enum path_treatmen
der whether it would make sense to add a `hdr-check` to at least
one macOS and on Windows job, too, so that we get some confidence in the
non-Linux contributions. But that I _will_ leave to others ;-)
> On Tue, Oct 01, 2019 at 04:16:26AM -0700, Johannes Schindelin via
> GitGitGadget wrote
Hi Elijah,
On Tue, Oct 01, 2019 at 11:30:05AM -0700, Elijah Newren wrote:
[...]
> diff --git a/dir.c b/dir.c
> index 7ff79170fc..bd39b86be4 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1962,8 +1962,9 @@ static enum path_treatment
> read_directory_recursive(struct dir_struct *dir,
>
Commits 404ebceda01c ("dir: also check directories for matching
pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
match files under a dir, recurse into it", 2019-09-17) added calls to
match_pathspec() and do_match_pathspec() passing along their paths
-y install coccinelle libcurl4-openssl-dev libssl-dev \
> + libexpat-dev gettext
> ;;
> Documentation)
> sudo apt-get -q update
> diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh
> index a19aa7ebbc..65bcebda41 100755
> --- a/ci/run-static-analysis.sh
> +++ b/ci/run-static-analysis.sh
> @@ -26,4 +26,7 @@ then
> exit 1
> fi
>
> +make hdr-check ||
> +exit 1
> +
> save_good_tree
> --
> gitgitgadget
Our hdr-check target is now functional in more ways than before. Let's run
it as part of the CI builds.
I offered this idea in a review of dl/honor-cflags-in-hdr-check
[https://public-inbox.org/git/nycvar.qro.7.76.6.1909261452340.15...@tvgsbejvaqbjf.bet/]
but it was not picked up. So I off
ci/run-static-analysis.sh
+++ b/ci/run-static-analysis.sh
@@ -26,4 +26,7 @@ then
exit 1
fi
+make hdr-check ||
+exit 1
+
save_good_tree
--
gitgitgadget
On Mon, Sep 30, 2019 at 3:31 PM Denton Liu wrote:
>
> Hi Elijah,
>
> On Mon, Sep 30, 2019 at 12:11:06PM -0700, Elijah Newren wrote:
> > Commits 404ebceda01c ("dir: also check directories for matching
> > pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our
Hi Elijah,
On Mon, Sep 30, 2019 at 12:11:06PM -0700, Elijah Newren wrote:
> Commits 404ebceda01c ("dir: also check directories for matching
> pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
> match files under a dir, recurse into it"
Commits 404ebceda01c ("dir: also check directories for matching
pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
match files under a dir, recurse into it", 2019-09-17) added calls to
match_pathspec() and do_match_pathspec() passing along their paths
acOS. I managed to bisect it down to
> > > 404ebceda0 (dir: also check directories for matching pathspecs,
> > > 2019-09-17), which should be the patch in the parent thread. The test
> > > case below works fine without this patch applied but segfaults once it
> > > is a
On Fri, Sep 27, 2019 at 03:09:30AM +0200, SZEDER Gábor wrote:
> On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> > Hi Elijah,
> >
> > I ran into a segfault on MacOS. I managed to bisect it down to
> > 404ebceda0 (dir: also check directories for matchin
On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> Hi Elijah,
>
> I ran into a segfault on MacOS. I managed to bisect it down to
> 404ebceda0 (dir: also check directories for matching pathspecs,
> 2019-09-17), which should be the patch in the parent thread. The test
>
h.len,
> + if (pathspec && !match_pathspec(istate, pathspec,
> path.buf, path.len,
> 0 /* prefix */, NULL,
> 0 /* do NOT special case dirs */))
>
On Wed, Sep 25, 2019 at 02:55:30PM -0700, Denton Liu wrote:
> Looks correct to me. I don't see why this wouldn't reproduce. I'll send
> you more information if I figure anything else out.
I looked into it a little more and I think I know why it's being
triggered.
When we checkout 'todo' from 'mas
Hi Denton,
On Mon, 23 Sep 2019, Denton Liu wrote:
> This patchset relates to `make hdr-check`. The first patch addresses
> getting it to run on platforms which require custom CFLAGS.
>
> The other two patches address errors/warnings caught by actually running
> `make hdr-check`.
&
these are two worktrees I have checked out):
/jch
/patches
aside from that, I don't think I've changed anything else. Anyway, to
double-check that it wasn't my setup that was broken, I ran
cd ..
git clone git git2
cd git2
make configure
./co
Hi Denton,
On Wed, Sep 25, 2019 at 1:39 PM Denton Liu wrote:
>
> Hi Elijah,
>
> I ran into a segfault on MacOS. I managed to bisect it down to
> 404ebceda0 (dir: also check directories for matching pathspecs,
> 2019-09-17), which should be the patch in the parent thread. The
Hi Elijah,
I ran into a segfault on MacOS. I managed to bisect it down to
404ebceda0 (dir: also check directories for matching pathspecs,
2019-09-17), which should be the patch in the parent thread. The test
case below works fine without this patch applied but segfaults once it
is applied
The first two patches fix errors causing `make hdr-check` to fail. The third is
legacy from v1 but provides code cleanup so we leave it. Finally, the last
patch is a patch which improves the portability and correctness of `hdr-check`.
Changes since v1:
* Reordered patches to put fixes first
This patchset relates to `make hdr-check`. The first patch addresses
getting it to run on platforms which require custom CFLAGS.
The other two patches address errors/warnings caught by actually running
`make hdr-check`.
Denton Liu (3):
Makefile: use $(ALL_CFLAGS) in $(HCO) target
apply.h
)
Fix this by actually checking whether the directory we are about to add
to the list of dir entries actually matches the pathspec; only do this
matching check after we have already returned from recursing into the
directory.
Signed-off-by: Elijah Newren
---
dir.c| 5 +
t/t7300-cl
Am 15.09.19 um 17:15 schrieb brian m. carlson:
> This approach seems reasonable. I must admit some curiosity as to how
> you discovered this issue, though. Did you have a cat assisting you in
> typing revisions?
Found it by reading the code, but I'm not sure anymore what I was
actually looking f
e can switch to a
> wider data type, but we'd still have to check for overflow.
Certainly we want Git to perform as well as possible on large
repositories, but I doubt if it will scale to more than 2 billion
revisions, even with significant effort. I think this restriction
should be fine.
Reject values that don't fit into an int, as get_parent() and
get_nth_ancestor() cannot handle them. That's better than potentially
returning a random object.
If this restriction turns out to be too tight then we can switch to a
wider data type, but we'd still have to check for ov
On 13/09/19 09:50AM, Birger Skogeng Pedersen wrote:
> Hi Marc and Philip,
>
>
> On 12/09/2019 22:34, Marc Branchaud wrote:
> > I disagree! Who expects anything to work properly when capslock is on?
>
> Me :-)
>
>
> On Fri, Sep 13, 2019 at 12:23 AM Philip Oakley wrote:
> > I'd tend to agree.
On 2019-09-13 3:50 a.m., Birger Skogeng Pedersen wrote:
Hi Marc and Philip,
On 12/09/2019 22:34, Marc Branchaud wrote:
I disagree! Who expects anything to work properly when capslock is on?
Me :-)
Fair enough, though I imagine you have a pretty narrow definition of
"anything". :)
On
Hi Marc and Philip,
On 12/09/2019 22:34, Marc Branchaud wrote:
> I disagree! Who expects anything to work properly when capslock is on?
Me :-)
On Fri, Sep 13, 2019 at 12:23 AM Philip Oakley wrote:
> I'd tend to agree. In other areas the use of shift is often used as the
> complement of the u
On 12/09/2019 22:34, Marc Branchaud wrote:
I just tested what happens when you press Ctrl+e while Caps Lock is
enabled; the Ctrl+e binding is not invoked. That's probably why other
key bindings have the same function bound for both lower- and
upper-case letters, to have the same behaviour with/wi
)
Fix this by actually checking whether the directory we are about to add
to the list of dir entries actually matches the pathspec; only do this
matching check after we have already returned from recursing into the
directory.
Signed-off-by: Elijah Newren
---
dir.c| 5 +
t/t7300-cl
On 2019-09-12 12:29 p.m., Pratyush Yadav wrote:
On 12/09/19 08:05AM, Birger Skogeng Pedersen wrote:
Hi Pratyush,
On Wed, Sep 11, 2019 at 10:55 PM Pratyush Yadav wrote:
Also, I notice that the bindings for other letters have the same
function bound for both small and capital letters (IOW, same
On 9/12/2019 10:44 AM, Jeff King wrote:
> Commit 43d3561805 (commit-graph write: don't die if the existing graph
> is corrupt, 2019-03-25) added an environment variable we use only in the
> test suite, $GIT_TEST_COMMIT_GRAPH_DIE_ON_LOAD. But it put the check for
> this variable a
On 12/09/19 08:05AM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> On Wed, Sep 11, 2019 at 10:55 PM Pratyush Yadav
> wrote:
> > Also, I notice that the bindings for other letters have the same
> > function bound for both small and capital letters (IOW, same behavior
> > with shift held and r
Commit 43d3561805 (commit-graph write: don't die if the existing graph
is corrupt, 2019-03-25) added an environment variable we use only in the
test suite, $GIT_TEST_COMMIT_GRAPH_DIE_ON_LOAD. But it put the check for
this variable at the very top of prepare_commit_graph(), which is called
Hi Pratyush,
On Wed, Sep 11, 2019 at 10:55 PM Pratyush Yadav wrote:
> Also, I notice that the bindings for other letters have the same
> function bound for both small and capital letters (IOW, same behavior
> with shift held and released).
>
> I don't necessarily think that is a great idea. It is
Birger,
Please ignore the two emails I sent about basing your work on top of
Bert's. I see that you have already done so (or maybe Bert did it, I
don't know), and I was reading an older version of the patch.
On 05/09/19 10:09PM, Bert Wesarg wrote:
> From: Birger Skogeng Pedersen
>
> Selecting
styped the variable name, and started
to check GIT_TEST_HTTPD instead. Consequently, if someone explicitly
set GIT_TEST_HTTPD to true and has only the general 'git-svn'
dependencies installed but not the Subversion server modules for
Apache (libapache2-mod-svn), then a couple of 'git-svn&
From: Birger Skogeng Pedersen
Selecting whether to "Amend Last Commit" or not does not have a hotkey.
With this patch, the user may toggle between the two options with
CTRL/CMD+e.
Signed-off-by: Birger Skogeng Pedersen
Rebased-by: Bert Wesarg
---
git-gui.sh | 8
1 file changed, 8 in
We have a function to strip the path suffix from a commit, but we don't
have one to check for a path suffix. For a plain filename, we can use
basename, but that requires an allocation, since POSIX allows it to
modify its argument. Refactor strip_path_suffix into a helper function
and
Taylor Blau writes:
> I wholeheartedly agree with this, and pledge my $.02 towards it as well.
> Now with a combined total of $.04, I think that this patch is ready for
> queueing as-is.
;-)
On 8/29/2019 8:43 PM, Taylor Blau wrote:
> Hi Elijah,
>
> On Thu, Aug 29, 2019 at 05:19:44PM -0700, Elijah Newren wrote:
>> Personally, although I understand the desire to support any possible
>> cases in general, *this is a performance hack*. As such, it should be
>> as simple and localized as p
Hi Elijah,
On Thu, Aug 29, 2019 at 05:19:44PM -0700, Elijah Newren wrote:
> On Thu, Aug 29, 2019 at 2:42 PM Pratyush Yadav wrote:
> >
> > On 30/08/19 02:00AM, Pratyush Yadav wrote:
> > > On 29/08/19 04:07PM, Derrick Stolee wrote:
> > > > On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > > > > Hi Stol
On Thu, Aug 29, 2019 at 2:42 PM Pratyush Yadav wrote:
>
> On 30/08/19 02:00AM, Pratyush Yadav wrote:
> > On 29/08/19 04:07PM, Derrick Stolee wrote:
> > > On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > > > Hi Stolee
> > > >
> > > > On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
> > > >>
On 30/08/19 02:00AM, Pratyush Yadav wrote:
> On 29/08/19 04:07PM, Derrick Stolee wrote:
> > On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > > Hi Stolee
> > >
> > > On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
> > >> +
> > >> + if (argc == 3 && !strcmp(argv[1], "-b")) {
> > >> +
On 29/08/19 04:07PM, Derrick Stolee wrote:
> On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > Hi Stolee
> >
> > On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
> >> +
> >> + if (argc == 3 && !strcmp(argv[1], "-b")) {
> >> + /*
> >> + * User ran 'git checkout -b ' and
On 8/29/2019 2:54 PM, Phillip Wood wrote:
> Hi Stolee
>
> On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
>> +
>> + if (argc == 3 && !strcmp(argv[1], "-b")) {
>> + /*
>> + * User ran 'git checkout -b ' and expects
>
> What if the user ran 'git checkout -b'? Then a
Hi Stolee
On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The 'git switch' command was created to separate half of the
behavior of 'git checkout'. It specifically has the mode to
do nothing with the index and working directory if the user
only specifies to crea
On Thu, Aug 29, 2019 at 10:04 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The 'git switch' command was created to separate half of the
> behavior of 'git checkout'. It specifically has the mode to
> do nothing with the index and working directory if the user
> only spec
From: Derrick Stolee
The 'git switch' command was created to separate half of the
behavior of 'git checkout'. It specifically has the mode to
do nothing with the index and working directory if the user
only specifies to create a new branch and change HEAD to that
branch. This is also the behavior
t checkout -b ' should do the fast thing, and we should check the
arguments directly.
This series makes 'git checkout -b ' do the same thing as 'git switch -c '.
Thanks, -Stolee
[1] https://public-inbox.org/git/pull.317.git.gitgitgad...@gmail.com/
Derr
"Johannes Schindelin via GitGitGadget"
writes:
> When I was playing with the Makefile target hdr-check, it looked as if it
> missed the correct CFLAGS. Without them, on Windows an attempt is made to
> include syslog.h, which does not make sense at all.
Makes sense.
Thanks.
We have a function to strip the path suffix from a commit, but we don't
have one to check for a path suffix. For a plain filename, we can use
basename, but that requires an allocation, since POSIX allows it to
modify its argument. Refactor strip_path_suffix into a helper function
and
When I was playing with the Makefile target hdr-check, it looked as if it
missed the correct CFLAGS. Without them, on Windows an attempt is made to
include syslog.h, which does not make sense at all.
This patch addresses that.
Johannes Schindelin (1):
hdr-check: make it work on Windows
From: Johannes Schindelin
On Windows, we define a specific set of pre-processor macros, among
other reasons: to avoid including syslog.h (which is not available on
Windows).
The hdr-check target did not use those definitions, resulting in a
failure to include said syslog.h.
To fix that, let&#
From: Phillip Wood
While a rebase is stopped for the user to edit a commit message it can
be convenient for them to also edit the todo list. The scripted version
of rebase supported this but the C version does not. We already check to
see if the todo list has been updated by an exec command so
We have a function to strip the path suffix from a commit, but we don't
have one to check for a path suffix. For a plain filename, we can use
basename, but that requires an allocation, since POSIX allows it to
modify its argument. Refactor strip_path_suffix into a helper function
and
SZEDER Gábor writes:
> ... And that function must be able to handle multiple path
> components, becase there is this callsite:
>
> exec-cmd.c: !(prefix = strip_path_suffix(executable_dirname,
> GIT_EXEC_PATH)) &&
>
> and the build sets '-DGIT_EXEC_PATH="libexec/git-core"' by default.
"brian m. carlson" writes:
> Well, I split it out from a function that handles multiple path
> components, mostly so that I could leverage existing work (and not have
> to worry about getting it wrong). It wasn't explicitly intended that it
> support multiple components, since I don't require tha
We have a function to strip the path suffix from a commit, but we don't
have one to check for a path suffix. For a plain filename, we can use
basename, but that requires an allocation, since POSIX allows it to
modify its argument. Refactor strip_path_suffix into a helper function
and
On Mon, Aug 12, 2019 at 09:49:20AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> >> "brian m. carlson" writes:
> >> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
> >> > *suffix)
> >>
> >> Perhaps
On Mon, Aug 12, 2019 at 10:40:21PM +, brian m. carlson wrote:
> I think "ends_with_path_components" might be the way forward, unless
> you think something else would be better.
FWIW, having read the rest of the thread, that was the name that clicked
for me.
-Peff
On 2019-08-12 at 16:49:20, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> >> "brian m. carlson" writes:
> >> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
> >> > *suffix)
> >>
> >> Perhaps
> >>
> >>
35
Subject: Re: Git add claims path is ignored, but git check-ignore returns no
results
On Mon, Aug 12, 2019 at 04:24:59PM +, geoffsim...@aim.com wrote:
> I can’t find anything relevant in .git/info/exclude either, or any of
> the .gitignore files I could find.
>
> git check
"brian m. carlson" writes:
> On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
>> > *suffix)
>>
>> Perhaps
>>
>> static ssize_t last_path_component_offset(const char *path, const cha
On Mon, Aug 12, 2019 at 04:24:59PM +, geoffsim...@aim.com wrote:
> I can’t find anything relevant in .git/info/exclude either, or any of
> the .gitignore files I could find.
>
> git check-ignore
> .\Source\UI\Website\LiveFeeds\Releases\IO\ReleasesSerializer.cs
> git add .
Hi,
I’m struggling with this. Adding a renamed file to git claims that it is
ignored, but git check-ignore returns no results.
I can’t find anything relevant in .git/info/exclude either, or any of the
.gitignore files I could find.
git check-ignore .\Source\UI\Website\LiveFeeds\Releases\IO
On Mon, Aug 12, 2019 at 01:10:54AM +, brian m. carlson wrote:
> On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> > "brian m. carlson" writes:
> > > +static ssize_t stripped_path_suffix_offset(const char *path, const char
> > > *suffix)
> >
> > Perhaps
> >
> > static ssize_t last_path_
On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> "brian m. carlson" writes:
> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
> > *suffix)
>
> Perhaps
>
> static ssize_t last_path_component_offset(const char *path, const char
> *name)
>
> I am tempted to also
"brian m. carlson" writes:
> We have a function to strip the path suffix from a commit, but we don't
> have one to check for a path suffix. For a plain filename, we can use
> basename, but that requires an allocation, since POSIX allows it to
> modify its argument.
We have a function to strip the path suffix from a commit, but we don't
have one to check for a path suffix. For a plain filename, we can use
basename, but that requires an allocation, since POSIX allows it to
modify its argument. Refactor strip_path_suffix into a helper function
and
We try to delete the non-existing tag "anothertag", but for the
verifications, we check that the tag "myhead" doesn't exist. "myhead"
isn't used in this test except for this checking. Comparing to the test
two tests earlier, it looks like a copy-paste mista
Alban Gruin writes:
>> > + test_i18ncmp expect.2 actual &&
>> > + cp .git/rebase-merge/git-rebase-todo.backup \
>> > + .git/rebase-merge/git-rebase-todo &&
>>
>> Why? Who uses this copy?
>>
>
> The same technique is used in "rebase -i respects rebase.missingCommitsCheck
> =
> erro
Hi Junio,
Le 18/07/2019 à 20:31, Junio C Hamano a écrit :
> Alban Gruin writes:
> > When set to "warn" or "error", `rebase.missingCommitCheck' would make
> > rebase -i warn if the user removed commits from the todo list to prevent
> > mistakes. Unfortunately, rebase --edit-todo and rebase --cont
Alban Gruin writes:
> When set to "warn" or "error", `rebase.missingCommitCheck' would make
> rebase -i warn if the user removed commits from the todo list to prevent
> mistakes. Unfortunately, rebase --edit-todo and rebase --continue don't
> take it into account.
>
> This adds three tests to t3
Jeff King writes:
> Other than that, our options seem to be:
>
> 1. Live with it. IIRC we're already not sparse-clean, and Ramsay
> mostly looks at the diff to find new problems.
OK.
> 2. Pass -Wno-non-pointer-null to sparse. Unfortunately that also
> disables more useful warnings
e the "{0}" version? In particular,
> > does it work for sparse?
>
> Yeah, I agree that it is the most important question. The best
> solution is not to do the macro, use "= { 0 };" everywhere *and*
> somehow arrange sparse not to complain about it. I am not
Jeff King writes:
> ... My big question is if we use "{}" for gcc (and
> compatible friends), does that squelch all of the complaints from other
> compilers and tools that might see the "{0}" version? In particular,
> does it work for sparse?
Yeah, I agree that it is the most important question.
Am 16.07.19 um 21:01 schrieb Junio C Hamano:
> but as long as we declare that we take "{ 0 }" as a mere convention
> [...], I am perfectly fine with it, and if it is hidden
> behind a macro, that would be even better ;-)
And I thought that "Avoid macros!" would be a welcome guideline...
I think w
This adds the ability to check if commits were dropped when resuming a
rebase (with `--continue') or when reloading the todo list after an
`exec' command.
Tests added previously should work now.
Signed-off-by: Alban Gruin
---
sequencer.c | 5 -
t/t3
When set to "warn" or "error", `rebase.missingCommitCheck' would make
rebase -i warn if the user removed commits from the todo list to prevent
mistakes. Unfortunately, rebase --edit-todo and rebase --continue don't
take it into account.
This adds three tests to t3404 to demonstrate this. The fir
After executing a command, rebase reloads the todo list from the disk,
in case the script has modified it, but does not honour
rebase.missingCommitsCheck.
This adds three tests to t3429 to demonstrate this. The first one is
not broken, as when `rebase.missingCommitsCheck' is not set, nothing
shou
On Tue, Jul 16, 2019 at 12:01:10PM -0700, Junio C Hamano wrote:
> And that "quiet and nice" form is a moral equivalent of
>
> struct foo foo = { 0 };
>
> that has been discussed in this thread. I'd rather not to see it
> turned into distinct FOO_INIT, BAR_INIT, etc. to force the reader to
Jeff King writes:
> But I'd be happy if we could address it in another way (e.g., convincing
> sparse to stop complaining about it, or just decide it's not worth
> dealing with). One other thing I haven't seen discussed in this thread:
> we could actually make our preferred style be for all struc
On Mon, Jul 15, 2019 at 07:30:09PM +0200, Johannes Sixt wrote:
> Am 15.07.19 um 16:46 schrieb Jeff King:
> > On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
> >>> But it does fall down
> >>> when the first element _has_ to be a struct (like, say, any user of our
> >>> hashmap.[ch] i
Am 15.07.19 um 16:46 schrieb Jeff King:
> On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
>>> But it does fall down
>>> when the first element _has_ to be a struct (like, say, any user of our
>>> hashmap.[ch] interface).
>>
>> No, it does not. It is not necessary to spell out nested
On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote:
> Why would you re-order members? There's nothing wrong when a pointer is
> initialized by 0.
To appease tooling like "sparse" without having to remember to do
anything specific at the point-of-use sites. I'm open to the idea that
it
Hi,
On Sat, 13 Jul 2019, Carlo Arenas wrote:
> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
> >
> > I wish if we could say
> >
> > struct patch patch = {};
>
> that is actually a GNU extension that is supported by gcc and clang (at least)
> and that sparse also recognizes as va
Am 14.07.19 um 02:51 schrieb Jeff King:
> I wonder if we could come up with a definition of INIT_ZERO such that:
>
> struct foo bar = { INIT_ZERO };
>
> worked everywhere. IMHO that is more readable than "{}" anyway.
Not when = {} becomes a well-established way to express
zero-initialization.
Am 13.07.19 um 23:29 schrieb Junio C Hamano:
> I do not think this position is maintainable, especially if you
> agree with me (and everybody else, including sparse) that this is a
> bad idea:
>
>> struct string_list dup_it = { 0, 0, 0, 1, 0 };
>
> The way I read "6.7.8 Initialization" (sorry,
On Sat, Jul 13, 2019 at 03:22:03PM -0700, Carlo Arenas wrote:
> On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
> >
> > I wish if we could say
> >
> > struct patch patch = {};
>
> that is actually a GNU extension that is supported by gcc and clang (at least)
> and that sparse also
On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
>
> I wish if we could say
>
> struct patch patch = {};
that is actually a GNU extension that is supported by gcc and clang (at least)
and that sparse also recognizes as valid; it is also valid C++ so it might be
even supported by MSVC
Johannes Sixt writes:
>> Hmm, care to elaborate a bit? Certainly, we have a clear preference
>> between these two:
>>
>> struct patch patch;
>> patch.new_name = 0;
>> patch.new_name = NULL;
>>
>> where the "char *new_name" field is the first one in the structure.
>> We always tr
1 - 100 of 3024 matches
Mail list logo
