On 6 August 2018 at 17:26, Jeff King wrote:
> I suspect it still has a bug, which is that it is handling this
> first-parent-goes-left case, but probably gets the straight-parent case
> wrong. But at least in this form, I think it is obvious to see where
> that bug is (the "thre
ted, it's only
> the index. It happends with git 2.18.0 and 2.17.0
Yeah this is a bug, I didn't dig much but testing with this script down
to 2.8.0:
#!/bin/sh
cd ~/g/git
make -j $(parallel --number-of-cores) USE_LIBPCRE2=YesPlease CFLAGS="-O0 -g
-ggdb3" DEVELOPER=1 DEVOPTS=no
Hi,
I've just had a scary error:
error: index uses $?+? extension, which we do not understand
fatal: index file corrupt
Things were quickly recovered by deleting the index but it clearly
looks to a but to me.
Here are the steps to reproduce it:
$ git clone
On Fri, Aug 31, 2018 at 2:39 PM Johannes Schindelin
wrote:
>
> Hi,
>
> On Thu, 30 Aug 2018, Stefan Beller wrote:
>
> > On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
> > >
> > > [...] Myers does not promise to find the absolute minimal diff. [...]
> >
> > The `Myers` (our default) diff
8,6 @@ int bitmap_has_sha1_in_uninteresting(struct bitmap_index
*bitmap_git,
if (!bitmap_git)
return 0; /* no bitmap loaded */
- if (!bitmap_git->result)
- BUG("failed to perform bitmap walk before querying");
if (!bitmap_git->
Hi,
On Thu, 30 Aug 2018, Stefan Beller wrote:
> On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
> >
> > [...] Myers does not promise to find the absolute minimal diff. [...]
>
> The `Myers` (our default) diff algorithm is really the Myers algorithm +
> a heuristic that cuts off the long tail
en I
> > > cut it down the problem went away.
> >
> > Oh, I had to look further down than I did initially. Now I can reproduce it
> > from the initial data as well.
> >
> > Note that it goes away with --minimal.
>
> That's interesting. I did wonder if thi
d out all the unimportant lines to
> > > remove.
> >
> > Yeah, I reproduced based on your initial post, but noticed that when I
> > cut it down the problem went away.
>
> Oh, I had to look further down than I did initially. Now I can reproduce it
> from the in
On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
>
> > > Could you cut down to a real minimal reproduction, i.e. just these 20
> > > lines or so?
> >
> > I'm working on getting down to a minimal reproduction, a few lines at
> >
On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> > Could you cut down to a real minimal reproduction, i.e. just these 20
> > lines or so?
>
> I'm working on getting down to a minimal reproduction, a few lines at
> a time. One thing that seems strange: as I've removed lines,
istogram seems to fix the issue. It
still occurs with --diff-algorithm=default. I also tried
--no-indent-heuristic, which had no effect.
> Are there any encoding issues locally (Which platform
> are you on?) or in transit (Could you re-download the files
> from [1] and confirm it still produc
On Sun, Aug 26, 2018 at 6:54 PM Gabriel Holodak wrote:
>
> I think I'm running into a bug with git diff on v2.18.0.
I cannot reproduce with the two files attached.
I suspected you might have a different diff algorithm configured,
so I tested
git diff --no-index old new
gi
I think I'm running into a bug with git diff on v2.18.0. When I diff
the attached files, part of the diff ends up looking like:
...
STARTCHAR U+00F0
ENCODING 240
SWIDTH 500 0
-DWIDTH 8 0
-BBX 7 12 1 0
-BITMAP
-12
-0C
-14
-22
-02
-3E
-42
-42
-82
-84
-84
-78
+DWIDTH 8 0
+BBX 8 12 0 0
+BITMAP
+1B
The logic for constructing the linked list of multi-pack-indexes
in the object store is incorrect. If the local object store has
a multi-pack-index, but an alternate does not, then the list is
dropped.
Add tests that would have revealed this bug.
Signed-off-by: Derrick Stolee
---
midx.c
ting 3rd party tools.
>
> I think we're talking past each other. I haven't proposed any blanket
> policy. I'm saying that "git bug" is a bad name for this tool:
>
> - it's hard to find with search engines
> - it conflicts with some likely good future changes to G
(+ git-dit authors)
Kyle Meyer wrote:
> Jonathan Nieder writes:
>> I believe you're thinking of TicGit[1].
>>
>> Some other related work is listed at [2]. Most of these projects have
>> gone quiet:
>>
>> - ditz[3]
>> - git-issues[4]
>> - cil[5]
>> - Bugs Everywhere[6]
>> - milli by Steve Kemp,
[+cc Stefan Monnier]
Jonathan Nieder writes:
> (cc-ing Scott)
[...]
> I believe you're thinking of TicGit[1].
>
> Some other related work is listed at [2]. Most of these projects have
> gone quiet:
>
> - ditz[3]
> - git-issues[4]
> - cil[5]
> - Bugs Everywhere[6]
> - milli by Steve Kemp,
base-without-touching-index-or-worktree that we can make accessible
to other scripts like git-bug. However, we have to have a pretty good
answer about what to do when we hit conflicts.
[1]
https://public-inbox.org/git/nycvar.qro.7.76.6.180616000...@tvgsbejvaqbjf.bet/
(cc-ing Scott)
Hi Junio,
Junio C Hamano wrote:
> Michael Muré writes:
>> I released today git-bug, a distributed bug tracker that embeds in
>> git. It use git's internal storage to store bugs information in a way
>> that can be merged without conflict. You can push/pull
e a workflow similar as what git does, to be
versatile and leave to the users the choice of the topology they want
to use. Obviously, it will be most of the time a single remote where
they collaborate.
As a bug tracker is a different workflow than regular code, there will
be some tooling to help.
Here was my reasoning for the naming choice:
- I need something meaningful
- I need something that encompass the idea and features of a bug
tracker because the narrower ideas and actions will be in sub commands
- other projects already used other words, in particular "issue"
- it kind
(cc-ing Elijah Newren for the points about merging)
Hi again,
To avoid the other thread shadowing more important things:
Michael Muré wrote:
> Someone suggested in the Hacker News thread [0] to post it here as well.
Thanks to Ævar for that.
[...]
> git-bug use as identifier th
Ævar Arnfjörð Bjarmason wrote:
> I'm just pointing out in the more general case that if someone comes up
> with a badly named git-xyz it doesn't scale to try to point this out to
> them before git-xyz is widely deployed.
>
> So we must either let it go (solution #1), or come up with some
>
t; without considering how widely used it is. It's us who
>> decided to expose the API of seamlessly integrating 3rd party tools.
>
> I think we're talking past each other. I haven't proposed any blanket
> policy. I'm saying that "git bug" is a bad name for this tool:
>
mlessly integrating 3rd party tools.
I think we're talking past each other. I haven't proposed any blanket
policy. I'm saying that "git bug" is a bad name for this tool:
- it's hard to find with search engines
- it conflicts with some likely good future changes to Git
- it a
On Sat, Aug 18 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Sat, Aug 18 2018, Jonathan Nieder wrote:
>>> Michael Muré wrote:
>
>>>> I released today git-bug, a distributed bug tracker
> [...]
>>> I am a bit u
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 18 2018, Jonathan Nieder wrote:
>> Michael Muré wrote:
>>> I released today git-bug, a distributed bug tracker
[...]
>> I am a bit unhappy about the namespace grab. Not for trademark
>> reasons: the Git trademar
Michael Muré writes:
> I released today git-bug, a distributed bug tracker that embeds in
> git. It use git's internal storage to store bugs information in a way
> that can be merged without conflict. You can push/pull to the normal
> git remote you are already using to interac
On Sat, Aug 18 2018, Jonathan Nieder wrote:
> Hi,
>
> Michael Muré wrote:
>
>> I released today git-bug, a distributed bug tracker that embeds in
>> git. It use git's internal storage to store bugs information in a way
>> that can be merged without conflict. Y
Hi,
Michael Muré wrote:
> I released today git-bug, a distributed bug tracker that embeds in
> git. It use git's internal storage to store bugs information in a way
> that can be merged without conflict. You can push/pull to the normal
> git remote you are already using to interac
I really like this idea. I've often wanted an integrated bug database like
this. My solution has always been to have a subrepo storing bug reports and
coments in .txt files and then using bash porcelain scripts to make a git-like
interface. I think I like this better. My only nit is Go
Hi everyone,
I released today git-bug, a distributed bug tracker that embeds in
git. It use git's internal storage to store bugs information in a way
that can be merged without conflict. You can push/pull to the normal
git remote you are already using to interact with other people. Normal
code
If I set
git config --global submodule.recurse true
and run git via:
git pull --progress -v --no-rebase "origin"
The command will fail with following output (Errorlevel is 1)
Fetching submodule submodules/tstemplates
From http://10.0.102.194:7990/scm/mcc/tstemplates
Hi,
On Mon, Aug 13, 2018 at 5:26 AM Dániel Vörös wrote:
> Hey All,
>
> I'm seeing some weird behavior when doing interactive rebase of a
> single commit with reword if there's a conflict. The rebased commit
> gets "squashed" into the target commit and is not a child of that.
This was previously
Hey All,
I'm seeing some weird behavior when doing interactive rebase of a
single commit with reword if there's a conflict. The rebased commit
gets "squashed" into the target commit and is not a child of that.
I've asked this question in the git-users group first a few weeks ago,
but got no
Hi Philip
Thanks for CC'ing me Peff.
On 10/08/18 19:27, Jeff King wrote:
On Thu, Aug 09, 2018 at 08:17:36PM -0700, Philip White wrote:
I’d like to report what I suspect is a bug in Git, tested in 2.18 and
2.14. (I’d be delighted to be corrected if it is my own
misunderstanding.) I’m
On Thu, Aug 09, 2018 at 08:17:36PM -0700, Philip White wrote:
> I’d like to report what I suspect is a bug in Git, tested in 2.18 and
> 2.14. (I’d be delighted to be corrected if it is my own
> misunderstanding.) I’m reporting it here based on guidance from
> https://git-scm.com/commu
Hello, git enthusiasts,
I’d like to report what I suspect is a bug in Git, tested in 2.18 and 2.14.
(I’d be delighted to be corrected if it is my own misunderstanding.) I’m
reporting it here based on guidance from https://git-scm.com/community.
I created a minimal testcase with a detailed
On Tue, Aug 7, 2018 at 5:09 AM Eric Sunshine wrote:
> On Mon, Aug 6, 2018 at 9:15 AM Johannes Schindelin
> wrote:
> > I think Andrei's assessment is wrong. The code could not test for that
> > earlier, as it did allow ranges to become "abutting" in the process, by
> > failing to merge them. So
On Mon, Aug 6, 2018 at 9:15 AM Johannes Schindelin
wrote:
> On Sun, 5 Aug 2018, Eric Sunshine wrote:
> > Although this appears to be a faithful translation of the assert() to
> > BUG(), as mentioned by Andrei in his review of 3/4, the existing
> > assert() seems to have an
On Mon, Aug 06, 2018 at 02:34:45PM -0400, Noam Postavsky wrote:
> On 30 June 2018 at 08:47, Noam Postavsky
> wrote:
>
> > I'm still having trouble getting a big picture understanding of how
> > the graph struct relates the what gets drawn on screen, but through
> > some poking around with the
return 2 * (last_col - first_col + 1);
}
static void graph_output_commit_line(struct git_graph *graph, struct strbuf
*sb)
I suspect it still has a bug, which is that it is handling this
first-parent-goes-left case, but probably gets the straight-parent case
wrong. But at least in this form, I thi
On 30 June 2018 at 08:47, Noam Postavsky wrote:
> I'm still having trouble getting a big picture understanding of how
> the graph struct relates the what gets drawn on screen, but through
> some poking around with the debugger + trial & error, I've arrived at
> a new patch which seems to work.
On Mon, Aug 06, 2018 at 06:07:06PM +0200, SZEDER Gábor wrote:
> 'git ls-files' has the options '--exclude', '--exclude-from',
> '--exclude-per-directory', and '--exclude-standard', which all work
> fine. However, it also allows the negated version of all these four
> options, and they definitely
'git ls-files' has the options '--exclude', '--exclude-from',
'--exclude-per-directory', and '--exclude-standard', which all work
fine. However, it also allows the negated version of all these four
options, and they definitely don't work very well:
$ git ls-files --no-exclude
Segmentation
Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>> It is really, really important to realize how valuable it is to have the
>> regression test as an individual patch that can be used to verify that
>> there is a bug, to pinpoint where it was introduced, to test alternat
Hi Dscho,
Johannes Schindelin wrote:
> On Sat, 4 Aug 2018, Jonathan Nieder wrote:
>> Alternatively, could it be squashed in with the patch that fixes it?
>
> There is this really awful trend on this mailing list to suggest
> conflating the demonstration of a bu
Hi Eric,
On Sun, 5 Aug 2018, Eric Sunshine wrote:
> On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget
> wrote:
> > The assertion in question really indicates a bug, when triggered, so we
> > might just as well use the sanctioned method to report it.
ell as
to segmentation faults. This test case demonstrates this.
> Alternatively, could it be squashed in with the patch that fixes it?
There is this really awful trend on this mailing list to suggest
conflating the demonstration of a bug with the bug fix.
It is really, really important to re
On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget
wrote:
> The assertion in question really indicates a bug, when triggered, so we
> might just as well use the sanctioned method to report it.
>
> Signed-off-by: Johannes Schindelin
> ---
> diff --git a/line-
Hi,
Johannes Schindelin wrote:
> Currently, this test case throws an assertion:
>
> Assertion failed!
>
> Program: git.exe
> File: line-log.c, Line 71
>
> Signed-off-by: Johannes Schindelin
> ---
> t/t4211-line-log.sh | 17 +
> 1 file changed, 17 insertions(+)
From: Johannes Schindelin
Currently, this test case throws an assertion:
Assertion failed!
Program: git.exe
File: line-log.c, Line 71
Signed-off-by: Johannes Schindelin
---
t/t4211-line-log.sh | 17 +
1 file changed, 17 insertions(+)
diff --git
From: Johannes Schindelin
The assertion in question really indicates a bug, when triggered, so we
might just as well use the sanctioned method to report it.
Signed-off-by: Johannes Schindelin
---
line-log.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/line-log.c b
quot;Version 1.0.${i}" -a 1.0.${i}
> for j in `seq 1 10`; do
> echo ${i}-${j} >> ${FILE}
> git add ${FILE}
> git commit -m "Update number ${i}-${j} to ${FILE}"
> done
> done
> ```
Yeah this is a documentation b
The documentation for the "git describe --abbrev" flag says that the
default value is 7 hexadecimal digits:
https://github.com/git/git/blob/master/Documentation/git-describe.txt#L63
and
https://git-scm.com/docs/git-describe
I have experienced that sometimes I see 7 digits, but other times more.
On 07/29, Jeff King wrote:
> I've noticed for the past couple of weeks that some of my fetches don't
> seem to actually update refs, but a follow-up fetch will. I finally
> managed to catch it in the act and track it down. It bisects to your
> 989b8c4452 (fetch-pack: put shallow info in output
I discovered it was an issue with the version of Git for Windows I was
using. Upgraded to the latest version and it works now.
--
Best regards,
Jeremy Morton (Jez)
On 30/07/2018 16:37, Jeff King wrote:
On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote:
I'm trying to search my
Am 30.07.2018 um 14:49 schrieb Jeremy Morton:
> I'm trying to search my git log history for a particular term - "unobtrusive"
> - so I run this command:
>
> git log -S unobtrusive --oneline
>
> When I do this, this is displayed and I'm in an interactive less terminal or
> something:
>
>
On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote:
> I'm trying to search my git log history for a particular term -
> "unobtrusive" - so I run this command:
>
> git log -S unobtrusive --oneline
>
> When I do this, this is displayed and I'm in an interactive less terminal or
>
I'm trying to search my git log history for a particular term -
"unobtrusive" - so I run this command:
git log -S unobtrusive --oneline
When I do this, this is displayed and I'm in an interactive less
terminal or something:
pdftotext version 4.00
Copyright 1996-2017 Glyph & Cog, LLC
Usage:
I've noticed for the past couple of weeks that some of my fetches don't
seem to actually update refs, but a follow-up fetch will. I finally
managed to catch it in the act and track it down. It bisects to your
989b8c4452 (fetch-pack: put shallow info in output parameter,
2018-06-27).
A
ttps://public-inbox.org/git/CA+55aFzLZ3UkG5svqZwSnhNk75=fxjrkvu1m_rhbg54nooa...@mail.gmail.com/
I don't want to regress the bug Linus reported, so to fix Ben's issue,
when we detect that a path's contents/mode won't be modified by the
merge, we can either:
- Update the working tree file if the original cache entry
e doesn't change them: very
desirable[1]
- Doing both: whoops
[1]
https://public-inbox.org/git/CA+55aFzLZ3UkG5svqZwSnhNk75=fxjrkvu1m_rhbg54nooa...@mail.gmail.com/
I don't want to regress the bug Linus reported, so to fix Ben's issue,
when we detect that a path's contents/mode won't be modified by
Elijah Newren writes:
> Ah, okay, that's helpful. So, if there are conflicts, it should be
> free to clear the skip_worktree flag. Since merge-recursive calls
> add_cacheinfo() for all entries it needs to update, which deletes the
> old cache entry and just makes new ones, we get that for
On Fri, Jul 20, 2018 at 2:13 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> But that brings up another interesting question. What if a merge
>> *does* modify a file for which you have skip-worktree set?
>> Previously, it'd clear the bit and write the file to the working tree,
>> but
Elijah Newren writes:
> But that brings up another interesting question. What if a merge
> *does* modify a file for which you have skip-worktree set?
> Previously, it'd clear the bit and write the file to the working tree,
> but that was by no means an explicit decision;
At least in my mind,
> is what exposed the bug.
Indeed, I've never used sparse checkout before. And I've got
questions related to it below...
> What is happening is that in merge_recursive, the skip-worktree bit is
> cleared on the cache entry but then the working directory isn't updated.
> The end resul
seq 1 100 >one
echo 99 > two
seq 1 2 98 >>two
git diff --no-index --histogram one two
In addition to the recent patches[1], I found another bug in the
histogram algorithm,
which can be produced with the instructions given above. At least I
think it is a bug as
the diff lo
As we were attempting to migrate to 2.18 some of our internal functional
tests failed. The tests that failed were testing merge and cherry-pick
when there was a merge conflict. Our tests run with sparse-checkout
enabled which is what exposed the bug.
What is happening
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
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
Jeff King writes:
> So I feel like the right answer here is probably this:
>
> diff --git a/wt-status.c b/wt-status.c
> index d1c05145a4..5fcaa3d0f8 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -2340,7 +2340,16 @@ int has_uncommitted_changes(int ignore_submodules)
> if
ead_to_pending() in has_uncommitted_change()
does not add anything to the "pending" list because HEAD is broken.
I think if we make add_head_to_pending() return a boolean, then we can
check that if no HEAD is added, there's no point to run_diff_index and
has_uncommitted_changes() can return 0 i
On Wed, Jul 11, 2018 at 01:00:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
> This segfaults, but should print an error instead, have a repo with a
> corrupt HEAD:
>
> (
> rm -rf /tmp/git &&
> git clone --single-branch --branch todo g...@github.com:git/git.git
> /tmp/git &&
>
This segfaults, but should print an error instead, have a repo with a
corrupt HEAD:
(
rm -rf /tmp/git &&
git clone --single-branch --branch todo g...@github.com:git/git.git
/tmp/git &&
echo
>/tmp/git/.git/refs/heads/todo &&
When cherry-picking a single commit, we go through a special
code path that avoids creating a sequencer todo list at all.
This path expects our revision parsing to turn up exactly
one commit, and dies with a BUG if it doesn't.
But it's actually quite easy to fool. For example:
$ git cherry
sions(struct replay_opts *opts)
> > return error(_("revision walk setup failed"));
> > cmit = get_revision(opts->revs);
> > if (!cmit || get_revision(opts->revs))
> > - return error("BUG: expected exactly one commit
+the public git mailing list, git-secur...@googlegroups.com -> bcc
Hi,
Lin Terry wrote:
> I can do past and feature commits. It is a bug?
>
> Check out my gitgub page.
> https://github.com/terrylinooo
>
> You can see a LOVE, they are past commits I commited yesterday
er_pick_revisions(struct replay_opts *opts)
>> return error(_("revision walk setup failed"));
>> cmit = get_revision(opts->revs);
>> if (!cmit || get_revision(opts->revs))
>> -return error("BUG: exp
error(_("revision walk setup failed"));
> cmit = get_revision(opts->revs);
> if (!cmit || get_revision(opts->revs))
> - return error("BUG: expected exactly one commit from
> walk");
> +
When cherry-picking a single commit, we go through a special
code path that avoids creating a sequencer todo list at all.
This path expects our revision parsing to turn up exactly
one commit, and dies with a BUG if it doesn't.
But it's actually quite easy to fool. For example:
$ git cherry
ve had to do this before,
I usually just cherry-pick and then follow-up with "commit --amend
--author" (or use "rebase -i" if there are several commits). You can
also do "cherry-pick -n $commit" followed by "commit -c $commit".
> All commits in tests existed
Hi,
I was trying to cherry pick commits, while simultaneously changing the
author. Unfortunately, cherry-pick doesn't have the same --author
option as git-commit. However, instead of complaining about unknown
option:
- when trying to cherry-pick one commit, it reported a BUG
- when trying
On 25 June 2018 at 12:23, Jeff King wrote:
> These diagrams confused me for a minute, because I see two differences:
>
> 1. The first one has an extra apparently unrelated parallel branch on
> the far left.
>
> 2. The first has the first-parent of the "*" merge commit immediately
>
f it, that's already sort-of an issue now. If you have a
> case-insensitive filesystem, then EXT:: is going to pass this check, but
> still run git-remote-ext. We're saved there somewhat by the fact that
> the default is to reject unknown helpers in submodules (otherwise, we'd
> have that
ill run git-remote-ext. We're saved there somewhat by the fact that
the default is to reject unknown helpers in submodules (otherwise, we'd
have that horrible submodule bug all over again).
That goes beyond just cases, too. On HFS+ I wonder if I could ask for
"\u{0200}ext::" and run git-remo
Jeff King writes:
>> > We seem to match url schemes case-sensitively:
>> >
>> > $ git clone SSH://example.com/repo.git
>> > Cloning into 'repo'...
>> > fatal: Unable to find remote helper for 'SSH'
>> >
>> > whereas rfc3986 is clear that the scheme portion is case-insensitive.
>> > We
On Mon, Jun 25, 2018 at 11:19:51AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > We seem to match url schemes case-sensitively:
> >
> > $ git clone SSH://example.com/repo.git
> > Cloning into 'repo'...
> > fatal: Unable to find remote helper for 'SSH'
> >
> > whereas rfc3986 is
Jeff King writes:
> We seem to match url schemes case-sensitively:
>
> $ git clone SSH://example.com/repo.git
> Cloning into 'repo'...
> fatal: Unable to find remote helper for 'SSH'
>
> whereas rfc3986 is clear that the scheme portion is case-insensitive.
> We probably ought to match at
On Sat, Jun 23, 2018 at 05:45:19PM -0400, Noam Postavsky wrote:
> On 20 May 2016 at 18:12, Noam Postavsky
> wrote:
My, this is a blast from the past. :)
> Subject: [PATCH v1] log: Fix coloring of certain octupus merge shapes
>
> For octopus merges where the first parent edge immediately
We seem to match url schemes case-sensitively:
$ git clone SSH://example.com/repo.git
Cloning into 'repo'...
fatal: Unable to find remote helper for 'SSH'
whereas rfc3986 is clear that the scheme portion is case-insensitive.
We probably ought to match at least our internal ones with
Archive link to previous discussion:
https://marc.info/?l=git=146331754420554=2
On 20 May 2016 at 18:12, Noam Postavsky wrote:
> Looking at the coloured output, for some octopus merges where the
> first parent edge immediately merges into the next column to the left,
> col_num should be
Hi,
I have a setup with tree of 250+ git repositories. Every now and then, I
want to clean everything except for files generated by my IDE. So for all
the git repos, I run git clean -dfx --exclude . What happens
then is, if a sub-git as that file, all its files are deleted (except for
that ide
shed onto.
>
> Hmm, is that something which other tests don't cover or an
> issue that could affect 'rebase -i --root' with reword
> differently than other 'rebase -i' commands?
>
> I admit I'm not well-versed in the rebase -i tests and I
> focused only on creat
--root' with reword
differently than other 'rebase -i' commands?
I admit I'm not well-versed in the rebase -i tests and I
focused only on creating a test which demonstrated the bug I
noticed.
--
Todd
~~
The average woman would rather be beautiful than smart because the
average man can see better than he can think.
Hi Todd/Johannes
On 15/06/18 05:31, Johannes Schindelin via GitGitGadget wrote:
>
> From: Todd Zullinger
>
> When splitting a repository, running `git rebase -i --root` to reword
> the initial commit, Git dies with
>
> BUG: sequencer.c:795: root commit without mes
On Sat, Jun 16, 2018 at 12:08 PM Elijah Newren wrote:
> Subject: [PATCH] sequencer: do not squash 'reword' commits when we hit
> conflicts
> [...]
> Signed-off-by: Elijah Newren
> ---
> diff --git a/t/t3423-rebase-reword.sh b/t/t3423-rebase-reword.sh
> @@ -0,0 +1,44 @@
> +test_expect_success
From: Todd Zullinger
When splitting a repository, running `git rebase -i --root` to reword
the initial commit, Git dies with
BUG: sequencer.c:795: root commit without message.
Signed-off-by: Todd Zullinger
Signed-off-by: Johannes Schindelin
---
t/t3404-rebase-interactive.sh | 9
On Mon, Jun 11, 2018 at 06:06:11PM +0200, ch wrote:
> During a recent rebase operation on one of my repositories a number of commits
> unexpectedly ended up getting squashed into other commits. After some
> experiments it turned out that the 'reword' instruction seems to squash the
> referenced
On 12.06.2018 12:08, Jeff King wrote:
> Thanks for a thorough report. I couldn't reproduce it on v2.17.1 on
> Linux, which makes me wonder if the issue is related to git-for-windows
> somehow. To the best of my knowledge (and a quick scan of "git diff"
> results) the code should be the same,
201 - 300 of 4422 matches
Mail list logo
