On Mon, Sep 12, 2016 at 04:10:09PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > In other words, something along this line, perhaps.
> > ...
>
> Not quite. There is no guanratee that the user is using autoconf at
> all. It should be more like this, I think.
>
> t/perf/run | 8 +
Kirill Smelkov writes:
> +static int want_found_object(int exclude, struct packed_git *p)
> +{
> + if (exclude)
> + return 1;
> + if (incremental)
> + return 0;
> +
> + /*
> + * When asked to do --local (do not include an object that appears in a
> +
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
emit_line_0 factors out the emission part into emit_line_emission,
and depending on the diff_options->use_buffer the emission
will be performed directly when calling emit_line_0 or after the
whole process is done, i.e. by buffering we have add the possibility
for a second pass over the whole output
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
When there is a lot of code moved around such as in 11979b9 (2005-11-18,
"http.c: reorder to avoid compilation failure.") for example, the review
process is quite hard, as it is not mentally challenging. It is rather a
tedious process, that gets boring quickly. However you still need to read
throug
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch we want to do more things before and after all filepairs
are flushed. So factor flushing out all file pairs into its own function
that the new code can be plugged in easily.
Signed-off-by: Stefan Beller
---
diff.c | 17 -
1 file changed, 12 insertions(+), 5 delet
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
In a later patch, I want to propose an option to detect&color
moved lines in a diff, which cannot be done in a one-pass over
the diff. Instead we need to go over the whole diff twice,
because we cannot detect the first line of the two corresponding
lines (+ and -) that got moved.
So to prepare the
At all call sites of emit_{add, del, context}_line we increment the line
count, so move it into the respective functions to make the code at the
calling site a bit clearer.
Signed-off-by: Stefan Beller
---
diff.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a
When `first` equals '\r', then it cannot equal '\n', which makes
`!has_trailing_newline` always true if `first` is '\r'.
Drop that check.
Signed-off-by: Stefan Beller
---
diff.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 156c2aa..9d2e704 100644
--
About a week ago, I started experimenting to add a new functionality to the
diff machinery: We want to color moved lines differently! This will aid
developers
to review patches such as the patch "Move libified code from builtin/apply.c to
apply.{c,h}"
Or a smaller example:
git show 11979b9
> static void write_name(const char *name)
> {
> /*
> +* NEEDSWORK: To make this thread-safe, full_name would have to be
> owned
> +* by the caller.
> +*
> +* full_name get reused across output lines to minimize the allocation
> +* churn.
> +
The pager code is often run early in the git.c startup,
before we have actually found the repository. When we ask
git_config() to look for values like core.pager, it doesn't
know where to find the repo-level config, and will blindly
examine ".git/config" if it exists. That's why t7006 shows
that ma
This is shorter, and saves a subshell.
Signed-off-by: Jeff King
---
t/t1302-repo-version.sh | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index 9bcd349..f859809 100755
--- a/t/t1302-repo-versi
The t1308 test script uses our test-config helper to read
repository-level config, but never actually sets up the
repository. This works because git_config() blindly reads
".git/config" even if we have not configured a repository.
This means that test-config won't work from a subdirectory,
though
git-init may copy "config" from the templates directory and
then re-read it. There are some comments explaining what's
going on here, but they are not grouped very well with the
matching code. Let's rearrange and expand them.
Signed-off-by: Jeff King
---
builtin/init-db.c | 11 +++
1 fil
When git_config() runs, it looks in the system, user-wide,
and repo-level config files. It gets the latter by calling
git_pathdup(), which in turn calls get_git_dir(). If we
haven't set up the git repository yet, this may simply
return ".git", and we will look at ".git/config". This
seems like it
After we copy the templates into place, we re-read the
config in case we copied in a default config file. But since
git_config() is backed by a cache these days, it's possible
that the call will not actually touch the filesystem at all;
we need to tell it that something has changed behind the
scene
While the cached configset interface is more pleasant to
use, it is not appropriate for "early" config like pager
setup, which must sometimes do tricky things like reading
from ".git/config" even when we have not set up the
repository.
As a preparatory step to handling these cases better, let's
sw
When "hash-object" is run without "-w", we don't need to be
in a git repository at all; we can just hash the object and
write its sha1 to stdout. However, if we _are_ in a git
repository, we would want to know that so we can follow the
normal rules for respecting config, .gitattributes, etc.
This
This variable is only ever used by the routines in pager.c,
and other parts of the code should always use those routines
(like git_pager()) to make decisions about which pager to
use. Let's reduce its scope to prevent accidents.
Signed-off-by: Jeff King
---
cache.h | 1 -
environment.c | 1
If we see an explicit "--no-index", we do not bother calling
setup_git_directory_gently() at all. This means that we may
miss out on reading repo-specific config.
It's arguable whether this is correct or not. If we were
designing from scratch, making "git diff --no-index"
completely ignore the rep
In git_pager(), we really only care about getting the value
of core.pager. But to do so, we use the git_default_config()
callback, which loads many other values. Ordinarily it
isn't a big deal to load this config an extra time, as it
simply overwrites the values from the previous run. But it's
a ba
Patch-id does not require a repository because it is just
processing the incoming diff on stdin, but it may look at
git config for keys like patchid.stable.
Even though we do not setup_git_directory(), this works from
the top-level of a repository because we blindly look at
".git/config" in this c
We can invoke no-index mode in two ways: by an explicit
request from the user, or implicitly by noticing that we
have two paths, and at least one is outside the repository.
If the user already told us --no-index, there is no need for
us to do the implicit test at all. However, we currently
do, an
The comment at the top of pager.c claims that we've split
the code out so that Windows can do something different.
This dates back to f67b45f (Introduce trivial new pager.c
helper infrastructure, 2006-02-28), because the original
implementation used fork(). Later, we ended up sticking the
Windows #
If we see an explicit "git diff --no-index ../foo ../bar",
then we do not set up the git repository at all (we already
know we are in --no-index mode, so do not have to check "are
we in a repository?"), and hence have no "prefix" within the
repository. A patch generated by this command will have th
The motivation for this series is to fix the regression in v2.9 where
core.logallrefupdates is sometimes not set properly in a newly
initialized repository, as described in this thread:
http://public-inbox.org/git/c46d36ef-3c2e-374f-0f2e-ffe31104e...@gmx.de/T/#u
The root of the problem is that
We have a series of 3 CRLF tests that do exactly the same
(long) setup sequence. Let's pull it out into a common setup
test, which is shorter, more efficient, and will make it
easier to add new tests.
Note that we don't have to worry about cleaning up any of
the setup which was previously per-test
On Mon, Sep 12, 2016 at 5:25 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> diff --git a/diff.c b/diff.c
>> index 2aefd0f..7dcef73 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -493,6 +493,19 @@ static void emit_line(struct diff_options *o, const
>> char *set, const char *reset
>> e
Allow ls-files to recognize submodules in order to retrieve a list of
files from a repository's submodules. This is done by forking off a
process to recursively call ls-files on all submodules. Also added an
output-path-prefix command in order to prepend paths to child processes.
Signed-off-by: B
Hi Kevin,
On 13 September 2016 at 09:29, Kevin Smith wrote:
> So when I move from master to develop that status would come up. If I
> ran "git reset --hard" I would no longer have that message. I also
> saw that when I do a git clone and specify to clone the develop branch
> that I would not se
(I have some hours online today, so I decided to work on this)
The key patch here is 3/3 which seems like an obvious fix to
adding the problem of adding a curl easy handle to a curl multi
handle repeatedly.
What is unclear to me is how only Yaroslav's repository seems to
trigger this bug after al
This will be useful for tracking down curl usage errors.
Signed-off-by: Eric Wong
---
http.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/http.c b/http.c
index cd40b01..cac5db9 100644
--- a/http.c
+++ b/http.c
@@ -1022,6 +1022,8 @@ int start_active_slot(struct active_request_slot *slot)
Stefan Beller writes:
> diff --git a/diff.c b/diff.c
> index 2aefd0f..7dcef73 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -493,6 +493,19 @@ static void emit_line(struct diff_options *o, const char
> *set, const char *reset
> emit_line_0(o, set, reset, line[0], line+1, len-1);
> }
>
> +sta
I find #ifdefs makes code difficult-to-follow.
An early version of this patch had error checking for
curl_multi_remove_handle calls, but caused some tests (e.g.
t5541) to fail under curl 7.26.0 on old Debian wheezy.
Signed-off-by: Eric Wong
---
http.c | 17 ++---
1 file changed, 10
We must call curl_multi_remove_handle when releasing the slot to
prevent subsequent calls to curl_multi_add_handle from failing
with CURLM_ADDED_ALREADY (in curl 7.32.1+; older versions
returned CURLM_BAD_EASY_HANDLE)
Signed-off-by: Eric Wong
---
http.c | 10 ++
1 file changed, 6 inserti
On Mon, Sep 12, 2016 at 5:11 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> From: Stefan Beller
>>
>> ---
>
> "X can do Y" can be taken as a statement of fact (to which "so
> what?" is an appropriate response), a desire (to which "then please
> say 'make X do Y' instead" is an appropria
Stefan Beller writes:
> From: Stefan Beller
>
> ---
"X can do Y" can be taken as a statement of fact (to which "so
what?" is an appropriate response), a desire (to which "then please
say 'make X do Y' instead" is an appropriate response), or a report
of a bug (to which "please explain why X sh
Stefan Beller writes:
> From: Stefan Beller
>
> ---
This shows why 04/10 should have had the overall plan for these two
steps. We want a short-and-sweet name "diff-flush-patch" to mean
"flush all the queued diff elements" so rename the singleton one
from diff-flush-patch to diff-flush-patch-fi
Stefan Beller writes:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> ---
The reason being...?
Stefan Beller writes:
> diff --git a/diff.c b/diff.c
> index 156c2aa..9d2e704 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -460,8 +460,7 @@ static void emit_line_0(struct diff_options *o, const
> char *set, const char *res
>
> if (len == 0) {
> has_trailing_newline = (first ==
Stefan Beller writes:
> From: Stefan Beller
>
> At all call sites of emit_{add, del, context}_line we increment the line
> count, so move it into the respective functions to make the code at the
> calling site a bit clearer.
>
> Signed-off-by: Stefan Beller
> ---
> diff.c | 15 ++-
Stefan Beller writes:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> ---
The reason being...?
"Doing this would not change any behaviour and would not break
anything" may be true, but that is not a reason to do a change.
Hopefully it will become clear why this is needed once we loo
larsxschnei...@gmail.com writes:
> +int packet_write_gently(const int fd_out, const char *buf, size_t size)
> +{
> + static char packet_write_buffer[LARGE_PACKET_MAX];
> +
> + if (size > sizeof(packet_write_buffer) - 4) {
> + error("packet write failed");
> + return
I hit an issue in Git today that seemed to be a bug. Basically what
happened is in our master branch we had two files, one named something
like "file_NAME.png" and another named "file_name.png" in the same
folder. In the develop branch in the same repo we had removed the
"file_NAME.png" file so t
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> packet_flush() would die in case of a write error even though for some
> callers an error would be acceptable. Add packet_flush_gently() which
> writes a pkt-line flush packet and returns `0` for success and `-1` for
> failure.
> ...
> +
> On 12 Sep 2016, at 21:11, Junio C Hamano wrote:
>
> [..]
> properly; supporting "huge objects" better in the object layer,
> without having to resort to ugly hacks like GitLFS that will never
> be part of the core Git. [...]
I agree with you that GitLFS is an ugly hack.
Some applications hav
Junio C Hamano writes:
> In other words, something along this line, perhaps.
> ...
Not quite. There is no guanratee that the user is using autoconf at
all. It should be more like this, I think.
t/perf/run | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/t/perf/run b
Try again, reply all this time...
On 12-Sep-16 22:24, Junio C Hamano wrote:
Michael Felt writes:
I had a couple of issues when packaging git for AIX
a) option -Wall by default - works fine with gcc I am sure, but not so
well when gcc is not your compiler
That is expected. As you said, it i
Jiang Xin writes:
> There are some l10n updates for Git 2.10.0, please merge them to the
> maint branch.
Thanks.
Thomas Gummerer writes:
> When the chmod option was added to git add, it was hooked up to the diff
> machinery, meaning that it only works when the version in the index
> differs from the version on disk.
>
> As the option was supposed to mirror the chmod option in update-index,
> which always ch
Importing a long history from Perforce into git using the git-p4 tool
can be especially challenging. The `git p4 clone` operation is based
on an all-or-nothing transactionality guarantee. Under real-world
conditions like network unreliability or a busy Perforce server,
`git p4 clone` and `git p4 s
Importing a long history from Perforce into git using the git-p4 tool
can be especially challenging. The `git p4 clone` operation is based
on an all-or-nothing transactionality guarantee. Under real-world
conditions like network unreliability or a busy Perforce server,
`git p4 clone` and `git p4 s
Thomas Gummerer writes:
> + char flip = force_mode == 0777 ? '+' : '-';
>
> pos = cache_name_pos(path, strlen(path));
> if (pos < 0)
> @@ -432,17 +433,11 @@ static void chmod_path(int flip, const char *path)
> mode = ce->ce_mode;
> if (!S_ISREG(mode))
>
On Mon, Sep 12, 2016 at 12:10:13PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I happened to notice today that this topic needs a minor tweak:
> >
> > -- >8 --
> > Subject: [PATCH] add_delta_base_cache: use list_for_each_safe
> >
> > We may remove elements from the list while we are i
Johannes Schindelin writes:
> This teaches the sequencer_commit() function to take an argument that
> will allow us to implement "todo" commands that need to amend the commit
> messages ("fixup", "squash" and "reword").
>
> Signed-off-by: Johannes Schindelin
> ---
> sequencer.c | 6 --
> se
Johannes Schindelin writes:
> @@ -788,7 +792,7 @@ static int do_pick_commit(enum todo_command command,
> struct commit *commit,
> }
> if (!opts->no_commit)
> res = sequencer_commit(opts->edit ? NULL : git_path_merge_msg(),
> - opts, allow, opts->edit
Johannes Schindelin writes:
> The return value of do_recursive_merge() may be positive (indicating merge
> conflicts), so let's OR later error conditions so as not to overwrite them
> with 0.
Are the untold assumptions as follows?
- The caller wants to act on positive (not quite an error), zer
W dniu 12.09.2016 o 20:09, Jon Loeliger napisał:
> So, like, David Bainbridge said:
>> Does anyone know whether the sessions will be recorded in any way?
>
> I am uncertain about outright recording (digital video/audio),
> but there will be at least summarizing notes taken and posted.
> Anyone wi
W dniu 12.09.2016 o 03:57, Junio C Hamano pisze:
> Jacob Keller writes:
>
>> Yes, I'm actually confused by "git commit " *not* usinng what's
>> in the index already, so I think that isn't intuitive as is.
>
> You are excused ;-)
>
> In ancient days, "git commit " was to add the contents
> from
When the chmod option was added to git add, it was hooked up to the diff
machinery, meaning that it only works when the version in the index
differs from the version on disk.
As the option was supposed to mirror the chmod option in update-index,
which always changes the mode in the index, regardle
While the chmod options for update-index and the add have the same
functionality, they are using different ways to parse and handle the
option internally. Unify these modes in order to make further
refactoring simpler.
Signed-off-by: Thomas Gummerer
---
builtin/update-index.c| 39 ++
As there are chmod options for both add and update-index, introduce a
new chmod_index_entry function to do the work. Use it in update-index,
while it will be used in add in the next patch.
Signed-off-by: Thomas Gummerer
---
builtin/update-index.c | 8 +---
cache.h| 2 ++
r
The git add --chmod option was introduced in 4e55ed3 ("add: add
--chmod=+x / --chmod=-x options", 2016-05-31), but was never
documented. Document the feature.
Signed-off-by: Thomas Gummerer
---
Documentation/git-add.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/D
Thanks to Junio on setting me straight on the change of behaviour in
the previous round.
This round includes a similar change, which does however not change
the behaviour of update-index with repeated arguments. I still think
the unification of the way git add and git update-index handle chmod
is
Jean-Noël AVILA writes:
> ..., and
> plural forms can be quite different depending on its value.
AHHhhh, of course you are right.
Jeff King writes:
> On Mon, Sep 12, 2016 at 10:18:33AM -0700, Junio C Hamano wrote:
>
>> > +static int patch_id_defined(struct commit *commit)
>> > +{
>> > + /* must be 0 or 1 parents */
>> > + return !commit->parents || !commit->parents->next;
>> > +}
>>
>> If we make the first hunk begin lik
"Ben Peart" writes:
> I completely agree that optimizing within merge_working_tree would provide
> more opportunities for optimization. I can certainly move the test into
> that function as a first step.
Note that "optimizing more" was not the primary point of my
response.
Quite honestly, I'd
Michael Felt writes:
> I had a couple of issues when packaging git for AIX
> a) option -Wall by default - works fine with gcc I am sure, but not so
> well when gcc is not your compiler
That is expected. As you said, it is merely "by default" and there
are mechanisms like config.mak provided for
Jon Loeliger writes:
> So, like, David Bainbridge said:
>> Hi,
>>
>> The subject matter of the conference looks really interesting but I am
>> unlikely to be able to attend, unfortunately.
>>
>> The subjects being covered like the current State of Git and the
>> Future of Git, for example, dese
git-am seems to add backslash that escapes double quote character, example
git format-patch
From 63da989a5295214f9bd06cd7b409a86a65241eea Mon Sep 17 00:00:00 2001
From: "Sebastian \"Swift Geek\" Grzywna"
Date: Mon, 12 Sep 2016 21:27:32 +0200
Subject: [PATCH] Example showing git-am bug that inc
Hello all,
We would like to ask you a few questions about your use of the Git
version control system. This survey is mainly to understand who is
using Git, how and why.
The results will be published to the Git wiki on the GitSurvey2016
page (https://git.wiki.kernel.org/index.php/GitSurvey2016) an
Johannes Schindelin writes:
> +static const char *get_dir(const struct replay_opts *opts)
> +{
> + return git_path_seq_dir();
> +}
Presumably this is what "In a couple of commits" meant, i.e. opts
will be used soonish.
> -static void remove_sequencer_state(void)
> +static void remove_sequen
Johannes Schindelin writes:
> -static int read_populate_opts(struct replay_opts **opts)
> +static int read_populate_opts(struct replay_opts *opts)
> {
> if (!file_exists(git_path_opts_file()))
> return 0;
> @@ -823,7 +823,7 @@ static int read_populate_opts(struct replay_opts
Johannes Schindelin writes:
> Signed-off-by: Johannes Schindelin
> ---
> builtin/commit.c | 2 +-
> sequencer.c | 11 ++-
> sequencer.h | 5 +
> 3 files changed, 8 insertions(+), 10 deletions(-)
OK. It's nice to see code reduction.
> -#define SEQ_DIR "seq
Johannes Schindelin writes:
> This change is not completely faithful: instead of initializing all fields
> to 0, we choose to initialize command and subcommand to -1 (instead of
> defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
> it makes no difference at all, but future-
Johannes Schindelin writes:
> The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves
> like a one-shot command when it reads its configuration: memory is
> allocated and released only when the command exits.
>
> This is kind of okay for git-cherry-pick, which *is* a one-shot
> comman
On 12.09.16 21:35, Torsten Bögershausen wrote:
> On 12.09.16 14:55, Виталий Ищенко wrote:
>> Good day
>>
>> I faced following issue with gitattributes file (at least eol setting)
>> when was trying to force `lf` mode on windows.
>>
>> We have 2 branches: master & dev. With master set as HEAD in rep
On 09/11, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > @@ -955,10 +941,8 @@ int cmd_update_index(int argc, const char **argv,
> > const char *prefix)
> > PARSE_OPT_NOARG | /* disallow --cacheinfo= form */
> > PARSE_OPT_NONEG | PARSE_OPT_LITERAL_AR
Johannes Schindelin writes:
> Johannes Schindelin (5):
> pull: drop confusing prefix parameter of die_on_unclean_work_tree()
> pull: make code more similar to the shell script again
> Make the require_clean_work_tree() function truly reusable
> Export also the has_un{staged,committed}_cha
On 12.09.16 14:55, Виталий Ищенко wrote:
> Good day
>
> I faced following issue with gitattributes file (at least eol setting)
> when was trying to force `lf` mode on windows.
>
> We have 2 branches: master & dev. With master set as HEAD in repository
>
> I've added `.gitattributes` with following
I had a couple of issues when packaging git for AIX
a) option -Wall by default - works fine with gcc I am sure, but not so
well when gcc is not your compiler
b) needs a special (GNU) grep argument (-a from memory). This I
resolved by downloading and packaging GNU grep. However, I hope this
has not
Kirill Smelkov writes:
>> This is v7, but as I understand your numbering, it goes with v5 of patch
>> 1/2 that I just reviewed (usually we just increment the version number
>> on the whole series and treat it as a unit, even if some patches didn't
>> change from version to version).
>
> The reaso
Junio C Hamano writes:
>> build_git_rev () {
>> rev=$1
>> -cp ../../config.mak build/$rev/config.mak
>> +cp -t build/$rev ../../{config.mak,config.mak.autogen,config.status}
>
> That unfortunately is a GNUism -t with a bash-ism {a,b,c}; just keep
> it simple and stupid to make sure
Kirill Smelkov writes:
> Otherwise for people who use autotools-based configure in main worktree,
> the performance testing results will be inconsistent as work and build
> trees could be using e.g. different optimization levels.
>
> See e.g.
>
>
> http://public-inbox.org/git/2016081817522
Jeff King writes:
> I happened to notice today that this topic needs a minor tweak:
>
> -- >8 --
> Subject: [PATCH] add_delta_base_cache: use list_for_each_safe
>
> We may remove elements from the list while we are iterating,
> which requires using a second temporary pointer. Otherwise
> stepping
Johannes Schindelin writes:
> It is remarkable that libgit.a did not sport this function yet... Let's
> move it into a more prominent (and into an actually reusable) spot:
> wt-status.[ch].
>
> Signed-off-by: Johannes Schindelin
> ---
I do not think "truly" is needed at all.
It was not reusabl
Johannes Schindelin writes:
> When converting the pull command to a builtin, the
> require_clean_work_tree() function was renamed and the pull-specific
> parts hard-coded.
>
> This makes it impossible to reuse the code, so let's modify the code to
> make it more similar to the original shell scri
> -Original Message-
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Friday, September 9, 2016 5:55 PM
> To: Ben Peart
> Cc: git@vger.kernel.org; pclo...@gmail.com; Ben Peart
>
> Subject: Re: [PATCH v2] checkout: eliminate unnecessary merge for trivial
> checkout
>
> Ben Pear
Hi,
The subject matter of the conference looks really interesting but I am unlikely
to be able to attend, unfortunately.
The subjects being covered like the current State of Git and the Future of Git,
for example, deserve much wider exposure, and I would certainly appreciate
hearing the though
1 - 100 of 144 matches
Mail list logo