Jeff King wrote:
On Tue, Aug 20, 2013 at 09:38:41PM -0700, Jonathan Nieder wrote:
That is what I was trying to get at in discussing the test. It is not
We would like --int to reject values higher than this, but some
platforms do not allow us to, but Either rejecting this value, or
even
No message body: areatrain...@iberotelmakadibeach.com
Original message follows.
--
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
Jiang Xin worldhello@gmail.com writes:
$ git status
# On branch topic
# Your branch is based on 'topicbase', but the upstream is gone.
# (use git branch --unset-upstream to fixup)
Sorry, I didn't follow closely the previous discussions. I'm not sure
gone is right
There are a few level 4 and 2 perlcritic issues in the current code.
We make level 5 fatal, and keep level 2 as warnings so that make
check pass.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
contrib/mw-to-git/Makefile | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
Git-mediawiki's dumb push sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting the update to the private
ref after a dumb push.
Hi,
Stefan Beller wrote:
[PATCH] repack: rewrite the shell script in C.
Thanks for your work so far. This review will have mostly cosmetic
notes. Hopefully others can try it out to see if the actual behavior
is good.
As a first nit: in git, as usual in emails, the style in subject lines
is
Stefan Beller stefanbel...@googlemail.com writes:
All tests are constantly positive now.
Cool!
+/*
+ * Fills the filename list with all the files found in the pack directory
Detail: filename list could be fname_list to match the actual
argument below.
+ * ending with .pack, without that
Junio C Hamano gits...@pobox.com wrote:
Tony Finch d...@dotat.at writes:
div.page_footer {
- height: 17px;
+ height: 22px;
padding: 4px 8px;
background-color: #d9d8d1;
}
div.page_footer_text {
+ line-height: 22px;
float: left;
color: #55;
Am 21.08.2013 00:36, schrieb Stefan Beller:
I think I got all the suggestions except the
use of git_path/mkpathdup.
I replaced mkpathdup by mkpath where possible,
but it's still not perfect.
I'll wait for the dokumentation patch of Jonathan,
before changing all these occurences forth and back
On 08/21/2013 10:25 AM, Jonathan Nieder wrote:
+static int delta_base_offset = 0;
The = 0 is automatic for statics without an initializer. The
prevailing style in git is to leave it out.
Behavior change: in the script, wasn't the default true?
Yes, I was printing out the arguments of
On 08/21/2013 10:49 AM, Matthieu Moy wrote:
+if (start_command(cmd))
+ return 1;
A warning message would be welcome in addition to returning 1.
Johannes Sixt proposes to retain the return value of
the sub process, which I'd agree on.
However why do we need a warning message
On 08/21/2013 10:49 AM, Matthieu Moy wrote:
I tend to dislike these set a variable and break twice to exit nested
loops. Using an auxiliary function, you could just do
int f()
{
for_each {
for () {
...
if ()
Stefan Beller stefanbel...@googlemail.com writes:
On 08/21/2013 10:49 AM, Matthieu Moy wrote:
+ if (start_command(cmd))
+ return 1;
A warning message would be welcome in addition to returning 1.
Johannes Sixt proposes to retain the return value of
the sub process, which I'd
Stefan Beller stefanbel...@googlemail.com writes:
But as these follow up changes heavily rely on the very first patch
I will first try to get that right, meaning accepted into pu.
Then I can send patches with these proposals such as making more
functions.
I think it's better to get the style
From: Shawn O. Pearce spea...@spearce.org
Signed-off-by: Shawn O. Pearce spea...@spearce.org
Revised-by: Tay Ray Chuan rcta...@gmail.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
This is basically the version from Tay Ray Chuan [1] with one more
proofreading round from me. My
Fixed typo in comment.
Steffen Prohaska (2):
xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X
Revert compate/clipped-write.c: large write(2) fails on Mac OS X/XNU
Makefile | 8
compat/clipped-write.c | 13 -
config.mak.uname |
The previous commit introduced a size limit on IO chunks on all
platforms. The compat clipped_write() is not needed anymore.
This reverts commit 6c642a878688adf46b226903858b53e2d31ac5c3.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
Makefile | 8
Previously, filtering 2GB or more through an external filter (see test)
failed on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of signal 13
error: external
Steffen Prohaska proha...@zib.de writes:
Fixed typo in comment.
Thanks, and sorry for not being clear that I'll locally tweak before
queuing when I commented on v5 yesterday.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
On 08/21/2013 10:25 AM, Jonathan Nieder wrote:
Hi,
Stefan Beller wrote:
[PATCH] repack: rewrite the shell script in C.
Thanks for your work so far. This review will have mostly cosmetic
notes. Hopefully others can try it out to see if the actual behavior
is good.
Thanks for all the
During the review process of the previous commit (repack: rewrite the
shell script in C), Johannes Sixt proposed to retain any exit codes from
the sub-process, which makes it probably more obvious in case of failure.
As the commit before should behave as close to the original shell
script, the
The motivation of this patch is to get closer to a goal of being
able to have a core subset of git functionality built in to git.
That would mean
* people on Windows could get a copy of at least the core parts
of Git without having to install a Unix-style shell
* people deploying to servers
Clarify documentation for git-diff: State that when not inside a
repository, --no-index is implied (and thus two arguments are
mandatory).
Clarify error message from diff-no-index to inform user that CWD is
not inside a repository and thus two arguments are mandatory.
Signed-off-by: Dale Worley
Matthieu Moy matthieu@imag.fr writes:
Git-mediawiki's dumb push sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting
wor...@alum.mit.edu (Dale R. Worley) writes:
Unfortunately, the error message presupposes that the decision to
execute diff-no-index reflects the user's intention, thus leaving me
confused, as the error message is only:
usage: git diff [--no-index] path path
and does not cover the case I
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This is basically the version from Tay Ray Chuan [1] with one more
proofreading round from me. My changes besides realignments are below.
There are TODOs remain but I think the document is valuable as it is.
Thanks.
On the topic, C Git's
When merge.log config is set, rebase --preserve-merges
will add the log lines to the message of the rebased merge
commit.
A rebase should not modify a commit message automatically.
Teach git-rebase to ignore that configuration by passing --no-log
to the git-merge call.
Signed-off-by: Ralf
This is a more polished attempt at implementing the message-id
caching. I apologize for the sloppiness (unrelated changes, unused
variables etc.) in the first version.
I have split the patch in two. The first half moves the choice-logic
inside ask(): If ask() decides to return the default
Make it possible for callers of ask() to provide a list of
choices. Entering an appropriate integer chooses from that list,
otherwise the input is treated as usual.
Each choice can either be a single string, which is used both for the
prompt and for the return value, or a two-element array ref,
Allow the user to specify a file (sendemail.msgidcachefile) in which
to store the message-ids generated by git-send-email, along with time
and subject information. When prompting for a Message-ID to be used in
In-Reply-To, that file can be used to generate a list of options.
When composing v2 or
This set of patches was meant to be a re-roll of [1] addressing Junio's
comments, however [1] graduated to 'next' before I found time to work on
it further, so these are instead incremental patches atop 'next'.
patch 1: address Junio's comment [2]
patch 2: address Junio's comment [3] with a
The short SHA-1 collision test requires carefully crafted commits in
order to ensure a collision at rebase time. This involves managing state
which impacts the resulting SHA-1, including commit time. To accomplish
this, test_tick is set to a known state for the short SHA-1 collision
test.
As its very first action, t3404 installs (via set_fake_editor) a
specialized $EDITOR which simplifies automated 'rebase -i' testing. Many
tests rely upon this setting, thus tests which need a different editor
must take extra care upon completion to restore $EDITOR in order to
avoid breaking
The short SHA-1 collision test employs two magic values in commit
messages to trigger an ambiguous SHA-1 error during 'rebase -i' -- one
for 'collide3' during setup, and one for 'collide2' at rebase time --
even though the collision can just as easily be triggered by a single
magic value at rebase
On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy matthieu@imag.fr wrote:
Git-mediawiki's dumb push sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous
On 2013-08-20 08.43, Steffen Prohaska wrote:
[]
Thanks for V5. It was tested OK on my system here.
(And apologies for recommending a wrapper on top of a wrapper).
One question is left:
As xread() is tolerant against EAGAIN and especially EINTR,
could it make sense to replace read() with xread()
On Thu, Aug 15, 2013 at 11:31 AM, Stefan Monnier
monn...@iro.umontreal.ca wrote:
I've had good success recently with the git-bzr bridge, but the
following still fails. This is on Debian with the git from unstable.
Which version are you using? The latest version works fine here:
On Wed, Aug 21, 2013 at 2:48 PM, Ralf Thielow ralf.thie...@gmail.com wrote:
When merge.log config is set, rebase --preserve-merges
will add the log lines to the message of the rebased merge
commit.
A rebase should not modify a commit message automatically.
Teach git-rebase to ignore that
Junio C Hamano gits...@pobox.com writes:
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index f8d7d2c..13919ad 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -53,6 +53,7
With 2eac2a4: ls-files -k: a directory only can be killed if the index has a
non-directory applied, t3010 fails test 3 validate git ls-files -k output.
It ends up missing the pathx/ju/nk file.
OS X 10.8.4
Xcode 4.6.3
clang Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
~~
From: Brandon Casey draf...@gmail.com
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, does not understand the
array+=() notation. Let's use an explicit assignment to the new array
element which works everywhere, like:
From: Brandon Casey draf...@gmail.com
The syntax for retrieving the number of elements in an array is:
${#name[@]}
Signed-off-by: Brandon Casey draf...@gmail.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Aug 16, 2013 at 11:01:38AM -0400, Jeff King wrote:
That makes me inclined to teach index-pack to reject duplicate objects
in a single pack in order to prevent denial-of-service attacks. We can
potentially make them work in all code paths, but given that nobody
should be doing this
From: Brandon Casey draf...@gmail.com
This reverts commit 69a8141a5d81925b7e08cb228535e9ea4a7a02e3.
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, does not have a printf that
supports -v. Let's revert this patch and go back to using
The sha1_entry_pos function tries to be smart about
selecting the middle of a range for its binary search by
looking at the value differences between the lo and hi
constraints. However, it is unable to cope with entries with
duplicate keys in the sorted list.
We may hit a point in the search
Git should never generate packs with duplicate objects.
However, we may see such packs due to bugs in Git or other
implementations (e.g., JGit had such a bug a few years ago).
In theory, such packs should not be a problem for us (we
will simply find one of the instances of the object when
looking
When we are building the pack index, we can notice that
there are duplicate objects, pick one winner instance, and
mention the object only once in the index (mapped to the
winner's offset).
This has the effect that the duplicate packfile entries are
never found by lookup. The data still exists in
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy matthieu@imag.fr wrote:
Felipe: Is this the right fix for git-remote-mediawiki? Any better idea?
Why not keep track of the revisions yourself? You can have file where
you store which was
Brian Gernhardt br...@gernhardtsoftware.com writes:
With 2eac2a4: ls-files -k: a directory only can be killed if the index has a
non-directory applied, t3010 fails test 3 validate git ls-files -k output.
It ends up missing the pathx/ju/nk file.
OS X 10.8.4
Xcode 4.6.3
clang Apple LLVM
Junio C Hamano gits...@pobox.com writes:
Stefan Beller stefanbel...@googlemail.com writes:
The motivation of this patch is to get closer to a goal of being
able to have a core subset of git functionality built in to git.
That would mean
* people on Windows could get a copy of at least the
On Wed, Aug 21, 2013 at 08:45:13PM +0700, Nguyen Thai Ngoc Duy wrote:
On the topic, C Git's (maybe) violations on this spec are:
- The client does not strip trailing slashes from $GIT_URL before
sending to the server, as described in section URL Format.
Yeah. We get the basic gist
On Wed, Aug 21, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote:
Brandon Casey bca...@nvidia.com writes:
From: Brandon Casey draf...@gmail.com
This reverts commit 69a8141a5d81925b7e08cb228535e9ea4a7a02e3.
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms
Jeff King p...@peff.net writes:
Which leaves the open question: should the default for index-pack flip
to reject duplicates rather than allow?
I'd say so.
In am emergency, people with broken packfiles can feed them to
unpack-objects ;-)
More seriously, an alternative emergency mode may be an
Ralf Thielow ralf.thie...@gmail.com writes:
When merge.log config is set, rebase --preserve-merges
will add the log lines to the message of the rebased merge
commit.
A rebase should not modify a commit message automatically.
Teach git-rebase to ignore that configuration by passing --no-log
Stefan Beller stefanbel...@googlemail.com writes:
+static int delta_base_offset = 1;
+char *packdir;
Does this have to be global?
We could pass it to all the functions, making it not global.
Sorry for being unclear; I meant not static. It is perfectly fine
for this to be a file-scope
On 08/22/2013 12:50 AM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
+static int delta_base_offset = 1;
+char *packdir;
Does this have to be global?
We could pass it to all the functions, making it not global.
Sorry for being unclear; I meant not static. It
Eric Sunshine sunsh...@sunshineco.com writes:
This set of patches was meant to be a re-roll of [1] addressing Junio's
comments, however [1] graduated to 'next' before I found time to work on
it further, so these are instead incremental patches atop 'next'.
Just FYI, 'next' will be rewound
Eric Sunshine sunsh...@sunshineco.com writes:
As its very first action, t3404 installs (via set_fake_editor) a
specialized $EDITOR which simplifies automated 'rebase -i' testing. Many
tests rely upon this setting, thus tests which need a different editor
must take extra care upon completion
2013/8/21 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com writes:
$ git status
# On branch topic
# Your branch is based on 'topicbase', but the upstream is gone.
# (use git branch --unset-upstream to fixup)
Sorry, I didn't follow closely the
Rasmus Villemoes r...@rasmusvillemoes.dk writes:
Rasmus Villemoes r...@rasmusvillemoes.dk writes:
my %config_path_settings = (
@@ -311,6 +314,7 @@ my $rc = GetOptions(h = \$help,
8bit-encoding=s = \$auto_8bit_encoding,
compose-encoding=s = \$compose_encoding,
Brandon Casey draf...@gmail.com writes:
On Wed, Aug 21, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote:
Brandon Casey bca...@nvidia.com writes:
From: Brandon Casey draf...@gmail.com
This reverts commit 69a8141a5d81925b7e08cb228535e9ea4a7a02e3.
Old Bash (3.0) which is distributed
On Wed, Aug 21, 2013 at 5:22 PM, Junio C Hamano gits...@pobox.com wrote:
Brandon Casey draf...@gmail.com writes:
On Wed, Aug 21, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote:
# on load...
printf -v __git_printf_supports_v -- %s yes /dev/null 21
...
On Wed, Aug 21, 2013 at 04:20:07PM -0700, Junio C Hamano wrote:
I do not understand the last bit. If two copies of an object exist
but you have only one slot for the object in the index, and another
object names it as its base with ref-delta, then reconstituting it
should work just
From: Brandon Casey draf...@gmail.com
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, do not have a printf that
supports -v. Neither does Zsh (which is already handled in the code).
As suggested by Junio, let's test whether printf
I've had good success recently with the git-bzr bridge, but the
following still fails. This is on Debian with the git from unstable.
Which version are you using?
The one that comes in Debian unstable.
The latest version works fine here:
Brandon Casey draf...@gmail.com writes:
Why is ${var-} necessary? Wouldn't that be equivalent to ${var}
or $var?
set -u
--
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
From: Brandon Casey draf...@gmail.com
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, do not have a printf that
supports -v. Neither does Zsh (which is already handled in the code).
As suggested by Junio, let's test whether printf
67 matches
Mail list logo
