Junio C Hamano writes:
> Here is how I phrased in the one queued tentatively.
OK with me, thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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 htt
Hello,
I am very happy to announce that another bug fix release of Tig is now
available. Among the most prominent fixes are readline completion and
srefreshing of view after returning from commands when refresh-mode is
set to after-command. This release also improves testing so that Tig now
has an
On Wed, Aug 27, 2014 at 3:48 PM, Jaime Soriano Pastor
wrote:
> Signed-off-by: Jaime Soriano Pastor
> ---
> read-cache.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/read-cache.c b/read-cache.c
> index 7f5645e..1cdb762 100644
> --- a/read-cache.c
> +++ b/read-cache
On Thu, Aug 28, 2014 at 12:54:30AM -0400, dev wrote:
> Funny I don't see libcurl anywhere. Thought that was needed? Also the
> RUNPATH
> and RPATH look duplicated and slightly borked but the initial data there
> is correct enough to locate all the libs except for some strange libz
> issue.
The mai
Maxim Bublis writes:
> Branch tree is NULLified by filedelete command if we are trying
> to delete root tree. Add sanity check and use load_tree() in that case.
>
> Signed-off-by: Maxim Bublis
> ---
> fast-import.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fa
Jeff King writes:
> On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
>
>> Interesting. I couldn't convince Helgrind to catch such a case...
>
> Ugh. It helps if you actually helgrind the git binary, and not the
> shell-script from bin-wrappers. I can easily replicate the problem now.
>
On Thu, Aug 28, 2014 at 06:15:18PM -0400, Jeff King wrote:
> As I implemented, I realized that even with the mutex, I really was just
> implementing compare_and_swap (and I wrote it that way to make it more
> obvious). So if we wanted to, it would be trivial to replace the
> "claim_delta" function
Beat Bolli writes:
> It uses the '%aI' and '%cI' format specifiers or the '--date=iso-strict'
> date format name.
OK.
>
> See http://article.gmane.org/gmane.comp.version-control.git/255879 for
> discussion.
Please think of a way to explain/justify your changes better before
forcing readers to
Maxim Bublis writes:
> Add new fast-import test series for filedelete command.
>
> Signed-off-by: Maxim Bublis
> ---
You may have been concentrating on the "delete root" case, but as
long as you claim "We add a series to test filedelete command", it
would be sensible to test more typical cases
On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
> Interesting. I couldn't convince Helgrind to catch such a case...
Ugh. It helps if you actually helgrind the git binary, and not the
shell-script from bin-wrappers. I can easily replicate the problem now.
The patch I just posted seems t
On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
> So we need some kind of mutual exclusion so that only one thread
> proceeds with resolving the delta. The "real_type" check sort-of
> functions in that way (except of course it is not actually thread safe).
Here's a patch which implemen
On Mon, Aug 25, 2014 at 06:39:45PM +0200, René Scharfe wrote:
> Thanks, that looks good. But while preparing the patch I noticed that
> the added test sometimes fails. Helgrind pointed outet a race
> condition. It is not caused by the patch to turn the asserts into
> regular ifs, however -- her
Junio C Hamano writes:
>> +if (check_refname_format(buffer, REFNAME_ALLOW_ONELEVEL))
>> +ret = error_func(&tag->object, FSCK_ERROR, "invalid 'tag' name:
>> %s", buffer);
>> +*eol = '\n';
>
> I actually think this check is harmful.
Let me take this one back; we do a moral equ
Johannes Schindelin writes:
> We inspect commit objects pretty much in detail in git-fsck, but we just
> glanced over the tag objects. Let's be stricter.
>
> This work was sponsored by GitHub Inc.
Is it only this commit, or all of these patches in the series?
Does GitHub want their name sprinkle
Johannes Schindelin writes:
> So far, we assumed that the buffer is NUL terminated, but this is not
> a safe assumption, now that we opened the fsck_object() API to pass a
> buffer directly.
>
> So let's make sure that there is at least an empty line in the buffer.
> That way, our checks would fa
Johannes Schindelin writes:
> When fsck'ing an incoming pack, we need to fsck objects that cannot be
> read via read_sha1_file() because they are not local yet (and might even
> be rejected if transfer.fsckobjects is set to 'true').
>
> For commits, there is a hack in place: we basically cache co
Johannes Schindelin writes:
> In the next commits, we will enhance the fsck_tag() function to check
> tag objects more thoroughly. To this end, we need a function to verify
> that a given string is a valid object type, but that does not die() in
> the negative case.
>
> Signed-off-by: Johannes Sc
On Wed, 2014-08-27 at 17:22 -0700, Jonathan Nieder wrote:
> Keller, Jacob E wrote:
> >> On Wed, 2014-08-27 at 21:14 +, Keller, Jacob E wrote:
>
> >>> I am having trouble using revert. If I attempt to
> >>>
> >>> $ git revert
> >>>
> >>> where sha1id is the same as the HEAD commit, I instead g
On Wed, 2014-08-27 at 17:22 -0700, Jonathan Nieder wrote:
> Keller, Jacob E wrote:
> >> On Wed, 2014-08-27 at 21:14 +, Keller, Jacob E wrote:
>
> >>> I am having trouble using revert. If I attempt to
> >>>
> >>> $ git revert
> >>>
> >>> where sha1id is the same as the HEAD commit, I instead g
Jonas 'Sortie' Termansen writes:
> setitimer() is an obsolescent XSI interface and may be removed in a
> future standard. Applications should use the core POSIX timer_settime()
> instead.
>
> This patch cleans up the progress reporting and changes it to try using
> timer_settime, or if that fails
Jonas 'Sortie' Termansen writes:
> The makefile has provisions for this case, so let's detect it in
> the configure script as well.
>
> Signed-off-by: Jonas 'Sortie' Termansen
> ---
This, 1/9 and later 7/9, are independently good changes to the
current codebase, unlike all the other patches tha
On Thu, Aug 28, 2014 at 01:44:18PM -0400, Marc Branchaud wrote:
> Heiko also said this:
> > On Fri, Aug 22, 2014 at 12:00:07PM -0400, Marc Branchaud wrote:
> >> With relative-path submodules, the push's target repo *must* also have the
> >> submodules in their proper places, so that they can get up
Torsten Bögershausen writes:
> Add test cases for core.eol "native" and "" (unset).
> (MINGW uses CRLF, all other systems LF as native line endings)
>
> Add test cases for the attributes "eol=lf" and "eol=crlf"
>
> Other minor changes:
> - Use the more portable 'tr' instead of 'od -c' to convert
On Thu, Aug 28, 2014 at 11:11:47AM -0700, Junio C Hamano wrote:
> > + Anonymize the contents of the repository while still retaining
> > + the shape of the history and stored tree. See the section on
> > + `ANONYMIZING` below.
>
> Technically s/tree/trees/, I would think. For a repository
On Thu, Aug 28, 2014 at 05:46:15PM +0100, Ramsay Jones wrote:
> Dumb question (I have not even read the patch, so please just ignore me
> if this is indeed dumb!): Is the map of
> available to the user while he attempts to confirm that the bug is still
> present?
No, it's not.
> For example, if
Jonathan Nieder writes:
>> It was already on my todo-list, as a friend of mine semi-beginner with
>> Git complained about the mis-advice the other day, and I had to agree.
>
> That's a useful sort of thing to put in a commit message. :)
>
>> Eventually, git could detect that conflicts have been r
Ramsay Jones writes:
> Dumb question (I have not even read the patch, so please just ignore me
> if this is indeed dumb!): Is the map of
> available to the user while he attempts to confirm that the bug is still
> present?
>
> For example, if I anonymized git.git, and did 'git branch -v' (say),
Matthieu Moy wrote:
> Signed-off-by: Matthieu Moy
[...]
> ---
> advice.c| 3 +--
> git-pull.sh | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
Thanks for taking it on.
Reviewed-by: Jonathan Nieder
[...]
> It was already on my todo-list, as a friend of mine semi-beginner with
>
Jeff King writes:
> Subject: docs/fast-export: explain --anonymize more completely
>
> The original commit made mention of this option, but not why
> one might want it or how they might use it. Let's try to be
> a little more thorough, and also explain how to confirm that
> the output really is a
It uses the '%aI' and '%cI' format specifiers or the '--date=iso-strict'
date format name.
See http://article.gmane.org/gmane.comp.version-control.git/255879 for
discussion.
Signed-off-by: Beat Bolli
---
Documentation/git-rev-list.txt | 2 +-
Documentation/pretty-formats.txt | 6 --
Sorry for dropping out of the conversation; the last few days were a bit hectic.
Regarding recursive branching, I agree that a super-repo's branch names are
not necessarily appropriate for its submodules, and that Heiko's "simple
workflow" is a workable base to build upon. More thought is needed
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> 'git commit -a' is rarely a good way to mark conflicts as resolved: the
>> user anyway has to go manually through the list of conflicts to do the
>> actual resolution, and it is usually better to use "git add" on each
>> files after doing the re
Matthieu Moy writes:
> 'git commit -a' is rarely a good way to mark conflicts as resolved: the
> user anyway has to go manually through the list of conflicts to do the
> actual resolution, and it is usually better to use "git add" on each
> files after doing the resolution.
>
> On the other hand,
Steffen Prohaska writes:
> On Aug 26, 2014, at 8:29 PM, Jeff King wrote:
> ...
> Makes all sense, and seems sane to me, too.
>
> Junio, I saw that you have the changes on pu with 'SQUASH???...'. Will you
> squash it, or shall I send another complete update of the patch series?
If I let you rer
Steffen Prohaska writes:
>> OK, then let's do that at least for now and move on.
>
> Ok. I saw that you tweaked my patch on pu. Maybe remove the outdated
> comment above the function completely:
>
> diff --git a/config.c b/config.c
> index 87db755..010bcd0 100644
> --- a/config.c
> +++ b/config
Stefan Beller writes:
> On 27.08.2014 20:23, Junio C Hamano wrote:
>> I am not doing this myself soon, though. Hint, hint...
>
> I asked once upon a time, if there was a place,
> which collects such topics for casual contributors and new comers.
>
> Would you mind to update the leftover bits at
Fixes several problems:
* include config.mak.uname, config.mak.autogen and config.mak
in order to use settings for prefix and other such things;
* link xdiff/lib.a as it is a requirement for libgit.a;
* fix CFLAGS, LDFLAGS and EXTLIBS for Linux and Mac OS X.
Signed-off-by: Maxim Bublis
On 28/08/14 13:32, Jeff King wrote:
> On Thu, Aug 28, 2014 at 05:30:44PM +0700, Duy Nguyen wrote:
>
>> On Thu, Aug 28, 2014 at 12:01 AM, Jeff King wrote:
>>> You can get an overview of what will be shared
>>> by running a command like:
>>>
>>> git fast-export --anonymize --all |
>>> perl -pe
This patch series introduces detailed checking of tag objects when calling
git fsck, and also when transfer.fsckobjects is set to true.
To this end, the fsck machinery is reworked to accept the buffer and size
of the object to check, and for commit and tag objects, we verify that the
buffers end i
the wrong bug report, it prove that git-bisect-run is very very
fast -- too fast to cause some mistake lol
Sincerely
YodaLee
20140828
On Aug 26, 2014, at 8:29 PM, Jeff King wrote:
> On Tue, Aug 26, 2014 at 05:23:24PM +0200, Steffen Prohaska wrote:
>
>> The caller opened the fd, so it should be responsible for closing it.
>>
>> Signed-off-by: Steffen Prohaska
>> ---
>> copy.c | 5 +
>> lockfile.c | 3 +++
>> 2 files ch
dev writes:
> Actually I found a file called GIT-BUILD-OPTIONS :
That's a generated file (not included by the Makefile, but by some shell
scripts later), don't edit it. Use config.mak for your build
configuration.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this lis
On Aug 27, 2014, at 4:47 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Tue, Aug 26, 2014 at 02:54:11PM -0700, Junio C Hamano wrote:
>>
>>> A worse position is to have git_env_bool() that says "empty is
>>> false" and add a new git_env_ulong() that says "empty is unset".
>>>
>>> We sh
On August 28, 2014 at 10:50 AM Jeff King wrote:
> On Thu, Aug 28, 2014 at 10:16:48AM -0400, dev wrote:
>
> > # gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \
> > > SHELL_PATH=/usr/local/bin/bash \
> > > SANE_TOOL_PATH=/usr/local/bin \
> > > USE_LIBPCRE=1 LIBPCREDIR=/usr/local
Add new fast-import test series for filedelete command.
Signed-off-by: Maxim Bublis
---
t/t9300-fast-import.sh | 46 ++
1 file changed, 46 insertions(+)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 5fc9ef2..3d557b3 100755
--- a/t
Removing root tree with filedelete command would lead to segmentation fault
in store_tree(). First patch from patch series adds test to show incorrect
behaviour and second one fixes bug by sanity check and load_tree() usage.
Maxim Bublis (2):
t9300: test filedelete root
fast-import: fix segfau
Branch tree is NULLified by filedelete command if we are trying
to delete root tree. Add sanity check and use load_tree() in that case.
Signed-off-by: Maxim Bublis
---
fast-import.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fast-import.c b/fast-import.c
index d73f5
On Thu, Aug 28, 2014 at 10:16:48AM -0400, dev wrote:
> # gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \
> > SHELL_PATH=/usr/local/bin/bash \
> > SANE_TOOL_PATH=/usr/local/bin \
> > USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \
> > EXPATDIR=/usr/local NEEDS_LIBINTL_BEF
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
This work was sponsored by GitHub Inc.
Signed-off-by: Johannes Schindelin
---
fsck.c | 88 +-
1 file changed,
So far, we assumed that the buffer is NUL terminated, but this is not
a safe assumption, now that we opened the fsck_object() API to pass a
buffer directly.
So let's make sure that there is at least an empty line in the buffer.
That way, our checks would fail if the empty line was encountered
prem
One of the most important use cases for the strict tag object checking
is when transfer.fsckobjects is set to true to catch invalid objects
early on. This new regression test essentially tests the same code path
by directly calling 'index-pack --strict' on a pack containing an
invalid tag object.
The intent of the two new test cases is to catch general breakages in
the fsck_tag() function, not so much to test it extensively, trying to
strike the proper balance between thoroughness and speed.
Signed-off-by: Johannes Schindelin
---
t/t1450-fsck.sh | 39 +
In the next commits, we will enhance the fsck_tag() function to check
tag objects more thoroughly. To this end, we need a function to verify
that a given string is a valid object type, but that does not die() in
the negative case.
Signed-off-by: Johannes Schindelin
---
object.c | 13
When fsck'ing an incoming pack, we need to fsck objects that cannot be
read via read_sha1_file() because they are not local yet (and might even
be rejected if transfer.fsckobjects is set to 'true').
For commits, there is a hack in place: we basically cache commit
objects' buffers anyway, but the s
Congratulations!!!Your email address has won $500,000 in Coca-Cola/Fifa
Promotion. Ticket No:7PW1124. Contact us on e-Mail:coke.f...@outlook.com for
your claim
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
Well I am making progress in that I have what looks like a
successful build.
what fails next on the non-linux world is the next requirement for
GNU tar for some reason :
# gmake CFLAGS="$CFLAGS" LDFLAGS="$LD_OPTIONS" NEEDS_LIBICONV=Yes \
> SHELL_PATH=/usr/local/bin/bash \
> SANE_TOOL_PATH=/usr/
Hi,
On Thu, Aug 28, 2014 at 3:49 AM, 李祐棠 wrote:
> Dear git developers:
>
> Allow me to describe the testing situation more detail:
>
> First the testing repository is in
> https://github.com/gawel/pyquery
> my git version is 1.9.2 running on Archlinux 3.14.2
>
> I try to track issue #74(which is
On Thu, Aug 28, 2014 at 05:30:44PM +0700, Duy Nguyen wrote:
> On Thu, Aug 28, 2014 at 12:01 AM, Jeff King wrote:
> > You can get an overview of what will be shared
> > by running a command like:
> >
> > git fast-export --anonymize --all |
> > perl -pe 's/\d+/X/g' |
> > sort -u |
> > less
On 27.08.2014 20:23, Junio C Hamano wrote:
> I am not doing this myself soon, though. Hint, hint...
I asked once upon a time, if there was a place,
which collects such topics for casual contributors and new comers.
Would you mind to update the leftover bits at
http://git-blame.blogspot.de/searc
It would appear that Darwin does not have timer_t, at least from looking
at the public libc and XNU headers online.
A quick additional change is needed in config.mak.uname:
ifeq ($(uname_S),Darwin)
...
HAVE_DEV_TTY = YesPlease
+ NO_TIMER_T = UnfortunatelyYes
COMPAT_OBJS += c
On Thu, Aug 28, 2014 at 12:01 AM, Jeff King wrote:
> You can get an overview of what will be shared
> by running a command like:
>
> git fast-export --anonymize --all |
> perl -pe 's/\d+/X/g' |
> sort -u |
> less
>
> which will show every unique line we generate, modulo any
> numbers (each
'git commit -a' is rarely a good way to mark conflicts as resolved: the
user anyway has to go manually through the list of conflicts to do the
actual resolution, and it is usually better to use "git add" on each
files after doing the resolution.
On the other hand, using 'git commit -a' is potentia
62 matches
Mail list logo
