As noted by Gábor in [1], the new tests in edefc31873 ("format-patch:
create leading components of output directory", 2019-10-11) cannot be
run independently. Fix this.
[1] https://public-inbox.org/git/20191011144650.gm29...@szeder.dev/
Signed-off-by: Bert Wesarg
---
Cc: Denton Liu
Cc: Junio C
gt;is_current))
> return;
die-if-checked-out is called from callers that expect to be stopped
before they do any harm, so it feels dirty to make a side effect
like this.
If the user tries to check out a branch that used to be checked out
in an already removed worktree, doesn
Currently, if you do:
$ git branch zonk origin/master
$ git worktree add zonk zonk
$ rm -rf zonk
$ git branch -d zonk
You get the following error:
$ git branch -d zonk
error: Cannot delete branch 'zonk' checked out at
'/home/pjones/devel/kernel.org/git/zonk'
It isn't meaningfully checked out,
Currently if you do, for example:
$ git worktree add path foo
And "foo" has already been checked out at some other path, but the user
has removed it without pruning, and the worktree is not locked, you'll
get an error that the branch is already checked out. It isn't
meaningfully checked out, the
On Thu, Oct 17, 2019 at 06:44:26PM +0200, SZEDER Gábor wrote:
> > if (!wt || (ignore_current_worktree && wt->is_current))
> > return;
> > + if (access(wt->path, F_OK) < 0 &&
> > + (errno == ENOENT || errno == ENOTDIR))
> > + return;
>
> I think this check is insuf
"Carlo Marcelo Arenas Belón via GitGitGadget"
writes:
> builtin/grep.c | 1 +
> grep.c | 34 +-
> grep.h | 1 +
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> +#if defined(USE_LIBPCRE2)
> + if (!pcre2_global_context)
> +
Currently, when index-pack resolves deltas, it does not split up delta
trees into threads: each delta base root (an object that is not a
REF_DELTA or OFS_DELTA) can go into its own thread, but all deltas on
that root (direct or indirect) are processed in the same thread.
This is a problem when a r
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index
> > > > Well in that case, this check is incorrect. `do_rescan` passes only
> > > > "ui_ready" and `ui_do_rescan` passes "force_first_diff ui_ready".
> > > >
> > > > But either way, I'm not a big fan of this. This check mak
On Thu, Oct 17, 2019 at 12:28 PM Peter Jones wrote:
> Currently, if you do:
>
> $ git branch zonk origin/master
> $ git worktree add zonk zonk
> $ rm -rf zonk
> $ git branch -d zonk
>
> You get the following error:
>
> $ git branch -d zonk
> error: Cannot delete branch 'zonk' checked out at
> '/h
On Thu, Oct 17, 2019 at 12:28:25PM -0400, Peter Jones wrote:
> Currently if you do, for example:
>
> $ git worktree add path foo
>
> And "foo" has already been checked out at some other path, but the user
> has removed it without pruning, you'll get an error that the branch is
> already checked o
Currently if you do, for example:
$ git worktree add path foo
And "foo" has already been checked out at some other path, but the user
has removed it without pruning, you'll get an error that the branch is
already checked out. It isn't meaningfully checked out, the repo's
data is just stale and n
Currently, if you do:
$ git branch zonk origin/master
$ git worktree add zonk zonk
$ rm -rf zonk
$ git branch -d zonk
You get the following error:
$ git branch -d zonk
error: Cannot delete branch 'zonk' checked out at
'/home/pjones/devel/kernel.org/git/zonk'
It isn't meaningfully checked out,
On Wed, Oct 09, 2019 at 04:44:22PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 267 ---
> 1 file changed, 127 insertions(+), 140 deletions(-)
I think this is a good direction to go in. I confess I didn't careful
On Wed, Oct 09, 2019 at 04:44:21PM -0700, Jonathan Tan wrote:
> A subsequent commit will make the quantum of work smaller, necessitating
> more locking. This commit allows resolve_delta() to be called outside
> the lock.
OK, that makes sense, I think.
-Peff
tions.
Extend the grep API with a "destructor" that could be called to cleanup
any objects that were created and used globally.
Update `builtin/grep.c` to use that new API, but any other future users
should make sure to have matching `grep_init()`/`grep_destroy()` calls
if they are us
loc, as well as other custom allocators like jemalloc
and mi-malloc, can be configured at runtime (via `LD_PRELOAD`),
therefore we cannot know at compile time whether a custom allocator is
used or not.
Make the minimum change possible to ensure this combination is supported
by extending `grep_init()` t
loc, as well as other custom allocators like jemalloc
and mi-malloc, can be configured at runtime (via `LD_PRELOAD`),
therefore we cannot know at compile time whether a custom allocator is
used or not.
Make the minimum change possible to ensure this combination is supported
by extending `grep_init()` t
tions.
Extend the grep API with a "destructor" that could be called to cleanup
any objects that were created and used globally.
Update `builtin/grep.c` to use that new API, but any other future users
should make sure to have matching `grep_init()`/`grep_destroy()` calls
if they are us
you revert a line or
> > > hunk), and a "full rescan" refers to `ui_do_rescan`.
> > >
> > > Well in that case, this check is incorrect. `do_rescan` passes only
> > > "ui_ready" and `ui_do_rescan` passes "force_first_diff ui_ready".
> > &
n` (called when you revert a line or
> > > hunk), and a "full rescan" refers to `ui_do_rescan`.
> > >
> > > Well in that case, this check is incorrect. `do_rescan` passes only
> > > "ui_ready" and `ui_do_rescan` passes "force_first_diff
i_ready" and `ui_do_rescan` passes "force_first_diff ui_ready".
> >
> > But either way, I'm not a big fan of this. This check makes assumptions
> > about the behaviour of its callers based on what they pass to $after.
> > The way I see it, $after sho
ssumptions
> about the behaviour of its callers based on what they pass to $after.
> The way I see it, $after should be a black box to `rescan`, and it
> should make absolutely no assumptions about it.
>
> Doing it this way is really brittle, and would break as soon as someone
> chan
;ui_ready"} {
What do you mean by a "full rescan"? I assume you use it as the
differentiator between `ui_do_rescan` (called when you hit F5 or choose
rescan from the menu) and `do_rescan` (called when you revert a line or
hunk), and a "full rescan" refers to `ui_do_rescan`.
W
This is an attempt to revive the discussion started in
https://public-inbox.org/git/0102016b8d597569-c1f6cfdc-cb45-4428-8737-cb1bc30655d8-000...@eu-west-1.amazonses.com/#t
Johannes Schindelin (1):
doc(stash): clarify the description of `save`
Documentation/git-stash.txt | 5 +++--
1 file chan
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 267 ---
1 file changed, 127 insertions(+), 140 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 3908cd3115..f6318037ca 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-
From: Johannes Schindelin
Since v2.9.0, Git knows about the config variable core.hookspath that
allows overriding the path to the directory containing the Git hooks.
Since v2.10.0, the `--git-path` option respects that config variable,
too, so we may just as well use that command.
Other paths i
Instead of hard-coding the length of an object ID, look this value up
using the translation tables. Similarly, compute input data for invalid
submodule entries using the tables as well.
Signed-off-by: brian m. carlson
---
t/t4027-diff-submodule.sh | 16
1 file changed, 8 insert
Replace a hard-coded all-zeros object ID with a use of $ZERO_OID.
Signed-off-by: brian m. carlson
---
t/t4045-diff-relative.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t4045-diff-relative.sh b/t/t4045-diff-relative.sh
index 36f8ed8a81..258808708e 100755
--- a/t/t4045
Carlo Arenas writes:
> or we could drop the current branch in pu and start again from scratch
> now that all of the required dependencies had been merged.
That would be the cleanest from my point of view. Thanks, both.
Hi Carlo,
On Thu, 3 Oct 2019, Carlo Arenas wrote:
> On Thu, Oct 3, 2019 at 1:09 AM Johannes Schindelin
> wrote:
> > I still need
> > https://github.com/git-for-windows/git/commit/719beb813e4f27f090696ce583df3e5f3c480545
> > and
> > https://github.com/git-for-windows/git/commit/3369c322bbd95820b9
On Thu, Oct 3, 2019 at 1:09 AM Johannes Schindelin
wrote:
> I still need
> https://github.com/git-for-windows/git/commit/719beb813e4f27f090696ce583df3e5f3c480545
> and
> https://github.com/git-for-windows/git/commit/3369c322bbd95820b971701fef7db44b26dd826f
> to fix that part in Git for Windows' `s
patch accounts for that (haven't tested
> > that assumption, but will do now that I have a windows box, probably
> > even with mi-alloc) but yes, the only reason why there were references
> > to NEDMALLOC was to isolate the code and make sure the fix was
> > tackling the probl
ows box, probably
> even with mi-alloc) but yes, the only reason why there were references
> to NEDMALLOC was to isolate the code and make sure the fix was
> tackling the problem, it was not my intention to do so at the end,
> specially once we agreed that xmalloc should be used anyway.
&
;s not really worthy since the warning
doesn't represent a real problem. Instead, to make sure we don't get
false positives (at ThreadSanitizer, at least) an entry for the
respective function is added to .tsan-suppressions.
Signed-off-by: Matheus Tavares
---
.tsan-suppressions | 6
Hi Denton,
On Mon, 23 Sep 2019, Denton Liu wrote:
> This patchset relates to `make hdr-check`. The first patch addresses
> getting it to run on platforms which require custom CFLAGS.
>
> The other two patches address errors/warnings caught by actually running
> `make hdr-check`.
&
The first two patches fix errors causing `make hdr-check` to fail. The third is
legacy from v1 but provides code cleanup so we leave it. Finally, the last
patch is a patch which improves the portability and correctness of `hdr-check`.
Changes since v1:
* Reordered patches to put fixes first
This patchset relates to `make hdr-check`. The first patch addresses
getting it to run on platforms which require custom CFLAGS.
The other two patches address errors/warnings caught by actually running
`make hdr-check`.
Denton Liu (3):
Makefile: use $(ALL_CFLAGS) in $(HCO) target
apply.h
Python 2 is EOL at the end of 2019, many distros
and systems now come with python 3 as their default version.
These changes introduce a syntaxe compatible with the both versions of
python and so with the nearly future python standard.
Signed-off-by: Hervé Beraud
---
contrib/hg-to-git/hg-to-git.
so with the nearly future python standard.
>
> Introduced changes:
> ---
Let's drop the above 5 lines. A canonical form of log message for
us is to begin with a brief background to make readers realize what
is lacking in the current system (if needed -- and you'
Python 2 is EOL at the end of 2019, many distros
and systems now come with python 3 is the default version.
These changes introduce a syntaxe compatible with the both versions of
python and so with the nearly future python standard.
Introduced changes:
---
Rewriting features that
The specific checks done in match_pathspec_item for the DO_MATCH_SUBMODULE
case are useful for other cases which have nothing to do with submodules.
Rename this constant; a subsequent commit will make use of this change.
Signed-off-by: Elijah Newren
---
dir.c | 6 +++---
1 file changed, 3
>
> > Again, I'm not sure how well this would work with Tcl's regex library,
> > or how commonly these URL patterns appear in actual commit messages.
> > Just something to consider.
> >
> > [0]
> > https://stackoverflow.com/questions/3809401/wha
On Fri, Aug 30, 2019 at 12:02:07AM +0530, Pratyush Yadav wrote:
> On 29/08/19 11:27AM, Paul Mackerras wrote:
> > This makes gitk look for http or https URLs in the commit description
> > and make the URLs clickable. Clicking on them will invoke an external
> > web
The specific checks done in match_pathspec_item for the DO_MATCH_SUBMODULE
case are useful for other cases which have nothing to do with submodules.
Rename this constant; a subsequent commit will make use of this change.
Signed-off-by: Elijah Newren
---
dir.c | 6 +++---
1 file changed, 3
deleted in index does not resu
test_path_is_missing to-remove
'
+test_expect_success 'stash apply should succeed with unmodified file' '
+ echo base >file &&
+ git add file &&
+ git commit -m base &&
+
+ # now
Compared to the previous round this round introduces a gentle flag for
refresh_and_write_{index,cache}, which should make this function
suitable for use in the Dscho's builtin-add-i series. The latter will have to
be
I have also pushed this to https://github.com/tgummerer/git
tg/stash-re
The specific checks done in match_pathspec_item for the DO_MATCH_SUBMODULE
case are useful for other cases which have nothing to do with submodules.
Rename this constant; a subsequent commit will make use of this change.
Signed-off-by: Elijah Newren
---
dir.c | 6 +++---
1 file changed, 3
ex does not resu
test_path_is_missing to-remove
'
+test_expect_success 'stash apply should succeed with unmodified file' '
+ echo base >file &&
+ git add file &&
+ git commit -m base &&
+
+ # now stash a modificat
if (write_locked_index(repo->index, &lock_file, COMMIT_LOCK |
write_flags))
+ return -1;
+ return 0;
2: 148a65d649 = 2: 0367d938b1 merge: use refresh_and_write_cache
3: e0f6815192 = 3: 8ed3df9fec stash: make sure to write refreshed cache
Thomas Gummerer (3):
factor out ref
Ben writes:
>> As long as you make it clear that you are 100% happy with the
>> fixed-up result that appeared in 'pu', there is no need to resend
>> (if you want to make any other changes, I do want to avoid me
>> screwing up by listening to you and hand app
Those labels must be valid ref names, and therefore valid file names.
This just came in via Git for Windows.
Matt R (1):
rebase -r: let `label` generate safer labels
sequencer.c | 12 +++-
t/t3430-rebase-merges.sh | 5 +
2 files changed, 16 insertions(+), 1 deletion(
On 01-09-2019 18:01, Junio C Hamano wrote:
> Ben writes:
>
>>
>> Would you like me to send in another patch or leave it like this?
>
> As long as you make it clear that you are 100% happy with the
> fixed-up result that appeared in 'pu', there is no need
&options.orig_head);
>>> + lookup_commit_reference(the_repository,
>>> &head_oid);
>>
>> This introduces decl-after-statement error, doesn't it?
>>
>> Perhaps like so...
>
> Would you like m
On Fri, Aug 30, 2019 at 9:25 PM Junio C Hamano wrote:
>
> But between these two:
>
> $ git clone --no-read-only-file-in-git https://github.com/foo/bar
> ...sightsee...
> $ rm -r bar
>
> to avoid "f" in "rm -r", vs.
>
> $ git clone https://github.com/foo/bar
>
On 30-08-2019 22:15, Junio C Hamano wrote:
> Ben Wijen writes:
>
>> +
>> struct commit *head =
>> -lookup_commit_reference(the_repository,
>> -&options.orig_head);
>> +
Ben Wijen writes:
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 670096c065..abcbfb8f01 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -1968,9 +1968,13 @@ int cmd_rebase(int argc, const char **argv, const char
> *prefix)
> state_dir_path("
Michal Suchánek writes:
>> But requiring an additional single "f" when doing "rm -rf .git"? Is
>> that realy too much of a hassle? The option "-f" is to allow people
>> deal with an unusual situation, while preventing everyday use from
>> doing something harmful unintendedly. And removing a cl
On Fri, 30 Aug 2019 09:38:11 -0700
Junio C Hamano wrote:
> Albert Vaca Cintora writes:
>
> > On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
> >>
> >> Ah, your "rm" command needs to learn "-f" option, too, then?
> >
> > The whole point of this thread was to remove the need of -f forc
Albert Vaca Cintora writes:
> On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
>>
>> Ah, your "rm" command needs to learn "-f" option, too, then?
>
> The whole point of this thread was to remove the need of -f forcing the
> removal.
OK, I misunderstood what you wanted to do.
If an implem
Consider the following scenario:
git checkout not-the-master
work work work
git rebase --autostash upstream master
Here 'rebase --autostash ' incorrectly moves the
active branch (not-the-master) to master (before the rebase).
The expected behavior: (58794775:/git-rebase.sh:526)
A
Here are my "fix things without making unnecessary changes"
Fixing a copy-paste fault which I missed in v5...
Ben Wijen (2):
builtin/rebase.c: make sure the active branch isn't moved when
autostashing
builtin/rebase.c: Remove obsolete message
builtin/rebase.c
On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
>
> Ah, your "rm" command needs to learn "-f" option, too, then?
The whole point of this thread was to remove the need of -f forcing the removal.
On Thu, 29 Aug 2019 at 22:08, René Scharfe wrote:
>
> Am 29.08.19 um 21:40 schrieb Martin Ågren:
> > On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote:
> >> diff --git a/help.h b/help.h
> >> index b8780fbd0f..7a455beeb7 100644
> >> --- a/help.h
> >> +++ b/help.h
> >> @@ -42,8 +42,8 @@ void list_co
Am 29.08.19 um 21:40 schrieb Martin Ågren:
> On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote:
>> diff --git a/help.h b/help.h
>> index b8780fbd0f..7a455beeb7 100644
>> --- a/help.h
>> +++ b/help.h
>> @@ -42,8 +42,8 @@ void list_commands(unsigned int colopts, struct cmdnames
>> *main_cmds, struct
On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote:
>
> Announce that calling help_unknown_ref() exits the program.
>
> Signed-off-by: René Scharfe
> ---
> Patch generated with --function-context for easier review.
>
> help.c | 3 ++-
> help.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletion
Announce that calling help_unknown_ref() exits the program.
Signed-off-by: René Scharfe
---
Patch generated with --function-context for easier review.
help.c | 3 ++-
help.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 5261d83ecf..9ff2be6b18 10064
On 29/08/19 11:27AM, Paul Mackerras wrote:
> This makes gitk look for http or https URLs in the commit description
> and make the URLs clickable. Clicking on them will invoke an external
> web browser with the URL.
>
> The web browser command is by default "xdg-open" on
ex does not resu
test_path_is_missing to-remove
'
+test_expect_success 'stash apply should succeed with unmodified file' '
+ echo base >file &&
+ git add file &&
+ git commit -m base &&
+
+ # now stash a modificat
COMMIT_LOCK | SKIP_IF_UNCHANGED))
-- return error(_("Unable to write index."));
-+ if (refresh_and_write_cache(REFRESH_QUIET, COMMIT_LOCK |
SKIP_IF_UNCHANGED) < 0)
-+ return -1;
++ if (refresh_and_write_cache(REFRESH_QUIET, SKIP_IF_UNCHANGED) < 0
Consider the following scenario:
git checkout not-the-master
work work work
git rebase --autostash upstream master
Here 'rebase --autostash ' incorrectly moves the
active branch (not-the-master) to master (before the rebase).
The expected behavior: (58794775:/git-rebase.sh:526)
A
Here are my "fix things without making unnecessary changes"
Ben Wijen (2):
builtin/rebase.c: make sure the active branch isn't moved when
autostashing
builtin/rebase.c: Remove obsolete message
builtin/rebase.c| 13 +
t/t3420-rebase-au
Paul Mackerras writes:
> I was expecting some comments and suggestions, so I didn't push it out
> yet. One suggestion which seems reasonable is to match any http or
> https URL anywhere in the commit description, not just with Link: or
> BugLink: at the start of the line. What do you think of t
This makes gitk look for http or https URLs in the commit description
and make the URLs clickable. Clicking on them will invoke an external
web browser with the URL.
The web browser command is by default "xdg-open" on Linux, "open" on
MacOS, and "cmd /c start" o
Hi Junio,
On Tue, Aug 27, 2019 at 01:32:30PM -0700, Junio C Hamano wrote:
> Paul Mackerras writes:
>
> > This makes gitk look for lines in the commit message which start with
> > "Link:" or "BugLink:" followed by a http or https URL, and make the
> >
So, yeah, if we are to spend extra effort to polish Ben's patch
further while keeping the "fix things without making unnecessary
changes", I think the approach that takes least amount of effort may
not to make the code manually say "Head is at ...", but to add a new
mes
nd the
working tree and talking about "HEAD is now..." is a bug in its
context.
So, from the purist point of view, I see it may make sense to update
this patch to add logic to give a pointless and misleading "HEAD is
now at..." message so that we will report the location o
Hi Ben,
On Mon, 26 Aug 2019, Ben Wijen wrote:
> Dscho's review got me thinking about the rationale behind the 'HEAD is now
> at...'
> message.
>
> A 'stash push' is followed by a 'reset -q' but since 'stash create autostash'
> is
> not, we must do it ourselves. I guess the legacy implementation
On 27/08/19 08:14AM, Paul Mackerras wrote:
> This makes gitk look for lines in the commit message which start with
> "Link:" or "BugLink:" followed by a http or https URL, and make the
> URL clickable. Clicking on it will invoke an external web browser with
> th
Paul Mackerras writes:
> This makes gitk look for lines in the commit message which start with
> "Link:" or "BugLink:" followed by a http or https URL, and make the
> URL clickable. Clicking on it will invoke an external web browser with
> the URL.
>
> The
Albert Vaca Cintora writes:
> It "works" for some definition of work, but it asks for confirmation
> for every file, which is a pain. I'm on Linux.
Ah, your "rm" command needs to learn "-f" option, too, then?
On 8/26/19 6:14 PM, Paul Mackerras wrote:
This makes gitk look for lines in the commit message which start with
"Link:" or "BugLink:" followed by a http or https URL, and make the
URL clickable. Clicking on it will invoke an external web browser with
the URL.
The web b
indows box, probably
even with mi-alloc) but yes, the only reason why there were references
to NEDMALLOC was to isolate the code and make sure the fix was
tackling the problem, it was not my intention to do so at the end,
specially once we agreed that xmalloc should be used anyway.
> The patch h
ess 'stash --keep-index with file
deleted in index does not resu
test_path_is_missing to-remove
'
+test_expect_success 'stash apply should succeed with unmodified file' '
+ echo base >file &&
+ git add file &&
+ git commit -m base &a
hich is what the shell script
did.
The first patch is a small refactoring that makes the actual fix a bit
easier, while the second patch is a cleanup that I found while there.
Thomas Gummerer (3):
factor out refresh_and_write_cache function
merge: use refresh_and_write_cache
sta
1, including
> a couple of wrapper functions.
>
> Extend the grep API with a "destructor" that could be called to cleanup
> any objects that were created and used globally.
>
> Update builtin/grep to use that new API, but any other future
> users should make sure to have matc
On Mon, Aug 26, 2019 at 11:54 AM Junio C Hamano wrote:
>
> Carlo Marcelo Arenas Belón writes:
>
> > e87de7cab4 ("grep: un-break building with PCRE < 8.32", 2017-05-25)
> > added a restriction for JIT support that is no longer needed after
> > pcre_jit_exec() calls were removed.
>
> I was initial
This patchset makes more config.c functions handle arbitrary repos and
use that to remove an add_to_alternates_memory() call in
submodule-config.c. This should hopefully benefit performance and
memory.
Matheus Tavares (2):
config: allow config_with_options() to handle any repo
submodule: pass
This makes gitk look for lines in the commit message which start with
"Link:" or "BugLink:" followed by a http or https URL, and make the
URL clickable. Clicking on it will invoke an external web browser with
the URL.
The web browser command is by default "xdg-open&q
On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora wrote:
> > Why don't you wrap your clone in a script that calls chmod -R u+w .git
> > after the clone? This seems like a pretty trivial approach regardless of
> > your workflow. This works in Linux, Mac, Windows (under cygwin-bash) and
Carlo Marcelo Arenas Belón writes:
> e87de7cab4 ("grep: un-break building with PCRE < 8.32", 2017-05-25)
> added a restriction for JIT support that is no longer needed after
> pcre_jit_exec() calls were removed.
I was initially puzzled by this statement, until I realized that the
removal of pcr
On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano wrote:
>
> And directories (e.g. .git/objects/) are not made read-only for
> obvious reasons. Read-only files inside a writeable directory can
> be deleted just like read-write ones can be (iow, the "delete
> permission" comes from the "write permiss
On Mon, Aug 26, 2019 at 06:45:13PM +0200, Ben Wijen wrote:
> +test_expect_success 'never change active branch' '
> + git checkout -b not-the-feature-branch unrelated-onto-branch &&
> + test_when_finished "git reset --hard && git checkout -" &&
I think it would be safer to explicitly spell
ash is re-applied after the rebase, leaving nothing
to be guessed about.
Thank you,
Ben Wijen (1):
rebase.c: make sure the active branch isn't moved when autostashing
builtin/rebase.c| 18 ++
t/t3420-rebase-autostash.sh | 12
2 files changed, 14 insertions(+), 16 deletions(-)
--
2.22.0
tash, "%s", oid_to_hex(&oid));
printf(_("Created autostash: %s\n"), buf.buf);
- if (reset_head(&head->object.oid, "reset --hard",
+
+ /*
+
On August 26, 2019 11:28 AM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> >> Sometimes I clone a repo just to grep for an error string and then I
> >> don't need it anymore, or I clone several repos until I find the one
> >> that contains what I want and delete the rest. Sometimes I wa
"Randall S. Becker" writes:
>> Sometimes I clone a repo just to grep for an error string and then I don't
>> need it anymore, or I clone several repos until I find the one that contains
>> what I want and delete the rest. Sometimes I want to write a patch for some
>> software I don't develop regu
Philip Oakley writes:
> Surely (?), if we are considering our stored revisions to be
> immutable, then removing the write bit is the right thing to do.
> If I understand correctly (*) we don't separate the delete permission
> from 'no-write' permissions, so the consequence will be that such
> fil
On August 25, 2019 3:59 PM, Albert Vaca Cintora wrote:
> To: Johannes Sixt
> On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote:
> >
> > Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
> > > However, I'm sure that a large percentage of developers out there
> > > will agree with me that having
1 - 100 of 5380 matches
Mail list logo
