Signed-off-by: Stefan Beller
---
This is the cherry on the cake named sb/diff-color-move-more.
Documentation/config.txt | 5 +
Documentation/diff-options.txt | 7 +--
diff.c | 9 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git
On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams wrote:
>
> Signed-off-by: Brandon Williams
> ---
>
> Since introducing protocol v2 and enabling fetch I've been thinking
> about what its inverse 'push' would look like. After talking with a
> number of people I have a longish list of things that
I'll squash the following in (which I have been carrying in 'pu' for
the past few days) unless I hear otherwise soonish to correct the
issues raised during the review.
Thanks.
t/t3404-rebase-interactive.sh | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git
Stolee said (privately):
I also ran into an issue where some of the "arbitrary repository"
patches don't fully connect. Jonathan's test demonstrated this
issue when I connected some things in an in-process patch
Work in progress: https://github.com/gitgitgadget/git/pull/11
Signed-off-by: Stefan Beller
---
builtin/replace.c | 3 ++-
refs.c| 9 -
refs.h| 2 +-
replace-object.c | 3 ++-
4 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index ef22d724bbc..5f34659071f 100644
---
In 60ce76d3581 (refs: add repository argument to for_each_replace_ref,
2018-04-11) and 0d296c57aec (refs: allow for_each_replace_ref to handle
arbitrary repositories, 2018-04-11), for_each_replace_ref learned how
to iterate over refs by a given arbitrary repository.
New attempts in the object
Оля Тележная writes:
>> Hmph, doesn't this belong to the previous step? In other words,
>> isn't the result of applying 1-3/4 has a bug that can leave eaten
>> uninitialized (and base decision to free(buf) later on it), and
>> isn't this change a fix for it?
>
> Oh. I was thinking that it was
On 17.07.18 23:49, Beat Bolli wrote:
> On 06.07.18 14:08, Pratik Karki wrote:
>> +static GIT_PATH_FUNC(apply_dir, "rebase-apply");
>> +static GIT_PATH_FUNC(merge_dir, "rebase-merge");
>
> Maybe fix this up with
>
> -static GIT_PATH_FUNC(apply_dir, "rebase-apply");
> -static
Hello,
On 17.07.2018 21:41, Alban Gruin wrote:
Hi,
I published a new blog post about last week:
https://blog.pa1ch.fr/posts/2018/07/17/en/gsoc2018-week11.html
Cheers,
Alban
Great entry!
Here I am too, with two updates on the blog:
* The weekly blog.
On 06.07.18 14:08, Pratik Karki wrote:
> +static GIT_PATH_FUNC(apply_dir, "rebase-apply");
> +static GIT_PATH_FUNC(merge_dir, "rebase-merge");
Maybe fix this up with
-static GIT_PATH_FUNC(apply_dir, "rebase-apply");
-static GIT_PATH_FUNC(merge_dir, "rebase-merge");
+static
SZEDER Gábor writes:
>> +fprintf(stdout, submodule_strategy_to_string(_strategy));
>
> Various compilers warn about the potential insecurity of the above
> call:
>
> CC builtin/submodule--helper.o
> builtin/submodule--helper.c: In function ‘module_update_module_mode’:
>
Stefan Beller writes:
>> As I most often edit the log message and material below three-dash
>> lines (long) _after_ format-patch produced files, I do not think it
>> is a win to force me to push and ask to pull
>
> Ah, that is an interesting workflow. Do you keep patch files/emails
> around
Henning Schild writes:
> Test setting gpg.format to both invalid and valid values.
>
> Signed-off-by: Henning Schild
> ---
> t/t7510-signed-commit.sh | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index
Henning Schild writes:
> diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> index a5d3b2cba..3fe02876c 100755
> --- a/t/lib-gpg.sh
> +++ b/t/lib-gpg.sh
> @@ -38,7 +38,33 @@ then
> "$TEST_DIRECTORY"/lib-gpg/ownertrust &&
> gpg --homedir "${GNUPGHOME}" /dev/null 2>&1 \
Signed-off-by: Brandon Williams
---
Since introducing protocol v2 and enabling fetch I've been thinking
about what its inverse 'push' would look like. After talking with a
number of people I have a longish list of things that could be done to
improve push and I think I've been able to distill
On Tue, Jul 17, 2018 at 12:52 PM Junio C Hamano wrote:
> > (A) This sign off is inherent to the workflow. So we could
> > change the workflow, i.e. you pull series instead of applying them.
> > I think this "more in git, less in email" workflow would find supporters,
> > such as DScho (cc'd).
>
Henning Schild writes:
> gnupg does print the keyid followed by a space and the signer comes
> next. The same pattern is also used in gpgsm, but there the key length
> would be 40 instead of 16. Instead of hardcoding the expected length,
> find the first space and calculate it.
> Input that does
Henning Schild writes:
> Create a struct that holds the format details for the supported formats.
> At the moment that is still just "openpgp". This commit prepares for the
> introduction of more formats, that might use other programs and match
> other signatures.
>
> Signed-off-by: Henning
On Tue, Jul 17, 2018 at 10:59:50AM +0200, Ævar Arnfjörð Bjarmason wrote:
> That doesn't make sense to me. Just because git itself is happily
> ignoring the exit code I don't think that should mean there shouldn't be
> a meaningful exit code. Why don't you just ignore the exit code in the
> repo
On Mon, Jul 16, 2018 at 11:57:40PM -0700, Jonathan Nieder wrote:
> External tools like repo[1], though, do care about the exit status
> from "git gc --auto". In non-daemonized mode, the exit status is
> straightforward: if there is an error, it is nonzero, but after a
> warning like the above,
On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote:
> A value of -1 returned from cmd_gc gets propagated to exit(),
> resulting in an exit status of 255. Use die instead for a clearer
> error message and a controlled exit.
This feels a little funny because we know we're going to
On Mon, Jul 16, 2018 at 11:53:21PM -0700, Jonathan Nieder wrote:
> A collection of minor error handling fixes:
>
> - use an error message in lower case, following the usual style
> - quote filenames in error messages to make them easier to read and to
> decrease translation load by matching
On Tue, Jul 17, 2018 at 11:48:45AM +0200, Ævar Arnfjörð Bjarmason wrote:
> In practice I think clone, checkout, reset etc. always work in the same
> order you see with `git ls-tree -r --name-only HEAD`, but as far as I
> know this has never been guaranteed or documented, and shouldn't be
> relied
Stefan Beller writes:
> Actually I thought it was really cool, i.e. when using your queued branch
> instead of my last sent branch, I can see any edits *you* did
> (including fixing up typos or applying at slightly different bases).
Absolutely. I did not say that there needs a mode to ignore
On Tue, Jul 17, 2018 at 07:28:07PM +0200, Duy Nguyen wrote:
> On Mon, Jul 16, 2018 at 7:38 PM Jeff King wrote:
> > in a user-visible way. And that's really my question: is pruning here
> > going to bite people unexpectedly (not rhetorical -- I really don't
> > know)?
>
> If shallow points are
On Tue, Jul 17, 2018 at 03:15:31PM -0400, Jeff King wrote:
> > - Also trigger `prune_shallow()` when `--unpack-unreachable=`
> > was passed to `git repack`.
> > - No need to trigger `prune_shallow()` when `git repack` was called with
> > `-k`.
>
> I think you might have missed the bigger
On Tue, Jul 17, 2018 at 06:51:39AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> Under certain circumstances, commits that were reachable can be made
> unreachable, e.g. via `git fetch --prune`. These commits might have
> been packed already, in which case `git repack -adlf` will just
Paul-Sebastian Ungureanu writes:
> @@ -1769,7 +1831,8 @@ void maybe_die_on_misspelt_object_name(const char
> *name, const char *prefix)
>
> int get_oid_with_context(const char *str, unsigned flags, struct object_id
> *oid, struct object_context *oc)
> {
> - if (flags &
On Tue, Jul 17, 2018 at 2:53 PM Stefan Beller wrote:
> > A tangent.
> >
> > Because this "-- " is a conventional signature separator, MUAs like
> > Emacs message-mode seems to omit everything below it from the quote
> > while responding, making it cumbersome to comment on the tbdiff.
> >
> >
Paul-Sebastian Ungureanu writes:
> Add `get_tree_entry_gently()`, `find_tree_entry_gently()`
> and `get_tree_entry_follow_symlinks_gently()`, which will
> make `get_oid()` to be more gently.
>
> Since `get_tree_entry()` is used in more than 20 places,
> adding a new parameter will make this
> A tangent.
>
> Because this "-- " is a conventional signature separator, MUAs like
> Emacs message-mode seems to omit everything below it from the quote
> while responding, making it cumbersome to comment on the tbdiff.
>
> Something to think about if somebody is contemplating on adding more
>
Hi,
I published a new blog post about last week:
https://blog.pa1ch.fr/posts/2018/07/17/en/gsoc2018-week11.html
Cheers,
Alban
Stefan Beller writes:
>> v2:
>> addressed review comments, renaming the struct, improving the commit message.
>>
>> v1:
>> https://public-inbox.org/git/20180712194754.71979-1-sbel...@google.com/
>> I thought about writing it all in one go, but the series got too large,
>> so let's chew one bite
Jonathan Nieder writes:
> A value of -1 returned from cmd_gc gets propagated to exit(),
> resulting in an exit status of 255. Use die instead for a clearer
> error message and a controlled exit.
>
> Signed-off-by: Jonathan Nieder
> ---
> As in
>
Jonathan Nieder writes:
> - avoid being confused by a gc.log larger than INT_MAX bytes
;-)
>
> Noticed by code inspection.
>
> Signed-off-by: Jonathan Nieder
> ---
Looks good.
Jonathan Nieder writes:
> That doesn't really solve the problem:
>
> 1. "gc --auto" would produce noise *every time it runs* until gc.log
> is removed, for example via expiry
>
> 2. "gc --auto" would not do any garbage collection until gc.log is
> removed, for example by expiry
>
> 3.
On Tue, Jul 17, 2018 at 11:50 AM Ævar Arnfjörð Bjarmason
wrote:
> In practice I think clone, checkout, reset etc. always work in the same
> order you see with `git ls-tree -r --name-only HEAD`, but as far as I
> know this has never been guaranteed or documented, and shouldn't be
> relied on.
>
>
On Tue, Jul 17, 2018 at 2:48 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Tue, Jul 17 2018, J. Paul Reed wrote:
>
> > Hey Git Devs,
> >
> > I have a bit of an odd question: do git clone/checkout operations have a
> > deterministic ordering?
> >
> > That is: are files guaranteed to be laid down onto
Junio C Hamano writes:
>> So, this SQUASH looks like the correct way forward. Hopefully, Junio
>> can just squash it so I don't have to flood the list again with this
>> long series.
>
> The topic already has another dependent topic so rerolling or
> squashing would be a bit cumbersome. I'll
Hi Johannes,
> > It's nice to see that the bulk of the range-diff functionality has
> > been libified in this re-roll (residing in range-diff.c rather than
>
> Can we *please* stop calling it "re-roll"? Thanks.
Fun fact of the day:
First appearance of "reroll" in the public archive is (09 Dec
On Tue, Jul 17, 2018 at 2:10 PM Paul-Sebastian Ungureanu
wrote:
>
> At the moment, `get_oid()` might call `die()` in some cases. To
> prevent that from happening, this patches introduces a new flag
> called `GET_OID_GENTLY` and a new function `get_oid_gently()`,
> which passes the mentioned flag
Junio C Hamano writes:
> But by splitting these into separate tests, the patch makes such a
> potential failure with "git commit --short" break the later steps.
>
> Not very nice.
>
> It may be a better change to just do in the original one
>
> git add test-file &&
> git commit
On Tue, Jul 17, 2018 at 9:51 AM Johannes Schindelin via GitGitGadget
wrote:
> While it is true that we never add unreachable commits into pack files
> intentionally (as `git repack`'s documentation states), we must not
> forget that a `git fetch --prune` (or even a `git fetch` when a ref was
>
Samuel Lijin writes:
> diff --git a/wt-status.c b/wt-status.c
> index 75d389944..4ba657978 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -718,6 +718,39 @@ static void wt_status_collect_untracked(struct wt_status
> *s)
> s->untracked_in_ms = (getnanotime() - t_begin) /
The clean filter can work around this problem by chdir GIT_PREFIX,
but needing to do this in unusual cases seems to be asking for bugs.
--
see shy jo
signature.asc
Description: PGP signature
On Mon, Jul 16, 2018 at 7:38 PM Jeff King wrote:
> in a user-visible way. And that's really my question: is pruning here
> going to bite people unexpectedly (not rhetorical -- I really don't
> know)?
If shallow points are no longer reachable, removing them should not
bite anybody, I think.
>
Samuel Lijin writes:
> To fix the breakages documented by t7501, the next patch in this series
> will teach wt_status_collect() to set the committable bit, instead of
> having wt_longstatus_print_updated() and show_merge_in_progress() set it
> (which is what currently happens). Unfortunately,
When git is running inside a subdirectory of the repository,
and needs to run the clean filter, it runs it chdired back to the top of
the repository. However, if git was run with a relative --work-tree,
it passes that relative path in GIT_WORK_TREE on to the clean filter.
If git was run with eg,
Samuel Lijin writes:
> The behavior of git commit when doing a dry run changes if there are
> unfixed/fixed merge conflits, but the test suite currently only asserts
> that `git commit --dry-run` succeeds when all merge conflicts are fixed.
>
> Add tests to document the behavior of all flags
On Tue, Jul 17, 2018 at 6:39 PM Duy Nguyen wrote:
>
> On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget
> wrote:
> >
> > From: Johannes Schindelin
> >
> > While it is true that we never add unreachable commits into pack files
> > intentionally (as `git repack`'s
Hi Daniel,
On Mon, 16 Jul 2018, Daniel Harding wrote:
> On Mon, 16 Jul 2018 at 18:59:03 +0300, Johannes Schindelin wrote:
> >
> > On Mon, 16 Jul 2018, Aaron Schrab wrote:
> > >
> > > Looking into that a bit further, it does seem like my explanation above
> > > was incorrect. Here's another
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:26 AM Johannes Schindelin via GitGitGadget
> wrote:
> > After using this command extensively for the last two months, this
> > developer came to the conclusion that even if the dual color mode still
> > leaves a lot
On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget
wrote:
>
> From: Johannes Schindelin
>
> While it is true that we never add unreachable commits into pack files
> intentionally (as `git repack`'s documentation states), we must not
> forget that a `git fetch --prune` (or even
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:27 AM Johannes Schindelin via GitGitGadget
> wrote:
> > The bulk of this patch consists of a heavily butchered version of
> > tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from
> >
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:26 AM Thomas Rast via GitGitGadget
> wrote:
> > These are essentially lifted from https://github.com/trast/tbdiff, with
> > light touch-ups to account for the command now being an option of `git
> > branch`.
>
> The
Jeff King writes:
> I'm OK with having a partial fix, or one that fixes immediate pain
> without doing a big cleanup, as long as it doesn't make anything _worse_
> in a user-visible way. And that's really my question: is pruning here
> going to bite people unexpectedly (not rhetorical -- I
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:26 AM Johannes Schindelin via GitGitGadget
> wrote:
> > This change brings `git range-diff` yet another step closer to
> > feature parity with tbdiff: it now shows the oneline, too, and indicates
> > with `=` when the
On Tue, Jul 17, 2018 at 3:53 AM Jonathan Nieder wrote:
> Subject: gc: do not return error for prior errors in daemonized mode
>
> Some build machines started failing to fetch updated source using
> "repo sync", with error
>
> error: The last gc run reported the following. Please correct the
On Tue, Jul 17 2018, Jonathan Nieder wrote:
> Hi Ævar,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Jul 17 2018, Jonathan Nieder wrote:
>
>>> That suggests a possible improvement. If all callers should be
>>> ignoring the exit code, can we make the exit code in daemonize mode
>>>
Hi Ævar,
Ævar Arnfjörð Bjarmason wrote:
> On Tue, Jul 17 2018, Jonathan Nieder wrote:
>> That suggests a possible improvement. If all callers should be
>> ignoring the exit code, can we make the exit code in daemonize mode
>> unconditionally zero in this kind of case?
>
> That doesn't make
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
From: Johannes Schindelin
While it is true that we never add unreachable commits into pack files
intentionally (as `git repack`'s documentation states), we must not
forget that a `git fetch --prune` (or even a `git fetch` when a ref was
force-pushed in the meantime) can make a commit unreachable
Under certain circumstances, commits that were reachable can be made
unreachable, e.g. via `git fetch --prune`. These commits might have been packed
already, in which case `git repack -adlf` will just drop them without giving
them the usual grace period before an eventual `git prune` (via `git
This commit allows git to create and check x509 type signatures using
gpgsm.
Signed-off-by: Henning Schild
---
Documentation/config.txt | 5 +++--
gpg-interface.c | 15 +++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt
Add test cases to cover the new X509/gpgsm support. Most of them
resemble existing ones. They just switch the format to x509 and set the
signingkey when creating signatures. Validation of signatures does not
need any configuration of git, it does need gpgsm to be configured to
trust the
Create a struct that holds the format details for the supported formats.
At the moment that is still just "openpgp". This commit prepares for the
introduction of more formats, that might use other programs and match
other signatures.
Signed-off-by: Henning Schild
---
gpg-interface.c | 88
Am Mon, 16 Jul 2018 13:14:34 -0700
schrieb Junio C Hamano :
> Henning Schild writes:
>
> > Add "gpg.format" where the user can specify which type of signature
> > to use for commits. At the moment only "openpgp" is supported and
> > the value is not even used. This commit prepares for a new
Add "gpg.format" where the user can specify which type of signature to
use for commits. At the moment only "openpgp" is supported and the value is
not even used. This commit prepares for a new types of signatures.
Signed-off-by: Henning Schild
---
Documentation/config.txt | 4
Supporting multiple signing formats we will have the need to configure a
custom program each. Add a new config value to cater for that.
Signed-off-by: Henning Schild
---
Documentation/config.txt | 5 +
gpg-interface.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff
Changes in v4:
- make gpg.format matching case sensitive
- (final?) coding style and wording changes
Changes in v3:
- drop patches 1 and 2 known from < v3, see pu hs/push-cert-check-cleanup
- dropped some testcases from p6, added two t7004 bad key/sig
- ship a binary x509 certificate for
Am Mon, 16 Jul 2018 13:45:40 -0700
schrieb Junio C Hamano :
> Henning Schild writes:
>
> > +gpg..program::
> > + Use this to customize the program used for the signing
> > format you
> > + chose. (see gpg.program) gpg.openpgp.program is a synonym
> > for the
> > + legacy gpg.program.
>
gnupg does print the keyid followed by a space and the signer comes
next. The same pattern is also used in gpgsm, but there the key length
would be 40 instead of 16. Instead of hardcoding the expected length,
find the first space and calculate it.
Input that does not match the expected format will
Test setting gpg.format to both invalid and valid values.
Signed-off-by: Henning Schild
---
t/t7510-signed-commit.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
index 6e2015ed9..7bdad570c 100755
--- a/t/t7510-signed-commit.sh
Am Mon, 16 Jul 2018 13:40:32 -0700
schrieb Junio C Hamano :
> Henning Schild writes:
>
> > Create a struct that holds the format details for the supported
> > formats. At the moment that is still just "openpgp". This commit
> > prepares for the introduction of more formats, that might use other
At the moment, `get_oid()` might call `die()` in some cases. To
prevent that from happening, this patches introduces a new flag
called `GET_OID_GENTLY` and a new function `get_oid_gently()`,
which passes the mentioned flag further to `get_oid_with_context()`.
The call graph of `get_oid()` is
This commit introduces a way to call `read_ref_at()` without
exiting on failure.
Signed-off-by: Paul-Sebastian Ungureanu
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index 0eb379f93..4a470158e 100644
--- a/refs.c
+++ b/refs.c
@@ -932,6 +932,8 @@ int
The current API does not provide a method to call
`get_oid()` and avoid `exit()` to be called. This commit
intention is to introduce a flag in order to make `get_oid()`
able to get the sha1 safely, without exiting the program.
Since `get_oid()` calls a lot of functions, which call other
functions
Add `get_tree_entry_gently()`, `find_tree_entry_gently()`
and `get_tree_entry_follow_symlinks_gently()`, which will
make `get_oid()` to be more gently.
Since `get_tree_entry()` is used in more than 20 places,
adding a new parameter will make this commit harder to read.
In every place it is called
After teaching `read_ref_at()` we need to teach `get_oid_basic()`
that `read_ref_at()` might not call `exit()`, but report an
error through the return value.
Signed-off-by: Paul-Sebastian Ungureanu
---
sha1-name.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff
This commit makes `get_oid_with_context()` and `get_oid_with_context_1()`
to recognize the `GET_OID_GENTLY` flag.
The `gentle` flag does not imply `quiet` and we might need to reconsider
whether we should display any message if `GET_OID_GENTLY` is given.
Signed-off-by: Paul-Sebastian Ungureanu
Add `get_oid_gently()` to be a gentle alternative to `get_oid()`.
Signed-off-by: Paul-Sebastian Ungureanu
---
cache.h | 1 +
sha1-name.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/cache.h b/cache.h
index cb8803e2f..36e196202 100644
--- a/cache.h
+++ b/cache.h
@@ -1321,6
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> When generating a range-diff, matching up commits between two version of
> a patch series involves heuristics, thus may give unexpected results.
> git-branch-diff allows tweaking the heuristic via --creation-weight.
> Follow suit by accepting
On Tue, Jul 17, 2018 at 6:45 AM Johannes Schindelin
wrote:
> On Wed, 30 May 2018, Eric Sunshine wrote:
> > + if (strstr(prev, "..")) {
> > + if (!origin)
> > + die(_("failed to infer range-diff ranges"));
> > + argv_array_push(args, prev);
> > +
Thanks for the review comments. In the new version of the series
(almost complete), almost the entire implementation has changed,
including most of the stuff on which you commented. Anyhow, see my
responses to your comments below...
On Tue, Jul 17, 2018 at 6:31 AM Johannes Schindelin
wrote:
> On
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index 460c31a293..e38cf06050 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -995,10 +995,20 @@ static char *find_branch_name(struct rev_info *rev)
>
> static void
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index e01a256c11..460c31a293 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -28,6 +28,7 @@
> #include "mailmap.h"
> #include "gpg-interface.h"
> #include "progress.h"
> +#include
On Tue, Jul 17, 2018 at 6:15 AM Johannes Schindelin
wrote:
> On Wed, 30 May 2018, Eric Sunshine wrote:
> > make_cover_letter() returns early when it lacks sufficient state to emit
> > a diffstat, which makes it difficult to extend the function to reliably
> > emit additional generated content.
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> make_cover_letter() returns early when it lacks sufficient state to emit
> a diffstat, which makes it difficult to extend the function to reliably
> emit additional generated content. Work around this shortcoming by
> factoring
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Mon, Jul 16, 2018 at 02:37:32PM -0700, Junio C Hamano wrote:
> > Eric Sunshine writes:
> > > On Mon, Jul 16, 2018 at 11:51 AM Johannes Schindelin
> > > wrote:
> > >> On Mon, 16 Jul 2018, Johannes Schindelin wrote:
> > >> > > -
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> Dscho recently implemented a 'tbdiff' replacement as a Git builtin named
> git-branch-diff[1] which computes differences between two versions of a
> patch series. Such a diff can be a useful aid for reviewers when
> inserted into a cover
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:27 AM Johannes Schindelin via GitGitGadget
> wrote:
> > At this stage, `git range-diff` can determine corresponding commits
> > of two related commit ranges. This makes use of the recently introduced
> >
On Tue, Jul 17 2018, J. Paul Reed wrote:
> Hey Git Devs,
>
> I have a bit of an odd question: do git clone/checkout operations have a
> deterministic ordering?
>
> That is: are files guaranteed to be laid down onto disk in any specific
> (and deterministic) order as a clone and/or checkout
Hi Jonathan,
[had to drop Perry Hutchinson, as the email address is apparently invalid,
and I only realized now that I never sent this out.]
On Tue, 10 Jul 2018, Jonathan Nieder wrote:
> If this [/proc issue] is the main obstacle to enabling RUNTIME_PREFIX by
> default, one option would be to
Hey Git Devs,
I have a bit of an odd question: do git clone/checkout operations have a
deterministic ordering?
That is: are files guaranteed to be laid down onto disk in any specific
(and deterministic) order as a clone and/or checkout operations occurs?
(And if so, is it alphabetical order?
On Tue, Jul 17 2018, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>> On Mon, Jul 16, 2018 at 03:56:39PM -0700, Jonathan Nieder wrote:
>
>>> The calling command in the motivating example is Android's "repo" tool:
>>>
>>> bare_git.gc('--auto')
>>>
>>> from
Use oid_object_info_extended() to get object info instead of
read_object_file().
It will help to handle some requests faster (e.g., we do not need to
parse whole object if we need to know %(objectsize)).
It could also help us to add new atoms such as %(objectsize:disk)
and %(deltabase).
Initialize variable `eaten` before its using. We may initialize it in
parse_object_buffer(), but there are cases when we do not reach this
invocation.
Signed-off-by: Olga Telezhnaia
---
ref-filter.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ref-filter.c
Add the source of object data to prevent parsing of unneeded data.
The goal is to improve performance by avoiding calling expensive
functions when we don't need the information they provide
or when we could get it by using a cheaper function.
It is stored in valid_atoms because it depends on the
Inline get_obj(): it would be easier to edit the code
without this split.
Signed-off-by: Olga Telezhnaia
---
ref-filter.c | 36 +++-
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 8db7ca95b12c0..2b401a17c4689
Atoms like "align" or "end" do not have string representation.
Earlier we had to go and parse whole object with a hope that we
could fill their string representations. It's easier to fill them
with an empty string before we start to work with whole object.
It is important to mention that we fill
1 - 100 of 107 matches
Mail list logo
