Nguyễn Thái Ngọc Duy writes:
> - unlink_or_warn(sb.buf);
> + if (!ret && opts->keep_locked) {
> + /*
> + * Don't keep the confusing "initializing" message
> + * after it's already over.
> + */
> + truncate(sb.buf, 0);
> +
Jacob Keller writes:
> On Fri, Apr 14, 2017 at 3:33 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita
>> wrote:
>>> This is much faster (below 0.1s):
>>>
>>> __git_index_files ()
>>> {
>>> local dir="$(__gitdir)" root="${2-.}" file;
>>> if [ -d "$dir
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> -unlink_or_warn(sb.buf);
>> +if (!ret && opts->keep_locked) {
>> +/*
>> + * Don't keep the confusing "initializing" message
>> + * after it's already over.
>> + */
>> +
Jeff King writes:
> On Sat, Apr 08, 2017 at 01:24:54PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> This adds PCRE v2 support, but as I was adding that I kept noticing
>> other related problems to fix. It's all bundled up into the same
>> series because much of it conflicts because it modifies the
Giuseppe Bilotta writes:
> This makes it easy to sign off a whole patchset before submission.
>
> To make things work, we also fix a design issue in git-am that made it
> ignore the signoff option during rebase (specifically, signoff was
> handled in parse_mail(), but not in parse_mail_rebasing()
On Sat, Apr 15, 2017 at 11:17 AM, Junio C Hamano wrote:
> Giuseppe Bilotta writes:
>
>> This makes it easy to sign off a whole patchset before submission.
>>
>> To make things work, we also fix a design issue in git-am that made it
>> ignore the signoff option during rebase (specifically, signoff
On Sat, Apr 15, 2017 at 10:11 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Sat, Apr 08, 2017 at 01:24:54PM +, Ævar Arnfjörð Bjarmason wrote:
>>
>>> This adds PCRE v2 support, but as I was adding that I kept noticing
>>> other related problems to fix. It's all bundled up into the same
Giuseppe Bilotta writes:
>> We need new tests for "git rebase --signoff" that makes sure this
>> works as expected and only when it should.
>
> Would the norm in this case be to introduce the test in the same
> commit, or in a previous commit (as in: this is the feature we want to
> implement, it
This is not yet the second issue of this month, but is a draft. I
haven't caught up with the list traffic yet, but have skimmed most
of the discussion and even managed to pick up some new topics.
Two requests to topic owners:
- You'd notice that the topics in the New Topics section below do
Followup to earlier discussion about use of name-rev in git-p4.
http://marc.info/?l=git&m=148979063421355
Luke Diamand (3):
git-p4: add failing test for name-rev rather than symbolic-ref
git-p4: add read_pipe_text() internal function
git-p4: don't use name-rev to get current branch
git-p4
git-p4 was using "git name-rev" to find out the current branch.
That is not safe, since if multiple branches or tags point at
the same revision, the result obtained might not be what is
expected.
Instead use "git symbolic-ref".
Signed-off-by: Luke Diamand
---
git-p4.py| 7 +
Using name-rev to find the current git branch means that git-p4
does not correctly get the current branch name if there are
multiple branches pointing at HEAD, or a tag.
This change adds a test case which demonstrates the problem.
Configuring which branches are allowed to be submitted from goes
wr
The existing read_pipe() function returns an empty string on
error, but also returns an empty string if the command returns
an empty string.
This leads to ugly constructions trying to detect error cases.
Add read_pipe_text() which just returns None on error.
Signed-off-by: Luke Diamand
---
git
I have a similar one
bash-4.4$ gitk
2017-04-15 13:09:52.514 Wish[3344:197352] *** Terminating app due to uncaught
exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN:
[nan 0]'
*** First throw call stack:
(
0 CoreFoundation 0x7fffd119048b
On Sat, Apr 15, 2017 at 3:07 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> -unlink_or_warn(sb.buf);
>>> +if (!ret && opts->keep_locked) {
>>> +/*
>>> + * Don't keep the confusing "initializing" message
>>> +
Hi.
That curious, but git allow to unconditionally delete files on other developer
host when he do `git pull`
How to reproduce:
1. File should be ignored:
echo "somefile" >> .gitignore
2. Add this ignored file into repository
git add -f somefile
3. Push changes to origin
git push
4. When oth
On Fri, Apr 14, 2017 at 01:43:37PM -0400, Jeff King wrote:
> On Fri, Apr 14, 2017 at 07:04:23PM +0200, Bert Wesarg wrote:
>
> > Dear Duy,
> >
> > heaving an includeIf in a git config file breaks calling external git
> > commands, most prominently git-gui.
> >
> > $ git --version
> > git version
Cc Gábor.
Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason:
On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita wrote:
This is much faster (below 0.1s):
__git_index_files ()
{
local dir="$(__gitdir)" root="${2-.}" file;
if [ -d "$dir" ]; then
__git_ls_files_helper "$root" "$1"
On Tue, Apr 11, 2017 at 12:14 PM, Jeff King wrote:
> On Sat, Apr 08, 2017 at 01:24:57PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Reword an outdated comment which suggests that only git-grep can use
>> PCRE.
>
> Makes sense.
>
>> -# Define USE_LIBPCRE if you have and want to use libpcre. git-grep
Am 15.04.2017 um 13:36 schrieb KES:
That curious, but git allow to unconditionally delete files on other developer
host when he do `git pull`
How to reproduce:
1. File should be ignored:
echo "somefile" >> .gitignore
2. Add this ignored file into repository
git add -f somefile
3. Push change
Cc Gábor, resent with working email (hopefully); please follow-up on
this mail.
Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason:
On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita wrote:
This is much faster (below 0.1s):
__git_index_files ()
{
local dir="$(__gitdir)" root="${2-.}" file
On Sat, 15 Apr 2017 14:27:00 +0200
Johannes Sixt wrote:
> > That curious, but git allow to unconditionally delete files on
> > other developer host when he do `git pull`
[...]
> Know that Git regards everything mentioned in .gitignore as
> dispensible; IOW, by mentioning a file in .gitignore you
Allow signing off a whole patchset by rebasing it with the --signoff
option, which is simply passed through to git am.
Compared to previous incarnations, I've split the am massaging to
separate commits (for cleanliness and easier reverts if needed),
and introduced a test case for both --signoff an
There are no more direct calls to am_signoff(), so we can fold its
logic in am_append_signoff().
(This is done in a separate commit rather than in the previous one, to
make it easier to revert this specific change if additional calls are
ever introduced.)
Signed-off-by: Giuseppe Bilotta
---
bu
This makes it easy to sign off a whole patchset before submission.
Signed-off-by: Giuseppe Bilotta
---
Documentation/git-rebase.txt | 5 +
git-rebase.sh| 3 ++-
t/t3428-rebase-signoff.sh| 46
3 files changed, 53 insertions(+)
Signoff is handled in parse_mail(), but not in parse_mail_rebasing(),
since the latter is only used when git-rebase calls git-am with the
--rebasing option, and --signoff is never passed in this case.
In order to introduce (in the upcoming commits) support for `git-rebase
--signoff`, we must make
Damnit! I just realized that I forgot to amend before the format-patch:
On Sat, Apr 15, 2017 at 4:41 PM, Giuseppe Bilotta
wrote:
> +signoff! passed to 'git am'
This should be without the ! or --no-signoff is not accepted. Do I
need to resend or ... ?
Am 14.04.2017 um 21:12 schrieb g...@jeffhostetler.com:
From: Jeff Hostetler
Teach add_index_entry_with_check() and has_dir_name()
to see if the path of the new item is greater than the
last path in the index array before attempting to search
for it.
During checkout, merge_working_tree() popula
It would be nice if the branch, remote tracking branch, and branch
commit comparison count colors in git status --short --branch were
configurable like the other git status colors.
Example command output:
$ git status --short --branch
## master...origin/master [ahead 1]
M README.md
M wrapper
While technically in the documentation, the fact that changes
introduced by a checkout are staged automatically, was
not obvious when reading its documentation. It is now specifically
pointed out.
Signed-off-by: Christoph Michelbach
---
Documentation/git-checkout.txt | 7 ---
1 file changed
From: "Christoph Michelbach"
While technically in the documentation, the fact that changes
introduced by a checkout are staged automatically, was
not obvious when reading its documentation. It is now specifically
pointed out.
Signed-off-by: Christoph Michelbach
---
Documentation/git-checkout.
On Sat, Apr 15, 2017 at 4:59 AM, Johannes Sixt wrote:
> Cc Gábor.
>
> Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason:
>>
>> On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita
>> wrote:
>>>
>>> This is much faster (below 0.1s):
>>>
>>> __git_index_files ()
>>> {
>>> local dir="$(__gitdir)"
Structure calls as
test_expect_success 'description' '
body
'
Use double quotes for the description if it requires parameter
expansion or contains a single quote.
Signed-off-by: Kyle Meyer
---
This patch follows up on a recent t1400 series:
https://public-inbox.org/git/xmqq8tnys
I would like to try to make git signing pluggable, this would allow for
using tools such as signify[1].
Now I'm wondering if this endeavor is worth taking and what would need
to be changed besides
gpg-interface?
[1] http://man.openbsd.org/signify
Given that other instances of "{...}" in the revision documentation
represent literal characters of revision specifications, describing
the rev^-n shorthand as "^-{}" incorrectly suggests that
something like "master^-{1}" is an acceptable form.
Signed-off-by: Kyle Meyer
---
Documentation/revisio
On Wed, Apr 12, 2017 at 10:37 PM, Kevin Willford wrote:
>
>> -Original Message-
>> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
>> Behalf Of Duy Nguyen
>> Sent: Wednesday, April 12, 2017 7:21 AM
>> To: Kevin Willford
>> Cc: Kevin Willford ; git@vger.kernel.org;
>>
On Sat, Apr 15, 2017 at 10:31:02PM -0400, Kyle Meyer wrote:
> Structure calls as
>
> test_expect_success 'description' '
> body
> '
>
> Use double quotes for the description if it requires parameter
> expansion or contains a single quote.
>
> Signed-off-by: Kyle Meyer
Looks good
On Sun, Apr 16, 2017 at 12:07:57AM -0400, Kyle Meyer wrote:
> Given that other instances of "{...}" in the revision documentation
> represent literal characters of revision specifications, describing
> the rev^-n shorthand as "^-{}" incorrectly suggests that
> something like "master^-{1}" is an ac
On 04/07/2017 12:57 PM, Duy Nguyen wrote:
> On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty
> wrote:
>> Extract a new function from `do_for_each_ref()`. It will be useful
>> elsewhere.
>>
>> Signed-off-by: Michael Haggerty
>> ---
>> refs.c | 15 +--
>> refs/refs-inte
On Sat, Apr 15, 2017 at 08:10:41PM -0700, Nathan McSween wrote:
> I would like to try to make git signing pluggable, this would allow for
> using tools such as signify[1].
> Now I'm wondering if this endeavor is worth taking and what would need to be
> changed besides
> gpg-interface?
>
> [1] htt
On 04/07/2017 01:20 PM, Duy Nguyen wrote:
> On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty
> wrote:
>> It turns out that we can now implement
>> `refs_verify_refname_available()` based on the other virtual
>> functions, so there is no need for it to be defined at the backend
>> level. Instead,
On Sat, Apr 15, 2017 at 06:49:01PM +0700, Duy Nguyen wrote:
> > Probably this fixes it:
> >
> > diff --git a/config.c b/config.c
> > index b6e4a57b9..8d66bdf56 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -213,6 +213,9 @@ static int include_by_gitdir(const char *cond, size_t
> > cond_len,
On 04/07/2017 01:32 PM, Duy Nguyen wrote:
> On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty
> wrote:
>> +void free_ref_cache(struct ref_cache *cache)
>> +{
>> + free_ref_entry(cache->root);
>> + free(cache);
>> +}
>
> free(NULL) is no-op (and safe). Maybe we should follow the same
On 04/07/2017 01:38 PM, Duy Nguyen wrote:
> On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty
> wrote:
>> Instead of keeping a pointer to the ref_store in every ref_dir entry,
>> store it once in `struct ref_cache`, and change `struct ref_dir` to
>> include a pointer to its containing `ref_cache`
On 04/07/2017 01:51 PM, Duy Nguyen wrote:
> On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty
> wrote:
>> Use reference iteration rather than do_for_each_entry_in_dir() in the
>> definition of files_pack_refs().
>
> A "why" is missing here. My guess is readability/maintainability
> because it's
On 04/07/2017 01:53 PM, Duy Nguyen wrote:
> On Wed, Apr 5, 2017 at 9:03 PM, Duy Nguyen wrote:
>> On Sat, Apr 1, 2017 at 12:16 PM, Michael Haggerty
>> wrote:
>>> Duy, have you looked over my patch series? Since you've been working in
>>> the area, your feedback would be very welcome, if you have
Dear Friend,
I would like to discuss a very important issue with you. I am writing to find
out if this is your valid email. Please, let me know if this email is valid
Kind regards
Adrien Saif
Attorney to Quatif Group of Companies
This is v3 of a patch series to separate the reference caching code
into a separate module that interacts with `files_ref_cache` more at
arm's length. Thanks to Stefan and Duy for their feedback about v2 [1].
This version has only minor changes since v2 (and indeed since v1 [2]):
* Rebased onto t
Since references under "refs/bisect/" are per-worktree, they have to
be sought in the worktree rather than in the main repository. But
since loose references are found by traversing directories, the
reference iterator won't even get the idea to look for a
"refs/bisect/" directory in the worktree if
Use reference iteration rather than `do_for_each_entry_in_dir()` in
the definition of `files_pack_refs()`. This makes the code shorter and
easier to follow, because the logic can be inline rather than spread
between the main function and a callback function, and it removes the
need to use `pack_ref
That "refs/bisect/" has to be handled specially when filling the
ref_cache for loose references is a peculiarity of the files backend,
and the ref-cache code shouldn't need to know about it. So move this
code to the callback function, `loose_fill_ref_dir()`.
Signed-off-by: Michael Haggerty
---
r
Instead of keeping a pointer to the `ref_store` in every `ref_dir`
entry, store it once in `struct ref_cache`, and change `struct
ref_dir` to include a pointer to its containing `ref_cache` instead.
This makes it easier to add to the information that is accessible from
a `ref_dir` without increasin
For now, it just wraps a `ref_entry *` that points at the root of the
tree. Soon it will hold more information.
Add two new functions, `create_ref_cache()` and `free_ref_cache()`.
Make `free_ref_entry()` private.
Change files-backend to use this type to hold its caches.
Signed-off-by: Michael Ha
Use reference iteration rather than do_for_each_entry_in_dir() in the
definition of commit_packed_refs().
Note that an internal consistency check that was previously done in
`write_packed_entry_fn()` is not there anymore. This is actually an
improvement:
The old error message was emitted when the
This function's visibility is about to be increased, so give it a more
distinctive name.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 6e08bc798c..f980af2420 10064
The new name is more analogous to `get_packed_ref_dir()`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index c0550ad9d6..3beab0b752 100644
--- a/refs/files-backend.c
Its only remaining caller was itself.
Signed-off-by: Michael Haggerty
---
refs/ref-cache.c | 21 -
refs/ref-cache.h | 11 ---
2 files changed, 32 deletions(-)
diff --git a/refs/ref-cache.c b/refs/ref-cache.c
index b3a30350d7..6059362f1d 100644
--- a/refs/ref-cache.c
This function's visibility is about to be increased, so give it a more
distinctive name.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index cf1c18cffb..05029d43b8 1
Change `lock_raw_ref()` and `lock_ref_sha1_basic()` to use
`refs_verify_refname_available()` instead of
`verify_refname_available_dir()`. This means that those callsites now
check for conflicts with all references rather than just packed refs,
but the performance cost shouldn't be significant (and
It was never used.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 4 ++--
refs/ref-cache.c | 6 +++---
refs/ref-cache.h | 11 +--
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 079ba941ef..c0550ad9d
It is a leveling violation for `ref_cache` to know about
`files_ref_store` or that it should call `read_loose_refs()` to lazily
fill cache directories. So instead, have its constructor take as an
argument a callback function that it should use for lazy-filling, and
change `files_ref_store` to suppl
Extract a new function, `get_loose_ref_cache()`, from
get_loose_ref_dir(). The function returns the `ref_cache` for the
loose refs of a `files_ref_store`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/refs/fi
Extract a new function from `refs_resolve_ref_unsafe()`. It will be
useful elsewhere.
Signed-off-by: Michael Haggerty
---
refs.c | 11 +--
refs/refs-internal.h | 4
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index bad05ba861..aa461
The `ref_cache` code is currently too tightly coupled to
`files-backend`, making the code harder to understand and making it
awkward for new code to use `ref_cache` (as we indeed have planned).
Start loosening that coupling by splitting `ref_cache` into a separate
module.
This commit moves code, a
This function's visibility is about to be increased, so give it a more
distinctive name.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 05029d43b8..6e08bc798c 100
Change `cache_ref_iterator_begin()` to take two new arguments:
* `prefix` -- to iterate only over references with the specified
prefix.
* `prime_dir` -- to "prime" (i.e., pre-load) the cache before starting
the iteration.
The new functionality makes it possible for
`files_ref_iterator_begin(
It turns out that we can now implement
`refs_verify_refname_available()` based on the other virtual
functions, so there is no need for it to be defined at the backend
level. Instead, define it once in `refs.c` and remove the
`files_backend` definition.
Signed-off-by: Michael Haggerty
---
refs.c
Extract a new function from `do_for_each_ref()`. It will be useful
elsewhere.
Signed-off-by: Michael Haggerty
---
refs.c | 15 +--
refs/refs-internal.h | 11 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index aa461156c4..2a
On Sat, Apr 15, 2017 at 01:00:51PM -0700, Stephen Kent wrote:
> It would be nice if the branch, remote tracking branch, and branch commit
> comparison count colors in git status --short --branch were configurable
> like the other git status colors.
That seems like a reasonable thing to want.
I t
69 matches
Mail list logo
