On August 27, 2014 at 6:28 PM Jonathan Nieder jrnie...@gmail.com
wrote:
Hi again,
dev wrote:
So I guess I have to create a config.mak file from somewhere.
Sorry, let's take a step back.
Actually I think we have some real progress to report here. After
scanning through the various magic
'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
On Thu, Aug 28, 2014 at 12:01 AM, Jeff King p...@peff.net 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
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 +=
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
On Thu, Aug 28, 2014 at 05:30:44PM +0700, Duy Nguyen wrote:
On Thu, Aug 28, 2014 at 12:01 AM, Jeff King p...@peff.net 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
Hi,
On Thu, Aug 28, 2014 at 3:49 AM, 李祐棠 r01942...@ntu.edu.tw 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
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 \
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
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 johannes.schinde...@gmx.de
---
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 johannes.schinde...@gmx.de
---
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
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
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 johannes.schinde...@gmx.de
---
fsck.c | 88
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
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 sat...@yandex-team.ru
---
fast-import.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fast-import.c
Add new fast-import test series for filedelete command.
Signed-off-by: Maxim Bublis sat...@yandex-team.ru
---
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
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
On August 28, 2014 at 10:50 AM Jeff King p...@peff.net 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
On Aug 27, 2014, at 4:47 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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.
dev d...@cor0.com 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
On Aug 26, 2014, at 8:29 PM, Jeff King p...@peff.net 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 proha...@zib.de
---
copy.c | 5 +
lockfile.c | 3
that git-bisect-run is very very
fast -- too fast to cause some mistake lol
Sincerely
YodaLee
20140828
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
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 p...@peff.net wrote:
You can get an overview of what will be shared
by running a command like:
git fast-export --anonymize --all |
perl -pe
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
Stefan Beller stefanbel...@gmail.com 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
Steffen Prohaska proha...@zib.de 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
+++
Steffen Prohaska proha...@zib.de writes:
On Aug 26, 2014, at 8:29 PM, Jeff King p...@peff.net 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
Matthieu Moy matthieu@imag.fr 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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr 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
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
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 bbo...@ewanet.ch
---
Documentation/git-rev-list.txt | 2 +-
Jeff King p...@peff.net 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
Matthieu Moy wrote:
Signed-off-by: Matthieu Moy matthieu@imag.fr
[...]
---
advice.c| 3 +--
git-pull.sh | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
Thanks for taking it on.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
[...]
It was already on my todo-list, as a
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Dumb question (I have not even read the patch, so please just ignore me
if this is indeed dumb!): Is the map of original-name, anonymized-name
available to the user while he attempts to confirm that the bug is still
present?
For example, if I
Jonathan Nieder jrnie...@gmail.com 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
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 original-name, anonymized-name
available to the user while he attempts to confirm that the bug is still
present?
No,
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 with
Torsten Bögershausen tbo...@web.de 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 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 updated.
Jonas 'Sortie' Termansen sor...@maxsi.org 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 sor...@maxsi.org
---
This, 1/9 and later 7/9, are independently good changes to the
current codebase,
Jonas 'Sortie' Termansen sor...@maxsi.org 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
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 sha1id
where sha1id is the same as the HEAD commit, I instead get the output of
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 sha1id
where sha1id is the same as the HEAD commit, I instead get the output of
Johannes Schindelin johannes.schinde...@gmx.de 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.
Johannes Schindelin johannes.schinde...@gmx.de 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:
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
Junio C Hamano gits...@pobox.com 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
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 -- here's
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 implements
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
Maxim Bublis sat...@yandex-team.ru writes:
Add new fast-import test series for filedelete command.
Signed-off-by: Maxim Bublis sat...@yandex-team.ru
---
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
Beat Bolli bbo...@ewanet.ch 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
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 with
Jeff King p...@peff.net 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
Maxim Bublis sat...@yandex-team.ru 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 sat...@yandex-team.ru
---
fast-import.c | 6 +-
1 file changed, 5
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 main
On Wed, Aug 27, 2014 at 3:48 PM, Jaime Soriano Pastor
jsorianopas...@gmail.com wrote:
Signed-off-by: Jaime Soriano Pastor jsorianopas...@gmail.com
---
read-cache.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index 7f5645e..1cdb762
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
62 matches
Mail list logo
