Hi,
same problem with all program, There is a crash before the launch
> git difftool --dir-diff 4cb98b4a307ce97d9e6b8e4b03211fa5ca8af7e7
0244799661b993b1f78fa5afb621de3fe4c4a39c --
fatal: could not open '/tmp/git-difftool.g80nLO/left/jenkins.war' for
writing: Permission denied
> git difftool --d
On 05/25/2018 12:08 AM, Jakub Narebski wrote:
> Derrick Stolee writes:
>> On 5/22/2018 1:39 AM, Michael Haggerty wrote:
>>> On 05/21/2018 08:10 PM, Derrick Stolee wrote:
[...]
>>> This may be beyond the scope of what you are working on, but there are
>>> significant advantages to selecting a
Hi,
On Thu, May 24, 2018 at 11:11 PM, Etienne d'Hautefeuille
wrote:
>
> #try a diff
> git difftool --dir-diff 4cb98b4a307ce97d9e6b8e4b03211fa5ca8af7e7
> 0244799661b993b1f78fa5afb621de3fe4c4a39c
> fatal: impossible d'ouvrir '/tmp/git-difftool.UQ4mqo/left/jenkins.war' en
> écriture: Permission non
Derrick Stolee writes:
> One other change worth mentioning: in "commit-graph: add '--reachable'
> option" I put the ref-iteration into a new external
> 'write_commit_graph_reachable()' method inside commit-graph.c. This
> makes the 'gc: automatically write commit-graph files' a simpler change.
;
Ævar Arnfjörð Bjarmason writes:
> fsck.skipList::
> - Like `fsck.` this variable has a corresponding
> - `receive.fsck.skipList` variant.
> + Like `fsck.` this variable has corresponding
> + `receive.fsck.skipList` and `fetch.fsck.skipList` variants.
> +
> The path to a sorted
On 24/05/2018 16:03, Mike Mason wrote:
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index 71f39410691b..9da4c5e83285 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -73,8 +73,10 @@ scm_version()
> printf -- '-svn%s' "`git svn
Hi Duy,
Nguyễn Thái Ngọc Duy wrote:
> Due to the implementation detail of intent-to-add entries. The current
> "git diff" (i.e. no treeish or --cached argument) would show the
> changes in the i-t-a file, but it does not mark the file as new, while
> "diff --cached" would mark the file as new whi
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 man-page, the above might be less
> scary. In this conte
Ævar Arnfjörð Bjarmason writes:
> Change the copy/pasted description of the fetch.fsckObjects and
> receive.fsckObjects variables to refer to transfer.fsckObjects
> instead.
>
> Let's not duplicate the description of what *.fsckObjects does twice.
> instead let's refer to transfer.fsckObjects fr
On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Hmm, actually, I suppose the true value of the warning is to help people
> > doing "git branch -l foo", and it would still work there. The "more
> > extreme" from your suggested patch would only affect "bra
Eric Sunshine writes:
> I see where you're coming from, however, I would think that readers
> arriving at this topic (generally) do so as a result of actively
> looking for it (as opposed to happening upon it), in which case they
> probably are directly seeking information about it; the incidenta
Jeff King writes:
> Hmm, actually, I suppose the true value of the warning is to help people
> doing "git branch -l foo", and it would still work there. The "more
> extreme" from your suggested patch would only affect "branch -l".
> Still, I think I prefer the gentler version that we get by keep
"Robert P. J. Day" writes:
> embarrassed to admit i had no idea that you could tag non-commit
> objects, only realized that when i was reading the man page and saw:
>
> SYNOPSIS
> git tag [-a | -s | -u ] [-f] [-m | -F ] [-e]
> [ | ]
> ^^^
SZEDER Gábor writes:
>> -test 2 = $(git ls-files -s | wc -l) &&
>> -test 2 = $(git ls-files -u | wc -l) &&
>> -test 2 = $(git ls-files -o | wc -l) &&
>
> Here 'git ls-files -o' should have listed two untracked files ...
>
>> +git ls-files -s >out &&
Thomas Gummerer writes:
> Sorry I botched the description here, and failed to describe what the
> code is actually doing. We're actually only removing the variant in
> the MERGE_RR file, whose path we are now no longer able to handle.
Oh, that's absolutely fine, then. Thanks for a prompt updat
Elijah Newren writes:
> I would have used a Reported-by tag for Florian and Todd, but looking at
> the bugzilla.redhat.com bug report doesn't show me Florian's email
> address. I grepped through git logs and found two associated with that
> name, but didn't know if they were still accurate, or w
Stefan Beller writes:
> There are 2 dimensions to it:
> * (where you are)
> if you run git-grep from a sub directory of the repository, then the
> "sub-working-tree"
> will be searched.
s/the repository/the top level directory of the working tree/, perhaps?
>> also, at the bottom of that
On 5/24/2018 6:47 PM, Stefan Beller wrote:
On Thu, May 24, 2018 at 9:25 AM, Derrick Stolee wrote:
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index 37420ae0fd
On Thu, 24 May 2018 16:07:49 -0700
Stefan Beller wrote:
> Hi Jonathan,
>
> On Thu, May 24, 2018 at 1:47 PM, Jonathan Tan
> wrote:
> > If "git pull --recurse-submodules --rebase" is invoked when the current
> > branch and its corresponding remote-tracking branch have no merge base,
> > a "bad o
Hi Jonathan,
On Thu, May 24, 2018 at 1:47 PM, Jonathan Tan wrote:
> If "git pull --recurse-submodules --rebase" is invoked when the current
> branch and its corresponding remote-tracking branch have no merge base,
> a "bad object" fatal error occurs. This issue was introduced with commit
> a6d7eb
How about something like this? It ignores attributes that should have no
bearing on whether the kernel is considered dirty. Copied trees with no other
changes would no longer be marked with -dirty. Plus it works on read-only
media since no index updating is required.
Would this also be considered
On Thu, 24 May 2018, Stefan Beller wrote:
> On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day
> wrote:
> >
> > maybe this is deliberate, but it's confusing that, with git 2.17.0,
> > the output of both "git log -h" and "git show -h" is exactly the same:
> >
> > $ git log -h
> > usage: git log
On Thu, May 24, 2018 at 4:12 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Thu, May 24 2018, Eric Sunshine wrote:
>> On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> fsck.skipList::
>>> + Like `fsck.` this variable has a corresponding
>>> + `receive.fsck.skipList` var
On Thu, May 24, 2018 at 9:25 AM, Derrick Stolee wrote:
> Signed-off-by: Derrick Stolee
> ---
> builtin/commit-graph.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
> index 37420ae0fd..f0875b8bf3 100644
> --- a/builtin
On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day wrote:
>
> maybe this is deliberate, but it's confusing that, with git 2.17.0,
> the output of both "git log -h" and "git show -h" is exactly the same:
>
> $ git log -h
> usage: git log [] [] [[--] ...]
>or: git show [] ...
>
> -q, --quie
Derrick Stolee writes:
> On 5/22/2018 1:39 AM, Michael Haggerty wrote:
>> On 05/21/2018 08:10 PM, Derrick Stolee wrote:
>>> [...]
>>> In the Discussion section of the `git merge-base` docs [1], we have the
>>> following:
>>>
>>> When the history involves criss-cross merges, there can be more
On Thu, May 24 2018, Derrick Stolee wrote:
> Thanks for all the feedback on v2. I've tried to make this round's
> review a bit easier by splitting up the commits into smaller pieces.
> Also, the test script now has less boilerplate and uses variables and
> clear arithmetic to explain which bytes
Hi,
In my repo, I have some symlink to readonly jar, I can't make difftool
between 2 commit
Steps to reproduce :
> git --version
git version 2.17.0
> id
uid=1000(sagoum) gid=1000(sagoum)
groupes=1000(sagoum),5(tty),10(wheel),14(uucp),18(audio),20(dialout),27(video),35(games),78(kvm),85(usb
On 23/05/2018 20:35, Jeff King wrote:
On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote:
On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:
$ git log --oneline master..ba95710a3b -- ci/
ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2
I keep s
On Wed, May 23, 2018 at 11:50 AM, Robert P. J. Day
wrote:
>
> more puzzling terminology, this time in the man page for "git grep".
> the SYNOPSIS shows, at the very end, the clearly optional
> "[...]",
>
> git grep ...
>... snip ...
>[--] [...]
>
> but nowhere in the
Am 24.05.2018 um 17:25 schrieb Ævar Arnfjörð Bjarmason:
> When I do:
>
> git -c fetch.fsckObjects=true clone
> g...@github.com:robbyrussell/oh-my-zsh.git
>
> I get:
>
> error: object 2b7227859263b6aabcc28355b0b994995b7148b6:
> zeroPaddedFilemode: contains zero-padded file modes
> f
If "git pull --recurse-submodules --rebase" is invoked when the current
branch and its corresponding remote-tracking branch have no merge base,
a "bad object" fatal error occurs. This issue was introduced with commit
a6d7eb2c7a ("pull: optionally rebase submodules (remote submodule
changes only)",
On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason
wrote:
> The existing documentation led the user to believe that all we were
> doing were basic readability sanity checks, but that hasn't been true
> for a very long time. Update the description to match reality, and
> note the caveat that
On Thu, May 24 2018, Eric Sunshine wrote:
> On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> The documentation for the fsck. and receive.fsck.
>> variables was mostly duplicated in two places, with fsck.
>> making no mention of the corresponding receive.fsck., and the
>> same
The standard for command documentation synopses appears to be:
[...] means optional
<...> means replaceable
[<...>] means both optional and replaceable
So fix a number of doc pages that use incorrect variations of the
above.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation
On Thu, 24 May 2018, Eric Sunshine wrote:
> On Thu, May 24, 2018 at 3:54 PM, Robert P. J. Day
> wrote:
> > The standard for command documentation synopses appears to be:
> >
> > [...] means optional
> > <...> means replaceable
> > [<...>] means both optional and replaceable
> >
> > So fix
On Thu, May 24, 2018 at 3:54 PM, Robert P. J. Day wrote:
> The standard for command documentation synopses appears to be:
>
> [...] means optional
> <...> means replaceable
> [<...>] means both optional and replaceable
>
> So fix a number of doc pages that use incorrect variations of the
> a
The standard for command documentation synopses appears to be:
[...] means optional
<...> means replaceable
[<...>] means both optional and replaceable
So fix a number of doc pages that use incorrect variations of the
above.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentatio
On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason
wrote:
> The documentation for the fsck. and receive.fsck.
> variables was mostly duplicated in two places, with fsck.
> making no mention of the corresponding receive.fsck., and the
> same for fsck.skipList.
> [...]
> Rectify this situation
On 24 May 2018 at 01:02, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I am stil
Introduce a checkout.implicitRemote setting which can be used to
designate a remote to prefer (via checkout.implicitRemote=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
On Thu, May 24 2018, Junio C Hamano wrote:
> * ab/fetch-tags-noclobber (2018-05-16) 9 commits
> - fixup! push tests: assert re-pushing annotated tags
> - fetch: stop clobbering existing tags without --force
> - fetch tests: add a test clobbering tag behavior
> - fetch tests: correct a comment
Implement support for fetch.fsck.* corresponding with the existing
receive.fsck.*. This allows for pedantically cloning repositories with
specific issues without turning off fetch.fsckObjects.
One such repository is https://github.com/robbyrussell/oh-my-zsh.git
which before this change will emit t
The documentation for the fsck. and receive.fsck.
variables was mostly duplicated in two places, with fsck.
making no mention of the corresponding receive.fsck., and the
same for fsck.skipList.
I spent quite a lot of time today wondering why setting the
fsck. variant wasn't working to clone a lega
Change the copy/pasted description of the fetch.fsckObjects and
receive.fsckObjects variables to refer to transfer.fsckObjects
instead.
Let's not duplicate the description of what *.fsckObjects does twice.
instead let's refer to transfer.fsckObjects from both fetch.* and
receive.*.
I don't think
The existing documentation led the user to believe that all we were
doing were basic readability sanity checks, but that hasn't been true
for a very long time. Update the description to match reality, and
note the caveat that there's a quarantine for accepting pushes, but
not for fetching.
Signed-
On Thu, May 24, 2018 at 9:02 PM, Jeff King wrote:
> On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> That doesn't work, because that's for the server-side, but I need the
>> fetch.fsck.* that doesn't exist. This works (I'll send a better patch
>> with tests / docs etc.
On 23/05/2018 20:35, Jeff King wrote:
There's more discussion in the thread at:
https://public-inbox.org/git/1366658602-12254-1-git-send-email-ke...@bracey.fi/
I haven't absorbed it all yet, but I'm adding Junio to the cc.
Just to ack that I've seen the discussion, but I can't identify th
On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote:
> On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote:
>
> > > On the other hand, I'm not sure this is that big a deal. The point of
> > > the deprecation warning is to catch people who are actually trying to
> > > use "-l" a
On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote:
> > On the other hand, I'm not sure this is that big a deal. The point of
> > the deprecation warning is to catch people who are actually trying to
> > use "-l" as "--create-reflog", and that case does not page. The people
> > doing
On Thu, May 24, 2018 at 4:45 AM, Robert P. J. Day wrote:
>
> but should the man pages be updated similarly? i can whip up a patch
> for that unless someone wants to comment on this further.
Yes, please!
I think [] are the best, as they are pedantically correct.
[--options] is the worst, as ther
> * sb/diff-color-move-more (2018-05-21) 8 commits
> - diff: color-moved white space handling options imply color-moved
> - diff.c: add --color-moved-ignore-space-delta option
> - diff.c: decouple white space treatment from move detection algorithm
> - diff.c: add a blocks mode for moved code d
On 05/24, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > No automated test for this yet. As mentioned in the cover letter as
> > well, I'm not sure if this is common enough for us to actually
> > consider this use case. I don't know how nested conflicts could
> > actually be created apar
On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote:
> That doesn't work, because that's for the server-side, but I need the
> fetch.fsck.* that doesn't exist. This works (I'll send a better patch
> with tests / docs etc. soon):
Yeah, I think this is the right direction.
> +s
On 05/24, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > To fix this, remove the rerere ID from the MERGE_RR file in case we
> > can't handle it, and remove the folder for the ID. Removing it
> > unconditionally is fine here, because if the user would have resolved
> > the conflict and ra
On Thu, May 24, 2018 at 01:36:57PM +0200, Michal Hocko wrote:
> `git commit' fails on a newly added file with the following
> *
> * You have some suspicious patch lines:
> *
> * In Documentation/core-api/gfp_mask-from-fs-io.rst
> * unresolved merge conflict (line 27)
> Documentation/core-api/gfp_m
On Wed, May 23, 2018 at 11:27:33PM -0700, Elijah Newren wrote:
> Commits 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax",
> 2008-07-26) and 3dd4e7320d ("Teach rev-parse the ... syntax.", 2006-07-04)
> taught rev-parse new syntax, and used lookup_commit_reference() as part of
> thei
On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote:
> When I do:
>
> git -c fetch.fsckObjects=true clone
> g...@github.com:robbyrussell/oh-my-zsh.git
>
> I get:
>
> error: object 2b7227859263b6aabcc28355b0b994995b7148b6:
> zeroPaddedFilemode: contains zero-padded
On Thu, May 24 2018, Kevin Daudt wrote:
> On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> When I do:
>>
>> git -c fetch.fsckObjects=true clone
>> g...@github.com:robbyrussell/oh-my-zsh.git
>>
>> I get:
>>
>> error: object 2b7227859263b6aabcc28355b0b994995b7148
On Thu, May 24, 2018 at 3:05 AM, SZEDER Gábor wrote:
>> --- a/t/t6036-recursive-corner-cases.sh
>> +++ b/t/t6036-recursive-corner-cases.sh
>> @@ -65,9 +65,12 @@ test_expect_success 'merge simple rename+criss-cross with
>> no modifications' '
>>
>> test_must_fail git merge -s recursi
On 5/21/2018 2:53 PM, Jakub Narebski wrote:
+corrupt_data() {
+ file=$1
+ pos=$2
+ data="${3:-\0}"
+ printf "$data" | dd of="$file" bs=1 seek="$pos" conv=notrunc
+}
First, if we do this that way (and not by adding a test helper), the use
of this function should be, I thin
While iterating through the commit parents, perform the generation
number calculation and compare against the value stored in the
commit-graph.
The tests demonstrate that having a different set of parents affects
the generation number calculation, and this value propagates to
descendants. Hence, w
When writing commit-graph files, it can be convenient to ask for all
reachable commits (starting at the ref set) in the resulting file. This
is particularly helpful when writing to stdin is complicated, such as a
future integration with 'git gc' which will call
write_commit_graph_reachable() after
If core.commitGraph is true, verify the contents of the commit-graph
during 'git fsck' using the 'git commit-graph verify' subcommand. Run
this check on all alternates, as well.
We use a new process for two reasons:
1. The subcommand decouples the details of loading and verifying a
commit-grap
The commit-graph file has an extra chunk to store the parent int-ids for
parents beyond the first parent for octopus merges. Our test repo has a
single octopus merge that we can manipulate to demonstrate the 'verify'
subcommand detects incorrect values in that chunk.
Signed-off-by: Derrick Stolee
The commit-graph feature is now integrated with 'fsck' and 'gc',
so remove those items from the "Future Work" section of the
commit-graph design document.
Also remove the section on lazy-loading trees, as that was completed
in an earlier patch series.
Signed-off-by: Derrick Stolee
---
Documenta
The commit-graph file ends with a SHA1 hash of the previous contents. If
a commit-graph file has errors but the checksum hash is correct, then we
know that the problem is a bug in Git and not simply file corruption
after-the-fact.
Compute the checksum right away so it is the first error that appea
The GRAPH_MIN_SIZE macro should be the smallest size of a parsable
commit-graph file. However, the minimum number of chunks was wrong.
It is possible to write a commit-graph file with zero commits, and
that violates this macro's value.
Rewrite the macro, and use extra macros to better explain the
When lazy-loading a tree for a commit, it will be important to select
the tree from a specific struct commit_graph. Create a new method that
specifies the commit-graph file and use that in
get_commit_tree_in_graph().
Signed-off-by: Derrick Stolee
---
commit-graph.c | 12 +---
1 file chan
The commit-graph file requires the following three chunks:
* OID Fanout
* OID Lookup
* Commit Data
If any of these are missing, then the 'verify' subcommand should
report a failure. This includes the chunk IDs malformed or the
chunk count is truncated.
Signed-off-by: Derrick Stolee
---
commit-
In the 'verify' subcommand, load commits directly from the object
database to ensure they exist. Parse by skipping the commit-graph.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 20
t/t5318-commit-graph.sh | 7 +++
2 files changed, 27 insertions(+)
diff
The commit-graph file is a very helpful feature for speeding up git
operations. In order to make it more useful, write the commit-graph file
by default during standard garbage collection operations.
Add a 'gc.commitGraph' config setting that triggers writing a
commit-graph file after any non-trivi
In the commit-graph file, the OID fanout chunk provides an index into
the OID lookup. The 'verify' subcommand should find incorrect values
in the fanout.
Similarly, the 'verify' subcommand should find out-of-order values in
the OID lookup.
Signed-off-by: Derrick Stolee
---
commit-graph.c
Signed-off-by: Derrick Stolee
---
commit-graph.c | 6 ++
t/t5318-commit-graph.sh | 6 ++
2 files changed, 12 insertions(+)
diff --git a/commit-graph.c b/commit-graph.c
index ead92460c1..d2b291aca2 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -981,6 +981,12 @@ int verify_c
The commit-graph file stores parents in a two-column portion of the
commit data chunk. If there is only one parent, then the second column
stores 0x to indicate no second parent.
The 'verify' subcommand checks the parent list for the commit loaded
from the commit-graph and the one parsed f
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index 37420ae0fd..f0875b8bf3 100644
--- a/builtin/commit-graph.c
+++ b/builtin/commit-graph.c
@@ -51,8 +51,11 @@ static
The 'verify' subcommand must compare the commit content parsed from the
commit-graph and compare it against the content in the object database.
Use lookup_commit() and parse_commit_in_graph_one() to parse the commits
from the graph and compare against a commit that is loaded separately
and parsed d
Thanks for all the feedback on v2. I've tried to make this round's
review a bit easier by splitting up the commits into smaller pieces.
Also, the test script now has less boilerplate and uses variables and
clear arithmetic to explain which bytes are being modified.
One other change worth mentionin
If the commit-graph file becomes corrupt, we need a way to verify
that its contents match the object database. In the manner of
'git fsck' we will implement a 'git commit-graph verify' subcommand
to report all issues with the file.
Add the 'verify' subcommand to the 'commit-graph' builtin and its
Before verifying a commit-graph file against the object database, we
need to parse all commits from the given commit-graph file. Create
parse_commit_in_graph_one() to target a given struct commit_graph.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 18 +++---
1 file changed, 15
In anticipation of verifying commit-graph file contents against the
object database, create parse_commit_internal() to allow side-stepping
the commit-graph file and parse directly from the object database.
Due to the use of generation numbers, this method should not be called
unless the intention
This is the first of several commits that add a test to check that
'git commit-graph verify' catches corruption in the commit-graph
file. The first test checks that the command catches an error in
the file signature. This is a check that exists in the existing
commit-graph reading code.
Add a help
On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote:
> When I do:
>
> git -c fetch.fsckObjects=true clone
> g...@github.com:robbyrussell/oh-my-zsh.git
>
> I get:
>
> error: object 2b7227859263b6aabcc28355b0b994995b7148b6:
> zeroPaddedFilemode: contains zero-padded f
When I do:
git -c fetch.fsckObjects=true clone
g...@github.com:robbyrussell/oh-my-zsh.git
I get:
error: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode:
contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed
The docs (https://git-sc
On 05/24/2018 04:04 PM, Todd Zullinger wrote:
I added Florian to Cc, in case he wants to provide a
preferred address.
Sorry, using this address is fine.
Thanks,
Florian
On Thursday 17 May 2018 07:06 PM, Jeff King wrote:
> But because git-branch does not kick in the pager until later
> (because it only wants to do it for list-mode), that happens _after_
> we've emitted the message.
>
I observe exactly the consequence of this behaviour. First, the error
is emitted
> -Original Message-
> From: Junio C Hamano On Behalf Of Junio C Hamano
> Sent: Thursday, May 24, 2018 12:52 AM
> To: Jameson Miller
> Cc: git@vger.kernel.org; pclo...@gmail.com; jonathanta...@google.com;
> sbel...@google.com; peart...@gmail.com
> Subject: Re: [PATCH v3 2/7] block alloc
embarrassed to admit i had no idea that you could tag non-commit
objects, only realized that when i was reading the man page and saw:
SYNOPSIS
git tag [-a | -s | -u ] [-f] [-m | -F ] [-e]
[ | ]
so i tried it and, sure enough, i coul
> -Original Message-
> From: Junio C Hamano On Behalf Of Junio C Hamano
> Sent: Thursday, May 24, 2018 12:55 AM
> To: Jameson Miller
> Cc: git@vger.kernel.org; pclo...@gmail.com; jonathanta...@google.com;
> sbel...@google.com; peart...@gmail.com
> Subject: Re: [PATCH v3 0/7] allocate ca
[Added Florian to Cc]
Elijah Newren wrote:
> Commits 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax",
> 2008-07-26) and 3dd4e7320d ("Teach rev-parse the ... syntax.", 2006-07-04)
> taught rev-parse new syntax, and used lookup_commit_reference() as part of
> their logic. Neither us
maybe this is deliberate, but it's confusing that, with git 2.17.0,
the output of both "git log -h" and "git show -h" is exactly the same:
$ git log -h
usage: git log [] [] [[--] ...]
or: git show [] ...
-q, --quiet suppress diff output
--source show source
Hi,
Le 24/05/2018 à 13:49, Alban Gruin a écrit :
> Changes since v2:
- Removing `mark_action_done()` from git-rebase--interactive.sh
- Removing unused variables from git-rebase--interactive.sh
Cheers,
Alban
This duplicates git-rebase--interactive.sh to
git-rebase--preserve-merges.sh. This is done to split -p from -i. No
modifications are made to this file here, but any code that is not used by -p
will be stripped in the next commit.
Signed-off-by: Alban Gruin
---
.gitignore |
This removes the code coming from git-rebase--interactive.sh that is not needed
by preserve-merges.
Signed-off-by: Alban Gruin
---
git-rebase--preserve-merges.sh | 65 +++---
1 file changed, 4 insertions(+), 61 deletions(-)
diff --git a/git-rebase--preserve-m
This splits the `rebase --preserve-merges` functionnality from
git-rebase--interactive.sh. All the dead code left by the duplication of
git-rebase--interactive.sh is also removed. This will make it easier to rewrite
this script in C.
This patch series is based of js/sequencer-and-root-commits.
Ch
All the code specific to preserve-merges was moved to
git-rebase--preserve-merges.sh, and so it’s useless to keep it here.
Signed-off-by: Alban Gruin
---
git-rebase--interactive.sh | 802 +
1 file changed, 8 insertions(+), 794 deletions(-)
diff --git
Creates a new type of rebase, "preserve-merges", used when rebase is called with
-p.
Before that, the type for preserve-merges was "interactive", and some places of
this script compared $type to "interactive". Instead, the code now checks if
$interactive_rebase is empty or not, as it is set to "ex
more pedantry -- was digging through "man git-diff" and noticed the
inconsistency in how options are represented. first, in the synopsis,
you see "[options]":
SYNOPSIS
git diff [options] [] [--] [...]
git diff [options] --cached [] [--] [...]
git diff [options] [--] [...]
gi
Thomas Gummerer writes:
> To fix this, remove the rerere ID from the MERGE_RR file in case we
> can't handle it, and remove the folder for the ID. Removing it
> unconditionally is fine here, because if the user would have resolved
> the conflict and ran rerere, the entry would no longer be in th
Hi,
`git commit' fails on a newly added file with the following
*
* You have some suspicious patch lines:
*
* In Documentation/core-api/gfp_mask-from-fs-io.rst
* unresolved merge conflict (line 27)
Documentation/core-api/gfp_mask-from-fs-io.rst:27:===
$ git status --porcelain
A Documentation
1 - 100 of 112 matches
Mail list logo