Since both functions are using the same data type, they should either both
refer to it as void *, or both use the real type (struct alloc_state *).
Opt for the latter.
Signed-off-by: Elijah Newren
---
alloc.c | 2 +-
alloc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
We're moving away from the_index in this code. "struct index_state *"
could be added to struct apply_state. But let's aim long term and put
struct repository here instead so that we could even avoid more global
states in the future. The index will be available via
apply_state->repo->index.
Hi Stefan,
On Fri, 10 Aug 2018, Stefan Beller wrote:
> This change itself only changes the internal communication and should
> have no visible effect to the user. We instruct the diff code that produces
> the inner diffs to use X, Y, Z instead of the usual markers for new, old
> and context
.
Therefore, we really want to make the dual color mode the default.
Signed-off-by: Johannes Schindelin
---
Documentation/git-range-diff.txt | 32 +++---
builtin/range-diff.c | 10
contrib/completion/git-completion.bash | 2 +-
3 files changed
> That will recurse any subdirectories, possibly wasting time, but since
> the point is that we expect it to be empty, that's probably OK.
One caveat involves invocations of `test_must_fail test_dir_is_empty`,
wherein we _don't_ actually expect the directory to be empty. It looks
like there might
Since both functions are using the same data type, they should either both
refer to it as void *, or both use the real type (struct alloc_state *).
Opt for the latter.
Signed-off-by: Elijah Newren
---
alloc.c | 2 +-
alloc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Since both functions are using the same data type, they should either both
refer to it as void *, or both use the real type (struct alloc_state *).
Opt for the latter.
Signed-off-by: Elijah Newren
---
alloc.c | 2 +-
alloc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
This change itself only changes the internal communication and should
have no visible effect to the user. We instruct the diff code that produces
the inner diffs to use X, Y, Z instead of the usual markers for new, old
and context lines
Signed-off-by: Stefan Beller
---
range-diff.c | 15
.
Therefore, we really want to make the dual color mode the default.
Signed-off-by: Johannes Schindelin
---
Documentation/git-range-diff.txt | 32 +++---
builtin/range-diff.c | 10
contrib/completion/git-completion.bash | 2 +-
3 files changed
f the dual color mode still
> > leaves a lot of room for confusion about what was actually changed, the
> > non-dual color mode is substantially worse in that regard.
> >
> > Therefore, we really want to make the dual color mode the default.
>
> Ah and here we're makin
This makes rebase_path_todo(), get_missing_commit_check_level(),
write_message() and the enum check_level accessible outside sequencer.c,
renames check_level to missing_commit_check_level, and prefixes its
value names by MISSING_COMMIT_ to avoid namespace pollution.
This function and this enum
rticularly think it is "dangerous". In fact, that sort
> of behaviour was what I had in mind when I said "work sensibly".
>
> When resolving a conflict that they added a new path at stage #3 to
> remove that path, I can say "git rm $that_path", which removes all
&
t;.
When resolving a conflict that they added a new path at stage #3 to
remove that path, I can say "git rm $that_path", which removes all
stages of that path and make the index closer to the next commit.
Or I may decide to keep that path by "git add $that_path", which
adds that pa
p files created by the merge operation.
>
> Yeah, and then our file "path" renamed to "path~2" to make room for
> directory "path" they introduced, can be relocated to its final
> place in the merge resolution, e.g. "git mv path~2 path/ours" or
&g
g in the way; if we also record
> the file under a different name in the index then it simplifies matters
> for the user, and ensures that 'git reset --hard' and 'git merge --abort'
> will clean up files created by the merge operation.
Yeah, and then our file "path" renamed to &quo
From: Jeff King
As get_delta_base() will be used outside 'packfile.c' in
a following commit, let's make it non static and let's
declare it in 'packfile.h'.
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
---
packfile.c | 10 +-
packfile.h | 7 +++
2 files changed, 12
Hi Phillip,
On Thu, 9 Aug 2018, Phillip Wood wrote:
> On 09/08/18 10:22, Johannes Schindelin wrote:
> >
> > On Mon, 6 Aug 2018, Phillip Wood wrote:
> >
> >> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
> >>>
> >>> + else if (is_fixup(command)) {
> >>> +
On 09/08/18 10:22, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Mon, 6 Aug 2018, Phillip Wood wrote:
>
>> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
>>>
>>> From: Johannes Schindelin
>>>
>>> The idea of `--exec` is to append an `exec` call after each `pick`.
>>>
>>> Since
the end of the fixup/squash chain, we
continue the loop, delaying the insertion until we know where the
fixup/squash chain ends, if any.
Johannes Schindelin (2):
t3430: demonstrate what -r, --autosquash & --exec should do
rebase --exec: make it work with --rebase-merges
seque
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of
Hi Phillip,
On Mon, 6 Aug 2018, Phillip Wood wrote:
> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
> >
> > From: Johannes Schindelin
> >
> > The idea of `--exec` is to append an `exec` call after each `pick`.
> >
> > Since the introduction of fixup!/squash! commits, this
Currently when git-fetch is asked to recurse into submodules, it dispatches
a plain "git-fetch -C " (and some submodule related options
such as prefix and recusing strategy, but) without any information of the
remote or the tip that should be fetched.
This works surprisingly well in some
There is a change in behaviour with this commit. When there was
no initial commit, the shell version of stash would still display
a message. This commit makes `push` to not display any message if
`--quiet` or `-q` is specified.
---
builtin/stash--helper.c | 41
On Tue, Aug 7, 2018 at 2:07 AM, SZEDER Gábor wrote:
>> A test making use of test_must_fail was failing like this:
>> fatal: ambiguous argument '|': unknown revision or path not in the working
>> tree.
>> when the intent was to verify that a specific string was not found
>> in the output of the
> A test making use of test_must_fail was failing like this:
> fatal: ambiguous argument '|': unknown revision or path not in the working
> tree.
> when the intent was to verify that a specific string was not found
> in the output of the git diff command, i.e. that grep returned
> non-zero.
File/directory conflicts are somewhat difficult to resolve; by way of
contrast, renames are much easier to handle. For file/directory
conflicts, we already have to record the file under a different name in
the working copy due to the directory being in the way; if we also record
the file under a
On Mon, Aug 6, 2018 at 9:02 AM Jeff King wrote:
> On Sun, Aug 05, 2018 at 04:52:31PM -0400, Jeff King wrote:
> > Perhaps even simpler:
> >
> > test "$1" = "$(find "$1")"
>
> Actually, I guess it needs to add "-print", since IIRC that is not the
> default on some old versions of "find".
You
On 06/08/18 16:23, Phillip Wood wrote:
Hi Johannes
On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply
A test making use of test_must_fail was failing like this:
fatal: ambiguous argument '|': unknown revision or path not in the working
tree.
when the intent was to verify that a specific string was not found
in the output of the git diff command, i.e. that grep returned
non-zero. Fix the test
Hi Johannes
On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a
Johannes Schindelin writes:
>> If we ever see a todo-list without any pick/merge, then insert_final
>> is still 1 when we leave the loop and we will add one single exec at
>> the end. Which may or may not make sense---I dunno, as I do not
>> offhand think of a reason wh
On Sun, Aug 05, 2018 at 04:52:31PM -0400, Jeff King wrote:
> On Sun, Aug 05, 2018 at 01:23:05AM -0400, Eric Sunshine wrote:
>
> > A simpler approach, without the portability concerns of -A, would be
> > to remove the "." and ".." lines from the top of the listing:
> >
> > ls -f1 "$1" | sed
rd inconsistency in insert location is okay.
Ciao,
Dscho
> Johannes Schindelin (2):
> t3430: demonstrate what -r, --autosquash & --exec should do
> rebase --exec: make it work with --rebase-merges
>
> sequencer.c | 37 +++--
> t/
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of
with--rebase-merges.
Fix this issue by using a correct, if longer and slightly more complex
implementation instead.
Johannes Schindelin (2):
t3430: demonstrate what -r, --autosquash & --exec should do
rebase --exec: make it work with --rebase-merges
sequencer.c
< todo_list.nr; ) {
> > + enum todo_command command = todo_list.items[i].command;
> > + int j = 0;
> > +
> > + if (command != TODO_PICK && command != TODO_MERGE) {
> > + i++;
> > + c
Hi Junio,
On Fri, 3 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > + /*
> > +* Insert after every pick. Here, fixup/squash chains
> > +* are considered part of the pick, so we insert the commands *after*
> > +* those chains if there are
Hi Junio,
On Fri, 3 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > The idea of `--exec` is to append an `exec` call after each `pick`.
> >
> > Since the introduction of fixup!/squash! commits, this idea was extended
>
Hi,
Jeff King wrote:
> On Thu, Aug 02, 2018 at 11:21:44PM -0700, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> I guess you could even replace "COCCI_COMBINED" with "COCCI_PATCH" in
>>> most of the targets, and that would let people do individual
On Sun, Aug 05, 2018 at 01:23:05AM -0400, Eric Sunshine wrote:
> A simpler approach, without the portability concerns of -A, would be
> to remove the "." and ".." lines from the top of the listing:
>
> ls -f1 "$1" | sed '1,2d'
>
> If we're worried about -f not being sufficiently portable,
From: Jeff King
As get_delta_base() will be used outside 'packfile.c' in
a following commit, let's make it non static and let's
declare it in 'packfile.h'.
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
---
packfile.c | 10 +-
packfile.h | 7 +++
2 files changed, 12
Am 05.08.2018 um 06:20 schrieb William Chargin:
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can fail when filenames contain newlines. This patch
changes the implementation to use `ls -A`, which is specified by POSIX.
The output should be empty exactly if
William Chargin wrote:
> Jonathan Nieder wrote:
>> This subject line will appear out of context in "git shortlog" output,
>> so it's useful to pack in enough information to briefly summarize what
>> the change does.
>
> I'm happy to do so. I think that "simplify" is misleading, because this
> is
Hi,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
>> support it). See t/t3600-rm.sh for an example of a portable way to do
>
> Is that "too recent"? I thought it was bashism, not even in POSIX,
> but I may be
Jonathan Nieder writes:
> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
> support it). See t/t3600-rm.sh for an example of a portable way to do
Is that "too recent"? I thought it was bashism, not even in POSIX,
but I may be mistaken.
Quite honestly, our tests are
Hi,
> This subject line will appear out of context in "git shortlog" output,
> so it's useful to pack in enough information to briefly summarize what
> the change does.
I'm happy to do so. I think that "simplify" is misleading, because this
is a bug fix, not a refactoring. I like your first
On Sun, Aug 5, 2018 at 12:20 AM Jonathan Nieder wrote:
> William Chargin wrote:
> > test_dir_is_empty () {
> > test_path_is_dir "$1" &&
> > - if test -n "$(ls -a1 "$1" | egrep -v '^\.\.?$')"
> > + if test "$(ls -A1 "$1" | wc -c)" != 0
>
> Another portability gotcha: wc output
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can fail when filenames contain newlines. This patch
changes the implementation to use `ls -A`, which is specified by POSIX.
The output should be empty exactly if the directory is empty.
The newly added unit test
Hi,
William Chargin wrote:
> Subject: t/test-lib: make `test_dir_is_empty` more robust
This subject line will appear out of context in "git shortlog" output,
so it's useful to pack in enough information to briefly summarize what
the change does. How about s
Hi Jonathan,
> This information belongs in the commit message
Agreed: I included it at the start of the commit message, though I
suppose that the wording in the cover letter is clearer, so I've amended
the commit to use that wording instead.
> Continuing the note about
Hi,
William Chargin wrote:
> While the `test_dir_is_empty` function appears correct in most normal
> use cases, it can fail when filenames contain newlines.
This information belongs in the commit message, since it's useful
context for understanding the motivation behind the patch when
The previous behavior could incorrectly pass given a directory with a
filename containing a newline. This patch changes the implementation to
use `ls -A`, which is specified by POSIX. The output should be empty
exactly if the directory is empty.
The newly added unit test fails before this change
):
t/test-lib: make `test_dir_is_empty` more robust
t/t-basic.sh| 29 +
t/test-lib-functions.sh | 2 +-
2 files changed, 30 insertions(+), 1 deletion(-)
--
2.18.0.548.g79b975644
This change itself only changes the internal communication and should
have no visible effect to the user. We instruct the diff code that produces
the inner diffs to use X, Y, Z instead of the usual markers for new, old
and context lines
Signed-off-by: Stefan Beller
---
range-diff.c | 15
are assumed to be bug-free.
Having a Git command upstream of a pipe is also discouraged since the
pipe swallows its exit status, which means we won't know if the Git
command actually crashed. So, what you really want is this:
git diff --raw >out &&
! grep "" out &&
On Fri, Aug 3, 2018 at 7:40 PM Eric Sunshine wrote:
> git diff --raw >out &&
> ! grep "" out &&
> (where is a literal TAB)
>
> Since this script has a number of instances of Git commands upstream
> pipes, it may not make sense to fix ju
Elijah Newren writes:
> A test making use of test_must_fail was failing like this:
> fatal: ambiguous argument '|': unknown revision or path not in the working
> tree.
> when the intent was to verify that a specific string was not found
> in the output of the git diff command, i.e. that grep
A test making use of test_must_fail was failing like this:
fatal: ambiguous argument '|': unknown revision or path not in the working
tree.
when the intent was to verify that a specific string was not found
in the output of the git diff command, i.e. that grep returned
non-zero. Fix the test
"Johannes Schindelin via GitGitGadget"
writes:
> + /*
> + * Insert after every pick. Here, fixup/squash chains
> + * are considered part of the pick, so we insert the commands *after*
> + * those chains if there are any.
> + */
> + insert_final_commands = 1;
> +
; todo_list.nr; ) {
> + enum todo_command command = todo_list.items[i].command;
> + int j = 0;
> +
> + if (command != TODO_PICK && command != TODO_MERGE) {
> + i++;
> + continue;
If we ever see a to
with--rebase-merges.
Fix this issue by using a correct, if longer and slightly more complex
implementation instead.
Johannes Schindelin (2):
t3430: demonstrate what -r, --autosquash & --exec should do
rebase --exec: make it work with --rebase-merges
sequencer.c
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of
just cat-ing the files was legitimate. It sounds from the
response elsewhere that it's not (but just happens to work now for out
limited case). But it also sounds like there may be even better options.
> > I guess you could even replace "COCCI_COMBINED" with "COCCI_PATCH" in
&
On Thu, 2 Aug 2018 13:50:55 -0700
Stefan Beller wrote:
> On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite wrote:
> >
> > The is_empty_file() function can be generally useful, move it to dir.c
> > and make it public.
> >
> > Signed-off-by: Antonio Ospite
>
By the way, you can see my performance numbers here:
https://www.usenix.org/system/files/conference/atc18/atc18-lawall.pdf
Page 8, figures 4 and 5.
julia
Hi,
Jeff King wrote:
> On Thu, Aug 02, 2018 at 02:01:55PM -0400, Jeff King wrote:
>> I suspect if we go with the one-spatch-per-source route, though, that we
>> could do this just with regular make rules.
>
> Yeah, it's pretty straightforward:
>
> diff --git a/
When matching a non-wildcard LHS of a refspec against a list of
refs, find_ref_by_name_abbrev() returns the first ref that matches
using any DWIM rules used by refname_match() in refs.c, even if a
better match occurs later in the list of refs.
This causes unexpected behavior when (for example)
On Thu, Aug 02 2018, Jeff King wrote:
> On Thu, Aug 02, 2018 at 01:55:22PM +0200, SZEDER Gábor wrote:
>
>> Let's add a bit of Makefile metaprogramming to generate finer-grained
>> make targets applying one semantic patch to only a single source file,
>> and speci
iles yet. I wonder whether it's portable enough. And it's
> > > ugly and complicated.
> >
> > I looked into this a long time ago for another set of Makefile patches I
> > was considering. $(eval) was added to GNU make in 3.80, released in
> > 2002. Which is prob
On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite wrote:
>
> The is_empty_file() function can be generally useful, move it to dir.c
> and make it public.
>
> Signed-off-by: Antonio Ospite
Makes sense,
Thanks,
Stefan
> +++ b/dir.c
> @@ -2412,6 +2412,22 @@ int is_empty
nd complicated.
>
> I looked into this a long time ago for another set of Makefile patches I
> was considering. $(eval) was added to GNU make in 3.80, released in
> 2002. Which is probably fine by now.
For the record, MacOS developer tools are stuck at GNU make 3.81 (from 2006).
On Thu, Aug 02, 2018 at 02:01:55PM -0400, Jeff King wrote:
> I suspect if we go with the one-spatch-per-source route, though, that we
> could do this just with regular make rules.
Yeah, it's pretty straightforward:
diff --git a/Makefile b/Makefile
index d616c0412..86fdcf567
On Thu, Aug 02, 2018 at 01:55:22PM +0200, SZEDER Gábor wrote:
> Let's add a bit of Makefile metaprogramming to generate finer-grained
> make targets applying one semantic patch to only a single source file,
> and specify these as dependencies of the targets applying one semantic
>
The is_empty_file() function can be generally useful, move it to dir.c
and make it public.
Signed-off-by: Antonio Ospite
---
builtin/am.c | 15 ---
dir.c| 16
dir.h| 1 +
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/builtin/am.c
port reading .gitmodules even when it's not checked out
t7416: add new test about HEAD:.gitmodules and not existing
.gitmodules
dir: move is_empty_file() from builtin/am.c to dir.c and make it
public
submodule: remove the .gitmodules file when it is empty
builtin/am.c
Am 02.08.2018 um 13:55 schrieb SZEDER Gábor:
> Let's add a bit of Makefile metaprogramming to generate finer-grained
> make targets applying one semantic patch to only a single source file,
> and specify these as dependencies of the targets applying one semantic
> patch to all
So, I have this PoC patch below on top of this patch series for some
months now; actually this series was all fallout from working on this
patch. It makes 'make -j coccicheck' much faster (speedup of over
99% :) in some scenarios that, in my experience, occur rather
frequently when working
From: Christian Couder
The callers of the fetch_object() and fetch_objects() might
be interested in knowing if these functions succeeded or not.
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
fetch-object.c | 15 +--
fetch-object.h | 6 +++---
sha1-file.c|
Junio C Hamano wrote:
> One thing I forgot to mention.
>
> When asking to fetch T, in order to be able to favor refs/tags/T
> over refs/heads/T at the fetching end, you would have to be able to
> *see* both, so all 6 variants "T", "refs/tags/T", "refs/heads/T",
> "refs/remotes/T",
eh, that is what I did in the "how about this" patch, which made
the caller a bit more cumbersome by two comparisons, which in turn
was why I rejected the approach.
> Sensible and simple. If we wanted to make items earlier in the list
> return a lower value from refname_match, then we'd need
(ref = refs; ref; ref = ref->next) {
> - if (refname_match(name, ref->name))
> - return ref;
> + int score = refname_match(name, ref->name);
> +
> + if (best_score < score) {
> + best_match = ref;
> +
On 7/23/2018 4:41 PM, Jonathan Tan wrote:
+ if (parse_commit(list[i]) ||
+ list[i]->generation < min_generation)
Here...
+ if (parse_commit(parent->item) ||
+ parent->item->date
Jonathan Tan writes:
>> +test_expect_success 'LHS of refspec follows ref disambiguation rules' '
>> +mkdir lhs-ambiguous &&
>> +(
>> +cd lhs-ambiguous &&
>> +git init server &&
>> +test_commit -C server unwanted &&
>> +test_commit -C server
> +test_expect_success 'LHS of refspec follows ref disambiguation rules' '
> + mkdir lhs-ambiguous &&
> + (
> + cd lhs-ambiguous &&
> + git init server &&
> + test_commit -C server unwanted &&
> + test_commit -C server wanted &&
> +
> +
When matching a non-wildcard LHS of a refspec against a list of
refs, find_ref_by_name_abbrev() returns the first ref that matches
using any DWIM rules used by refname_match() in refs.c, even if a
better match occurs later in the list of refs.
This causes unexpected behavior when (for example)
This makes rebase_path_todo(), get_missing_commit_check_level() and the
enum check_level accessible outside sequencer.c, renames check_level to
missing_commit_check_level, and prefixes its value names by
MISSING_COMMIT_ to avoid namespace pollution.
This function and this enum will eventually be
On Fri, Jul 27, 2018 at 7:48 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Change various tests that use an idiom of the form:
>
> >expect &&
> test_cmp expect actual
>
> To instead use:
>
> test_must_be_empty actual
Thanks for working on this.
> The test_must_be_empty() wrapper was
ctually changed, the
> non-dual color mode is substantially worse in that regard.
>
> Therefore, we really want to make the dual color mode the default.
Ah and here we're making it default, so I wouldn't need a
`rangeDiff.dualColor` config variable anymore. Even better!
> Signed-
Ævar Arnfjörð Bjarmason writes:
Ævar Arnfjörð Bjarmason writes:
> Change various tests that use an idiom of the form:
>
> >expect &&
> test_cmp expect actual
>
> To instead use:
>
> test_must_be_empty actual
I trust that you eyeballed
Change various tests that use an idiom of the form:
>expect &&
test_cmp expect actual
To instead use:
test_must_be_empty actual
The test_must_be_empty() wrapper was introduced in ca8d148daf ("test:
test_must_be_empty helper", 2013-06-09). Many of these tests have been
added after
On Tue, Jul 24, 2018 at 09:19:27AM -0700, Junio C Hamano wrote:
> Christian Couder writes:
>
> > From: Jeff King
> >
> > As get_delta_base() will be used outside 'packfile.c' in
> > a following commit, let's make it non static and let's
> > declare it in 'pa
Hi,
On Fri, 20 Jul 2018, brian m. carlson wrote:
> On Fri, Jul 20, 2018 at 05:51:46PM -0400, Jeffrey Walton wrote:
>
> > (If anyone is interested in first class Solaris support then I am
> > happy to help. The patch set needed for the platform has been stable
> > for the last couple of years).
This makes rebase_path_todo(), get_missing_commit_check_level() and the
enum check_level accessible outside sequencer.c, renames check_level to
missing_commit_check_level, and prefixes its value names by
MISSING_COMMIT_ to avoid namespace pollution.
This function and this enum will eventually be
Christian Couder writes:
> From: Jeff King
>
> As get_delta_base() will be used outside 'packfile.c' in
> a following commit, let's make it non static and let's
> declare it in 'packfile.h'.
As a public function in *.h, don't we want a bit of comment there to
help those who want
annot be parsed.
Other than that, I've compared the commits in this version to v1, and
all my review comments have been addressed, thanks. (With the exception
of the skip_prefix() one, but that is a minor matter - I suggested that
to make it easier to implement my "Ancestor:" and "Desc
SZEDER Gábor writes:
> The dependencies of the 'coccicheck' make target are listed with the
> help of the $(patsubst) make function, which in this case doesn't do
> any pattern substitution, but only adds the '.patch' suffix.
>
> Use the shorter and more idiomatic $(addsuffix
SZEDER Gábor writes:
> The 'coccicheck' target doesn't create a file with the same name, so
> mark it as .PHONY.
>
> Signed-off-by: SZEDER Gábor
> ---
Good. It is customary to do so immediately before the target, not
after a blank line, though.
> Makefile | 2 ++
> 1 file changed, 2
not know about phony targets [1] so thanks for teaching me
something today.
[1] https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
Sometimes I want to remove only Coccinelle's results, but keep all
other build artifacts left after my usual 'make all man' build. This
new 'cocciclean' make target will allow just that.
Signed-off-by: SZEDER Gábor
---
Makefile | 8 +---
1 file changed, 5 insertions(+), 3 deletions
The dependencies of the 'coccicheck' make target are listed with the
help of the $(patsubst) make function, which in this case doesn't do
any pattern substitution, but only adds the '.patch' suffix.
Use the shorter and more idiomatic $(addsuffix) make function instead.
Signed-off-by: SZEDER
301 - 400 of 5712 matches
Mail list logo
