On Fri, Jun 01, 2018 at 10:42:00AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I haven't tested it, but I suspect that doing multiple fetches could
> > result in passing bad objects through a fetch.fsckObjects filter.
> > Because the objects aren't quarantined on fetch, and because
>
On Thu, May 31, 2018 at 09:17:41AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Ævar Arnfjörð Bjarmason writes:
> >
> >> Before this change git will die on any unknown color.ui values:
> >>
> >> $ git -c color.ui=doesnotexist show
> >> fatal: bad numeric config value 'doesnotexist' for
On Thu, May 31, 2018 at 09:09:58AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> Instead let's briefly describe what each variable is for, and then
> >> copy/paste a new boilerplate saying that this variable takes the exact
> >> same values as color.ui, and if it's unset it'll fallback to whatever
>
On Thu, May 31, 2018 at 09:01:49AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Is there some case where a pager can only handle color if _it's_ output
> > is going to a tty, and otherwise not?
>
> Maybe I'm missing something but how is that something we can deal with?
> We just:
>
> 1. use
From f4b04cf65c4b220c8127ed2692c057fab76392a9 Mon Sep 17 00:00:00 2001
From: kx
Date: Thu, 31 May 2018 22:47:49 +0300
Subject: [PATCH 1/3] I suggest to add following lines into commit
message
created by 'git subtree add' command:
git-subtree-repo: https://github.com/.../remote.git
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>> @@ -1269,6 +1270,16 @@ int cmd_checkout(int argc, const char **argv, const
>> char *prefix)
>> if (opts.patch_mode || opts.pathspec.nr) {
>> int ret = checkout_paths(, new_branch_info.name,
>>
As there are plans to implement other ref storage systems,
let's use a way to remove remote refs that does not depend
on refs being files.
This makes it clear to readers that this test does not
depend on which ref backend is used.
Suggested-by: Michael Haggerty
Helped-by: Jeff King
Ævar Arnfjörð Bjarmason writes:
> @@ -1269,6 +1270,16 @@ int cmd_checkout(int argc, const char **argv, const
> char *prefix)
> if (opts.patch_mode || opts.pathspec.nr) {
> int ret = checkout_paths(, new_branch_info.name,
>
Ævar Arnfjörð Bjarmason writes:
> Add an *_INIT macro for the tracking_name_data similar to what exists
> elsewhere in the codebase, e.g. OID_ARRAY_INIT in sha1-array.h. This
> will make it more idiomatic in later changes to add more fields to the
> struct & its initialization macro.
Makes
Ævar Arnfjörð Bjarmason writes:
> Assert that whenever there's a DWIM checkout that the index should be
> clean afterwards, in addition to the correct branch being checked-out.
> ...
> So let's amend the tests (mostly added in) 399e4a1c56 ("t2024: Add
> tests verifying current DWIM behavior of
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> This patch adds a test to check this behavior that notices another
>> behavior difference between protocol v0 and v2 in the process. Add a
>> NEEDSWORK comment to clear it up.
>
> Thanks.
>
> I wonder if there is a more effective way to smoke
Junio C Hamano writes:
> Perhaps a better fisx is to explicitly assign NULL to item->dst when
> we see there is no right-hand-side.
-- >8 --
Subject: [PATCH] refspec-api: avoid uninitialized field in refspec item
When parse_refspec() function was created at 3eec3700 ("refspec:
factor out
Derrick Stolee writes:
> Shallow clones do not interact well with the commit-graph feature for
> several reasons. Instead of doing the hard thing to fix those
> interactions, instead prevent reading or writing a commit-graph file for
> shallow repositories.
The latter instead would want to
Stefan Beller writes:
> plumbing command, so the likelihood of git-log calls in scripts out
> there is high.
>
> So maybe the community should strive to be more aggressive about
> changing the porcelain interface for the better.
To me, these two paragraphs are being incoherent.
If plumbing
Thomas Gummerer writes:
>> I considered splitting this into checkout.defaultRemote and
>> worktree.defaultRemote, but it's probably less confusing to break our
>> own rules that anything shared between config should live in core.*
>> than have two config settings, and I couldn't come up with a
Thomas Gummerer writes:
> We seem to have plenty of structs defined in '.c' files, if they are
> only needed there. Its use also seems to be single purpose for the
> callback data, so I'm a bit puzzled how having this in a header file
> instead of the .c file would be helpful?
>
> I feel like
Jonathan Nieder writes:
> When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation
> logic, 2018-05-16) factored out the ref-prefix generation code for
> reuse, it left out the 'if (!item->exact_sha1)' test in the original
> ref-prefix generation code. As a result, fetches by SHA-1
Stefan Beller writes:
> 'item->dst' has not been assigned if '!rhs' is true. As the caller is allowed
> to pass in uninitialized
> memory (we don't assume 'item' was zeroed out before calling), this fixes an
> access to
> uninitialized memory.
Did I miss the other 4 patches that this might
Hi,
Git v2.18.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 108 updated messages need to be translated since last
update:
l10n: git.pot: v2.18.0 round 1 (108 new, 14 removed)
Generate po/git.pot from v2.18.0-rc0 for git v2.18.0 l10n round 1.
Jeff King writes:
> I haven't tested it, but I suspect that doing multiple fetches could
> result in passing bad objects through a fetch.fsckObjects filter.
> Because the objects aren't quarantined on fetch, and because
> fsck_finish() requires the objects to be installed into place, they may
>
Jeff King writes:
> So I think you're proposing:
>
> - step 0: warn about "-l" when it actually gets used, and otherwise
> continue ignoring
>
> - step 1: turn "-l" into "--list"
>
> - step 2: there is no step 2
>
> ... So I
> guess the right rule is to warn when we are not in
Ævar Arnfjörð Bjarmason writes:
> We already have to deal with this special case of origin/HEAD
> being re-pointed in a repository that we "clone", so we would just
> do whatever happens to a repository that's cloned.
OK. Not visiting that issue while we discuss this "origin/HEAD is
useful, so
isteph...@atlassian.com writes:
> From: Isabella Stephens
>
> If the -L option is used to specify a line range in git blame, and the
> end of the range is past the end of the file, git will fail with a fatal
> error. This commit prevents such behavior - instead we display the blame
> for
isteph...@atlassian.com writes:
> From: Isabella Stephens
>
> If the -L option is used to specify a line range in git log, and the end
> of the range is past the end of the file, git will fail with a fatal
> error. This commit prevents such behaviour - instead we perform the log
> for existing
On 5/31/2018 2:33 PM, Stefan Beller wrote:
On Thu, May 31, 2018 at 10:40 AM, Derrick Stolee wrote:
The commit-graph file stores a condensed version of the commit history.
This helps speed up several operations involving commit walks. This
feature does not work well if those commits "change"
Elijah Newren writes:
> In the 2.18 cycle, directory rename detection was merged, then reverted,
> then reworked in such a way to fix another prominent bug in addition to
> the original problem causing it to be reverted. When the reworked series
> was merged, we ended up with two nearly
Ævar Arnfjörð Bjarmason writes:
> It's our documentation that should be clearly stating those reasons. If
> we're not saying anything about these being historical bugs, then e.g. I
> (not knowing the implementation) wouldn't have turned this on globally
> on my site knowing that because I have
Duy Nguyen writes:
> On Wed, May 30, 2018 at 8:38 AM, Junio C Hamano wrote:
>> * sb/object-store-alloc (2018-05-16) 13 commits
>> - alloc: allow arbitrary repositories for alloc functions
>> - object: allow create_object to handle arbitrary repositories
>> - object: allow grow_object_hash to
On Thu, May 31, 2018 at 4:09 PM, Robert P. J. Day wrote:
> On Fri, 1 Jun 2018, Johannes Sixt wrote:
>
>> Am 31.05.2018 um 19:27 schrieb Robert P. J. Day:
>> > On Thu, 31 May 2018, Duy Nguyen wrote:
>> >> git diff-index is "plumbing", designed for writing scripts. "git
>> >> diff" on the other
Taylor Blau writes:
> I have these patches mostly updated on my copy (available at
> https://github.com/ttaylorr/git/compare/tb/grep-column) but am out of
> the office for the next week, so I will polish and send these on June
> 8th.
>
>> * tb/grep-only-matching (2018-05-14) 2 commits
>> -
On Fri, 1 Jun 2018, Johannes Sixt wrote:
> Am 31.05.2018 um 19:27 schrieb Robert P. J. Day:
> > On Thu, 31 May 2018, Duy Nguyen wrote:
> >> git diff-index is "plumbing", designed for writing scripts. "git
> >> diff" on the other hand is for users and its behavior may change
> >> even if it breaks
Am 31.05.2018 um 19:27 schrieb Robert P. J. Day:
On Thu, 31 May 2018, Duy Nguyen wrote:
git diff-index is "plumbing", designed for writing scripts. "git
diff" on the other hand is for users and its behavior may change
even if it breaks backward compatibility.
ah, this was a philosophical
Commit 73c3f0f704 (index-pack: check .gitmodules files with
--strict, 2018-05-04) added a call to add_packed_git(), with
the intent that the newly-indexed objects would be available
to the process when we run fsck_finish(). But that's not
what add_packed_git() does. It only allocates the struct,
The parse_commit_buffer() function consults lookup_commit_graft()
to see if we need to rewrite parents. The latter will look
at $GIT_DIR/info/grafts. If you're outside of a repository,
then this will trigger a BUG() as of b1ef400eec (setup_git_env:
avoid blind fall-back to ".git", 2016-10-20).
Coverity reported that the recently-added call to add_packed_git() in
index-pack.c actually does nothing. It's right, and it turns out this is
a minor bug in the .gitmodules fsck patches in v2.17.1. I say minor
because it errs on the side of complaining too much (so it's not a
security problem)
On 05/31, Ævar Arnfjörð Bjarmason wrote:
> Introduce a checkout.defaultRemote setting which can be used to
> designate a remote to prefer (via checkout.defaultRemote=origin) when
> running e.g. "git checkout master" to mean origin/master, even though
> there's other remotes that have the "master"
Hi Ævar,
Sorry for chiming in late. I have a couple of thoughts:
> (
> cd /tmp &&
> rm -rf tbdiff &&
> git clone g...@github.com:trast/tbdiff.git &&
> cd tbdiff &&
> git branch -m topic &&
> git checkout master
> )
>
> That will output:
>
>
On 05/31, Ævar Arnfjörð Bjarmason wrote:
> Move the tracking_name_data struct used in checkout.c into its
> corresponding header file. This wasn't done in 7c85a87c54 ("checkout:
> factor out functions to new lib file", 2017-11-26) when checkout.[ch]
> were created, and is more consistent with the
Sehr geehrte Damen und Herren,
Sie brauchen Geld? Sie sind auf der suche nach einem Darlehen? Seriös und
unkompliziert?
Dann sind Sie hier bei uns genau richtig.
Durch unsere jahrelange Erfahrung und kompetente Beratung sind wir
Europaweit tätig.
Wir bieten jedem ein GÜNSTIGES Darlehen zu TOP
Introduce a checkout.defaultRemote setting which can be used to
designate a remote to prefer (via checkout.defaultRemote=origin) when
running e.g. "git checkout master" to mean origin/master, even though
there's other remotes that have the "master" branch.
I want this because it's very handy to
As the "checkout" documentation describes:
If is not found but there does exist a tracking branch in
exactly one remote (call it ) with a matching name, treat
as equivalent to [...] /
hint: instead of ?
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config.txt | 7
Move the tracking_name_data struct used in checkout.c into its
corresponding header file. This wasn't done in 7c85a87c54 ("checkout:
factor out functions to new lib file", 2017-11-26) when checkout.[ch]
were created, and is more consistent with the rest of the codebase.
Signed-off-by: Ævar
There is no point in doing this right now, but in later change the
"ret" variable will be inspected. This change makes that meaningful
change smaller.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/checkout.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Add an *_INIT macro for the tracking_name_data similar to what exists
elsewhere in the codebase, e.g. OID_ARRAY_INIT in sha1-array.h. This
will make it more idiomatic in later changes to add more fields to the
struct & its initialization macro.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Assert that whenever there's a DWIM checkout that the index should be
clean afterwards, in addition to the correct branch being checked-out.
The way the DWIM checkout code in checkout.[ch] works is by looping
over all remotes, and for each remote trying to find if a given
reference name only
v4 started as a simple bug-fix for this one-part series, but since
it's not going to make 2.18.0 at this point I thought I'd do some more
work on it. Comments on patches below:
Ævar Arnfjörð Bjarmason (9):
checkout tests: index should be clean after dwim checkout
Tests that would have revealed
Pass the previously added "num_matches" struct value up to the callers
of unique_tracking_name(). This will allow callers to optionally print
better error messages in a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/checkout.c | 16 +++-
builtin/worktree.c | 4
The line was too long already, and will be longer still when a later
change adds another argument.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/checkout.h b/checkout.h
index 9980711179..4cd4cd1c23 100644
---
Internally track how many matches we find in the check_tracking_name()
callback. Nothing uses this now, but it will be made use of in a later
change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
checkout.c | 4 ++--
checkout.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
On Thu, May 31, 2018 at 12:33 PM, Alban Gruin wrote:
> Hi Stefan,
>
> Le 31/05/2018 à 20:44, Stefan Beller a écrit :
>> On Thu, May 31, 2018 at 10:48 AM, Phillip Wood
>> wrote:
>>> Hi Alban, it's great to see you working on this
>>>
>>> On 31/05/18 12:01, Alban Gruin wrote:
This series
On Thu, May 31, 2018 at 10:41 AM, Derrick Stolee wrote:
> Also enable core.commitGraph and gc.commitGraph. Helps to test the
> commit-graph feature with the rest of the test infrastructure.
>
> Signed-off-by: Derrick Stolee
> ---
> builtin/commit.c | 5 +
> builtin/gc.c | 2 +-
>
Hi Stefan,
Le 31/05/2018 à 20:44, Stefan Beller a écrit :
> On Thu, May 31, 2018 at 10:48 AM, Phillip Wood
> wrote:
>> Hi Alban, it's great to see you working on this
>>
>> On 31/05/18 12:01, Alban Gruin wrote:
>>> This series rewrites append_todo_help() from shell to C. This is part
>>> of the
On Thu, May 31, 2018 at 10:41 AM, Derrick Stolee wrote:
> The commit-graph feature is not compatible with history-rewriting
> features such as shallow clones.
I associate "history rewriting" with changing objects in the history.
For example interactive rebase or the BFG cleaner[1] /
Hi Phillip,
Le 31/05/2018 à 19:48, Phillip Wood a écrit :
> Hi Alban, it's great to see you working on this
>
> On 31/05/18 12:01, Alban Gruin wrote:
>> This series rewrites append_todo_help() from shell to C. This is part
>> of the effort to rewrite interactive rebase in C.
>>
>> The first
On 05/30, brian m. carlson wrote:
> On Wed, May 30, 2018 at 09:52:55PM +0100, Thomas Gummerer wrote:
> > Add a mention of the security mailing list to the README, and to
> > Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note
> > git-secur...@googlegroups.com", 2018-03-08) already
On Thu, May 31, 2018 at 10:41 AM, Derrick Stolee wrote:
> Shallow clones do not interact well with the commit-graph feature for
> several reasons. Instead of doing the hard thing to fix those
> interactions, instead prevent reading or writing a commit-graph file for
> shallow repositories.
Makes
On Thu, May 31, 2018 at 5:07 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Wed, 30 May 2018, Stefan Beller wrote:
>
>> Signed-off-by: Stefan Beller
>> ---
>> builtin/submodule--helper.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/builtin/submodule--helper.c
On Thu, May 31, 2018 at 5:04 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Wed, 30 May 2018, Stefan Beller wrote:
>
>> Signed-off-by: Stefan Beller
>> ---
>>
>> This was a deliberate oversight in f241ff0d0a9 (prepare the builtins for a
>> libified merge_recursive(), 2016-07-26)
>
> No, it
On Thu, May 31, 2018 at 10:48 AM, Phillip Wood
wrote:
> Hi Alban, it's great to see you working on this
>
> On 31/05/18 12:01, Alban Gruin wrote:
>> This series rewrites append_todo_help() from shell to C. This is part
>> of the effort to rewrite interactive rebase in C.
>>
>> The first commit
Hi,
On Thu, May 31, 2018 at 6:30 PM, wrote:
>
> I was trying to build git 2.9.5 as a normal user, as I have no root access
> on a cluster with outdated software.
>
> The build fails, unless I change the PREFIX=/usr/local line in
> per/perl.mak:80 to a folder where I have write permission.
>
On Thu, May 31, 2018 at 10:40 AM, Derrick Stolee wrote:
> The commit-graph file stores a condensed version of the commit history.
> This helps speed up several operations involving commit walks. This
> feature does not work well if those commits "change" using features like
> commit grafts,
Hi Alban, it's great to see you working on this
On 31/05/18 12:01, Alban Gruin wrote:
> This series rewrites append_todo_help() from shell to C. This is part
> of the effort to rewrite interactive rebase in C.
>
> The first commit rewrites append_todo_help() in C (the C version
> covers a bit
On Thu, May 31, 2018 at 7:27 PM, Robert P. J. Day wrote:
> On Thu, 31 May 2018, Duy Nguyen wrote:
>
>> On Thu, May 31, 2018 at 6:38 PM, Robert P. J. Day
>> wrote:
>> >
>> > was going over some hooks and writing some tutorials for some of
>> > the commit-related, client-side hooks, and was
Also enable core.commitGraph and gc.commitGraph. Helps to test the
commit-graph feature with the rest of the test infrastructure.
Signed-off-by: Derrick Stolee
---
builtin/commit.c | 5 +
builtin/gc.c | 2 +-
environment.c| 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
Shallow clones do not interact well with the commit-graph feature for
several reasons. Instead of doing the hard thing to fix those
interactions, instead prevent reading or writing a commit-graph file for
shallow repositories.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 12
The commit-graph format includes a way to specify a parent is
"missing" from the commit-graph (i.e. we do not have a record of
that parent in our list of object IDs, and hence cannot provide
a graph position). For mose cases, this does not occur due to
the close_reachable() method adding all
Create destroy_commit_graph() method to delete the commit-graph file
when history is altered by a replace-object call. If the commit-graph
is rebuilt after that, we will load the correct object while reading
the commit-graph.
When parsing a commit, first check if the commit was grafted. If so,
The commit-graph feature is not compatible with history-rewriting
features such as shallow clones. When running a 'git fetch' with
any of the shallow/unshallow options, destroy the commit-graph
file and override core.commitGraph to be false.
Signed-off-by: Derrick Stolee
---
builtin/fetch.c | 6
THIS IS ONLY FOR TESTING TO INCREASE TEST COVERAGE
Signed-off-by: Derrick Stolee
---
builtin/fetch.c | 4
1 file changed, 4 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 8ee998ea2e..af896e4b74 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -20,6 +20,7 @@
The commit-graph file stores a condensed version of the commit history.
This helps speed up several operations involving commit walks. This
feature does not work well if those commits "change" using features like
commit grafts, replace objects, or shallow clones.
Since the commit-graph feature is
On Thu, 31 May 2018, Duy Nguyen wrote:
> On Thu, May 31, 2018 at 6:38 PM, Robert P. J. Day
> wrote:
> >
> > was going over some hooks and writing some tutorials for some of
> > the commit-related, client-side hooks, and was wondering (perhaps
> > stupidly) why the pre-commit.sample hook uses,
On Thu, May 31, 2018 at 6:38 PM, Robert P. J. Day wrote:
>
> was going over some hooks and writing some tutorials for some of the
> commit-related, client-side hooks, and was wondering (perhaps
> stupidly) why the pre-commit.sample hook uses, as its last line:
>
> exec git diff-index --check
was going over some hooks and writing some tutorials for some of the
commit-related, client-side hooks, and was wondering (perhaps
stupidly) why the pre-commit.sample hook uses, as its last line:
exec git diff-index --check --cached $against --
^^
as in, could this not
On Thu, May 31, 2018 at 04:00:38PM +, Erika Voss wrote:
> Yes here is what was sent to me -
>
> https://www.theregister.co.uk/2018/05/30/git_vulnerability_could_lead_to_an_attack_of_the_repo_clones/
> https://www.debian.org/security/2018/dsa-4212
Yeah, the release announcement from the
Hi,
I was trying to build git 2.9.5 as a normal user, as I have no root
access on a cluster with outdated software.
The build fails, unless I change the PREFIX=/usr/local line in
per/perl.mak:80 to a folder where I have write permission.
Apparently, perl.mak does not honour the --prefix=
Hi Randall,
Yes here is what was sent to me -
https://www.theregister.co.uk/2018/05/30/git_vulnerability_could_lead_to_an_attack_of_the_repo_clones/
https://www.debian.org/security/2018/dsa-4212
The one that I could find from online was:
https://git-scm.com/download/mac
But, the latest
On May 31, 2018 11:57 AM, Erika Voss wrote:
> There was an article I came across yesterday identifying a vulnerability to
> patch our Git environments. I don’t see one that is available for our Mac
> Clients - is there a more recent one that I can download that is available to
> patch the 2.17.0
Good morning,
There was an article I came across yesterday identifying a vulnerability to
patch our Git environments. I don’t see one that is available for our Mac
Clients - is there a more recent one that I can download that is available to
patch the 2.17.0 version?
Thank you,
Erika
Thanks for finding this, I don't know how I missed moving that bit
over when factoring it out. Well I guess I sort of rewrote it and
combined two pieces of logic so that's how. Anyway, this looks right
and thanks for adding the test.
On Thu, May 31, 2018 at 12:23 AM, Jonathan Nieder wrote:
>
On 31/05/2018 08:43, Jeff King wrote:
If there are zero parents (neither relevant nor irrelevant), is it still
TREESAME? I would say in theory yes.
Not sure - I think roots are such a special case that TREESAME
effectively doesn't matter. We always test for roots first.
So what I was
On 5/30/2018 6:24 PM, Jakub Narebski wrote:
Derrick Stolee writes:
The 'verify' subcommand must compare the commit content parsed from the
commit-graph and compare it against the content in the object database.
You have "compare" twice in the above sentence.
Use lookup_commit() and
On 5/30/2018 3:22 PM, Jakub Narebski wrote:
Derrick Stolee writes:
In the 'verify' subcommand, load commits directly from the object
database to ensure they exist. Parse by skipping the commit-graph.
All right, before we check that the commit data matches, we need to
check that all the
Gratulujeme, že ste získali € 650,000.00 v miliónoch Euro / Google
Propagacné remízy sa konali 1. mája 2018.
Obrátte sa na nášho reklamného zástupcu s nasledujúcimi informáciami o nárokoch
na tento e-mail.
janosiklubos...@gmail.com
1. Celé meno: 2. Adresa:
3. Pohlavie: 4. Vek:
5. Zamestnanie
Hi Brian,
On Wed, 30 May 2018, brian m. carlson wrote:
> On Wed, May 30, 2018 at 09:14:06AM -0700, Stefan Beller wrote:
> > Good point. I remember my initial reaction to the file names was
> > expecting some hungarian notation, which totally didn't make sense, so
> > I refrained from commenting.
Hi Stefan,
just to close the loop:
On Wed, 30 May 2018, Stefan Beller wrote:
> On Wed, May 30, 2018 at 12:48 PM, John Meyer wrote:
> > Ran the installer, selected the option to not modify the path & the path
> > was modified anyway... it removed git from the path (it was there from a
> >
Hi Stefan,
On Wed, 30 May 2018, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> builtin/submodule--helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 7c3cd9dbeba..96024fee1b1 100644
> ---
Hi Stefan,
I am Cc:ing Michael, the original author of the fixed commit.
On Wed, 30 May 2018, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
>
> This was an oversight in 01caf20d57a (load_contents(): don't try to mmap an
> empty file, 2018-01-24).
>
> This and the following 2
Hi Stefan,
On Wed, 30 May 2018, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
>
> This was a deliberate oversight in f241ff0d0a9 (prepare the builtins for a
> libified merge_recursive(), 2016-07-26)
No, it was not deliberate. It was inadvertent, most likely ;-)
> sequencer.c | 4
On Wed, May 30, 2018 at 7:03 PM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
>
> This was an oversight in 01caf20d57a (load_contents(): don't try to mmap an
> empty file, 2018-01-24).
>
> This and the following 2 patches apply on master.
>
> refs/packed-backend.c | 1 +
> 1 file
Hi Brian,
On Wed, 30 May 2018, brian m. carlson wrote:
> On Wed, May 30, 2018 at 11:54:27AM +0200, Johannes Schindelin wrote:
>
> > > + third=$(git rev-parse HEAD) &&
> > > + git checkout -b labels master &&
> > > + git merge --no-commit third &&
> > > + test_tick &&
> > > + git commit -m
This series rewrites append_todo_help() from shell to C. This is part
of the effort to rewrite interactive rebase in C.
The first commit rewrites append_todo_help() in C (the C version
covers a bit more than the old shell version), adds some parameters to
rebase--helper, etc.
The second one
This rewrites append_todo_help() from shell to C. It also incorporates
some parts of initiate_action() and complete_action() that also write
help texts to the todo file.
Two flags are added to rebase--helper.c: one to call
append_todo_help() (`--append-todo-help`), and another one to tell
This removes newlines before and after the messages in
append_todo_help(). This is done to avoid confusions from
translators.
These newlines are now inserted with
`strbuf_add_commented_lines()`. Messages were ended by two newlines
characters, but here we only insert one at a time. This is because
On Thu, May 24 2018, Ævar Arnfjörð Bjarmason wrote:
> struct tracking_name_data {
> /* const */ char *src_ref;
> char *dst_ref;
> struct object_id *dst_oid;
> int unique;
> + const char *implicit_remote;
> + char *implicit_dst_ref;
> };
There's a bug here that
On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> If you make an initial commit and push to a remote repo "origin", you
>> don't get a remote origin/HEAD reference, and a "fetch" won't create it
>> either.
>> ...
>> Some code spelunking reveals
On Fri, May 25 2018, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> +will instead be left unreferenced in the repository. That's considered
>>> +a bug, and hopefully future git release will implement a quarantine
>>> +for the "fetch" side as well.
>>
>> If this was a "BUGS" section in a
When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation
logic, 2018-05-16) factored out the ref-prefix generation code for
reuse, it left out the 'if (!item->exact_sha1)' test in the original
ref-prefix generation code. As a result, fetches by SHA-1 generate
ref-prefixes as though the
On Wed, May 30 2018, Junio C Hamano wrote:
> Earlier I mumbled "this 4-patch series generally looks good but I
> need to re-read the implementation step"; I meant this 5-patch
> series and here is my impression after re-reading the implementation
> step.
>
> Ævar Arnfjörð Bjarmason writes:
>
On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano wrote:
>>> If the project has some tool constraints and have to accept new
>>> "broken" objects on ongoing basis, then fsck. facility may
>>> make sense, but that
On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Before this change git will die on any unknown color.ui values:
>>
>> $ git -c color.ui=doesnotexist show
>> fatal: bad numeric config value 'doesnotexist' for 'color.ui': invalid
>> unit
>
> I do not
1 - 100 of 106 matches
Mail list logo
