* Re: [PATCH v4 00/13] New remote-hg helper
From: Johannes Schindelin @ 2012-10-30 17:20 UTC (permalink / raw)
To: Jeff King
Cc: Felipe Contreras, git, Junio C Hamano, Sverre Rabbelier,
Ilari Liusvaara, Daniel Barkalow, Michael J Gruber
In-Reply-To: <20121029215631.GF20513@sigill.intra.peff.net>
Hi all,
On Mon, 29 Oct 2012, Jeff King wrote:
> On Mon, Oct 29, 2012 at 10:47:04PM +0100, Felipe Contreras wrote:
>
> > >> Yeah, the test script is not ready for merging, it needs to check
> > >> for python, hg, and hg-git.
> > >>
> > >> Do you have hg-git installed?
> > >
> > > No. But it's important that it fail gracefully; I can't even take it
> > > in pu if I can't run the test suite in a sane way.
> >
> > The contrib part is fine for 'pu'. The tests aren't even meant to
> > exercise stuff in 'contrib', right? There might be some exceptions,
> > but either way, there's plenty of stuff in 'contrib' without any
> > tests. The tests I'm providing are simply a little sugar.
>
> Yeah, contrib is a bit of a wildcard. Most things do not have tests.
Given that the tests of remote-hg as in git://github.com/msysgit/git's
'devel' branch run just fine without additional dependencies (which
probably triggered the not-quite-constructive and unnecessarily-flaming
"bloated" comment of Felipe), and given that the code in said branch is
well-tested and exercised by daily use, and given the fact that my major
concern was not understood (and probably not addressed), and also given
the fact that Sverre indicated that he could finalize the work as a 20%
project, I decided that other projects I have to do unfortunately have a
too-high priority to take care of testing and measuring the performance of
the patch series that is discussed in this thread.
Sorry,
Johannes
P.S.: I would still recommend to have a detailed look at the 'devel'
branch, in particular the commits starting with "fast-export: do not refer
to non-existing marks" and ending with "t5801: skip without hg". My
understanding is that it was completely ignored after a brief and maybe
too-cursory look. In the least, it has a couple of lessons we learnt the
hard way, and if git.git is dead set on duplicating the work, making these
mistakes again could be avoided by learning from our lessons.
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-30 17:18 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Michael J Gruber
In-Reply-To: <20121029220604.GA21712@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 11:06 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 11:02:31PM +0100, Felipe Contreras wrote:
>
>> > If remote-hg is going to live in contrib, it probably makes sense to
>> > have its tests live there, too, like subtree.
>>
>> Probably, I'll check that option.
>>
>> But eventually I think it should be installed by default, unless
>> somebody can come up for a reason not to. For now contrib might be OK.
>
> I would one day like to have it as part of the main distribution, too,
> but it would be nice to prove its worth in the field for a while first.
> I especially would like to find out how it compares in practice with the
> work that is in msysgit.
Yeah, I would like to compare it with that work, if only the patches
were readily available somewhere.
--
Felipe Contreras
^ permalink raw reply
* Re: git push tags
From: Chris Rorvick @ 2012-10-30 17:09 UTC (permalink / raw)
To: Jeff King
Cc: Kacper Kornet, Drew Northup, Michael Haggerty, Angelo Borsotti,
Philip Oakley, Johannes Sixt, git
In-Reply-To: <20121029213508.GB20513@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 4:35 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 06:23:30PM +0100, Kacper Kornet wrote:
>
>> > That patch just blocks non-forced updates to refs/tags/. I think a saner
>> > start would be to disallow updating non-commit objects without a force.
>> > We already do so for blobs and trees because they are not (and cannot
>> > be) fast forwards. The fact that annotated tags are checked for
>> > fast-forward seems to me to be a case of "it happens to work that way"
>> > and not anything planned. Since such a push drops the reference to the
>> > old version of the tag, it should probably require a force.
>>
>> I'm not sure. Looking at 37fde87 ("Fix send-pack for non-commitish
>> tags.") I have an impression that Junio allowed for fast-forward pushes
>> of annotated tags on purpose.
>
> Hmm. You're right, though I'm not sure I agree with the reasoning of
> that commit. I'd certainly like to get Junio's input on the subject.
>
>> > Then on top of that we can talk about what lightweight tags should do.
>> > I'm not sure. Following the regular fast-forward rules makes some sense
>> > to me, because you are never losing objects. But there may be
>> > complications with updating tags in general because of fetch's rules,
>> > and we would be better off preventing people from accidentally doing so.
>> > I think a careful review of fetch's tag rules would be in order before
>> > making any decision there.
>>
>> The problem with the current behaviour is, that one can never be 100% sure
>> that his push will not overwrite someone else tag.
>
> Yes, although you do know that you are not throwing away history if you
> do (because it must be a fast forward). Whereas if you have to use "-f"
> to update a tag, then you have turned off all safety checks. So it is an
> improvement for one case (creating a tag), but a regression for another
> (updating an existing tag). I agree that the latter is probably less
> common, but how much? If virtually nobody is doing it because git-fetch
> makes the fetching side too difficult, then the regression is probably
> not a big deal.
>
> -Peff
This is probably a bit premature given there are still open questions,
but I was curious and decided to take a stab at this.
The change is to only allow fast-forward when both the old and new are
commits and the reference is not a lightweight tag. All other
reference updates require --force. I think this resolves the reported
issue and takes into account feedback on this thread. This change
only broke one test and it was an expected failure given the change in
behavior (i.e., I needed to add a "-f" to update a tag in the remote.)
I wasn't sure how to handle provided feedback to the user when there
are multiple refs not pushed for different reasons. But I think this
adds the plumbing for handling it correctly, whateverever that this.
It needs some work, but thought I'd throw it out for feedback to see
if it's at least in the right direction.
Chris
--- 8< ---
diff --git a/builtin/push.c b/builtin/push.c
index db9ba30..fabcea0 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -220,6 +220,10 @@ static const char message_advice_checkout_pull_push[] =
"(e.g. 'git pull') before pushing again.\n"
"See the 'Note about fast-forwards' in 'git push --help' for details.");
+static const char message_advice_ref_already_exists[] =
+ N_("Updates were rejected because a matching reference already exists in\n"
+ "the remote. Use git push -f if you really want to make this update.");
+
static void advise_pull_before_push(void)
{
if (!advice_push_non_ff_current || !advice_push_nonfastforward)
@@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
advise(_(message_advice_checkout_pull_push));
}
+static void advise_ref_already_exists(void)
+{
+ advise(_(message_advice_ref_already_exists));
+}
+
static int push_with_options(struct transport *transport, int flags)
{
int err;
@@ -277,6 +286,9 @@ static int push_with_options(struct transport
*transport, int flags)
else
advise_checkout_pull_push();
break;
+ case ALREADY_EXISTS:
+ advise_ref_already_exists();
+ break;
}
return 1;
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 7d05064..f159ec3 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -202,6 +202,11 @@ static void print_helper_status(struct ref *ref)
msg = "non-fast forward";
break;
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
+ res = "error";
+ msg = "already exists";
+ break;
+
case REF_STATUS_REJECT_NODELETE:
case REF_STATUS_REMOTE_REJECT:
res = "error";
@@ -288,6 +293,7 @@ int send_pack(struct send_pack_args *args,
/* Check for statuses set by set_ref_status_for_push() */
switch (ref->status) {
case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
case REF_STATUS_UPTODATE:
continue;
default:
diff --git a/cache.h b/cache.h
index a58df84..2d160a9 100644
--- a/cache.h
+++ b/cache.h
@@ -1002,11 +1002,14 @@ struct ref {
unsigned int force:1,
merge:1,
nonfastforward:1,
+ forwardable:1,
+ update:1,
deletion:1;
enum {
REF_STATUS_NONE = 0,
REF_STATUS_OK,
REF_STATUS_REJECT_NONFASTFORWARD,
+ REF_STATUS_REJECT_ALREADY_EXISTS,
REF_STATUS_REJECT_NODELETE,
REF_STATUS_UPTODATE,
REF_STATUS_REMOTE_REJECT,
diff --git a/remote.c b/remote.c
index 04fd9ea..0d94888 100644
--- a/remote.c
+++ b/remote.c
@@ -1309,22 +1309,42 @@ void set_ref_status_for_push(struct ref
*remote_refs, int send_mirror,
* to overwrite it; you would not know what you are losing
* otherwise.
*
- * (3) if both new and old are commit-ish, and new is a
- * descendant of old, it is OK.
+ * (3) if both new and old are commits, the reference is not
+ * a tag, and new is a descendant of old, it is OK.
*
* (4) regardless of all of the above, removing :B is
* always allowed.
*/
- ref->nonfastforward =
+ ref->update =
!ref->deletion &&
- !is_null_sha1(ref->old_sha1) &&
+ !is_null_sha1(ref->old_sha1);
+
+ ref->nonfastforward =
+ ref->update &&
(!has_sha1_file(ref->old_sha1)
|| !ref_newer(ref->new_sha1, ref->old_sha1));
- if (ref->nonfastforward && !ref->force && !force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
- continue;
+ if (prefixcmp(ref->name, "refs/tags/")) {
+ struct object *old = parse_object(ref->old_sha1);
+ struct object *new = parse_object(ref->new_sha1);
+ ref->forwardable = (old && new &&
+ old->type == OBJ_COMMIT && new->type == OBJ_COMMIT);
+ } else
+ ref->forwardable = 0;
+
+ if (!ref->force && !force_update) {
+ if (ref->forwardable) {
+ if (ref->nonfastforward) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
+ } else {
+ if (ref->update) {
+ ref->status = REF_STATUS_REJECT_ALREADY_EXISTS;
+ continue;
+ }
+ }
}
}
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index b5417cc..cff559f 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -368,7 +368,7 @@ test_expect_success 'push with colon-less refspec (2)' '
git branch -D frotz
fi &&
git tag -f frotz &&
- git push testrepo frotz &&
+ git push -f testrepo frotz &&
check_push_result $the_commit tags/frotz &&
check_push_result $the_first_commit heads/frotz
@@ -929,6 +929,34 @@ test_expect_success 'push into aliased refs
(inconsistent)' '
)
'
+test_expect_success 'push tag requires --force to update remote tag' '
+ mk_test heads/master &&
+ mk_child child1 &&
+ mk_child child2 &&
+ (
+ cd child1 &&
+ git tag lw_tag &&
+ git tag -a -m "message 1" ann_tag &&
+ git push ../child2 lw_tag &&
+ git push ../child2 ann_tag &&
+ >file1 &&
+ git add file1 &&
+ git commit -m "file1" &&
+ git tag -f lw_tag &&
+ git tag -f -a -m "message 2" ann_tag &&
+ ! git push ../child2 lw_tag &&
+ ! git push ../child2 ann_tag &&
+ git push --force ../child2 lw_tag &&
+ git push --force ../child2 ann_tag &&
+ git tag -f lw_tag HEAD~ &&
+ git tag -f -a -m "message 3" ann_tag &&
+ ! git push ../child2 lw_tag &&
+ ! git push ../child2 ann_tag &&
+ git push --force ../child2 lw_tag &&
+ git push --force ../child2 ann_tag
+ )
+'
+
test_expect_success 'push --porcelain' '
mk_empty &&
echo >.git/foo "To testrepo" &&
diff --git a/transport-helper.c b/transport-helper.c
index cfe0988..ef9a6f8 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -643,6 +643,11 @@ static void push_update_ref_status(struct strbuf *buf,
free(msg);
msg = NULL;
}
+ else if (!strcmp(msg, "already exists")) {
+ status = REF_STATUS_REJECT_ALREADY_EXISTS;
+ free(msg);
+ msg = NULL;
+ }
}
if (*ref)
@@ -702,6 +707,7 @@ static int push_refs_with_push(struct transport *transport,
/* Check for statuses set by set_ref_status_for_push() */
switch (ref->status) {
case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
case REF_STATUS_UPTODATE:
continue;
default:
diff --git a/transport.c b/transport.c
index 9932f40..d218884 100644
--- a/transport.c
+++ b/transport.c
@@ -659,7 +659,7 @@ static void print_ok_ref_status(struct ref *ref,
int porcelain)
const char *msg;
strcpy(quickref, status_abbrev(ref->old_sha1));
- if (ref->nonfastforward) {
+ if (ref->nonfastforward || (!ref->forwardable && ref->update)) {
strcat(quickref, "...");
type = '+';
msg = "forced update";
@@ -695,6 +695,10 @@ static int print_one_push_status(struct ref *ref,
const char *dest, int count, i
print_ref_status('!', "[rejected]", ref, ref->peer_ref,
"non-fast-forward", porcelain);
break;
+ case REF_STATUS_REJECT_ALREADY_EXISTS:
+ print_ref_status('!', "[rejected]", ref, ref->peer_ref,
+ "already exists", porcelain);
+ break;
case REF_STATUS_REMOTE_REJECT:
print_ref_status('!', "[remote rejected]", ref,
ref->deletion ? NULL : ref->peer_ref,
@@ -714,7 +718,7 @@ static int print_one_push_status(struct ref *ref,
const char *dest, int count, i
}
void transport_print_push_status(const char *dest, struct ref *refs,
- int verbose, int porcelain, int *nonfastforward)
+ int verbose, int porcelain, int *willnotupdate)
{
struct ref *ref;
int n = 0;
@@ -733,18 +737,21 @@ void transport_print_push_status(const char
*dest, struct ref *refs,
if (ref->status == REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
- *nonfastforward = 0;
+ *willnotupdate = 0;
for (ref = refs; ref; ref = ref->next) {
if (ref->status != REF_STATUS_NONE &&
ref->status != REF_STATUS_UPTODATE &&
ref->status != REF_STATUS_OK)
n += print_one_push_status(ref, dest, n, porcelain);
if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD &&
- *nonfastforward != NON_FF_HEAD) {
+ *willnotupdate != NON_FF_HEAD) {
if (!strcmp(head, ref->name))
- *nonfastforward = NON_FF_HEAD;
+ *willnotupdate = NON_FF_HEAD;
else
- *nonfastforward = NON_FF_OTHER;
+ *willnotupdate = NON_FF_OTHER;
+ } else if (ref->status == REF_STATUS_REJECT_ALREADY_EXISTS &&
+ *willnotupdate == 0) {
+ *willnotupdate = ALREADY_EXISTS;
}
}
}
@@ -1031,9 +1038,9 @@ static void die_with_unpushed_submodules(struct
string_list *needs_pushing)
int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
- int *nonfastforward)
+ int *willnotupdate)
{
- *nonfastforward = 0;
+ *willnotupdate = 0;
transport_verify_remote_names(refspec_nr, refspec);
if (transport->push) {
@@ -1099,7 +1106,7 @@ int transport_push(struct transport *transport,
if (!quiet || err)
transport_print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
- nonfastforward);
+ willnotupdate);
if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
set_upstreams(transport, remote_refs, pretend);
diff --git a/transport.h b/transport.h
index 3b21c4a..326271e 100644
--- a/transport.h
+++ b/transport.h
@@ -142,6 +142,7 @@ void transport_set_verbosity(struct transport
*transport, int verbosity,
#define NON_FF_HEAD 1
#define NON_FF_OTHER 2
+#define ALREADY_EXISTS 3
int transport_push(struct transport *connection,
int refspec_nr, const char **refspec, int flags,
int * nonfastforward);
@@ -170,7 +171,7 @@ void transport_update_tracking_ref(struct remote
*remote, struct ref *ref, int v
int transport_refs_pushed(struct ref *ref);
void transport_print_push_status(const char *dest, struct ref *refs,
- int verbose, int porcelain, int *nonfastforward);
+ int verbose, int porcelain, int *willnotupdate);
typedef void alternate_ref_fn(const struct ref *, void *);
extern void for_each_alternate_ref(alternate_ref_fn, void *);
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v6 0/3] completion: refactor and zsh wrapper
From: Felipe Contreras @ 2012-10-30 16:15 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Matthieu Moy,
Felipe Contreras
In-Reply-To: <1350870342-22653-1-git-send-email-felipe.contreras@gmail.com>
Hi,
On Mon, Oct 22, 2012 at 3:45 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Here's a bit of reorganition. I'm introducing a new __gitcompadd helper that is
> useful to wrapp all changes to COMPREPLY, but first, lets get rid of
> unnecessary assignments as SZEDER suggested.
>
> The zsh wrapper is now very very simple.
Junio, Jeff, just to let you know, this is an updated version of the
new zsh wrapper patch series with the feedback from SZEDER. I see the
old version is in pu, and hasn't been updated.
Cheers.
> Since v5:
>
> * Get rid of unnecessary COMPREPLY assignments
>
> Felipe Contreras (3):
> completion: get rid of empty COMPREPLY assignments
> completion: add new __gitcompadd helper
> completion: add new zsh completion
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] test-lib: avoid full path to store test results
From: Felipe Contreras @ 2012-10-30 16:02 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Junio C Hamano, Jeff King, Ævar Arnfjörð,
Johannes Sixt
In-Reply-To: <20121030044609.GA10873@elie.Belkin>
On Tue, Oct 30, 2012 at 5:46 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> No reason to use the full path in case this is used externally.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>
> "No reason not to" is not a reason to do anything. What symptoms does
> this prevent? Could you describe the benefit of this patch in a
> paragraph starting "Now you can ..."?
./test-lib.sh: line 394:
/home/felipec/dev/git/t/test-results//home/felipec/dev/git/contrib/remote-hg/test-21865.counts:
No such file or directory
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 00/14] New remote-hg helper
From: Felipe Contreras @ 2012-10-30 15:51 UTC (permalink / raw)
To: Chris Webb
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <20121030102526.GN4891@arachsys.com>
On Tue, Oct 30, 2012 at 11:25 AM, Chris Webb <chris@arachsys.com> wrote:
> Hi. I routinely work with projects in both hg and git, so I'm really
> interested in this. Thanks for working on it! I grabbed the latest version
> from
>
> https://github.com/felipec/git/blob/fc-remote-hg/contrib/remote-hg/git-remote-hg
>
> and have been trying it out. For the most part, it seems to work very nicely
> for the hg repos I have access to and can test against. I've spotted a couple
> of issues along the way that I thought would be worth reporting.
Great!
> The first is really a symptom of a general difference between hg and git: an hg
> repository can have multiple heads, whereas a git repo has exactly one head. To
> demonstrate:
> Now if I try to convert this:
>
> $ git clone hg::$PWD/hgtest gittest
> Cloning into 'gittest'...
> WARNING: Branch 'default' has more than one head, consider merging
> Traceback (most recent call last):
> File "/home/chris/bin/git-remote-hg", line 773, in <module>
> sys.exit(main(sys.argv))
> File "/home/chris/bin/git-remote-hg", line 759, in main
> do_list(parser)
> File "/home/chris/bin/git-remote-hg", line 463, in do_list
> list_branch_head(repo, cur)
> File "/home/chris/bin/git-remote-hg", line 425, in list_branch_head
> tip = get_branch_tip(repo, cur)
> File "/home/chris/bin/git-remote-hg", line 418, in get_branch_tip
> return repo.branchtip(branch)
> AttributeError: 'mqrepo' object has no attribute 'branchtip'
Yes, it seems this is an API issue; repo.branchtip doesn't exist in
python 2.2. I've added a check for that, and it should work fine now.
We'll be picking a random head (the first one), but the user has been
warned anyway.
> The second thing I spotted is the behaviour of bookmarks on push:
> i.e. the development bookmark hasn't been updated by the push. This might be
> connected to the warning message
This is not an API issue, this is a bug; bookmarks are not updated
(only the first creation works). I've fixed this as well, and added a
test with the example you put above:
http://github.com/felipec/git/commit/d006d54fc444484707dffa24d9fad053e574918d
Both issues should be fixed now :)
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Git clone fails with "bad pack header", how to get remote log
From: kevin molcard @ 2012-10-30 14:57 UTC (permalink / raw)
To: Konstantin Khomoutov
Cc: git-users-/JYPxA39Uh5TLH3MbocFFw, git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121029211854.b58c791d30a6c8d68665e574-g5ZlayWIM10NZ+ppGFcyYQ@public.gmane.org>
I tried to install git 1.8 on the remote server and get exactly the same
problem :(.
Kevin
On 10/29/12 6:18 PM, Konstantin Khomoutov wrote:
> On Mon, 29 Oct 2012 09:52:54 -0700 (PDT)
> Kevin Molcard <kev2041-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I have a problem with my build system.
>>
>> I have a remote server with a relatively large repository (around 12
>> GB, each branch having a size of 3 GB).
>>
>> I have also 2 build servers (Mac, Windows) that are cloning the repo
>> from the remote.
>>
>> Sometimes (very often when several git clone are sent at the same
>> time), I have the following error:
>>
>> remote: internal server error
>> fatal: protocol error: bad pack header
>>
>> I know that it happens when the remote is compressing objects (thanks
>> to `--progress -v` flags) because the last line of the log before the
>> erro is:
>> remote: Compressing objects: 93% (17959/19284) [K
>>
>> * So I have 2 questions, does anybody what is the problem and what
>> should I do?
>> * Is there a way to get a more precise log from the remote to debug
>> this problem?
> This reminds me of a bug fixed in 1.7.12.1 [1]:
>
> * When "git push" triggered the automatic gc on the receiving end, a
> message from "git prune" that said it was removing cruft leaked to
> the standard output, breaking the communication protocol.
>
> In any case, bugs should be reported to the main Git list (which is
> git at vger.kernel.org), not here.
> I'm Cc'ing the main Git list so you'll get any responses from there, if
> any.
>
> Kevin, please answer to this message (keeping all the Ccs -- use "Reply
> to group" or "Reply to all" in your MUA) and describe exactly what Git
> versions on which platforms your have.
>
> 1. https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.12.1.txt
>
--
You received this message because you are subscribed to the Google Groups "Git for human beings" group.
To post to this group, send email to git-users-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
^ permalink raw reply
* Re: Why does git-commit --template want the template to be modified ?
From: Francis Moreau @ 2012-10-30 14:23 UTC (permalink / raw)
To: Tomas Carnecky, Johannes Sixt; +Cc: git
In-Reply-To: <1351595365-ner-1835@calvin>
Hi,
On Tue, Oct 30, 2012 at 12:09 PM, Tomas Carnecky
<tomas.carnecky@gmail.com> wrote:
> On Tue, 30 Oct 2012 11:53:08 +0100, Francis Moreau <francis.moro@gmail.com> wrote:
>> Hi,
>>
>> I'm using git-commit with the --template option. The template I'm
>> given is self sufficient for my purpose but as stated in the
>> documentation, git-commit wants the template to be edited otherwise it
>> aborts the operation.
>>
>> Is it possible to change this ?
>
> It seems you want -F instead of --template.
Yes, but I want git to still parse the log and sanitize it (remove
trailing whitespaces, comments ...)
I actually found that "-F --edit" is what I needed.
Thanks both for your answer.
--
Francis
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)
From: Florian Achleitner @ 2012-10-30 12:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Michael Barr, Dmitry Ivankov, Jonathan Nieder
In-Reply-To: <7vmx045umh.fsf@alter.siamese.dyndns.org>
Sorry for reacting so late, I didn't read the list carefully in the last weeks
and my gmail filter somehow didn't trigger on that.
On Tuesday 02 October 2012 16:20:22 Junio C Hamano wrote:
> * fa/remote-svn (2012-09-19) 16 commits
> - Add a test script for remote-svn
> - remote-svn: add marks-file regeneration
> - Add a svnrdump-simulator replaying a dump file for testing
> - remote-svn: add incremental import
> - remote-svn: Activate import/export-marks for fast-import
> - Create a note for every imported commit containing svn metadata
> - vcs-svn: add fast_export_note to create notes
> - Allow reading svn dumps from files via file:// urls
> - remote-svn, vcs-svn: Enable fetching to private refs
> - When debug==1, start fast-import with "--stats" instead of "--quiet"
> - Add documentation for the 'bidi-import' capability of remote-helpers
> - Connect fast-import to the remote-helper via pipe, adding 'bidi-import'
> capability - Add argv_array_detach and argv_array_free_detached
> - Add svndump_init_fd to allow reading dumps from arbitrary FDs
> - Add git-remote-testsvn to Makefile
> - Implement a remote helper for svn in C
> (this branch is used by fa/vcs-svn.)
>
> A GSoC project.
> Waiting for comments from mentors and stakeholders.
>From my point of view, this is rather complete. It got eight review cycles on
the list.
Note that the remote helper can only fetch, pushing is not possible at all.
>
>
> * fa/vcs-svn (2012-09-19) 4 commits
> - vcs-svn: remove repo_tree
> - vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
> - vcs-svn/svndump: restructure node_ctx, rev_ctx handling
> - svndump: move struct definitions to .h
> (this branch uses fa/remote-svn.)
>
> A GSoC project.
> Waiting for comments from mentors and stakeholders.
This is the result of what I did when I wanted to start implementing branch
detection. I found that the existing code is not suitable and restructured it.
The main goal is to seperate svn revision parsing from git commit creation.
Because for creating commits, you need to know on which branch to create the
commit.
While for finding out which branch is the right one, you need to read the
complete svn revision first to see what dirs are changed and how.
It is rather invasive and it doesn't make sense without using it later on.
So I'm not surprised that you may not like it.
Anyways it passes all existing tests (that doesn't mean it's good of course
;))
Florian
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Jeff King @ 2012-10-30 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Oberndorfer, git
In-Reply-To: <da24b6ea-ac9b-46dd-b591-25fd4e8e6504@email.android.com>
On Tue, Oct 30, 2012 at 09:46:01PM +0900, Junio C Hamano wrote:
> (1) sounds attractive for more than one reason. In addition to
> avoidance of this issue, it would bring bug-to-bug compatibility
> across platforms.
Yeah. I mentioned breaking the build for people who would now need to
turn on NO_REGEX. But the only reason to do that is to let people on
glibc systems use the system version of the tools. A much saner approach
would be to just always build with our compat regex, and turn NO_REGEX
into a no-op. We already do the same thing for kwset.
> (4), if we can run grep on streaming data (tweak interface we have for
> checking out a large blob to the working tree), would let us work on
> dataset larger than fit in core. Even though it would be much more
> work, it might turn out to be a better option in the longer run.
Agreed, that would be nice. It's potentially a lot of work, but we could
probably get by with a special streaming version of diff_populate_filespec.
The tricky thing is that we have to run the regex matcher progressively
as we stream data in (since your match might fall in the middle of a
read boundary). Which is certainly going to require switching off of
regular regexec. I don't think glibc regex will handle it either,
though. It looks like pcre can report a partial match at the end of the
string, and you can either continue with the next chunk (if using
pcre_dfa) or append and re-start the pattern match (for regular
pcre_exec).
Which means we'd probably have to make streaming matches an optional
feature, and still do (1) first to fix the correctness issue.
-Peff
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Junio C Hamano @ 2012-10-30 12:46 UTC (permalink / raw)
To: Jeff King, Peter Oberndorfer; +Cc: git
In-Reply-To: <20121030121747.GA4231@sigill.intra.peff.net>
(1) sounds attractive for more than one reason. In addition to avoidance of this issue, it would bring bug-to-bug compatibility across platforms.
(4), if we can run grep on streaming data (tweak interface we have for checking out a large blob to the working tree), would let us work on dataset larger than fit in core. Even though it would be much more work, it might turn out to be a better option in the longer run.
Jeff King <peff@peff.net> wrote:
>On Mon, Oct 29, 2012 at 06:47:05PM -0400, Jeff King wrote:
>
>> On Mon, Oct 29, 2012 at 06:35:21PM -0400, Jeff King wrote:
>>
>> > The patch below fixes it, but it's terribly inefficient (it just
>detects
>> > the situation and reallocates). It would be much better to disable
>the
>> > reuse_worktree_file mmap when we populate the filespec, but it is
>too
>> > late to pass an option; we may have already populated from an
>earlier
>> > diffcore stage.
>> >
>> > I guess if we teach the whole diff code that "-G" (and
>--pickaxe-regex)
>> > is brittle, we can disable the optimization from the beginning
>based on
>> > the diff options. I'll take a look.
>>
>> Hmm. That is problematic for two reasons.
>>
>> 1. The whole diff call chain will have to be modified to pass the
>> options around, so they can make it down to the
>> diff_populate_filespec level. Alternatively, we could do some
>kind
>> of global hack, which is ugly but would work OK in practice.
>>
>> 2. Reusing a working tree file is only half of the reason a
>filespec
>> might be mmap'd. It might also be because we are literally
>diffing
>> the working tree. "-G" was meant to be used to limit log
>traversal,
>> but it also works to reduce the diff output for something like
>"git
>> diff HEAD^".
>>
>> I really wish there were an alternate regexec interface we could use
>> that took a pointer/size pair. Bleh.
>
>Thinking on it more, my patch, hacky thought it seems, may not be the
>worst solution. Here are the options that I see:
>
> 1. Use a regex library that does not require NUL termination. If we
> are bound by the regular regexec interface, this is not feasible.
> But the GNU implementation works on arbitrary-length buffers (you
> just have to use a slightly different interface), and we already
> carry it in compat. It would mean platforms which provide a working
> but non-GNU regexec would have to start defining NO_REGEX.
>
> 2. Figure out a way to get one extra zero byte via mmap. If the
> requested size does not fall on a page boundary, you get extra
> zero-ed bytes. Unfortunately, requesting an extra byte does not
> do what we want; you get SIGBUS accessing it.
>
> 3. Copy mmap'd data at point-of-use into a NUL-terminated buffer. That
> way we only incur the cost when we need it.
>
> 4. Avoid mmap-ing in the first place when we are using -G or
> --pickaxe-regex (e.g., by doing a big read()). At first glance,
> this sounds more efficient than loading the data one way and then
> making another copy. But mmap+memcpy, aside from the momentary
> doubled memory requirement, is probably just as fast or faster than
> calling read() repeatedly.
>
>I am really tempted by (1).
>
>Given that (2) does not work, unless somebody comes up with something
>clever there, that would make (3) the next best choice.
>
>-Peff
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Jeff King @ 2012-10-30 12:17 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git, Junio C Hamano
In-Reply-To: <20121029224705.GA32148@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 06:47:05PM -0400, Jeff King wrote:
> On Mon, Oct 29, 2012 at 06:35:21PM -0400, Jeff King wrote:
>
> > The patch below fixes it, but it's terribly inefficient (it just detects
> > the situation and reallocates). It would be much better to disable the
> > reuse_worktree_file mmap when we populate the filespec, but it is too
> > late to pass an option; we may have already populated from an earlier
> > diffcore stage.
> >
> > I guess if we teach the whole diff code that "-G" (and --pickaxe-regex)
> > is brittle, we can disable the optimization from the beginning based on
> > the diff options. I'll take a look.
>
> Hmm. That is problematic for two reasons.
>
> 1. The whole diff call chain will have to be modified to pass the
> options around, so they can make it down to the
> diff_populate_filespec level. Alternatively, we could do some kind
> of global hack, which is ugly but would work OK in practice.
>
> 2. Reusing a working tree file is only half of the reason a filespec
> might be mmap'd. It might also be because we are literally diffing
> the working tree. "-G" was meant to be used to limit log traversal,
> but it also works to reduce the diff output for something like "git
> diff HEAD^".
>
> I really wish there were an alternate regexec interface we could use
> that took a pointer/size pair. Bleh.
Thinking on it more, my patch, hacky thought it seems, may not be the
worst solution. Here are the options that I see:
1. Use a regex library that does not require NUL termination. If we
are bound by the regular regexec interface, this is not feasible.
But the GNU implementation works on arbitrary-length buffers (you
just have to use a slightly different interface), and we already
carry it in compat. It would mean platforms which provide a working
but non-GNU regexec would have to start defining NO_REGEX.
2. Figure out a way to get one extra zero byte via mmap. If the
requested size does not fall on a page boundary, you get extra
zero-ed bytes. Unfortunately, requesting an extra byte does not
do what we want; you get SIGBUS accessing it.
3. Copy mmap'd data at point-of-use into a NUL-terminated buffer. That
way we only incur the cost when we need it.
4. Avoid mmap-ing in the first place when we are using -G or
--pickaxe-regex (e.g., by doing a big read()). At first glance,
this sounds more efficient than loading the data one way and then
making another copy. But mmap+memcpy, aside from the momentary
doubled memory requirement, is probably just as fast or faster than
calling read() repeatedly.
I am really tempted by (1).
Given that (2) does not work, unless somebody comes up with something
clever there, that would make (3) the next best choice.
-Peff
^ permalink raw reply
* Re: Why does git-commit --template want the template to be modified ?
From: Johannes Sixt @ 2012-10-30 11:14 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBjeuy8dpSnp5Jq55hs1-CJUzwpH70GZ1ZGOF2dAAeypaw@mail.gmail.com>
Am 10/30/2012 11:53, schrieb Francis Moreau:
> I'm using git-commit with the --template option. The template I'm
> given is self sufficient for my purpose but as stated in the
> documentation, git-commit wants the template to be edited otherwise it
> aborts the operation.
>
> Is it possible to change this ?
Perhaps you wanted to use --file instead of --template?
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-30 11:13 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <005701cdb67f$f8b44d00$ea1ce700$@schmitz-digital.de>
On Tue, Oct 30, 2012 at 10:21:40AM +0100, Joachim Schmitz wrote:
> This fixes the vast majority of test failures on HP NonStop.
> Some test don't work with /bin/diff, some fail with /bin/tar,
> so let's put /usr/local/bin in PATH first.
> Some tests fail with /bin/sh (link to /bin/ksh) so use bash instead
>
> Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
> ---
>
> Makefile | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index f69979e..35380dd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1381,6 +1381,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> MKDIR_WO_TRAILING_SLASH = YesPlease
> # RFE 10-120912-4693 submitted to HP NonStop development.
> NO_SETITIMER = UnfortunatelyYes
> + SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
> + SHELL_PATH=/usr/local/bin/bash
> + # as of H06.25/J06.14, we might better use this
> + #SHELL_PATH=/usr/coreutils/bin/bash
> endif
> ifneq (,$(findstring MINGW,$(uname_S)))
> pathsep = ;
Your patch was whitespace damaged, but I was able to fix it up. Thanks.
-Peff
^ permalink raw reply
* Re: Why does git-commit --template want the template to be modified ?
From: Tomas Carnecky @ 2012-10-30 11:09 UTC (permalink / raw)
To: Francis Moreau, git
In-Reply-To: <CAC9WiBjeuy8dpSnp5Jq55hs1-CJUzwpH70GZ1ZGOF2dAAeypaw@mail.gmail.com>
On Tue, 30 Oct 2012 11:53:08 +0100, Francis Moreau <francis.moro@gmail.com> wrote:
> Hi,
>
> I'm using git-commit with the --template option. The template I'm
> given is self sufficient for my purpose but as stated in the
> documentation, git-commit wants the template to be edited otherwise it
> aborts the operation.
>
> Is it possible to change this ?
It seems you want -F instead of --template.
^ permalink raw reply
* Re: Links broken in ref docs.
From: Holger Hellmuth (IKS) @ 2012-10-30 10:38 UTC (permalink / raw)
To: Mike Norman; +Cc: Kevin, Scott Chacon, Andrew Ardill, git
In-Reply-To: <CAJr+XPE17vbqKJuJ4DfjPVfhzvL7B24eJJU-ipqUi3R+7p_yig@mail.gmail.com>
Am 30.10.2012 09:07, schrieb Mike Norman:
> Not seen any recently. I'm guessing the dev is in the path of
> hurricane Sandy? (Not sarcasm, btw.)
Do you still see failures? I checked out the website just now and it
seemed to work flawlessly (at least the links I tried, could not find
any Sharing or Updating section). New design since I last visited, more
end-user polish.
^ permalink raw reply
* Why does git-commit --template want the template to be modified ?
From: Francis Moreau @ 2012-10-30 10:53 UTC (permalink / raw)
To: git
Hi,
I'm using git-commit with the --template option. The template I'm
given is self sufficient for my purpose but as stated in the
documentation, git-commit wants the template to be edited otherwise it
aborts the operation.
Is it possible to change this ?
Thanks
--
Francis
^ permalink raw reply
* git-p4 clone @all error
From: Arthur @ 2012-10-30 10:44 UTC (permalink / raw)
To: git
Hi,
(I am a French student, sorry for my English.)
So, i want import my perforce projet on my server git.
perforce my project tree :
depot
dev_data
mainline
release_1.0
release_1.0.0
my command is :
git-p4 clone -v --detect-branches //depot@all /home/user/projets/deport
The problem :
Importing revision 7727 (100%)Traceback (most recent call last):
File "/usr/bin/git-p4", line 3183, in <module>
main()
File "/usr/bin/git-p4", line 3177, in main
if not cmd.run(args):
File "/usr/bin/git-p4", line 3048, in run
if not P4Sync.run(self, depotPaths):
File "/usr/bin/git-p4", line 2911, in run
self.importChanges(changes)
File "/usr/bin/git-p4", line 2618, in importChanges
self.initialParent)
File "/usr/bin/git-p4", line 2198, in commit
epoch = details["time"]
KeyError: 'time'
if i make a p4 sync //depot/...#head on my perforce server i've this error :
Librarian checkout
depot/mainline/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/api429decryption.txt failed.
open for read: depot/mainline/xxxxxxxxxxxxxxxxxx/api429decryption.txt,v: Le
fichier spcifi est introuvable.
My p4 clone can't checking out files after importing revision..
I hope I was clear ...
Thanks for your help.
--
View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v5 00/14] New remote-hg helper
From: Chris Webb @ 2012-10-30 10:28 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <20121030102526.GN4891@arachsys.com>
Chris Webb <chris@arachsys.com> writes:
> The first is really a symptom of a general difference between hg and git: an hg
> repository can have multiple heads, whereas a git repo has exactly one head.
By this I mean an hg repository without bookmarks or branches can still have
multiple heads, whereas a git branch points at exactly one place. Sorry,
very vague description there!
Cheers,
Chris.
^ permalink raw reply
* Re: [PATCH v5 00/14] New remote-hg helper
From: Chris Webb @ 2012-10-30 10:25 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <1351571736-4682-1-git-send-email-felipe.contreras@gmail.com>
Hi. I routinely work with projects in both hg and git, so I'm really
interested in this. Thanks for working on it! I grabbed the latest version
from
https://github.com/felipec/git/blob/fc-remote-hg/contrib/remote-hg/git-remote-hg
and have been trying it out. For the most part, it seems to work very nicely
for the hg repos I have access to and can test against. I've spotted a couple
of issues along the way that I thought would be worth reporting.
The first is really a symptom of a general difference between hg and git: an hg
repository can have multiple heads, whereas a git repo has exactly one head. To
demonstrate:
$ hg init hgtest && cd hgtest
$ echo zero >foo && hg add foo && hg commit -m zero
$ echo one >foo && hg commit -m one
$ hg checkout -r 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo two >foo && hg commit -m two
created new head
$ hg log --graph
@ changeset: 2:ca09651009cb
| tag: tip
| parent: 0:9f552c53d116
| user: Chris Webb <chris@arachsys.com>
| date: Tue Oct 30 09:33:38 2012 +0000
| summary: two
|
| o changeset: 1:58fad8998339
|/ user: Chris Webb <chris@arachsys.com>
| date: Tue Oct 30 09:33:25 2012 +0000
| summary: one
|
o changeset: 0:9f552c53d116
user: Chris Webb <chris@arachsys.com>
date: Tue Oct 30 09:33:08 2012 +0000
summary: zero
$ cd ..
Now if I try to convert this:
$ git clone hg::$PWD/hgtest gittest
Cloning into 'gittest'...
WARNING: Branch 'default' has more than one head, consider merging
Traceback (most recent call last):
File "/home/chris/bin/git-remote-hg", line 773, in <module>
sys.exit(main(sys.argv))
File "/home/chris/bin/git-remote-hg", line 759, in main
do_list(parser)
File "/home/chris/bin/git-remote-hg", line 463, in do_list
list_branch_head(repo, cur)
File "/home/chris/bin/git-remote-hg", line 425, in list_branch_head
tip = get_branch_tip(repo, cur)
File "/home/chris/bin/git-remote-hg", line 418, in get_branch_tip
return repo.branchtip(branch)
AttributeError: 'mqrepo' object has no attribute 'branchtip'
Strip the second head and it's fine:
$ hg -R hgtest strip 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
saved backup bundle to /tmp/hgtest/hgtest/.hg/strip-backup/ca09651009cb-backup.hg
$ git clone hg::$PWD/hgtest gittest
Cloning into 'gittest'...
$
Not sure what the most friendly thing to do here is. Perhaps refuse to
clone/pull from a repo with multiple heads unless you name the specific head
you want?
The second thing I spotted is the behaviour of bookmarks on push:
$ hg init hgtest && cd hgtest
$ echo zero >foo && hg add foo && hg commit -m zero
$ hg bookmark development
$ cd ..
$ git clone hg::$PWD/hgtest gittest && cd gittest
Cloning into 'gittest'...
$ git checkout development
Branch development set up to track remote branch development from origin.
Switched to a new branch 'development'
$ echo one >foo && git add foo && git commit -m one
[development 9f67dc4] one
1 file changed, 1 insertion(+), 1 deletion(-)
$ git status
# On branch development
# Your branch is ahead of 'origin/development' by 1 commit.
#
nothing to commit
$ git push
warning: helper reported unexpected status of refs/hg/origin/bookmarks/development
To hg::/tmp/hgtest/hgtest
* [new branch] branches/default -> branches/default
* [new branch] development -> development
$ hg log -R ../hgtest
changeset: 1:1c0714d93864
tag: tip
user: Chris Webb <chris@arachsys.com>
date: Tue Oct 30 09:51:51 2012 +0000
summary: one
changeset: 0:f56c463398ea
bookmark: development
user: Chris Webb <chris@arachsys.com>
date: Tue Oct 30 09:50:53 2012 +0000
summary: zero
i.e. the development bookmark hasn't been updated by the push. This might be
connected to the warning message
warning: helper reported unexpected status of refs/hg/origin/bookmarks/development
I'm testing with hg 2.2.2 and current git master, so I expect this could be a
python api change in the more recent versions of hg if you don't see the same
behaviour.
Best wishes,
Chris.
^ permalink raw reply
* Re: [PATCH] update-index/diff-index: use core.preloadindex to improve performance
From: Erik Faye-Lund @ 2012-10-30 10:15 UTC (permalink / raw)
To: karsten.blees; +Cc: git, msysgit, pro-logic
In-Reply-To: <OF831F4AE9.23F46743-ONC1257AA7.00353C1F-C1257AA7.00361535@dcon.de>
On Tue, Oct 30, 2012 at 10:50 AM, <karsten.blees@dcon.de> wrote:
> 'update-index --refresh' and 'diff-index' (without --cached) don't honor
> the core.preloadindex setting yet. Porcelain commands using these (such as
> git [svn] rebase) suffer from this, especially on Windows.
>
> Use read_cache_preload to improve performance.
>
> Additionally, in builtin/diff.c, don't preload index status if we don't
> access the working copy (--cached).
>
> Results with msysgit on WebKit repo (2GB in 200k files):
>
> | update-index | diff-index | rebase
> ----------------+--------------+------------+---------
> msysgit-v1.8.0 | 9.157s | 10.536s | 42.791s
> + preloadindex | 9.157s | 10.536s | 28.725s
> + this patch | 2.329s | 2.752s | 15.152s
> + fscache [1] | 0.731s | 1.171s | 8.877s
>
Wow, awesome results :)
This also makes me want to play around with the fscache stuff a bit;
about an order of magnitude improvement is quite noticeable :)
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCH] update-index/diff-index: use core.preloadindex to improve performance
From: karsten.blees @ 2012-10-30 9:50 UTC (permalink / raw)
To: git; +Cc: msysgit, pro-logic
'update-index --refresh' and 'diff-index' (without --cached) don't honor
the core.preloadindex setting yet. Porcelain commands using these (such as
git [svn] rebase) suffer from this, especially on Windows.
Use read_cache_preload to improve performance.
Additionally, in builtin/diff.c, don't preload index status if we don't
access the working copy (--cached).
Results with msysgit on WebKit repo (2GB in 200k files):
| update-index | diff-index | rebase
----------------+--------------+------------+---------
msysgit-v1.8.0 | 9.157s | 10.536s | 42.791s
+ preloadindex | 9.157s | 10.536s | 28.725s
+ this patch | 2.329s | 2.752s | 15.152s
+ fscache [1] | 0.731s | 1.171s | 8.877s
[1] https://github.com/kblees/git/tree/kb/fscache-v3
Thanks-to: Albert Krawczyk <pro-logic@optusnet.com.au>
Signed-off-by: Karsten Blees <blees@dcon.de>
---
Can also be pulled from:
https://github.com/kblees/git/tree/kb/update-diff-index-preload-upstream
I thought I might send this upstream directly, as its not msysgit related.
More performance figures (for msysgit) can be found in this discussion:
https://github.com/pro-logic/git/commit/32c03dd8
Ciao,
Karsten
builtin/diff-index.c | 8 ++++++--
builtin/diff.c | 12 ++++++++----
builtin/update-index.c | 1 +
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/builtin/diff-index.c b/builtin/diff-index.c
index 2eb32bd..1c737f7 100644
--- a/builtin/diff-index.c
+++ b/builtin/diff-index.c
@@ -41,9 +41,13 @@ int cmd_diff_index(int argc, const char **argv, const
char *prefix)
if (rev.pending.nr != 1 ||
rev.max_count != -1 || rev.min_age != -1 || rev.max_age != -1)
usage(diff_cache_usage);
- if (!cached)
+ if (!cached) {
setup_work_tree();
- if (read_cache() < 0) {
+ if (read_cache_preload(rev.diffopt.pathspec.raw) < 0) {
+ perror("read_cache_preload");
+ return -1;
+ }
+ } else if (read_cache() < 0) {
perror("read_cache");
return -1;
}
diff --git a/builtin/diff.c b/builtin/diff.c
index 9650be2..198b921 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -130,8 +130,6 @@ static int builtin_diff_index(struct rev_info *revs,
usage(builtin_diff_usage);
argv++; argc--;
}
- if (!cached)
- setup_work_tree();
/*
* Make sure there is one revision (i.e. pending object),
* and there is no revision filtering parameters.
@@ -140,8 +138,14 @@ static int builtin_diff_index(struct rev_info *revs,
revs->max_count != -1 || revs->min_age != -1 ||
revs->max_age != -1)
usage(builtin_diff_usage);
- if (read_cache_preload(revs->diffopt.pathspec.raw) < 0) {
- perror("read_cache_preload");
+ if (!cached) {
+ setup_work_tree();
+ if (read_cache_preload(revs->diffopt.pathspec.raw) < 0) {
+ perror("read_cache_preload");
+ return -1;
+ }
+ } else if (read_cache() < 0) {
+ perror("read_cache");
return -1;
}
return run_diff_index(revs, cached);
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 74986bf..ada1dff 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -593,6 +593,7 @@ struct refresh_params {
static int refresh(struct refresh_params *o, unsigned int flag)
{
setup_work_tree();
+ read_cache_preload(NULL);
*o->has_errors |= refresh_cache(o->flags | flag);
return 0;
}
--
1.8.0.msysgit.0.3.g7d9d98c
^ permalink raw reply related
* Password parsing fix on windows
From: Aleksey Vasenev @ 2012-10-30 9:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: patch.diff --]
[-- Type: application/octet-stream, Size: 421 bytes --]
diff --git a/perl/Git/SVN/Prompt.pm b/perl/Git/SVN/Prompt.pm
index 3a6f8af..ae2aeda 100644
--- a/perl/Git/SVN/Prompt.pm
+++ b/perl/Git/SVN/Prompt.pm
@@ -124,7 +124,7 @@ sub _read_password {
if (exists $ENV{GIT_ASKPASS}) {
open(PH, "-|", $ENV{GIT_ASKPASS}, $prompt);
$password = <PH>;
- $password =~ s/[\012\015]//; # \n\r
+ $password =~ s/[\012\015]+//; # \n\r
close(PH);
} else {
print STDERR $prompt;
^ permalink raw reply related
* Re: relative objects/info/alternates doesn't work on remote SMB repo
From: Orgad Shaneh @ 2012-10-30 9:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, msysGit
In-Reply-To: <CAGHpTBLbPvkEGqh5PGbtNS0MKY5YutaQpx3D_Fv5oSWeR52K9A@mail.gmail.com>
On Thu, Aug 30, 2012 at 3:34 PM, Orgad and Raizel Shaneh
<orgads@gmail.com> wrote:
>
> On Thu, Aug 30, 2012 at 4:22 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com>
> wrote:
> > On Thu, Aug 30, 2012 at 8:12 PM, Orgad and Raizel Shaneh
> > <orgads@gmail.com> wrote:
> >>> Could be path normalization. What does "git rev-parse --git-dir" say?
> >>> Try to run it at top working directory and a subdirectory as well.
> >>>
> >>> If you set GIT_OBJECT_DIRECTORY environment variable to
> >>> //server/share/foo/repo/.git/objects, does it work?
> >>
> >> git rev-parse --git-dir in a subdirectory has //server
> >
> > Hmm where is your git repository? That does not look like a git
> > repository's path.
> >
>
> Let me try to explain again.
> I have /d/share/bare, which is a bare repository, and /d/share/repo
> which is a clone with a relative path to bare/.git/objects in its
> .git/objects/info/alternates
>
> D:\share is configured as a SMB shared folder. It is accessed using
> //server/share.
> I do not clone from this directory, but work directly in it using 'cd
> //server/share', then performing git operations.
>
> >> setting GIT_OBJECT_DIRECTORY prints "fatal: bad object HEAD" on git
> >> status.
> >
> > I guessed you put your repo in .../repo/.git, but I was probably
> > wrong. Try setting again, pointing GIT_OBJECT_DIRECTORY to the
> > "objects" directory inside your repository. I just want to make see if
> > it's because git miscalculates this path. If setting the env variable
> > works, then it probably does.
> > --
> > Duy
>
> Same result. fatal: bad object HEAD. Tried even using a full (local)
> path to the objects dir.
>
> - Orgad
Any news? This still doesn't work with 1.8.0.
- Orgad
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* RE: [PATCH v2] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-30 9:21 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git
In-Reply-To: <20121029070642.GD5102@sigill.intra.peff.net>
> From: Jeff King [mailto:peff@peff.net]
> Sent: Monday, October 29, 2012 8:07 AM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH v2] fix 'make test' for HP NonStop
>
> On Thu, Oct 25, 2012 at 12:57:10PM +0200, Joachim Schmitz wrote:
>
> > diff --git a/Makefile b/Makefile
> > index f69979e..35380dd 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> > MKDIR_WO_TRAILING_SLASH = YesPlease
> > # RFE 10-120912-4693 submitted to HP NonStop development.
> > NO_SETITIMER = UnfortunatelyYes
> > +
> > + # for 'make test'
> > + # some test don't work with /bin/diff, some fail with /bin/tar
> > + # some need bash, and some need /usr/local/bin in PATH first
> > + SHELL_PATH=/usr/local/bin/bash
> > + SANE_TOOL_PATH=/usr/local/bin
>
> I think we can drop these comments, as the reasoning really should just
> go in the commit message.
OK by me.
> > + # as of H06.25/J06.14, we might better use this
> > + #SHELL_PATH=/usr/coreutils/bin/bash
> > + #SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
>
> Is there any reason not to put both into the default SANE_TOOL_PATH? If
> /usr/coreutils/bin does not exist on older versions, it will be a
> harmless no-op. I guess we arestuck with picking one $SHELL_PATH,
> though.
And because of that have to modify something anyway...
But I don't really mind about an extended SANE_TOOL_PATH
> -Peff
Bye, Jojo
-- 8< --
This fixes the vast majority of test failures on HP NonStop.
Some test don't work with /bin/diff, some fail with /bin/tar,
so let's put /usr/local/bin in PATH first.
Some tests fail with /bin/sh (link to /bin/ksh) so use bash instead
Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
---
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
+ SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
+ SHELL_PATH=/usr/local/bin/bash
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH=/usr/coreutils/bin/bash
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox