Michael Haggerty wrote:
>> Jonathan Nieder 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)
Thanks,
Jon
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 be
On 09/12/2014 09:56 PM, Junio C Hamano wrote:
> Jonathan Nieder 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 few d
Junio C Hamano writes:
> Jonathan Nieder 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 m
Jonathan Nieder 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 with them t
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 diffe
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:
>
> $
Junio C Hamano wrote:
> Jonathan Nieder 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 me
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 3:
On 14-09-11 11:06 PM, Eric Sunshine wrote:
> On Thu, Sep 11, 2014 at 11:36 AM, Marc Branchaud wrote:
>> On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
>>> (alias R=$GIT_COMMON_DIR/worktrees/)
>>>
>>> - linked checkouts are supposed to keep its location in $R/gitdir up
>>>to date. The use c
David Aguilar writes:
> Use `git rev-parse --verify --quiet` instead of redirecting
> stderr to /dev/null.
>
> Signed-off-by: David Aguilar
> ---
Has this patch ever been tested? t3903 seems to break with this at
least for me.
> git-stash.sh | 13 +++--
> 1 file changed, 7 insertions
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
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder 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
>> things ("git remote
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.
--
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 b
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: boinc_...@
Am 12.09.2014 um 19:58 schrieb Junio C Hamano:
> Johannes Sixt 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 be
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 up
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
Johannes Sixt 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
> test_cm
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 du
On Fri, Sep 12, 2014 at 10:13 AM, Michael Haggerty 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
>> your patch s
Roman Neuhauser 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 you proposed that ch
Matthieu Moy writes:
> Tanay Abhra 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 wi
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) - LOCK_SUFF
Jeff King 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 are enou
On 09/12/2014 12:15 AM, Ronnie Sahlberg wrote:
> On Sat, Sep 6, 2014 at 12:50 AM, Michael Haggerty
> wrote:
>> There are a few places that use these values, so define constants for
>> them.
>>
>> Signed-off-by: Michael Haggerty
>> ---
>> cache.h| 4
>> lockfile.c | 11 ++-
>>
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
v
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
---
builtin/describe.c | 26
Signed-off-by: Jonh Wendell
---
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
+++ b/Documentation/git-describe.txt
@@ -54,6
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 lock
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 submodule.
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?' > .gi
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 fc12
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 i
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 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 individu
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 o
On 09/10/2014 12:41 AM, Junio C Hamano wrote:
> Michael Haggerty 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.
Same reply app
On 09/10/2014 12:39 AM, Junio C Hamano wrote:
> Michael Haggerty 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 the lock
>> fil
Tanay Abhra 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 version or this
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
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 obje
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
---
fsck.c
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 conta
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. s
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
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
Hi Junio,
On Thu, 11 Sep 2014, Junio C Hamano wrote:
> Junio C Hamano 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 hash-object and
>
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 i
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 defi
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: 13E2
51 matches
Mail list logo
