POSIX rm(1) accepts both -r and -R, so we accept -R here by analogy
with that and with commands like cp(1) + ls(1) + grep(1), where on
many or all platforms it’s the only way to recurse. For completeness
with GNU coreutils, we also accept --recursive here.
5c387428f10c2 introduces a mechanism
I agree that the code locally was simple enough.
Ultimately I feel that sanitizing and uniqueifying the label should
probably be done closer together/at the same place. I'm just not
familiar enough with the codebase to know a good place (if any) to move
that to. Eventually though this would stil
Johannes Schindelin writes:
> If you care deeply about double dashes and leading dashes, how about
> this instead?
>
> char *from, *to;
>
> for (from = to = label.buf; *from; from++)
> if ((*from & 0x80) || isalnum(*from))
>
Johannes Schindelin writes:
>> I'm sightly concerned that this opens the possibility for unexpected effects
>> if two different labels get sanitized to the same string. I suspect it's
>> unlikely to happen in practice but doing something like percent encoding
>> non-alphanumeric characters would
Hi Junio,
On Mon, 2 Sep 2019, Junio C Hamano wrote:
> Phillip Wood writes:
>
> >>for (p1 = label.buf; *p1; p1++)
> >> - if (isspace(*p1))
> >> + if (!(*p1 & 0x80) && !isalnum(*p1))
> >>*(char *)p1 = '-';
> >
> > I'm sightl
On 02/09/2019 22:47, Matt Rogers wrote:
I can redo the commit, I had thought that I had previously fixed the
author but I guess I was mistaken.
As for issues with non utf-8 encodings, I don't know of any simple way
to check for those except for restricting to asci alphanumeric characters
If
On 02/09/2019 19:29, Junio C Hamano wrote:
I see there are "lets make sure it is unique by suffixing "-%d" in
other codepaths; would that help if this piece of code yields a
label that is not unique?
maybe use a trailing 4 characters of the oid to get a reasonably unique
label?
Oh, just seen
On 2019-09-02 at 18:29:56, Junio C Hamano wrote:
> Phillip Wood writes:
>
> > Being picking I'll point out that ':' is not a valid in refs
> > either. Looking at
> > https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file I
> > think only " and | are not allowed on NTFS/FAT but are va
Hi Phillip,
On Mon, 2 Sep 2019, Phillip Wood wrote:
> This is definitely worth fixing, I've got a couple of comments below
>
> On 02/09/2019 15:01, Matt R via GitGitGadget wrote:
> > From: Matt R
I just noticed that the surname is abbreviated. The full name of the
au
Phillip Wood writes:
> Being picking I'll point out that ':' is not a valid in refs
> either. Looking at
> https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file I
> think only " and | are not allowed on NTFS/FAT but are valid in refs
> (see the man page for git check-ref-format for
Hi Matt
This is definitely worth fixing, I've got a couple of comments below
On 02/09/2019 15:01, Matt R via GitGitGadget wrote:
From: Matt R
The `label` todo command in interactive rebases creates temporary refs
in the `refs/rewritten/` namespace. These refs are stored as loose refs
From: Matt R
The `label` todo command in interactive rebases creates temporary refs
in the `refs/rewritten/` namespace. These refs are stored as loose refs,
i.e. as files in `.git/refs/rewritten/`, therefore they have to conform
with file name limitations on the current filesystem.
This poses a
only demonstrates that this works, but
also that `git rebase -r` works with merge strategies now.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 7 +--
sequencer.c | 4 +++-
sequencer.h | 6 ++
t/t3427-rebase-subtree.sh | 11 +++
4
if (argc < 1) {
struct branch *branch;
diff --git a/sequencer.c b/sequencer.c
index 334de14542..d228448cd8 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3256,6 +3256,9 @@ static int do_merge(struct repository *r,
struct commit *head_commit, *merge_commit, *
ebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -120,6 +120,20 @@ test_expect_success REBASE_P 'rebase passes merge strategy
options correctly' '
git rebase --continue
'
+test_expect_success 'rebase -r passes merge strategy options correctly
accommodate for the `rebase --merge` backend having been
replaced
t3427: fix another incorrect assumption
rebase -r: support merge strategies other than `recursive`
t/lib-rebase: prepare for testing `git rebase --rebase-merges`
t3418: test `rebase -r` with merge strategies
rebase -r: do no
On 2019-07-25 at 10:11:14, Johannes Schindelin via GitGitGadget wrote:
> This is the most notable shortcoming that --rebase-merges has, still,
> relative to --preserve-merges' capabilities: it does not support passing
> custom merge strategies or custom merge strategy options.
>
> Let's fix this.
; https://github.com/gitgitgadget/git/releases/tag/pr-294%2Fdscho%2Frebase-r-with-strategies-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git
> pr-294/dscho/rebase-r-with-strategies-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/294
if (argc < 1) {
struct branch *branch;
diff --git a/sequencer.c b/sequencer.c
index 334de14542..d228448cd8 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3256,6 +3256,9 @@ static int do_merge(struct repository *r,
struct commit *head_commit, *merge_commit, *
only demonstrates that this works, but
also that `git rebase -r` works with merge strategies now.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 7 +--
sequencer.c | 4 +++-
sequencer.h | 6 ++
t/t3427-rebase-subtree.sh | 11 +++
4
ebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -120,6 +120,20 @@ test_expect_success REBASE_P 'rebase passes merge strategy
options correctly' '
git rebase --continue
'
+test_expect_success 'rebase -r passes merge strategy options correctly
accommodate for the `rebase --merge` backend having been
replaced
t3427: fix another incorrect assumption
t3427: mark two test cases as requiring support for `git rebase -p`
rebase -r: support merge strategies other than `recursive`
t/lib-rebase: prepare for testing `git rebase --rebase-m
ent HEAD is "B", and call
-
-$ git rebase -i -p --onto Q O
+$ git rebase -i -r --onto Q O
-
Reordering and editing commits usually creates untested intermediate
--
gitgitgadget
Johannes Schindelin writes:
> I think this one fell through the cracks (at least I failed to find it in
> `pu`),
Thanks, I think I was waiting for an Ack or two, but then the thread
was buried.
e suggested.
>
> Range-diff:
> 1: 0532b70644 ! 1: 738799241a rebase -r: always reword merge -c
> @@ -40,9 +40,12 @@
>
> +test_expect_success 'fast-forward merge -c still rewords' '
> + git checkout -b fast-forward-merge-c H &&
> -+ set_fake
Hi Phillip,
On Thu, 2 May 2019, Phillip Wood wrote:
> From: Phillip Wood
>
> If a merge can be fast-forwarded then make sure that we still edit the
> commit message if the user specifies -c. The implementation follows the
> same pattern that is used for ordinary rewords that are fast-forwarded.
comments on v1, I've changed the test as he suggested.
Range-diff:
1: 0532b70644 ! 1: 738799241a rebase -r: always reword merge -c
@@ -40,9 +40,12 @@
+test_expect_success 'fast-forward merge -c still rewords' '
+ git checkout -b fast-forward-merge-c H &&
Hi Phillip,
On Tue, 30 Apr 2019, Phillip Wood wrote:
> On 29/04/2019 17:14, Johannes Schindelin wrote:
> > Hi Phillip,
> >
> > On Fri, 26 Apr 2019, Phillip Wood wrote:
> >
> > > ret = !!run_git_commit(r, git_path_merge_msg(r), opts,
> > >
..ff8565e7a8 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3248,6 +3248,10 @@ static int do_merge(struct repository *r,
rollback_lock_file(&lock);
ret = fast_forward_to(r, &commit->object.oid,
&head_commit->o
44
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3248,6 +3248,10 @@ static int do_merge(struct repository *r,
> rollback_lock_file(&lock);
> ret = fast_forward_to(r, &commit->object.oid,
> &head_commit->obj
| 5 +
t/t3430-rebase-merges.sh | 10 ++
2 files changed, 15 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 0db410d590..ff8565e7a8 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3248,6 +3248,10 @@ static int do_merge(struct repository *r,
rollback_lock_file
In df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13), I obviously
made the assumption that calling uname -r in MSYS2 would always yield a
version number starting with "2".
That is incorrect, though, as uname -r reports the version of the Cygwin
runtime on which the current MSY
)
diff_opt_relative),
OPT_BOOL('a', "text", &options->flags.text,
N_("treat all files as text")),
+ OPT_BOOL('R', NULL, &options->flags.reverse_diff,
+
)
diff_opt_relative),
OPT_BOOL('a', "text", &options->flags.text,
N_("treat all files as text")),
+ OPT_BOOL('R', NULL, &options->flags.reverse_diff,
+
Johannes Schindelin writes:
> You misunderstand. In this case it is crucial to read the regression test
> first. The fix does not make much sense before one understands the
> condition under which the order of the code statements matters.
I am not sure what you mean. It sounds as if you want to
"am"ing everything and then "diff |
> >> apply -R" the part outside t/ for the same purpose) is easy enough.
> >
> > I disagree. It helps both development and porting to different branches to
> > be able to cherry-pick the regression test individually. P
Johannes Schindelin writes:
>> For a trivially small change/fix like this, it is OK and even
>> preferrable to make 1+2 a single step, as applying t/ part only to
>> try to see the breakage (or "am"ing everything and then "diff |
>> apply -R" the p
s.sh | 16
> > 1 file changed, 16 insertions(+)
>
> For a trivially small change/fix like this, it is OK and even
> preferrable to make 1+2 a single step, as applying t/ part only to
> try to see the breakage (or "am"ing everything and then "diff |
ferrable to make 1+2 a single step, as applying t/ part only to
try to see the breakage (or "am"ing everything and then "diff |
apply -R" the part outside t/ for the same purpose) is easy enough.
Because the patch 2 with your method ends up showing only the test
set-up part in t
From: Johannes Schindelin
When we detect that a `merge` can be skipped because the merged commit
is already an ancestor of HEAD, we do not need to commit, therefore
writing the MERGE_HEAD file is useless.
It is actually worse than useless: a subsequent `git commit` will pick
it up and think that
test_commit H2 &&
+
+ git checkout -b conflicts-in-merge H &&
+ test_commit H2 H2.t conflicts H2-conflict &&
+ test_must_fail git rebase -r already-has-g &&
+ grep conflicts H2.t &&
+ echo resolved >H2.t &&
I often use "grep -r $pattern" to recursively grep a source tree. If
that takes too long, I hit ^C and tag "git" in front of the command
line and re-run it. git then complains "error: unknown switch `r'"
because "git grep" is naturally recursive.
Co
The current naming convention for 'struct repository *' is 'r' for
temporary variables or arguments. I did not notice this. Since we're
updating blame.c again in the next patch, let's fix this.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Jun
Nguyễn Thái Ngọc Duy writes:
> The current naming convention for 'struct repository *' is 'r' for
> temporary variables or arguments. I did not notice this. Since we're
> updating blame.c again in the next patch, let's fix this.
It is likely that
The current naming convention for 'struct repository *' is 'r' for
temporary variables or arguments. I did not notice this. Since we're
updating blame.c again in the next patch, let's fix this.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
blame.c | 36 ++
The current naming convention for 'struct repository *' is 'r' for
temporary variables or arguments. I did not notice this. Since we're
updating blame.c again in the next patch, let's fix this.
---
blame.c | 36 ++--
1 file changed,
The current naming convention for 'struct repository *' is 'r' for
temporary variables or arguments. I did not notice this. Since we're
updating blame.c again in the next patch, let's fix this.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
blame.c | 36 ++
From: Johannes Schindelin
The --exec option's implementation is not really well-prepared for
--rebase-merges. Demonstrate this.
Signed-off-by: Johannes Schindelin
---
t/t3430-rebase-merges.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3430-rebase-merges.sh b/t/t3
From: Johannes Schindelin
The --exec option's implementation is not really well-prepared for
--rebase-merges. Demonstrate this.
Signed-off-by: Johannes Schindelin
---
t/t3430-rebase-merges.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3430-rebase-merges.sh b/t/t3
From: Johannes Schindelin
The --exec option's implementation is not really well-prepared for
--rebase-merges. Demonstrate this.
Signed-off-by: Johannes Schindelin
---
t/t3430-rebase-merges.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3430-rebase-merges.sh b/t/t3
+++ b/builtin/replace.c
@@ -57,9 +57,8 @@ static int show_reference(struct repository *r, const char
*refname,
if (get_oid(refname, &object))
return error("Failed to resolve '%s' as a valid
ref.", refname);
-
Johannes Sixt writes:
> Am 12.07.2018 um 18:26 schrieb Junio C Hamano:
>> Johannes Schindelin writes:
>>> A much more meaningful measure would be: how many octopus merge commits
>>> have been pushed to GitHub in the past two weeks. I don't think I have the
>>> technical means to answer that ques
Am 12.07.2018 um 18:26 schrieb Junio C Hamano:
Johannes Schindelin writes:
A much more meaningful measure would be: how many octopus merge commits
have been pushed to GitHub in the past two weeks. I don't think I have the
technical means to answer that question, though.
It does not mean that
Johannes Schindelin writes:
> Git is used in *so many* different scenarios, and both in terms of
> commits/day as well as overall repository size *and* development speed,
That misses another important factor, though. How well the project
uses the tool, iow, how canonical should its way of using
Hi Stefan,
On Wed, 11 Jul 2018, Stefan Beller wrote:
> On Wed, Jul 11, 2018 at 10:35 AM Junio C Hamano wrote:
> > To be honest, I am not sure if there still are people who use
> > octopus
>
> The latest merge with more than 2 parents in linux.git is df958569dbaa
> (Merge branches 'acpi-tables'
Hi Junio,
On Wed, 11 Jul 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > The `--rebase-merges` option of `git rebase` generates todo lists that
> > include the merge commits that are to be rebased.
> >
> > To keep things simpler to review, I decided to suppo
On Wed, Jul 11, 2018 at 10:35 AM Junio C Hamano wrote:
> To be honest, I am not sure if there still are people who use
> octopus
The latest merge with more than 2 parents in linux.git is
df958569dbaa (Merge branches 'acpi-tables' and 'acpica', 2018-07-05),
although looking through the log of octo
"Johannes Schindelin via GitGitGadget"
writes:
> The `--rebase-merges` option of `git rebase` generates todo lists that
> include the merge commits that are to be rebased.
>
> To keep things simpler to review, I decided to support only regular, 2-parent
> merge commits first.
>
> With this patc
The `--rebase-merges` option of `git rebase` generates todo lists that include
the merge commits that are to be rebased.
To keep things simpler to review, I decided to support only regular, 2-parent
merge commits first.
With this patch series, support is extended to cover also octopus merges.
On Tue, 10 Oct 2017, Heiko Voigt wrote:
> On Sun, Oct 08, 2017 at 07:56:20AM -0400, Robert P. J. Day wrote:
> > but as i asked in my earlier post, if i wanted to remove *all* files
> > with names of "Makefile*", why can't i use:
> >
> > $ git rm 'Makefile*'
> >
> > just as i used:
> >
> > $
On Tue, 10 Oct 2017, Paul Smith wrote:
> On Tue, 2017-10-10 at 04:36 -0400, Robert P. J. Day wrote:
> > ah, now *that* is a compelling rationale that justifies the
> > underlying weirdness. but it still doesn't explain the different
> > behaviour between:
> >
> > $ git rm -n 'Makefile*'
> >
On Tue, 2017-10-10 at 04:36 -0400, Robert P. J. Day wrote:
> ah, now *that* is a compelling rationale that justifies the
> underlying weirdness. but it still doesn't explain the different
> behaviour between:
>
> $ git rm -n 'Makefile*'
> $ git rm -n '*Makefile'
I explained that behavior in
On Sun, Oct 08, 2017 at 07:56:20AM -0400, Robert P. J. Day wrote:
> but as i asked in my earlier post, if i wanted to remove *all* files
> with names of "Makefile*", why can't i use:
>
> $ git rm 'Makefile*'
>
> just as i used:
>
> $ git rm '*.c'
>
> are those not both acceptable fileglob
ecursive". It happens
way before we decide to go recursive (or not).
We are not going down recursively from the paths in the index that
are matched by pathspec patterns with the above two "git rm"
requests (because there is no "-r" there), but even if we were,
because these three Makefile files are not directories, there is
nothing to remove recursively underneath them.
On Mon, 9 Oct 2017, Jeff King wrote:
> On Sun, Oct 08, 2017 at 04:42:27PM -0400, Theodore Ts'o wrote:
>
> > On Sun, Oct 08, 2017 at 03:44:14PM -0400, Robert P. J. Day wrote:
> > > >
> > > > find | xargs git rm
> > > >
> > > > myself.
> > >
> > > that's what i would have normally used until
On Sun, Oct 08, 2017 at 04:42:27PM -0400, Theodore Ts'o wrote:
> On Sun, Oct 08, 2017 at 03:44:14PM -0400, Robert P. J. Day wrote:
> > >
> > > find | xargs git rm
> > >
> > > myself.
> >
> > that's what i would have normally used until i learned about git's
> > magical globbing capabilitie
On Sun, Oct 08, 2017 at 03:44:14PM -0400, Robert P. J. Day wrote:
> >
> > find | xargs git rm
> >
> > myself.
>
> that's what i would have normally used until i learned about git's
> magical globbing capabilities, and i'm going to go back to using it,
> because git's magical globbing capabi
On Sun, 8 Oct 2017, Theodore Ts'o wrote:
> On Sun, Oct 08, 2017 at 10:32:40AM -0400, Paul Smith wrote:
> > Personally I don't use Git's magical globbing capabilities, and
> > use "git rm" as if it were UNIX rm. So in your request above I'd
> > use:
> >
> >git rm $(find . -name Makefile)
> >
>
On Sun, Oct 08, 2017 at 10:32:40AM -0400, Paul Smith wrote:
> Personally I don't use Git's magical globbing capabilities, and use "git
> rm" as if it were UNIX rm. So in your request above I'd use:
>
>git rm $(find . -name Makefile)
>
> which I find simpler.
I have to agree that git's magic
atterns to Git, because you're
escaping them from the shell. Hence, you might consider the behavior
bizarre, at least until you grok it fully.
If you want to avoid this, simply use normal shell globbing and don't
ask Git to do the globbing for you. Then it behaves exactly as nor
On Sun, 8 Oct 2017, René Scharfe wrote:
> [My SMTP server still refuses to accept emails to rpj...@crashcourse.ca
> and reports "mailbox unavailable" and "invalid DNS MX or A/ resource
> record." So just replying to the list.]
>
> Am 08.10.2017 um 13:56 schrieb Robert P. J. Day:
> >but
[My SMTP server still refuses to accept emails to rpj...@crashcourse.ca
and reports "mailbox unavailable" and "invalid DNS MX or A/ resource
record." So just replying to the list.]
Am 08.10.2017 um 13:56 schrieb Robert P. J. Day:
>but as i asked in my earlier post, if i wanted to remove
On 8 October 2017 at 13:56, Robert P. J. Day wrote:
> but as i asked in my earlier post, if i wanted to remove *all* files
> with names of "Makefile*", why can't i use:
>
> $ git rm 'Makefile*'
>
> just as i used:
>
> $ git rm '*.c'
>
> are those not both acceptable fileglobs? why does the f
and that's why, when i try a dry run, i
can see the effect it would have on the kernel source:
$ git rm -n '*.c' | wc -l
25569
$
> If you said
>
> $ git rm *.c
>
> then the shell expands the glob and all Git sees is that you want to
> remove a.c b.c d.c ...;
On Sun, Oct 08, 2017 at 05:07:12AM -0400, Robert P. J. Day wrote:
> On Sun, 8 Oct 2017, Junio C Hamano wrote:
>
> > "Robert P. J. Day" writes:
> >
> > > ... so if, in the kernel source
> > > tree, i ran:
> > >
> > > $ git rm \*.c
> > >
> > > i would end up removing *all* 25,569 "*.c" files in t
On Sun, 8 Oct 2017, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > ... so if, in the kernel source
> > tree, i ran:
> >
> > $ git rm \*.c
> >
> > i would end up removing *all* 25,569 "*.c" files in the kernel source
> > repository.
>
> Yes, as that is exactly what the command line ask
ou said
$ git rm *.c
then the shell expands the glob and all Git sees is that you want to
remove a.c b.c d.c ...; if you said "git rm -r *.c", unless b.c is
not a directory, these and only these files are removed.
> however, let's say i wanted to remove, recursively, all fil
On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote:
> it's been a long week, so take this in the spirit in which it is
> intended ... i think the "git rm" command and its man page should be
> printed out, run through a paper shredder, then set on fire. i can't
> remember the last time i sa
On Sat, 7 Oct 2017, Paul Smith wrote:
> On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote:
> > it's been a long week, so take this in the spirit in which it is
> > intended ... i think the "git rm" command and its man page should be
> > printed out, run through a paper shredder, then set
On Sat, 7 Oct 2017, Theodore Ts'o wrote:
> On Sat, Oct 07, 2017 at 03:43:43PM -0400, Robert P. J. Day wrote:
> > > -r
> > > Recursively remove the contents of any directories that match
> > > ``.
> > >
> > > or something.
> >
>
On Sat, Oct 07, 2017 at 03:43:43PM -0400, Robert P. J. Day wrote:
> > -r
> > Recursively remove the contents of any directories that match
> > ``.
> >
> > or something.
>
> it's been a long week, so take this in the spirit in which it is
> i
git rm drivers
> > > fatal: not removing 'drivers' recursively without -r
> > >
> > > versus
> > >
> > > $ git rm -r drivers
> > > [...removes everything under drivers/...]
> >
> > that is not what the man page is say
On Sat, Oct 07, 2017 at 03:32:24PM -0400, Robert P. J. Day wrote:
> > Nothing, because there is nothing to recurse in the pathspecs you've
> > given.
> >
> > Try:
> >
> > $ git rm drivers
> > fatal: not removing 'drivers' recursivel
On Sat, 7 Oct 2017, Jeff King wrote:
> On Sat, Oct 07, 2017 at 03:12:01PM -0400, Robert P. J. Day wrote:
>
> > ok, in that case, can you give me an example where "-r" makes a
> > difference, given that the man page refers to "a leading directory
> > nam
On Sat, Oct 07, 2017 at 03:12:01PM -0400, Robert P. J. Day wrote:
> ok, in that case, can you give me an example where "-r" makes a
> difference, given that the man page refers to "a leading directory
> name being given"? let's use as an example the linux kerne
On Sat, 7 Oct 2017, Todd Zullinger wrote:
> Robert P. J. Day wrote:
> >
> > was just testing variations of "git rm", and man page claims:
> >
> > -r Allow recursive removal when a leading directory name is given.
> >
> > i tested this on th
Robert P. J. Day wrote:
was just testing variations of "git rm", and man page claims:
-r
Allow recursive removal when a leading directory name is given.
i tested this on the "pro git" book repo, which contains a top-level
"book/" directory, and quit
was just testing variations of "git rm", and man page claims:
-r
Allow recursive removal when a leading directory name is given.
i tested this on the "pro git" book repo, which contains a top-level
"book/" directory, and quite a number of "*.asc"
Minor change to be consistent with the rest of the fast-export code.
DIFF_STATUS_RENAMED is defined as 'R'.
Signed-off-by: Miguel Torroja
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
ind
Minor change to be consistent with the rest of the fast-export code.
DIFF_STATUS_RENAMED is defined as 'R'.
Signed-off-by: Miguel Torroja
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
ind
Minor change to be consistent with the rest of the fast-export code.
DIFF_STATUS_RENAMED is defined as 'R'.
Signed-off-by: Miguel Torroja
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
ind
I've finally found the correct command after some significant research:
git filter-branch --tag-name-filter cat --index-filter "git rm -r
--cached --ignore-unmatch ${file_path}/${file_name}" --prune-empty
--force -- --all
On Fri, Jan 20, 2017 at 4:23 PM, jean-christophe manciot
> On Tue, Jan 17, 2017 at 4:30 PM, jean-christophe manciot
> wrote:
>> Hi there,
>>
>> I'm trying to purge a complete folder and its files from the
>> repository history with:
>>
>> git-Games# git filter-branch 'git rm -r --ignore-unmatch --
&g
th:
>
> git-Games# git filter-branch 'git rm -r --ignore-unmatch --
> Ubuntu/16.04/' --tag-name-filter cat -- --all HEAD
> fatal: bad revision 'git rm -r --ignore-unmatch -- Ubuntu/16.04/'
>
> git does not find the folder although it's there:
&
On Tue, Jan 17, 2017 at 04:30:48PM +0100, jean-christophe manciot wrote:
> I'm trying to purge a complete folder and its files from the
> repository history with:
>
> git-Games# git filter-branch 'git rm -r --ignore-unmatch --
> Ubuntu/16.04/' --tag-name-filter
Hi there,
I'm trying to purge a complete folder and its files from the
repository history with:
git-Games# git filter-branch 'git rm -r --ignore-unmatch --
Ubuntu/16.04/' --tag-name-filter cat -- --all HEAD
fatal: bad revision 'git rm -r --ignore-unmatch -- Ubuntu/16.04/
On 3 January 2017 at 20:02, Ori Rawlings wrote:
> Looks good to me.
And me.
>
>
> Ori Rawlings
Looks good to me.
Ori Rawlings
git-p4 crashes when used with a very old p4 client version
that does not support the '-r ' option in its commands.
Allow making git-p4 work with old p4 clients by setting git-p4.retries to 0.
Alternatively git-p4.retries could be made opt-in.
But since only very old, barely mai
> On 29 Dec 2016, at 10:05, Igor Kushnir wrote:
>
> git-p4 crashes when used with a very old p4 client version
> that does not support the '-r ' option in its commands.
>
> Allow making git-p4 work with old p4 clients by setting git-p4.retries to 0.
>
> Alt
1 - 100 of 274 matches
Mail list logo
