Eric Sunshine wrote:
Although undocumented, directory_exists_in_index_icase(dirname,len)
unconditionally assumes the presence of a '/' at dirname[len] (despite
being past the end-of-string). Callers are expected to respect
[...]
Fix this problem.
Hi,
Jeff King wrote:
---
I was tempted to not involve filter-branch in this commit at all, and
instead require the user to manually invoke
GIT_ALLOW_NULL_SHA1=1 git filter-branch ...
to perform such a filter. That would be slightly safer, but requires
some specialized knowledge from
Eric Sunshine wrote:
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1037,4 +1037,28 @@ test_expect_success 'rebase -i with --strategy and -X'
'
test $(cat file1) = Z
'
+test_expect_success 'short SHA-1 setup' '
+ test_when_finished git checkout
Jonathan Nieder jrnie...@gmail.com writes:
Kacper Kornet wrote:
In the test 'using invalid commit with -C' git-commit would have failed
even if the -C option had been given the correct commit, as there was
nothing to commit.
Good catch.
[...]
--- a/t/t7501-commit.sh
+++
Junio C Hamano wrote:
Kacper Kornet wrote:
In the test 'using invalid commit with -C' git-commit would have failed
even if the -C option had been given the correct commit, as there was
nothing to commit.
[...]
Also it would be much simpler to say git commit --allow-empty.
Sounds good. ;-)
Jonathan Nieder jrnie...@gmail.com writes:
Kacper Kornet wrote:
Signed-off-by: Kacper Kornet drae...@pld-linux.org
Thanks.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Here's a style cleanup on top.
-- 8 --
Subject: reset test: modernize style
Avoid command substitution and pipes
Junio C Hamano wrote:
The change to the one that feeds 'y' to reset -p may be a bit too
pedantic, as we are not in the business of testing echo y, though.
Yeah, that's true. Here's a patch for squashing in.
diff --git i/t/t7106-reset-unborn-branch.sh w/t/t7106-reset-unborn-branch.sh
index
On Sun, Aug 25, 2013 at 1:55 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Eric Sunshine wrote:
The short SHA-1 collision test requires carefully crafted commits in
order to ensure a collision at rebase time.
Yeah, this breaks the usual rule that tests should be independent
of hashing
On Sun, Aug 25, 2013 at 2:00 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Eric Sunshine wrote:
Although undocumented, directory_exists_in_index_icase(dirname,len)
unconditionally assumes the presence of a '/' at dirname[len] (despite
being past the end-of-string). Callers are expected to
I wonder if this longer wall of text (added in 13be3e31, 2010-01-29)
is too aggressive.
It is the only piece of advice that I explicitly disable in
~/.gitconfig, so I haven't looked at it again for a while. Since
then, the usual stream of questions about how to recover from people
who
Sure. I wonder if there should be some text to replace the output
that mentions the pack being created, though. E.g.:
You can then run
Total 6020 (delta 4070), reused 0 (delta 0)
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only end - buf
bytes
Eric Sunshine wrote:
On Sun, Aug 25, 2013 at 1:55 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Would be clearer if the code in a subshell were indented:
(
unset test_tick
test_commit ...
)
I considered it, but decided against it for a
On Sun, Aug 25, 2013 at 04:45:50AM -0400, Jeff King wrote:
This is the minimal fix. Another option would be to switch
read_mailmap_buf to read_mailmap_string, and I think we could even get
away with avoiding the extra allocation/copy in the loop (because
read_mailmap_line seems to cope with
On Sun, Aug 25, 2013 at 04:55:00AM -0400, Jeff King wrote:
On Sun, Aug 25, 2013 at 04:45:50AM -0400, Jeff King wrote:
This is the minimal fix. Another option would be to switch
read_mailmap_buf to read_mailmap_string, and I think we could even get
away with avoiding the extra
-Or you can use linkgit:git-name-rev[1], which will give the commit a
+or you can use linkgit:git-name-rev[1], which will give the commit a
I think this reads better with a capital 'O'. (The pedant in me
likes it, too, since a colon ends a sentence.)
The lowercase 'but' later in
That's a mouthful. I'd say
To update the index with the contents of a new or modified file, use
OK; thanks! I will change this.
---
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
- A test tree into which patches are initially placed so that they
can get some exposure when integrated with other ongoing development.
- This tree is available to Andrew for pulling into -mm whenever he
- wants.
This drops useful information (namely, that Tony was
On Sun, Aug 25, 2013 at 7:16 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
Do we need to clear_mailmap before returning to avoid a leak?
Good question. What I queued yesterday seems to have a call to
clear_mailmap(mailmap) before that return.
Indeed, the version
On Sat, Aug 24, 2013 at 11:15:00PM -0700, Jonathan Nieder wrote:
I was tempted to not involve filter-branch in this commit at all, and
instead require the user to manually invoke
GIT_ALLOW_NULL_SHA1=1 git filter-branch ...
to perform such a filter. That would be slightly safer, but
git commit --author=$name sets the author to one whose name
matches the given string from existing commits, when $name is not in
the Name e-mail format. However, it does not honor the mailmap
to use the canonical name for the author found this way.
Fix it by telling the logic to find a matching
On Sun, Aug 25, 2013 at 12:01:29PM +0200, Antoine Pelisse wrote:
So I kept clear_mailmap() where you put it, but I think it could be moved
right after get_revision(). That is because I think format_commit_message()
will run another read_mailmap() with an heap-allocated string_list.
Anyway,
Hm. It's been too long since I was a novice, since I find the above
clear already.
OK; I will drop that patch.
---
Thomas
--
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
But is this correct? I somehow thought that we check with the
current or the upstream.
You are correct. I will add this. Thanks.
---
Thomas
--
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
Maybe the intent is
Git can help you perform a three-way merge, which can in turn be
used for a many-way merge by repeating the merge procedure several
times. The usual situation is that you only do one three-way merge
(reconciling two lines of history) and commit
I need your partnership in a business transaction worth $18.2m USD for you
to handle with me. Are you interested?
--
Independencia y Patria Socialista, Viviremos y Venceremos
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index decdc33..8f631ac 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -263,4 +263,17 @@
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 8f631ac..4807689 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,4 +276,10 @@ test_expect_success
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
There is no case where one object can be replaced with one
There were no hints in the documentation about how to create
replacement objects.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-replace.txt
A previous patch ensures that both the replaced and the replacement
objects passed to git replace must be of the same type.
While at it state that there is no other restriction on both objects.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 7 ---
Here is a reroll of the patch forbiding replacing an bject with one
of a different type (1/5).
It is followed by a documentation update (2/5) and a test (3/5).
I also added for good mesure another test (4/5) I came up with while
developing the previous test, and another doc update related to what
cmt...@gmail.com wrote on Fri, 23 Aug 2013 07:48 -0400:
On Fri, Aug 23, 2013 at 08:16:58AM +0100, Luke Diamand wrote:
On 23/08/13 02:12, Corey Thompson wrote:
Hello,
Has anyone actually gotten git-p4 to clone a large Perforce repository?
Yes. I've cloned repos with a couple of Gig
On Sun, Aug 25, 2013 at 03:37:24PM +0200, Antoine Pelisse wrote:
So we would stop passing mailmap string_list along down to map_user(),
and the mailmap file (or blob) would be read the first time it's
needed, and stored in a static global variable in mailmap.c. I think
I'm OK with that
Am 25.08.2013 15:06, schrieb Christian Couder:
@@ -100,6 +101,15 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
if (check_refname_format(ref, 0))
die('%s' is not a valid ref name., ref);
+ obj_type = sha1_object_info(object, NULL);
+
From: Johannes Sixt j...@kdbg.org
Am 25.08.2013 15:06, schrieb Christian Couder:
@@ -100,6 +101,15 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
if (check_refname_format(ref, 0))
die('%s' is not a valid ref name., ref);
+obj_type =
On Sun, Aug 25, 2013 at 05:58:18AM -0400, Jeff King wrote:
On Sat, Aug 24, 2013 at 11:15:00PM -0700, Jonathan Nieder wrote:
I was tempted to not involve filter-branch in this commit at all, and
instead require the user to manually invoke
GIT_ALLOW_NULL_SHA1=1 git filter-branch ...
to
Am 25.08.2013 15:06, schrieb Christian Couder:
+test_expect_success 'replaced and replacement objects must be of the same
type' '
+ test_must_fail git replace mytag $HASH1 2err
+ grep Object ref '\''mytag'\'' is of type '\''tag'\'' err
Uh, this hurts in the eye! Please write this
Thomas Ackermann wrote:
Maybe the intent is
Git can help you perform a three-way merge, which can in turn be
[...]
If you don't mind I will use your text
No problem.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the
Am 25.08.2013 21:44, schrieb Christian Couder:
What about:
die(Objects must be of the same type.\n
'%s' points to a replaced object of type '%s'\n
while '%s' points to a replacement object of type '%s'.,
Much better!
-- Hannes
--
To
On Sun, Aug 25, 2013 at 6:51 PM, Jeff King p...@peff.net wrote:
On Sun, Aug 25, 2013 at 03:37:24PM +0200, Antoine Pelisse wrote:
So we would stop passing mailmap string_list along down to map_user(),
and the mailmap file (or blob) would be read the first time it's
needed, and stored in a
--
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
Starting from 6035d6a fetch-pack: prepare updated shallow file before
fetching the pack the shallow fetches of commits with tags can result
in broken git repo. The following script illustrates the problem:
#!/bin/sh
mkdir repo1 repo2
cd repo1
git init
for i in `seq 1 3`; do
echo $i foo
fetch_pack() can remove .git/shallow file when a shallow repository
becomes a full one again. This behavior is triggered incorrectly when
tags are also fetched because fetch_pack() will be called twice. At
the first fetch_pack() call:
- shallow_lock is set up
- alternate_shallow_file points to
Jeff King p...@peff.net writes:
Exactly. Sample (largely untested) patch is below if you want to use it
as a starting point. There are probably a few additional cleanups on top
(e.g., git log understands --mailmap, which should probably be
centralized to handle_revision_opt).
I'm on the
Jonathan Nieder jrnie...@gmail.com writes:
Eric Sunshine wrote:
On Sun, Aug 25, 2013 at 1:55 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Would be clearer if the code in a subshell were indented:
(
unset test_tick
test_commit ...
)
I
Eric Sunshine sunsh...@sunshineco.com writes:
... A
follow-up series [2] fixes both directory_exists_in_index() and
directory_exists_in_index_icase() to be more liberal in what they
accept, relieving the caller of the burden. By the time that series
was posted, however, Junio and Peff had
47 matches
Mail list logo
