Hello,
I have spotted a problem using 'git diff' when non ascii characters are
involved.
Not sure if the problem is due to the name of the file, or its content.
Cheers,
Giulio Cesare
Steps to reproduce the problem:
$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.9.4
BuildVersion:
If we have a config file like,
[foo]
baz
bar =
and we try something like, git config --add foo.baz roll, Git will
segfault. Moreover, for git config --add foo.bar roll, it will
overwrite the original value instead of appending after the existing
empty value. Document these
The problem lies with the regexp used for simulating --add in
`git_config_set_multivar_in_file()`, ^$, which in ideal case should
not match with any string but is true for empty strings. Instead use a
sentinel value CONFIG_REGEX_NONE to say we do not want to replace any
existing entry and use it
Hi Junio,
On Thu, 11 Sep 2014, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
When our toolset has become too tight without leaving enough escape
hatch to hinder further development, it is very sensible to at least
think about adding a new --for-debug option to
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
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
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.
While at it, prepare type_from_string() for counted strings, i.e.
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
Since we do not want to limit 'tag' lines unduly, values that would fail
the refname check only result in warnings, not errors.
Signed-off-by: Johannes Schindelin
The intent of the new test case 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.
While it *would* have been nice to test the code path where fsck_object()
encounters an invalid tag
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
tag object without a
Tanay Abhra tanay...@gmail.com writes:
+const char CONFIG_REGEX_NONE[] = a^;
I have a slight preference for this version (no magic (void *)1 value,
and belts-and-suspenders solution since someone actually using the regex
should still get a correct behavior.
But I'm fine with both Junio/Peff's
On 09/10/2014 12:39 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back the lockfile before returning so that
On 09/10/2014 12:41 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
If there is an error copying the old contents to the lockfile, roll
back the lockfile before exiting so that the lockfile is not held
until process cleanup.
Same comment as 06/32 applies here.
On 09/10/2014 06:51 PM, Junio C Hamano wrote:
[...]
I am wondering if it makes sense to maintain a single ref that
reaches all the commits in this shared object store repository,
instead of keeping these millions of refs. When you need to make
more objects kept and reachable, create an
On 09/10/2014 09:11 PM, Jeff King wrote:
On Wed, Sep 10, 2014 at 09:51:03AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yes, we don't let normal fetchers see these repos. They're only for
holding shared objects and the ref tips to keep them reachable.
Are these individual
On 09/07/2014 04:21 PM, Torsten Bögershausen wrote:
On 2014-09-06 09.50, Michael Haggerty wrote:
Sorry for the long delay since v3. This version mostly cleans up a
couple more places where the lockfile object was left in an
ill-defined state.
No problem with the delay.
The most important
Hello Jens,
Excerpts from Jens Lehmann's message of 2014-09-11 15:29:28 -0400:
Git does know what's going on, just fails to display it properly
in the diff, as the output of ls-files shows:
$git ls-files -u
16 6a6e215138b7f343fba67ba1b6ffc152019c6085 1b
16
hello,
git-diff-tree without --root is absolutely silent for the root commit,
and i see no bad effects of --root on non-root commits. are there any
hidden gotchas? IOW, why is the --root behavior not the default?
cram[1] testcase::
$ git init -q scratch
$ cd scratch
$ echo '.*.sw?'
tl;dr You can't git-new-workdir checkouts which use core.worktree. This
is unfortunate because 'git submodule init' uses core.worktree by
default, which means you can't recursively git-new-workdir without a
hack.
In the beginning, the Developer created the remote Git repository and
the
On 09/10/2014 10:13 AM, Jeff King wrote:
[...]
I did coincidentally have an interesting experience with our lockfile
code earlier today, which I'd like to relate.
I was running pack-refs on a repository with a very large number of
loose refs (about 1.8 million). [...] Each call to
Sometimes it's interesting to have a simple output that answers the question:
Are there commits after the latest tag?
One possible solution is to just print a + (plus) signal after the tag.
Example:
git describe --abbrev=1 5261ec5d5
v2.1.0-rc1-2-g5261ec
git describe --abbrev=+ 5261ec5d5
It will print just a + sign appended to the found tag, if there
are commits between the tag and the supplied commit.
It's useful when you just need a simple output to know if the
supplied commit is an exact match or not.
Signed-off-by: Jonh Wendell jonh.wend...@gmail.com
---
builtin/describe.c
Signed-off-by: Jonh Wendell jonh.wend...@gmail.com
---
Documentation/git-describe.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index d20ca40..e291770 100644
--- a/Documentation/git-describe.txt
+++
On 09/12/2014 12:15 AM, Ronnie Sahlberg wrote:
On Sat, Sep 6, 2014 at 12:50 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
There are a few places that use these values, so define constants for
them.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h| 4
Jeff King p...@peff.net writes:
I dunno. I wrote that original set of lua pretty-format patches to try
to stop the insanity once and for all. But I realized that I do not
actually want to do anything complicated with the output formats, and
--oneline and a few simple --format calls usually
On 09/12/2014 12:42 AM, Ronnie Sahlberg wrote:
Maybe we should not have a public constant defined for the length :
+#define LOCK_SUFFIX_LEN 5
since it encourages unsafe code like : (this was unsafe long before
your patch so not a regression)
+ i = strlen(result_file) -
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com writes:
+const char CONFIG_REGEX_NONE[] = a^;
I have a slight preference for this version (no magic (void *)1 value,
and belts-and-suspenders solution since someone actually using the regex
should still get a
Roman Neuhauser neuhau...@sigpipe.cz writes:
git-diff-tree without --root is absolutely silent for the root commit,
and i see no bad effects of --root on non-root commits. are there any
hidden gotchas? IOW, why is the --root behavior not the default?
Because tools that was written before
On Fri, Sep 12, 2014 at 10:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 09/12/2014 12:42 AM, Ronnie Sahlberg wrote:
Maybe we should not have a public constant defined for the length :
+#define LOCK_SUFFIX_LEN 5
since it encourages unsafe code like : (this was unsafe long before
test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use cmp to compare the files.
This was noticed because on Windows we have a special implementation of
test_cmp in pure bash code (to ignore differences
Johannes Sixt j...@kdbg.org writes:
test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use cmp to compare the files.
Thanks.
This was noticed because on Windows we have a special implementation of
Thanks. I think this is ready for 'next' and then down to 'master'
for the next release.
--
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
Today I run again into the CR/LF pain when I pulled from BOINC upstream and me
wonders how I can repair the repository using git-2.1.0 at a 32bit Linux
without cloning the full repository again (as I did it in the past). FWIW I did
not changed anything locally, I just do pull regularly from
Am 12.09.2014 um 19:58 schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use cmp to compare the files.
Thanks.
This was noticed
Try:
git checkout -f master
git pull origin
I committed fixes for that stuff this morning.
- Rom
-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf
Förster
Sent: Friday, September 12, 2014 2:09 PM
To: git@vger.kernel.org
Cc:
On 09/12/2014 08:19 PM, Rom Walton wrote:
Try:
git checkout -f master
git pull origin
I committed fixes for that stuff this morning.
doesn't helped :
tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master
Already on 'master'
Your branch is behind 'origin/master' by 7 commits, and can be
Crud...
Well, personally, I would delete the locale directory and the two translation
files in html.
Do the 'git pull', and then switch between master and some other branch.
like:
git checkout -f client_release/7/7.4
git checkout -f master
It is round about, but it should get the job done.
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
These patches are also available from the git repository at
git://repo.or.cz/git/jrn.git tags/rs/ref-transaction
The tag fetched and built as-is seems to break 5514 among other
On 09/12/2014 08:55 PM, Rom Walton wrote:
Crud...
Well, personally, I would delete the locale directory and the two translation
files in html.
Do the 'git pull', and then switch between master and some other branch.
like:
git checkout -f client_release/7/7.4
git checkout -f master
David Aguilar dav...@gmail.com writes:
Use `git rev-parse --verify --quiet` instead of redirecting
stderr to /dev/null.
Signed-off-by: David Aguilar dav...@gmail.com
---
Has this patch ever been tested? t3903 seems to break with this at
least for me.
git-stash.sh | 13 +++--
1
On 14-09-11 11:06 PM, Eric Sunshine wrote:
On Thu, Sep 11, 2014 at 11:36 AM, Marc Branchaud marcn...@xiplink.com wrote:
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
(alias R=$GIT_COMMON_DIR/worktrees/id)
- linked checkouts are supposed to keep its location in $R/gitdir up
to date.
I found this:
http://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft
That might help in the future.
- Rom
-Original Message-
From: Toralf Förster [mailto:toralf.foers...@gmx.de]
Sent: Friday, September 12, 2014
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
The tag fetched and built as-is seems to break 5514 among other
things (git remote rm segfaults).
Yeah, I noticed that right after sending the series out. :/
The patch below fixes it[1].
Is this
On 2014-09-12 08.53, Giulio Cesare Solaroli wrote:
Hello,
I have spotted a problem using 'git diff' when non ascii characters are
involved.
Not sure if the problem is due to the name of the file, or its content.
Cheers,
Giulio Cesare
Steps to reproduce the problem:
$ sw_vers
test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use test_cmp_bin to compare the files.
This was noticed because on Windows we have a special implementation of
test_cmp in pure bash code (to ignore
Jonathan Nieder jrnie...@gmail.com writes:
It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
and this is to patch it up in advance. :)
But it should apply on top, too.
I think in advance makes sense for this one, too.
There were a few other minor changes, and I think
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
It's Oops, the next one (refs.c: do not permit err == NULL) is broken,
and this is to patch it up in advance. :)
But it should apply on top, too.
I think in advance makes sense for this one, too.
There
On 09/12/2014 09:56 PM, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
[...]
There were a few other minor changes, and I think with them the series
should be ready for next. My send and hope that more reviewers
appear strategy didn't really work,...
You sent them just a
The pre-receive and post-receive hooks were designed to be an
improvement over old style update and post-update hooks that used to
take the update information on the command line and were limited by
the command line length limit. They take the same information from
their standard input. It has
Michael Haggerty wrote:
Jonathan Nieder jrnie...@gmail.com writes:
so I'll send a reroll of the series as-is in an hour or so.
Jonathan: Is a current version of this patch series set up for review in
Gerrit?
Yes.
(https://code-review.googlesource.com/#/q/project:git+topic:ref-transaction)
51 matches
Mail list logo
