Hello,
On Wed, May 20, 2015 at 8:01 PM, Jeff King wrote:
> The option parser for git-stash stuffs unknown flags into
> the $FLAGS variable, where they can be accessed by the
> individual commands. However, most commands do not even look
> at these extra flags, leading to unexpected results like
>
On Wed, May 20, 2015 at 8:17 PM, Jeff King wrote:
> On Wed, May 20, 2015 at 02:01:32PM -0400, Jeff King wrote:
>
>> This takes away the immediate pain. We may also want to
>> teach "--help" to the option. I guess we cannot do better
>> than just having it run "git help stash" in all cases (i.e.,
>
On 10/28/2015 03:14 AM, David Turner wrote:
> The common ref code will build up a ref transaction. Backends will
> then commit it. So the transaction creation and update functions should
> be in the common code. We also need to move the ref structs into
> the common code so that alternate backen
On Sun, Nov 1, 2015 at 1:32 AM, wrote:
> Some implementations of SHA_Updates have inherent limits
> on the max chunk size. SHA1_MAX_BLOCK_SIZE can be defined
> to set the max chunk size supported, if required. This is
> enabled for OSX CommonCrypto library and set to 1GiB.
>
> Signed-off-by: Ato
On 31.10.2015 11:25, Matthieu Moy wrote:
>> ca:text-no-eol wt:text-no-eol t/t5100/empty
>> ca:binarywt:binaryt/test-binary-2.png
>> ca:text-lf wt:text-lf t/t5100/rfc2047-info-0007
>> ca:text-lf wt:text-crlf doit.bat
>> ca:text-crlf-lf wt:text-crlf-lf loc
On Wed, Oct 28, 2015 at 7:21 PM, Stefan Beller wrote:
> Just pass it along to "git submodule update", which may pick reasonable
> defaults if you don't specify an explicit number.
>
> Signed-off-by: Stefan Beller
> ---
> @@ -724,8 +723,20 @@ static int checkout(void)
> err |= run_hook_le(
On Sun, 01 Nov 2015 at 00:40:39, Lukas Fleischer wrote:
> On Sat, 31 Oct 2015 at 18:31:23, Junio C Hamano wrote:
> > [...]
> > You earlier (re)discovered a good approach to introduce a new
> > feature without breaking settings of existing users when we
> > discussed a "whitelist". Since setting th
Hi Victor,
On Sat, 31 Oct 2015, Victor Leschuk wrote:
> > > +if test -n "$TEST_GDB_GIT"
> > > +then
> > > + exec gdb -args "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> > Maybe we could make $TEST_GDB_GIT not just a boolean flag? It would be
> > useful
> > to contain "gdb" executable name. It would all
trace_stats() is intended for GIT_TRACE_*_STATS variable group and
GIT_TRACE_PACK_STATS is more like an example how new vars can be added.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git.txt | 3 +++
cache.h | 2 ++
git.c | 1 +
sha1_file.c |
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 84616c8..a76c789 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1345,7 +1345,7 @@ struct ondisk_cache_entry_extended {
This allows signal handlers and atexit functions to realize this
situation and not clean up.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/gc.c | 2 +-
cache.h | 2 +-
daemon.c | 2 +-
setup.c | 4 +++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/gc.c b
Windows supports shared memory, but the semantics is a bit different
than POSIX shm. The most noticeable thing is there's no way to get the
shared memory's size by the reader, and wrapping fstat to do that
would be hell. So the shm size is added near the end, hidden away from
shm users (storing it
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-index-helper.txt | 3 +++
index-helper.c | 10 --
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-index-helper.txt
b/Documentation/git-index-helper.txt
index ad40366..9ced091
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 3 +++
read-cache.c | 13 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 8791dbc..89e9aaf 100644
--- a/cache.h
+++ b/cache.h
@@ -311,11 +311,14 @@ struct index_state {
struct spli
There's are "holes" in the index-helper approach because the shared
memory is not verified again by git. If $USER is compromised, shared
memory could be modified. But then they can already modify
$GIT_DIR/index. A more realistic risk is some bugs in index-helper
produce corrupt shared memory. --str
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git.txt | 1 +
cache.h | 1 +
read-cache.c | 16
trace.c | 5 -
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 108
This is the rebased version since last time [1] with
s/free_index_shm/release_index_shm/ as suggested by David Turner. It
introduces a daemon that can cache index data in memory so that
subsequent git processes can avoid reading (and more importantly,
verifying) the index from disk. Together with s
Instead of reading the index from disk and worrying about disk
corruption, the index is cached in memory (memory bit-flips happen
too, but hopefully less often). The result is faster read. Read time
is reduced by 70%.
The biggest gain is not having to verify the trailing SHA-1, which
takes lots of
This series builds on top of the index-helper series I just sent and
uses watchman to keep track of file changes in order to avoid lstat()
at refresh time. The series can also be found at [1]
When I started this work, watchman did not support Windows yet. It
does now, even if still experimental [2
The extension contains a bitmap, one bit for each entry in the
index. If the n-th bit is zero, the n-th entry is considered
unchanged, we can ce_mark_uptodate() it without refreshing. If the bit
is non-zero and we found out the corresponding file is clean after
refresh, we can clear the bit.
The '
Watchman is hidden behind index-helper. Before git tries to read the
index from shm, it notifies index-helper with SIGHUP and sleep,
waiting for index-helper to prepare shm. index-helper then contacts
watchman, updates 'WAMA' extension and put it in a separate shm and
wakes git up with SIGHUP.
Git
If index-helper puts 'W' before pid in $GIT_DIR/index-helper.pid, then
git will sleep for a while, expecting to be waken up by SIGUSR1 when
index-helper has done shm preparation, or after the timeout.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 14 --
1 file changed, 12 in
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/update-index.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 7431938..86aec21 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -903,6 +903,7 @@ int cmd_updat
The previous patch has the logic to clear bits in 'WAMA' bitmap. This
patch has logic to set bits as told by watchman. The missing bit,
_using_ these bits, are not here yet.
A lot of this code is written by David Turner originally, mostly from
[1]. I'm just copying and polishing it a bit.
[1] htt
git_mailinfo_config() expects "struct mailinfo *". But in
setup_mailinfo(), "mi" is already "struct mailinfo *". &mi would make
it "struct mailinfo **" and git_mailinfo_config() would damage some
other memory when it assigns some value to mi->use_scissors.
This is caught by t4150.20. git_mailinfo_
On Sat, Oct 31, 2015 at 6:45 PM, Eric Sunshine wrote:
> Patches in 'next' are pretty much set in stone, and those in 'master'
> definitely are, but 'pu' is volatile, so just send the entire patch
> revised, tagged v2 (or v3, etc.), rather than sending a patch to fix
> what is in 'pu', and Junio wi
Under normal circumstances, and like other git commands,
git checkout will write progress info to stderr if
attached to a terminal. This option allows progress
to be forced even if not using a terminal. Also,
progress can be skipped if using option --no-progress.
---
Documentation/git-checkout.txt
On Sun, Nov 1, 2015 at 11:22 AM, Edmundo Carmona Antoranz
wrote:
> + /*
> +* Final processing of show_progress
> +* - User selected --progress: show progress
> +* - user selected --no-progress: skip progress
> +* - User didn't specify:
> +* (check
Under normal circumstances, and like other git commands,
git checkout will write progress info to stderr if
attached to a terminal. This option allows progress
to be forced even if not using a terminal. Also,
progress can be skipped if using option --no-progress.
Signed-off-by: Edmundo Carmona Ant
René Scharfe writes:
> If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
> the string "HEAD (no branch)", translates it, skips the first eleven
> characters and passes the result to branch_get(), which returns a bogus
> result and accesses memory out of bounds in order to pro
René Scharfe writes:
> Use the variable branch_name, which already has "refs/heads/" removed,
> instead of blindly advancing in the ->branch string by 11 bytes. This
> is safer and less magical.
>
> Signed-off-by: Rene Scharfe
> ---
> wt-status.c | 2 +-
> 1 file changed, 1 insertion(+), 1 del
On Sun, Nov 1, 2015 at 12:47 PM, Edmundo Carmona Antoranz
wrote:
> Under normal circumstances, and like other git commands,
> git checkout will write progress info to stderr if
> attached to a terminal. This option allows progress
> to be forced even if not using a terminal. Also,
> progress can b
Junio C Hamano writes:
>> diff --git a/wt-status.c b/wt-status.c
>> index e206cc9..42ea15e 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -1656,7 +1656,7 @@ static void wt_shortstatus_print_tracking(struct
>> wt_status *s)
>> if (starts_with(branch_name, "refs/heads/"))
>>
On Sun, Nov 1, 2015 at 11:52 AM, Eric Sunshine wrote:
>> + if (opts.quiet) {
>> + opts.show_progress = 0;
>> + } else {
>> + opts.show_progress = isatty(2);
>> + }
>
> Style: drop unnecessary braces
>
Ok. WIll d
Under normal circumstances, and like other git commands,
git checkout will write progress info to stderr if
attached to a terminal. This option allows progress
to be forced even if not using a terminal. Also,
progress can be skipped if using option --no-progress.
Signed-off-by: Edmundo Carmona Ant
Am 01.11.2015 um 18:50 schrieb Junio C Hamano:
René Scharfe writes:
If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
the string "HEAD (no branch)", translates it, skips the first eleven
characters and passes the result to branch_get(), which returns a bogus
result and acc
Lukas Fleischer writes:
> Now, this cannot be intended behavior and I do not think this is
> something we want to retain when improving that feature.
Yup, that makes me suspect that namespace support with hiderefs was
done without giving much thought even stronger than before, and the
fact that
Matthieu Moy writes:
> Torsten Bögershausen writes:
>
>> ca:text-no-eol wt:text-no-eol t/t5100/empty
>> ca:binarywt:binaryt/test-binary-2.png
>> ca:text-lf wt:text-lf t/t5100/rfc2047-info-0007
>> ca:text-lf wt:text-crlf doit.bat
>> ca:text-crlf-lf wt:te
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Atousa Duprat writes:
> Indeed, the declaration needs a const void *; but I need to advance by
> a specific number of bytes in each iteration of the loop. Hence the
> cast.
Ah, of course you are right. Silly me.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
atous...@gmail.com writes:
> diff --git a/cache.h b/cache.h
> index 79066e5..ec84b16 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -14,7 +14,12 @@
> #ifndef git_SHA_CTX
> #define git_SHA_CTX SHA_CTX
> #define git_SHA1_InitSHA1_Init
> -#define git_SHA1_Update SHA1_Update
> +#ifdef SH
Sebastian Schuberth writes:
> However, the commit message says "to check if text files are stored
> normalized in the *repository*", yet the output refers to the index /
> cache. Is there a (potential) difference between line endings in the
> index and repo?
There is when you have staged changes
Junio C Hamano writes:
> i/ and w/ have been used to denote the "i"ndex and "w"orktree
> versions for the past 7 years with diff.mnemonicprefix option,
> which you may want to match.
Indeed.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsub
On Sun, Nov 1, 2015 at 1:03 PM, Edmundo Carmona Antoranz
wrote:
> Under normal circumstances, and like other git commands,
> git checkout will write progress info to stderr if
> attached to a terminal. This option allows progress
> to be forced even if not using a terminal. Also,
> progress can be
Oh, man... I'm sorry... I didn't notice them. Let me go over them to
see what we can do.
On Sun, Nov 1, 2015 at 1:13 PM, Eric Sunshine wrote:
> I'll assume that you simply overlooked the remainder of my v4 review
> comments, so I'll merely provide a reference to them[1] rather than
> repeating my
On Sun, Nov 01, 2015 at 12:52:57PM -0500, Eric Sunshine wrote:
> > diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> > index e269fb1..93ba35a 100644
> > --- a/Documentation/git-checkout.txt
> > +++ b/Documentation/git-checkout.txt
> > @@ -107,6 +107,12 @@ OPTIONS
> >
On Sun, Nov 1, 2015 at 2:19 PM, Jeff King wrote:
> On Sun, Nov 01, 2015 at 12:52:57PM -0500, Eric Sunshine wrote:
>> > +--progress::
>> > + Progress status is reported on the standard error stream
>> > + by default when it is attached to a terminal, unless -q
>> > + is specified.
In addition to matching stripped refs, one can now add hideRefs patterns
that the full (unstripped) ref is matched against. To distinguish
between stripped and full matches, those new patterns must be prefixed
with a circumflex (^).
This commit also removes support for the undocumented and uninten
Right now, there is no clear definition of how transfer.hideRefs should
behave when a namespace is set. Explain that hideRefs prefixes match
stripped names in that case. This is how hideRefs patterns are currently
handled in receive-pack.
Signed-off-by: Lukas Fleischer
---
Documentation/config.t
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Signed-off-by: Lukas Fleischer
---
t/t5509-fetch-push-namespaces.sh | 29 +
1 file changed, 29 insertions(+)
diff --git a/t/t5509-fetch-push-namespaces.sh b/t/t5509-fetch-push-
This is a first set of patches improving documentation and behavior of
the transfer.hideRefs feature as discussed in [1]. In particular,
hideRefs is changed to generally match stripped refs by default and
match full refs when prefixed with "^". The documentation is updated
accordingly. Basic tests
Make hideRefs handling in upload-pack consistent with the behavior
described in the documentation by stripping refs before comparing them
with prefixes in hideRefs.
Signed-off-by: Lukas Fleischer
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/upload-p
On Sun, Nov 1, 2015 at 1:29 PM, Eric Sunshine wrote:
>>> > +--progress::
>>> > + Progress status is reported on the standard error stream
>>> > + by default when it is attached to a terminal, unless -q
>>> > + is specified. This flag forces progress status even if the
>>> > +
On Sun, Nov 1, 2015 at 2:35 PM, Edmundo Carmona Antoranz
wrote:
> On Sun, Nov 1, 2015 at 1:29 PM, Eric Sunshine wrote:
> +--progress::
> + Progress status is reported on the standard error stream
> + by default when it is attached to a terminal, unless -q
> +
On Sun, Nov 1, 2015 at 7:40 PM, Matthieu Moy
wrote:
>> Any I find it a bit confusing to refer to the index where, as e.g. for
>> a freshly cloned repo the index should be empty,
>
> No it is not. The index is a complete snapshot of your working tree.
> When you have no uncommited staged changes,
On Sun, Nov 1, 2015 at 2:15 PM, Eric Sunshine wrote:
>
> Progress status is reported on the standard error stream by
> default when it is attached to a terminal, unless `--quiet` is
> specified. This flag enables progress reporting even if not
> attached to a terminal, regardless o
Under normal circumstances, and like other git commands,
git checkout will write progress info to stderr if
attached to a terminal. This option allows progress
to be forced even if not using a terminal. Also,
progress can be skipped if using option --no-progress.
Signed-off-by: Edmundo Carmona Ant
On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
> In addition to matching stripped refs, one can now add hideRefs patterns
> that the full (unstripped) ref is matched against. To distinguish
> between stripped and full matches, those new patterns must be prefixed
> with a circumflex (^).
>
On Sun, Nov 1, 2015 at 3:27 PM, Edmundo Carmona Antoranz
wrote:
> Under normal circumstances, and like other git commands,
> git checkout will write progress info to stderr if
> attached to a terminal. This option allows progress
> to be forced even if not using a terminal. Also,
> progress can be
Under normal circumstances, and like other git commands,
git checkout will write progress info to stderr if
attached to a terminal. This option allows progress
to be forced even if not using a terminal. Also,
progress can be skipped if using option --no-progress.
Signed-off-by: Edmundo Carmona Ant
On Sun, Nov 1, 2015 at 3:06 PM, Eric Sunshine wrote:
>> +--[no-]progress::
>> + Progress status is reported on the standard error stream
>> + by default when it is attached to a terminal, unless --quiet
>> + is specified. This flag enables progress reporting even if not
>> +
On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
> Test whether regular and full hideRefs patterns work as expected when
> namespaces are used.
>
> Signed-off-by: Lukas Fleischer
> ---
> diff --git a/t/t5509-fetch-push-namespaces.sh
> b/t/t5509-fetch-push-namespaces.sh
> @@ -82,4 +82,33 @@
On Sun, Nov 1, 2015 at 4:12 PM, Edmundo Carmona Antoranz
wrote:
> Under normal circumstances, and like other git commands,
> git checkout will write progress info to stderr if
> attached to a terminal. This option allows progress
> to be forced even if not using a terminal. Also,
> progress can be
On Sun, Nov 1, 2015 at 3:15 PM, Eric Sunshine wrote:
>> +--[no-]progress::
>> + Progress status is reported on the standard error stream
>> + by default when it is attached to a terminal, unless `--quiet`
>> + is specified. This flag enables progress reporting even if not
>> +
Under normal circumstances, and like other git commands,
git checkout will write progress info to stderr if
attached to a terminal. This option allows progress
to be forced even if not using a terminal. Also,
progress can be skipped if using option --no-progress.
Signed-off-by: Edmundo Carmona Ant
Hi,
some linkers, namely the one on IRIX are rather strict concerning the
order or arguments for symbol resolution, i.e. no libraries listed
before objects or other libraries on the command line are considered
for symbol resolution. That means that -lpthread can't work if it's
put in CFLAGS, bec
On Fri, 30 Oct 2015, Jeff King wrote:
The goal makes sense. Why weren't we using CURLOPT_RANGE before? Did it not
exist (or otherwise have limitations) in 2005, and if so, when did it become
usable? Do we need to protect this with an #ifdef for the curl version?
CURLOPT_RANGE existed already
On Mon, Nov 02, 2015 at 12:00:42AM +0100, Daniel Stenberg wrote:
> On Fri, 30 Oct 2015, Jeff King wrote:
>
> >The goal makes sense. Why weren't we using CURLOPT_RANGE before? Did it
> >not exist (or otherwise have limitations) in 2005, and if so, when did it
> >become usable? Do we need to protec
I've merged a handful of topics to 'next', and hoping that many of
them can be merged to 'master' before I'll go offline for a few
weeks starting on the week #7 of the cycle (starting Nov 9th).
As I hate sending out the whole text back to back (the last one was
issued on the last Friday), here is
Hello all,
do we have any objections on this patch?
--
Best Regards,
Victor
From: Victor Leschuk [vlesc...@gmail.com]
Sent: Tuesday, October 27, 2015 14:22
To: git@vger.kernel.org
Cc: Victor Leschuk
Subject: [PATCH v4] Add git-grep threads param
Make numb
To be specific
In my Unity project, there is a native plugin, and plugin's extension
is .dll, and this plugin is
under git version control, when Unity is running, the plugin file will
be locked.
If i merge another branch, which contains modification of the plugin,
git will report error, looks
like
On Sun, 01 Nov 2015 at 21:42:37, Eric Sunshine wrote:
> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
> > In addition to matching stripped refs, one can now add hideRefs patterns
> > that the full (unstripped) ref is matched against. To distinguish
> > between stripped and full matches, t
On Sun, 01 Nov 2015 at 22:13:51, Eric Sunshine wrote:
> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
> > Test whether regular and full hideRefs patterns work as expected when
> > namespaces are used.
> >
> > Signed-off-by: Lukas Fleischer
> > ---
> > diff --git a/t/t5509-fetch-push-name
Hello,
my name is Jim Stenberg and I'm a developer, albeit not that experienced with
Git.
Please note that I'm not a native English speaker.
If there is anything unclear or lacking, feel free to ask me on this email
address.
My problem:
"Git merge-base --fork-point" acts unexpected when I refer
On Sun, 1 Nov 2015, Jeff King wrote:
While I have your attention, Daniel, am I correct in assuming that
performing a second unrelated request with the same CURL object will need an
explicit:
curl_easy_setopt(curl, CURLOPT_RANGE, NULL);
to avoid using the range twice?
Correct. As the optio
On Mon, Nov 2, 2015 at 1:25 AM, Lukas Fleischer wrote:
> On Sun, 01 Nov 2015 at 22:13:51, Eric Sunshine wrote:
>> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
>> > + cd pushee &&
>> > + test_config transfer.hideRefs refs/tags &&
>> > + GIT_NAMESPACE=namespace git ls-re
Hi,
I have an issue with git 2.4.3 when trying to limit the amount of data
fetched when cloning submodules. The --depth option is useful, but
when .gitmodules specifies a non-default branch, the submodule
repository clone invocation (which is a single-branch clone due to
--depth) fetches master re
77 matches
Mail list logo