Am 13.08.19 um 22:32 schrieb Junio C Hamano:
> So perhaps
>
> + !ce_intent_to_add(a) && !ce_intent_to_add(b) &&
>
> i.e. "a cache entry is eligible to be same with something else only
> when its I-T-A bit is unset".
FWIW, here's another way to express that:
diff --git a/unpack-trees.c b/unpac
From: Phil Hord
'git tag -d' and 'git branch -d' both accept one or more refs to
delete, but each deletion is done by calling `delete_ref` on each argv.
This is very slow when removing from packed refs as packed-refs is
locked and rewritten each time. Use delete_refs instead so all the
removals c
On 2019-08-13 at 22:37:56, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > +test_expect_success 'rebase --am and .gitattributes' '
> > + test_create_repo attributes &&
> > + (
> > + cd attributes &&
> > + test_commit init &&
> > + test_config filter.test
"brian m. carlson" writes:
> +test_expect_success 'rebase --am and .gitattributes' '
> + test_create_repo attributes &&
> + (
> + cd attributes &&
> + test_commit init &&
> + test_config filter.test.clean "sed -e
> '\''s/smudged/clean/g'\''" &&
> +
Am 13.08.19 um 16:18 schrieb Pratyush Yadav:
> Now, I want to add a similar feature, but one that discards/resets the
> selected lines. And I'd like to avoid the hack that git-gui's
> apply_range_or_line is. So, is there a cleaner way to do this that does
> not involve generating a diff and then
On Tue, 13 Aug 2019 13:16:11 PDT (-0700), johannes.schinde...@gmx.de wrote:
Hi,
On Mon, 12 Aug 2019, Palmer Dabbelt wrote:
The existing --jobs argument was defined to control the number of jobs
used for submodule fetching, but it makes more sense to have this
argument control the number of jo
On Tue, 13 Aug 2019 15:00:13 PDT (-0700), gits...@pobox.com wrote:
Palmer Dabbelt writes:
The existing --jobs argument was defined to control the number of jobs
used for submodule fetching, but it makes more sense to have this
argument control the number of jobs to be used when fetching from
m
Palmer Dabbelt writes:
> The existing --jobs argument was defined to control the number of jobs
> used for submodule fetching, but it makes more sense to have this
> argument control the number of jobs to be used when fetching from
> multiple remotes as well.
>
> This patch simply changes the --j
Rohit Ashiwal writes:
> --ignore-date::
> - This flag is passed to 'git am' to change the author date
> - of the rebased commits (see linkgit:git-am[1]).
> + Instead of using the given author date, re-set it to the value
> + same as committer (current) date. This implies --force-
Junio C Hamano writes:
> "Derrick Stolee via GitGitGadget" writes:
>
>> * Update docs and 0 constant in feature.experimental around
>>merge.directoryRenames.
>
> I somehow thought that the concensus was that *.experimental is for
> things that should become the future default, and this one
"Derrick Stolee via GitGitGadget" writes:
> * Update docs and 0 constant in feature.experimental around
>merge.directoryRenames.
I somehow thought that the concensus was that *.experimental is for
things that should become the future default, and this one is not
something we would want to m
René Scharfe writes:
> Am 13.08.19 um 18:03 schrieb Varun Naik:
>> It is possible to delete a committed file from the index and then add it
>> as intent-to-add. Several variations of "reset" and "checkout" should
>> resurrect the file in the index from HEAD. "merge", "cherry-pick", and
>> "revert
Hi,
On Mon, 12 Aug 2019, Palmer Dabbelt wrote:
> The existing --jobs argument was defined to control the number of jobs
> used for submodule fetching, but it makes more sense to have this
> argument control the number of jobs to be used when fetching from
> multiple remotes as well.
>
> This pat
Eric Sunshine writes:
> On Tue, Aug 13, 2019 at 2:04 PM SZEDER Gábor wrote:
>> To avoid data loss, 'git worktree remove' refuses to delete a worktree
>> if it's dirty or contains untracked files. However, the error message
>> only mentions that the worktree "is dirty", even if the worktree in
>
Hi,
On Mon, 12 Aug 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think it might be worth just eliminating the whole idea.
>
> I kinda like the simplification ;-) An even thinner wrapper that
> calls malloc() and dies if it gets NULL, without any "try-to-free"
> logic.
This is one of t
Jeff King writes:
> I don't think there are. Most of Git's locks are predicated purely on
> the existence of the lockfile (with the intent that they'd work over
> systems like NFS). The gc lock is a weird one-off.
>
> And while it's not great for multiple gc's to run at the same time
> (because i
On Tue, Aug 13, 2019 at 2:04 PM SZEDER Gábor wrote:
> To avoid data loss, 'git worktree remove' refuses to delete a worktree
> if it's dirty or contains untracked files. However, the error message
> only mentions that the worktree "is dirty", even if the worktree in
> question is in fact clean, b
From: Derrick Stolee
The commit-graph feature has seen a lot of activity in the past
year or so since it was introduced. The feature is a critical
performance enhancement for medium- to large-sized repos, and
does not significantly hurt small repos.
Change the defaults for core.commitGraph and g
From: Derrick Stolee
There are a few important config settings that are not loaded
during git_default_config. These are instead loaded on-demand.
Centralize these config options to a single scan, and store
all of the values in a repo_settings struct. The values for
each setting are initialized a
From: Derrick Stolee
t6501-freshen-objects.sh sends the standard error from
'git gc' to a file and verifies that it is empty. This
is intended as a way to ensure no warnings are written
during the operation. However, as the commit-graph is
added as a step to 'git gc', its progress will appear
in
From: Derrick Stolee
The core.untrackedCache config setting is slightly complicated,
so clarify its use and centralize its parsing into the repo
settings.
The default value is "keep" (returned as -1), which persists the
untracked cache if it exists.
If the value is set as "false" (returned as 0
From: Derrick Stolee
The feature.manyFiles setting is suitable for repos with many
files in the working directory. By setting index.version=4 and
core.untrackedCache=true, commands such as 'git status' should
improve.
While adding this setting, modify the index version precedence
tests to check
From: Derrick Stolee
The 'feature.experimental' setting includes config options that are
not committed to become defaults, but could use additional testing.
Update the following config settings to take new defaults, and to
use the repo_settings struct if not already using them:
* 'pack.useSpars
This is a brand-new thread to replace ds/early-access. The discussion on
that thread was very helpful [1].
With this in mind, I propose instead a set of "feature.*" config settings
that form groups of "community recommended" settings (with some caveats). In
the space below, I'll list a set of poss
Am 13.08.19 um 18:03 schrieb Varun Naik:
> It is possible to delete a committed file from the index and then add it
> as intent-to-add. Several variations of "reset" and "checkout" should
> resurrect the file in the index from HEAD. "merge", "cherry-pick", and
> "revert" should all fail with an err
"brian m. carlson" writes:
> When applying multiple patches with git am, or when rebasing using the
> am backend, it's possible that one of our patches has updated a
> gitattributes file. Currently, we cache this information, so if a
> file in a subsequent patch has attributes applied, the file w
To avoid data loss, 'git worktree remove' refuses to delete a worktree
if it's dirty or contains untracked files. However, the error message
only mentions that the worktree "is dirty", even if the worktree in
question is in fact clean, but contains untracked files:
$ git worktree add test-workt
Jeff King writes:
> Git's index and trees only understand whole files, so at some point you
> must generate the final file content. A diff is an easy way to represent
> the changes, apply them to the existing state, and then get that final
> content. But it doesn't _have_ to be. You could make so
Pratyush Yadav writes:
>> The Git community members needs to be able to trust that the new
>> Git-gui maintainer would make a sensible decision when picking up
>> (or asking to improve) a patch from the list to collect and forward
>> to me. We somehow need to make sure that happens.
>
> Yes, b
Rohit Ashiwal writes:
> The previous commit introduced --ignore-date flag to interactive
> rebase, but the name is actually very vague in context of rebase -i
> since there are two dates we can work with. Add an alias to convey
> the precise purpose.
This sounds more like the existing "--reset-a
Phillip Wood writes:
>> +static void push_dates(struct child_process *child)
>> +{
>> +time_t now = time(NULL);
>> +struct strbuf date = STRBUF_INIT;
>> +
>> +strbuf_addf(&date, "@%"PRIuMAX, (uintmax_t)now);
>> +argv_array_pushf(&child->args, "--date=%s", date.buf);
>
> it doesn't
Phillip Wood writes:
>> + if (opts->committer_date_is_author_date) {
>> +size_t len;
>> +int res = -1;
>> +struct strbuf datebuf = STRBUF_INIT;
>> +char *date = read_author_date_or_null();
>
> You must always check the return value of functions t
SZEDER Gábor writes:
> ... And that function must be able to handle multiple path
> components, becase there is this callsite:
>
> exec-cmd.c: !(prefix = strip_path_suffix(executable_dirname,
> GIT_EXEC_PATH)) &&
>
> and the build sets '-DGIT_EXEC_PATH="libexec/git-core"' by default.
"brian m. carlson" writes:
> Well, I split it out from a function that handles multiple path
> components, mostly so that I could leverage existing work (and not have
> to worry about getting it wrong). It wasn't explicitly intended that it
> support multiple components, since I don't require tha
Torsten Bögershausen writes:
>> Sigh. Okay, great, life makes sense again. I want to yell at my
>> IDE now.
>>
>> I now feel brave enough to attempt to come up with better wording
>> for autocrlf docs, if you think that's worth trying.
>
> That would be good, I am happy to review patches.
Good
It is possible to delete a committed file from the index and then add it
as intent-to-add. Several variations of "reset" and "checkout" should
resurrect the file in the index from HEAD. "merge", "cherry-pick", and
"revert" should all fail with an error message. This patch provides the
desired behav
> Would you like to elobarate which IDE that is?
IntelliJ from JetBrains. I'm planning on emailing them to at least mention
this somewhere in their own docs, because I think it's not there.
Will attempt revised wording soon-ish, but not promising today.
-
On Tue, Aug 13, 2019 at 07:48:16PM +0530, Pratyush Yadav wrote:
> To put things into context of why I am asking this, git-gui has a
> feature where you can select parts of a displayed diff, and can
> stage/unstage those parts. That feature is implemented in git-gui by
> just generating a diff f
On Tue, Aug 13, 2019 at 03:31:43PM +, Yagnatinsky, Mark wrote:
> Thank you once more. Finally, I believe I understood everything you said.
> I was about to say that this contradicts my own experience.
> But then I remembered that I normally use my IDE rather than the command line.
> And I just
Thank you once more. Finally, I believe I understood everything you said.
I was about to say that this contradicts my own experience.
But then I remembered that I normally use my IDE rather than the command line.
And I just checked that indeed that the behavior of my IDE is totally different!
It r
Palmer Dabbelt wrote:
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 8aa6a0caf1ab..fa12ad44e7d9 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> +static int next_remote_to_fetch(struct child_process *cp,
> + struct strbuf *out,
> +
Hi,
To put things into context of why I am asking this, git-gui has a
feature where you can select parts of a displayed diff, and can
stage/unstage those parts. That feature is implemented in git-gui by
just generating a diff from the selected lines, and then applying it.
Check git-gui/lib/dif
On 09/08/19 01:03PM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> >> If you meant to volunteer to act as a git-gui maintainer, that would
> >> be wonderful. Then I do not have to play an interim maintainer.
> >
> > Yes, I do mean to volunteer to act as a git-gui maintainer.
> >
> > Is ther
On 12/08/2019 20:42, Rohit Ashiwal wrote:
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 8 +++-
builtin/rebase.c
Hi Rohit
On 12/08/2019 20:42, Rohit Ashiwal wrote:
The purpose of amend_author was to free() the malloc()'d string
obtained from get_author() while amending a commit. But we can
also use the variable to free() the author at our convenience.
Rename it to convey this meaning.
Thanks for rewordin
Hi Rohit
This is looking better - there are a couple of memory management issues
and minor nit-picks but apart from that it looks good.
On 12/08/2019 20:42, Rohit Ashiwal wrote:
rebase am already has this flag to "lie" about the author date
by changing it to the committer (current) date. Let'
We have a function to strip the path suffix from a commit, but we don't
have one to check for a path suffix. For a plain filename, we can use
basename, but that requires an allocation, since POSIX allows it to
modify its argument. Refactor strip_path_suffix into a helper function
and a new function
This series makes rebase --am honor the .gitattributes file for
subsequent patches when a patch changes it.
Changes from v2:
* Rename has_path_suffix to ends_with_path_components.
Changes from v1:
* Add has_path_suffix in a separate commit.
brian m. carlson (2):
path: add a function to check f
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes applied, the file will be
written out with the attribute
On Tue, Aug 13, 2019, at 21:17, Jeff King wrote:
> But I think it's actually happening at a level above that. git-grep
> supports multiple patterns, which can be joined with --and, --or, --not,
> etc. And they can be grouped with parentheses.
>
> What you're seeing is the argument parser thinki
The next patches will change/refactor the way we complete
configuration variable names and values, so add a few tests to cover
the basics, namely the completion of matching configuration sections,
full variable names, and their values.
Note that the test checking the completion of configuration se
'git config' expects a configuration variable's name and value in
separate options, so we complete values as they stand on their own on
the command line. 'git -c', however, expects them in a single option
joined by a '=' character, so we should be able to complete values
when they are following 's
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index e087c4bf00..cd9d8e1940 100644
--- a/contrib/completion/git-completion.b
Recently I've been writing 'git -c foo.bar ...' often enough that
typing our long configuration variables got annoying...
So this patch series teaches our Bash completion script to complete
supported configuration variables and their values after 'git -c
', and, while at it, after 'git clone -c '
The second '*' in the '--*=*' pattern of the inner 'case' statement of
the __gitcomp() helper function never matches anything, so let's use
'--*=' instead.
The purpose of that inner case statement is to decide when to append a
trailing space to the listed options and when not. When an option
requ
'git config' expects a configuration variable's name and value in
separate arguments, so we let the __gitcomp() helper append a space
character to each variable name by default, like we do for most other
things (--options, refs, paths, etc.). 'git -c', however, expects
them in a single option join
Most 'color.*' configuration variables, with the sole exception of
'color.pager', accept the same set of values, but our completion
script recognizes only about half of them. We could explicitly add
all those missing variables, but let's try to reduce future
maintenance burden, and use the catch-a
The completion script runs the classic '| sort | uniq' pipeline to
deduplicate the output of 'git help --config-for-completion'. 'sort
-u' does the same, but uses one less external process and pipeline
stage. Not a bit win, as it's only run once as the list of supported
configuration variables is
The previous commits taught the completion script how to complete
configuration section, variable names, and their valus after 'git -c
', and with a bit of foresight encapsulated all that in a
dedicated helper function. Use that function to complete the unstuck
argument of 'git config -c|--config
_git_config() contains two enormous case statements, one to complete
configuration sections and variable names, and the other to complete
their values.
Split these out into two separate helper functions, so in the next
patches we can use them to implement completion for 'git -c '.
Signed-off-by:
Completing configuration sections and variable names for the stuck
argument of 'git clone --config=' requires a bit of extra care
compared to doing the same for the unstuck argument of 'git clone
--config ', because we have to deal with that '--config=' being
part of the current word to be complete
The number of configuration variables listed by the completion script
grew quite when we started to auto-generate it from the documentation
[1], so we now complete them in two steps: first we list only the
section names, then the rest [2]. To get the section names we simply
strip everything follow
On Tue, Aug 13, 2019 at 03:01:04PM +0900, nanaya wrote:
> I observed this today:
>
> $ git grep -F '('
> fatal: unmatched parenthesis
>
> Which doesn't make sense and I believe shouldn't happen.
At first glance this looks like we're feeding a fixed-string pattern to
the regex compiler, which wo
On 13/08/2019 11:38, Phillip Wood wrote:
Hi Rohit
[...]
@@ -964,6 +976,25 @@ static int run_git_commit(struct repository *r,
{
struct child_process cmd = CHILD_PROCESS_INIT;
+ if (opts->committer_date_is_author_date) {
+ size_t len;
+ int res = -1;
+ struct strbu
Hi Rohit
Thanks for the re-roll
On 12/08/2019 20:42, Rohit Ashiwal wrote:
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicate
Unë jam Katie Higgins. Ju lutemi mund të diskutojmë?
Hi Matheus,
On Tue, Aug 13, 2019 at 6:06 AM Matheus Tavares Bernardino
wrote:
>
> I just posted a new update on my project:
> https://matheustavares.gitlab.io/posts/simplified-version-of-parallel-inflation
Great blog post as usual!
> This week I sent a simplified version of the series I was wor
Hi Rohit
This is looking good, I think it is almost there now
On 12/08/2019 20:42, Rohit Ashiwal wrote:
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documen
68 matches
Mail list logo
