Nguyễn Thái Ngọc Duy writes:
> > The two possible fixes which I see are:
> >
> > 1) Replace back if (alternate_shallow_file) condition in fetch pack with
> >if (args->depth > 0)
> >
> > 2) alternate_shallow_file should be copy of shallow_lock.filename not a
> >reference to it
>
>
Jonathan Nieder writes:
> In other words, why not use something like this?
>
> write_index: optionally allow broken null sha1s
>
> Commit 4337b58 (do not write null sha1s to on-disk index, 2012-07-28)
> added a safety check preventing git from writing null sha1s into the
>
Eric Sunshine 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 decided that a fix at
Jonathan Nieder writes:
> Eric Sunshine wrote:
>> On Sun, Aug 25, 2013 at 1:55 AM, Jonathan Nieder wrote:
>
>>> Would be clearer if the code in a subshell were indented:
>>>
>>> (
>>> unset test_tick &&
>>> test_commit ...
>>> )
>>
>> I considered
Jeff King 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 fence.
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 s
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 > f
--
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
On Sun, Aug 25, 2013 at 6:51 PM, Jeff King 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 static glo
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
--
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
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 2>err &&
> + grep "Object ref '\''mytag'\'' is of type '\''tag'\''" err &&
Uh, this hurts in the eye! Please wr
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
From: Johannes Sixt
> 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 =
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, NU
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 bec
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
On Sun, Aug 25, 2013 at 12:30 PM, Jeff King wrote:
> 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 re
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
---
Documentation/git-replace.txt | 7 ---
1 file changed, 4 inse
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
w
There were no hints in the documentation about how to create
replacement objects.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index aa66d27..7
Signed-off-by: Christian Couder
---
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 @@ test_expect_success 'not just comm
Signed-off-by: Christian Couder
---
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 'replaced and replaceme
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 o
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.o
>
> 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
>
> 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
>
> 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 http://vger.kerne
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,
"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 " 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 exis
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
On Sun, Aug 25, 2013 at 7:16 AM, Junio C Hamano wrote:
> Jeff King 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 you queued has clear_ma
> >
> > - 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
>
> 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
> >
> > -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'
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 allo
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 wit
Eric Sunshine wrote:
> On Sun, Aug 25, 2013 at 1:55 AM, Jonathan Nieder 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 coupl
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
>
> 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)
> --
>
> 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 peopl
On Sun, Aug 25, 2013 at 2:00 AM, Jonathan Nieder 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 respect
> [...
On Sun, Aug 25, 2013 at 1:55 AM, Jonathan Nieder 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 functio
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
ind
44 matches
Mail list logo
