* Re: [PATCH] http: add_fill_function checks if function has been added
From: Tay Ray Chuan @ 2009-03-09 12:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4crls8q.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, Mar 9, 2009 at 3:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> That is not what I was worried about. There are two callsites to
> add_fill_function().
I'm sorry I didn't catch this from your earlier message; on a
re-reading I caught it.
> But it is not immediately obvious in http-walker.c callchain if multiple
> calls to add_fill_function(), if they were ever made, give the same
> "walker" as the callback data. Your patch only looks at the function but
> not the callback data for its filtering. Doesn't it mean that if a caller
> made two calls to add_fill_function() with walker#1 and then walker#2 as
> the callback data, you would discard the request for walker#2 and call the
> callback function fill_active_slot() with walker#1 inside run_active_slot
> repeatedly, without ever calling it for walker#2?
You're right, in addition to checking whether the callback is the
same, I should also have checked the callback data, before discarding
the invocation of add_fill_function as a duplicate.
> If it is the former, then your change is introducing a bug. If it is the
> latter, your change won't break anything immediately, but still introduces
> a potential bug waiting to happen, as the API looks as if you can call
> add_fill_function() to ask for callback functions to be called with
> different callback data and the caller can rely on both of them to be
> called at appropriate times, but in reality that guarantee does not hold.
That indeed is true, but afaik, none of the two instances of the API
usage does that -- calling callback functions with different callback
data to change behaviour. The fill functions are basically used to
"clear" the request queue.
Look at the fill function in http-walker.c. Yes, it's true that
callback data is passed on by the fill function, unlike the one in
http-push.c, which is passed NULL. But it doesn't really seem to use
the callback data. It loops through the request queue to find requests
that have yet to start (ie. their state is WAITING), and starts them
if they haven't start yet. The request object (struct file_request)
already contains a pointer to the callback data (walker), so it
doesn't really need it.
Nevertheless, I'll make add_fill_function additionally check the callback data.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Help designing work flow
From: Andreas Ericsson @ 2009-03-09 12:27 UTC (permalink / raw)
To: John Tapsell; +Cc: John Dlugosz, git
In-Reply-To: <43d8ce650903090444n352f310fs9cd4b8b0184be010@mail.gmail.com>
John Tapsell wrote:
> 2009/3/9 Andreas Ericsson <ae@op5.se>:
>> John Dlugosz wrote:
>>> I know we (my group) should use "topic" branches and apply them back to
>>> the dev branch when done. There is concern that the commit history gets
>>> too full of detailed stuff, especially with several developers, that you
>>> can't tell what "really changed". So, our dev branch should appear to
>>> contain only commit nodes representing completed assignments; not every
>>> day's checkpoint and trying to keep one's own stuff on top to avoid
>>> merging later.
>>>
>>> I guess that's how it is on these Open Source projects where patches are
>>> submitted by email and applied by the maintainer. We don't see the
>>> details, just the final patch. But, my situation will be developers
>>> gathered around an in-house master repo, and everyone should be able to
>>> push their own changes as assignments are completed.
>>>
>>> What is the best procedure to achieve that? Or what are some good
>>> alternatives with trade-offs?
>>>
>> Use topic-branches and let someone merge them into master after having
>> verified that they work properly.
>>
>> We usually commit simple bugfixes directly to master and then have
>> developers rebase their changes onto master when they're ready to
>
> The trouble with rebasing is that it then you end up with lots of
> patches that haven't been tested. You can end up with lots of
> uncompiling commits.
>
Not really, no. Unit-tests can still run just fine, and integration
testing still needs to be done after each feature is completed.
> Although merging is no better either. Then you end up with one single
> commit that tries to merge two trees, making it almost impossible to
> track down bugs that resulted from the merge.
>
Not really. If bugs are in "unrelated" areas (if the topic changed some
API without changing its' other callers, fe), you can backstep between
each commit on the merged branch, remerge that commit (instead of the
tip) and then run the tests again. But really, such bugs should have
been detected prior to merging the branch, and in any case "git bisect"
will find the commit that introduced the bug for you either way.
For next time, please cut away those parts of the email you didn't
reply to. I had to scroll down to the bottom to make sure you hadn't
written more.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* [PATCH 2/2] grep Added --blame so that grep can show result tagged with blame entries
From: pi song @ 2009-03-09 13:20 UTC (permalink / raw)
To: git, gitster
This part:-
1) Implementation & man for grep --blame option
Signed-off-by: Pi Song <pi.songs@gmail.com>
---
Documentation/git-grep.txt | 5 ++
builtin-grep.c | 10 ++++-
grep.c | 98
++++++++++++++++++++++++++++++++++++-------
grep.h | 1 +
4 files changed, 96 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 553da6c..23dae7f 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -18,6 +18,7 @@ SYNOPSIS
[-z | --null]
[-c | --count] [--all-match]
[-A <post-context>] [-B <pre-context>] [-C <context>]
+ [-b | --blame ]
[-f <file>] [-e] <pattern>
[--and|--or|--not|(|)|-e <pattern>...] [<tree>...]
[--] [<path>...]
@@ -105,6 +106,10 @@ OPTIONS
Instead of showing every matched line, show the number of
lines that match.
+-b::
+--blame::
+ Show blame of every matched line and context
+
-[ABC] <context>::
Show `context` trailing (`A` -- after), or leading (`B`
-- before), or both (`C` -- context) lines, and place a
diff --git a/builtin-grep.c b/builtin-grep.c
index 3f12ba3..c6cffa0 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -630,6 +630,11 @@ int cmd_grep(int argc, const char **argv, const
char *prefix)
opt.word_regexp = 1;
continue;
}
+ if (!strcmp("-b", arg) ||
+ !strcmp("--blame", arg)) {
+ opt.include_blame = 1;
+ continue;
+ }
if (!prefixcmp(arg, "-A") ||
!prefixcmp(arg, "-B") ||
!prefixcmp(arg, "-C") ||
diff --git a/grep.c b/grep.c
index 062b2b6..0514384 100644
--- a/grep.c
+++ b/grep.c
@@ -1,3 +1,4 @@
+#include "blame.h"
#include "cache.h"
#include "grep.h"
#include "xdiff-interface.h"
@@ -252,14 +253,17 @@ static int word_char(char ch)
}
static void show_line(struct grep_opt *opt, const char *bol, const char
*eol,
- const char *name, unsigned lno, char sign)
+ const char *name, unsigned lno, char sign,
+ char sign2, char* suspect)
{
if (opt->null_following_name)
sign = '\0';
if (opt->pathname)
printf("%s%c", name, sign);
+ if ((opt->include_blame) && (suspect!=NULL))
+ printf("%s%c", suspect);
if (opt->linenum)
- printf("%d%c", lno, sign);
+ printf("%d%c", lno, sign2);
printf("%.*s\n", (int)(eol-bol), bol);
}
@@ -442,6 +446,14 @@ static int match_line(struct grep_opt *opt, char
*bol, char *eol,
return 0;
}
+static int setup_revision_by_revId(char *revId, struct rev_info *revs)
+{
+ const char *args[] = {"grep", revId};
+ init_revisions(revs, NULL);
+ setup_revisions(2, args, revs, NULL);
+ return 1 ;
+};
+
static int grep_buffer_1(struct grep_opt *opt, const char *name,
char *buf, unsigned long size, int collect_hits)
{
@@ -457,6 +469,7 @@ static int grep_buffer_1(struct grep_opt *opt, const
char *name,
int binary_match_only = 0;
const char *hunk_mark = "";
unsigned count = 0;
+ int blame_calculated = 0 ;
enum grep_context ctx = GREP_CONTEXT_HEAD;
if (buffer_is_binary(buf, size)) {
@@ -477,6 +490,8 @@ static int grep_buffer_1(struct grep_opt *opt, const
char *name,
if (opt->pre_context || opt->post_context)
hunk_mark = "--\n";
+ /* List of blame tags */
+ struct blame_tag *blame_tags = NULL;
while (left) {
char *eol, ch;
int hit;
@@ -505,6 +520,35 @@ static int grep_buffer_1(struct grep_opt *opt,
const char *name,
return 0;
goto next_line;
}
+
+ /* Calculate blame if necessary */
+ if (hit && opt->include_blame && !blame_calculated)
+ {
+ struct blame_stat blame_stat ;
+ struct rev_info revs;
+ char filename[128] ;
+ char revId[41] ;
+ char *splitterPtr ;
+
+ if ((splitterPtr=strstr(name, ":")) != NULL)
+ {
+ strcpy(filename, splitterPtr + 1) ;
+ strncpy(revId, name, splitterPtr - name) ;
+ revId[40] = '\0' ;
+ setup_revision_by_revId(revId, &revs) ;
+ }
+ else
+ {
+ const char *args[] = {};
+ strcpy(filename, name) ;
+ init_revisions(&revs, NULL);
+ setup_revisions(0, args, &revs, NULL);
+ }
+
+ blame_tags = retrieve_blame_tags(&revs,
&blame_stat, filename) ;
+ blame_calculated = 1 ;
+ }
+
if (hit) {
count++;
if (opt->status_only)
@@ -533,30 +577,47 @@ static int grep_buffer_1(struct grep_opt *opt,
const char *name,
from = last_shown + 1;
if (last_shown && from != last_shown + 1)
fputs(hunk_mark, stdout);
- while (from < lno) {
+
+ /* This prints the precontext*/
+ while (from < lno)
+ {
pcl = &prev[lno-from-1];
show_line(opt, pcl->bol, pcl->eol,
- name, from, '-');
+ name, from, ':', '-',
+ blame_tags==NULL?
+ NULL:
blame_tags[from-1].author);
from++;
}
last_shown = lno-1;
}
if (last_shown && lno != last_shown + 1)
fputs(hunk_mark, stdout);
- if (!opt->count)
- show_line(opt, bol, eol, name, lno, ':');
+
+ if (!opt->count) {
+ /* The matching line */
+ show_line(opt, bol, eol, name, lno,
+ ':', ':',
+ blame_tags==NULL?
+ NULL:blame_tags[lno-1].author);
+ }
+
last_shown = last_hit = lno;
}
- else if (last_hit &&
- lno <= last_hit + opt->post_context) {
- /* If the last hit is within the post context,
- * we need to show this line.
- */
- if (last_shown && lno != last_shown + 1)
- fputs(hunk_mark, stdout);
- show_line(opt, bol, eol, name, lno, '-');
- last_shown = lno;
- }
+ else if (last_hit && lno <= last_hit + opt->post_context)
+ {
+ /* If the last hit is within the post context,
+ * we need to show this line.
+ */
+ if (last_shown && lno != last_shown + 1)
+ fputs(hunk_mark, stdout);
+
+ show_line(opt, bol, eol, name, lno, ':', '-',
+ blame_tags==NULL?
+ NULL:blame_tags[lno-1].author);
+
+ last_shown = lno;
+ }
+
if (opt->pre_context) {
memmove(prev+1, prev,
(opt->pre_context-1) * sizeof(*prev));
@@ -572,6 +633,11 @@ static int grep_buffer_1(struct grep_opt *opt,
const char *name,
lno++;
}
+ if (blame_calculated)
+ {
+ free(blame_tags) ;
+ }
+
free(prev);
if (collect_hits)
return 0;
diff --git a/grep.h b/grep.h
index 5102ce3..2e12e03 100644
--- a/grep.h
+++ b/grep.h
@@ -79,6 +79,7 @@ struct grep_opt {
int regflags;
unsigned pre_context;
unsigned post_context;
+ unsigned include_blame;
};
extern void append_grep_pattern(struct grep_opt *opt, const char *pat,
const char *origin, int no, enum grep_pat_token t);
--
1.5.4.3
^ permalink raw reply related
* Re: Help designing work flow
From: John Tapsell @ 2009-03-09 13:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: John Dlugosz, git
In-Reply-To: <49B50B3C.50700@op5.se>
2009/3/9 Andreas Ericsson <ae@op5.se>:
> John Tapsell wrote:
> Not really. If bugs are in "unrelated" areas (if the topic changed some
> API without changing its' other callers, fe), you can backstep between
> each commit on the merged branch, remerge that commit (instead of the
> tip) and then run the tests again.
Doing that manually? Sounds really complicated, especially if the
merge is nontrivial.
> But really, such bugs should have
> been detected prior to merging the branch, and in any case "git bisect"
> will find the commit that introduced the bug for you either way.
How will you detect bugs that arise from merging two trees, before you
merge them?
> For next time, please cut away those parts of the email you didn't
> reply to. I had to scroll down to the bottom to make sure you hadn't
> written more.
I'll try sorry. Most email clients will hide the quoted text - there
might be an option for that in your client?
John
^ permalink raw reply
* Re: Help designing work flow
From: Andreas Ericsson @ 2009-03-09 13:28 UTC (permalink / raw)
To: John Tapsell; +Cc: John Dlugosz, git
In-Reply-To: <43d8ce650903090622j51b73801gb4be62a7f50029a4@mail.gmail.com>
John Tapsell wrote:
> 2009/3/9 Andreas Ericsson <ae@op5.se>:
>> John Tapsell wrote:
>
>> Not really. If bugs are in "unrelated" areas (if the topic changed some
>> API without changing its' other callers, fe), you can backstep between
>> each commit on the merged branch, remerge that commit (instead of the
>> tip) and then run the tests again.
>
> Doing that manually? Sounds really complicated, especially if the
> merge is nontrivial.
>
Well, using git bisect should work.
>> But really, such bugs should have
>> been detected prior to merging the branch, and in any case "git bisect"
>> will find the commit that introduced the bug for you either way.
>
> How will you detect bugs that arise from merging two trees, before you
> merge them?
>
Assuming you don't start each topic-branch from a completely empty tree
and that you have *some* tests, you can run those tests at every single
commit just as if you had done those on the 'master' branch. API changes
that break things should break earlier, unless another branch made those
changes.
Aside from that, it's quite simple to run tests before publishing the
results of the merge, and it's absolutely trivial to undo the merge
in case tests don't pass.
>> For next time, please cut away those parts of the email you didn't
>> reply to. I had to scroll down to the bottom to make sure you hadn't
>> written more.
>
> I'll try sorry. Most email clients will hide the quoted text - there
> might be an option for that in your client?
>
I'm sure there is, but then I wouldn't have seen what you were replying
to, so that's not a very good option. In the space between me sending
and you replying, I wrote six other emails. Keeping track of them all
in my head is not something I'm prepared to even consider trying.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 0/2] Move push logic to transport.c
From: Jeff King @ 2009-03-09 14:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903091033330.10279@pacific.mpi-cbg.de>
On Mon, Mar 09, 2009 at 10:35:45AM +0100, Johannes Schindelin wrote:
> BTW thanks for the patch, I guess it will help Peff to complete "push
> --track" properly ;-)
If I wait long enough, maybe my original patch will Just Work. ;)
-Peff
^ permalink raw reply
* git-p4 workflow suggestions?
From: Sam Hocevar @ 2009-03-09 14:21 UTC (permalink / raw)
To: git
Dear list,
I have modified git and git-p4 to a point where they are usable in
my work environment. I am now faced with a new problem: Perforce's
composite workspaces. They allow you to "mount" parts of the repo onto
other directories, even nonempty ones.
Take the following example repository, where a "framework" project
contains an example subdirectory with build files and other directories,
and a "project1" project contains subdirectories that are meant to
replace the ones in "example":
//work/framework/example/src/
/include/
/Makefile
/...
//work/project1/src/
/include/
Using the Perforce client, one can reorganise the workspace
so that project1/src/ transparently replaces the contents of
framework/example/src/ (same for */include). All the work is then done
in the framework/ local checkout, but commits may also affect project1/.
I could not find a way to do the same with git and git-p4. My main
requirements are the following:
- preserve the atomicity of commits affecting both project1/src and
project1/include (having to commit from a different directory due to
symlink hacks is acceptable to me, even if not terribly practical)
- have git-p4 rebase work without requiring tedious merges
- *if possible* (but not a strong requirement), preserve the
atomicity of commits affecting both framework/ and project1/.
If anyone ever ran into the problem, I'd like to hear from their
experience. Or maybe someone will have suggestions based on similar
requirements.
Cheers,
--
Sam.
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Paolo Ciarrocchi @ 2009-03-09 14:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vbpsh93q5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> Tor Arne Vestbø <torarnv <at> gmail.com> writes:
>
> > The options --branch and -b allow the user to override the initial
> > branch created and checked out by git-clone (normally this is the
> > active branch of the remote repository).
> >
> > If the selected branch is not found the operation aborts.
> >
> > Signed-off-by: Tor Arne Vestbø <torarnv <at> gmail.com>
>
> The semantics and desirability of the new feature have been already
> discussed, and I am not convinced that it is necessary, in the sense that
> I do not think I likely ever use this myself, but I am just one of git
> users so that is not a strong basis for rejection.
I wrote a comment about the --branch approach a couple of days ago, dunno why
but this thread never reached my inbox (replying via gmame web interface).
http://thread.gmane.org/gmane.comp.version-control.git/112527
As I wrote in my post a friend of mine, new to git, was looking for the
possibility of cloning a repo and automatically checkout a specific branch.
Regards,
Paolo
^ permalink raw reply
* RE: git-forest on msysgit
From: John Dlugosz @ 2009-03-09 14:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903070352580.10279@pacific.mpi-cbg.de>
>> Note: this is pretty much obviously the wrong mailing list for
msysGit-related issues.
This is the list where I get friendly and useful answers as well as
fruitful discussions, and I've seen Windows and MSYSget in particular
mentioned many times when reviewing the threads.
>> You can try recompiling git-svn. Maybe I forgot to commit a file.
I've not delved into the source code yet, but some day...
>> > I wonder if I can just copy it from somewhere, like someone's Linux
>> > build?
>> How do you expect a Linux-specific binary object to be usable on
Windows?
Because it's the Perl inside MSys/Cigwin. Isn't the POSIX layer like
Wine in reverse?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PoC PATCH JGIT 0/2] Proof of concept code for Git Freenet transport
From: Shawn O. Pearce @ 2009-03-09 14:59 UTC (permalink / raw)
To: Daniel Cheng (aka SDiZ); +Cc: devl, git
In-Reply-To: <1236569765-8882-1-git-send-email-j16sdiz+freenet@gmail.com>
"Daniel Cheng (aka SDiZ)" <j16sdiz+freenet@gmail.com> wrote:
>
> Here is some proof-of-concept code for Git-over-Freenet.
> I am sending this to see the feedback from communities.
Interesting!
I'm quite open to bringing this into JGit itself, so long as it
doesn't cause us to import 42 other libraries that we don't need.
:-)
> FIXME:
> - How to store the private key of repository?
> Currently, we use URI of form fcp://SSK@<public key>^<private key>/some-id
> This is quite ugly. Could we use a per remote Config ? How can I get remote
> name from transport?
Use something like amazon-s3 does, where there is a file path under
~/ specified by the host part of the URI, and store the data there?
I did that rather than storing into ~/.gitconfig or GIT_DIR/config
as the private key really should remain private. Chmod'ing your
config file to be private is a pain, and "git config" last I checked
wouldn't preserve the permissions when it modified the file for you.
That said, the Transport API in JGit doesn't get access to the
RemoteConfig it was created with, because it isn't always made
from a remote (e.g. you can pass the URIish on the command line).
We could however optionally expose it, but in general I prefer
to make everything that can be obtained via the RemoteConfig be
settable without one, so it can also come through from the CLI
or some higher-level GUI.
> - Make pushing async, could we?
I'm not sure I understand that. Do you want to background the push
task? Isn't that what your shell is for? Or do you want to perform
the writes in an async fashion in parallel, to reduce the latency?
--
Shawn.
^ permalink raw reply
* Re: [CVSPS PATCH] fix: correct rev order in case commiters clocks were not syncronised
From: Michael Haggerty @ 2009-03-09 15:02 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, ydirson, git
In-Reply-To: <49B4FCDA.4030106@hvoigt.net>
Heiko Voigt wrote:
> This fixes the following kind of cvsps issues:
>
> Structure of the test cvs repository
>
> Message File:Content Commit Time
> Rev 1 a: 1.1 2009-02-21 19:11:43 +0100
> Rev 2 a: 1.2 b: 1.1 2009-02-21 19:11:14 +0100
> Rev 3 b: 1.2 2009-02-21 19:11:43 +0100
>
> As you can see the commit of Rev 3 has the same time as
> Rev 1 this was leading to a broken estimation of patchset
> order.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
I am not familiar with the cvsps code, so I will just make some comments
about things that it is not obvious from your patch that you have
considered. These things all caused problems in pre-2.0 versions of
cvs2svn:
1. It is not clear from the patch in what order the revisions are being
processed. If they are being processed in the order that they appear in
the RCS file, then you have to consider branches:
* The date adjustment should only occur along chains of revisions
that are "causally related" -- that is, adjacent revisions on trunk, or
adjacent revisions on a branch, or the first revision on a branch
relative to the revision from which the branch sprouted. It is not
always the case that revisions that are adjacent in the RCS file are
causally related.
* The revisions along trunk appear in RCS files in reverse
chronological order; e.g., 1.3, 1.2, 1.1 (this seems to be the case you
handle). But the revisions along a branch appear in chronological
order; e.g., 1.3.2.1, 1.3.2.2, 1.3.2.3. Do you handle both cases
correctly? (A unit test involving revisions on branches would be helpful.)
2. One form of clock skew that is common in CVS repositories is that
some computer's CMOS battery went dead and the clock reverted to 1970
after every reboot. Given that you adjust revisions' times only towards
the past, then such a glitch would force the times of all earlier
revisions to be pushed back to 1970. (Since you unconditionally
subtract one second from each commit timestamp, this could also
conceivably cause an underflow to 2038, but this is admittedly rather
unlikely.) This is a hard problem to solve generally. But if you want
to handle this problem more robustly, I suggest that you always adjust
times towards the future, as incorrect clock times in the far future
seem to be less common in practice.
Of course these clock skew corrections, if only applied to one file at a
time, can easily cause changesets to be broken up if the time deltas
exceed five minutes.
3. When cvsps collects individual file revisions into changesets (within
the 5 minute window), a single "consensus" commit time has to be chosen
from all of the single-file commits. Depending on how cvsps does this,
it could be that the consensus commit times for two commits involving
revisions within a single file are put back out of order (undoing your
timestamp fixup). It would be nice to verify that this does not result
in out-of-order commits.
Michael
^ permalink raw reply
* RE: fetch and pull
From: John Dlugosz @ 2009-03-09 15:08 UTC (permalink / raw)
To: Bryan Donlan; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <3e8340490903070000t2780764cocfbf28d538037df5@mail.gmail.com>
=== Re: ===
If the local "dev" is meant to just track the remote, [that is the case]
you really ought to avoid doing anything very involved in it (unless
you're
planning on merging something into it and pushing the result, that is!).
If
there's no local changes, then you can just pull with impunity, and
let it fast-forward - or use git merge or git rebase if you've already
fetched and don't want to spend the few seconds it takes to ask the
server if there's anything new :)
=== end ===
I thought about that. But wouldn't that require you to checkout dev
first? It seems that pull wants to merge into the current branch,
period. That makes it unsuitable for something that just refreshes the
remote view of things, and is an accident waiting to happen if you run
it while on your topic branch instead.
=== Re: ===
Finally, if you really, truly, definitely want to blow away the
current branch and replace it with another one, you can use git reset
--hard. This will throw away (irretrievably) local uncommitted
changes, and force the current branch to point to the specified one.
=== end ===
"reset" does not change the current branch. It updates the contents of
the working directory and index to match the node specified, but does
not change what git considers to be the branch you are "on". I got a
few floating heads and later merge confusion before I finally understood
that. It appears that "checkout" is the only thing that changes the
"current branch". In any case, reset does not reposition any refs at
all.
=== Re: ===
Remember, you can undo most things using the reflog if you mess up,
including unwanted merges, git reset --hard (committed changes only)
etc.
=== end ===
Yes, indeed.
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: JGit server performance
From: Shawn O. Pearce @ 2009-03-09 15:27 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0903090801w7748d26pb821a7bfb3db660@mail.gmail.com>
[+git]
Scott Chacon <schacon@gmail.com> wrote:
> On Sat, Mar 7, 2009 at 8:22 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > As Gerrit Code Review provides Gitosis-like functionality, but
> > that is implemented through JGit's pure Java implementation, the
> > performance of JGit's UploadPack matters to me.
> >
> > JGit is about 66% slower on my hardware when cloning the linux-2.6
> > repository, compared to git-core (jgit 2m21s, git-core 1m23s).
>
> What about packfile caching? I thought I just saw someone propose
> this for a GSOC project - it obviously wouldn't help with making the
> first clone faster, but since it seems that you're talking about a
> server that is probably recomputing the same packfile bits over and
> over, perhaps caching the final output would be a simpler way to get
> more aggregate time savings. I remember there were some issues with
> client capabilities and whatnot, but would that be a useful solution
> to speeding up overall throughput?
Indeed.
I think over the weekend I came to the conclusion that the only
way I can "fix" this is to implement some form of automatic caching
inside of JGit.
I came up with two ideas, but haven't tried either one yet:
Cache Object List:
The idea here is that JGit spends the majority of its server side
resources enumerating objects, doing the `git rev-list --objects
$wants --not $haves` computation. Once you reach a certain point
on the DAG, that computation just isn't going to change much.
So, for example, if we tag a dump of the object listing for all
objects that are reachable from the most recently reachable
annotated tag, and cache that dump, we can reload it when we
encounter that tag again. By restoring that dump, we can cut
off a huge part of the object evaluation.
Initial clones would always benefit from this dump, and we can
expand it to cover more of the DAG as new tags are produced.
The really recent commits still require enumeration, but this
is a small percentage of the total objects being processed,
and should go quite quickly.
We still need to select and serve ranges of existing packs,
based on the objects chosen for transmission.
Cache Packs:
As you point out above, do the GSoC project idea (but in JGit)
where we cache packs.
My problem with this approach is it doesn't help initial clones
very much once any one of the refs changes. As soon as any
ref is updated in any way, that cached pack is invalid and must
be recomputed from scratch.
However, it probably would generalize nicely into supporting a
decent cache for incremental updates of clients. In many cases
in a Linus/Junio single-push-a-day world, all clients would be
roughly asking for the same pack, and we'd get a decent return on
our investment by saving the thin pack to disk in some cache area.
But in a Gerrit Code Review world, its expected that the
branches will update hundreds of times per day, and clients
will be fetching off those multiple times throughout the day.
So the life span of any given cached pack is probably quite small.
However, I have no real proof to back this theory up with yet,
its just back of the envelope guessing on my part.
Hybrid:
I also considered some sort of hybrid approach.
E.g. create a cache pack for everything reachable from a stable
tag point (the object set in that pack is the same as the cached
object list). When sending data to a client, we send the current
objects that aren't in the big cache pack, and then we tack the
pack onto the end of the data stream. So we only need to "read,
SHA-1, send" through the entire length of the file (minus the 12
byte header, 20 byte footer).
Really quite efficient.
My problem with this approach is you cannot duplicate an object
in a pack stream. So I have to be very careful when using this
pack to complete a larger pack stream, as I need to avoid writing
any object in the front if it will appear in the pack I am tacking
onto the end.
That is more common that you might expect, e.g. consider a
"Documentation/SubmittingPatches" file that hasn't been touched in
ages... it would appear in the recent commit object enumeration,
but it also will appear in the big cache pack I want to tack on
the end, as it hasn't changed since the pack was created.
Right now I am leaning towards caching the object enumeration
(the first approach mentioned).
--
Shawn.
^ permalink raw reply
* RE: fetch and pull
From: John Dlugosz @ 2009-03-09 15:27 UTC (permalink / raw)
To: Junio C Hamano, Bryan Donlan; +Cc: Jakub Narebski, git
In-Reply-To: <7vfxhpnl7g.fsf@gitster.siamese.dyndns.org>
Thanks for your thoughts. I'm still trying to figure out not just the
basic meaning of the tools but what can be done with them.
=== Re: ===
With git that is not ancient (i.e. v1.5.0 or newer), there is no reason
to
have local "dev" that purely track the remote anymore. If you only want
to go-look-and-see, you can check out the remote tracking branch
directly
on a detached HEAD with "git checkout origin/dev".
=== end ===
Yes, I figured out that since gitk shows the remote, there is no reason
to have local copies of any master (upstream) refs that I don't plan on
modifying. After setting it to track remotes, I deleted all my unneeded
copies.
=== Re: ===
Which means that the only cases we need to make it convenient for users
are to handle these local branches that "track" remote ones when you do
have local changes, or when you plan to have some.
=== end ===
I also realized recently that, with the use of topic branches, the user
doesn't need to see the "old" (local copy of) dev to understand what
changed since he last looked. The visible branch point with the topic
will serve as that marker.
The only time the local dev is used is when the developer is going to
add a commit for the completed topic. But, dealing with it (only) then
would be more steps when doing that. And the local dev would still be
visible and out-dated from day-to-day, and when keeping the topic
up-to-date with dev changes he would need to use origin/dev not just dev
in his commands to rebase or merge.
=== Re: ===
I'd actually say we should give users a convenient way to remove the
local
branches that are marked to track remote tracking branches but do not
have
anything interesting on their own (iow when they can fast-forward to
their
corresponding remote tracking branches), if the true motive behind this
thread is "'git push' will notice 'dev' that is left behind and gives
clutter".
=== end ===
I found that using the GUI was easy enough, when "converting" my local
to track remote branches. If you mean make a way to have a local
version of a tracking branch transiently, that is, only when it is
interesting, then I think I like that idea.
=== Re: ===
So how about "git branch --prune --remote=<upstream>" that iterates over
local branches, and if
(1) it is not the current branch; and
(2) it is marked to track some branch taken from the <upstream>; and
(3) it does not have any commits on its own;
then remove that branch? "git remote --prune-local-forks <upstream>" is
also fine; I do not care about which command implements the feature that
much.
=== end ===
Since fetch is the command that does the tracking of remotes, how about
having an option to fetch that does this before proceeding with the
fetch? That is what people really want if they think they want locals
to auto-track the remotes.
=== Re: ===
But in that case, you shouldn't mark "dev" as tracking the remote's
"dev"
to begin with, so the hypothetical "branch --prune --remote=<upstream>"
would not touch such a "fork to address old issues", and we'd be safe.
=== end ===
Does git now "associate" local branch names with the remotes, other than
by simply having the same name?
--John
(please excuse the footer; it's not my choice)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* RE: Help designing work flow
From: John Dlugosz @ 2009-03-09 15:36 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <49B4F5A9.5060304@op5.se>
Thank you very much for your thoughts, especially the specific commands
etc. that I can show the team as reasons.
=== Re: ===
You can tell "git log" to only show one line of history too, but besides
that, micro-details are good. You definitely want to be able to search
the micro-details when things go awry (and they will), so you see
exactly
why some particular algorithm changed later.
=== end ===
Is there a way that someone (for example, product manager) can view only
the main line consisting of topic merges, and not see each one separated
by many many lines of detail changes? Especially using the GUI?
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH 0/5] Extend pattern refspecs
From: Jay Soffian @ 2009-03-09 15:46 UTC (permalink / raw)
To: Daniel Barkalow, Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903080447450.19665@iabervon.org>
On Sun, Mar 8, 2009 at 4:49 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Sun, 8 Mar 2009, Junio C Hamano wrote:
>
>> Jay Soffian <jaysoffian@gmail.com> writes:
>>
>> > This series and js/remote-improvements (e5dcbfd) in pu may not get
>> > along completely. "git remote show" tries to show how the refspecs
>> > expand out.
>>
>> I've created an "early semantic conflict resolution" topic branch that is
>> a cross between this series and js/remote-improvements, like so:
>>
>> $ git checkout -b xx/db-refspec-vs-js-remote db/refspec-wildcard-in-the-middle
>> $ git merge js/remote-improvements
>> $ git apply evil-fixup.diff
>> $ git commit --amend -a -m "Evil merge."
>>
>> with the following "fixup-as-an-evil-merge patch", which I'd appreciate if
>> you two can sanity check.
>
> That looks like what I'd come up with as a resolution, too, so I think
> it's sane unless Jay knows of another way to get remote to care about
> patterns.
Looks good to me too.
j.
^ permalink raw reply
* Re: [EGIT PATCH] Prevent an exception if the user tries to push a non-existing ref.
From: Shawn O. Pearce @ 2009-03-09 15:50 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Daniel Cheng, git
In-Reply-To: <1236525667-852-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Instead of a StringIndexOutOfBoundsException we now get an error telling
> us that the ref could not be resolved.
*sigh*
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java b/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
> index a0a2575..8a25213 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
> @@ -255,7 +255,7 @@ else if (TransportLocal.canHandle(remote))
> } else {
> if (!remoteName.startsWith(Constants.R_REFS)) {
> // null source is another special case (delete)
> - if (srcRef != null) {
> + if (src != null) {
> // assume the same type of ref at the destination
> String srcPrefix = srcRef.substring(0, srcRef.indexOf('/', Constants.R_REFS.length()));
> remoteName = srcPrefix + "/" + remoteName;
After reading that code again, I'm tempted to apply this instead.
Its a much larger patch, but I think the result is a lot easier
to follow.
--8<--
Fix DWIMery for push to handle non-existant source refs
Instead of a StringIndexOutOfBoundsException we now get an error
telling us that the ref could not be resolved.
Found-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/transport/Transport.java | 45 ++++++++++---------
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java b/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
index a0a2575..1068f50 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
@@ -244,29 +244,32 @@ else if (TransportLocal.canHandle(remote))
final Collection<RefSpec> procRefs = expandPushWildcardsFor(db, specs);
for (final RefSpec spec : procRefs) {
- String srcRef = spec.getSource();
- final Ref src = db.getRef(srcRef);
- if (src != null)
- srcRef = src.getName();
- String remoteName = spec.getDestination();
- // null destination (no-colon in ref-spec) is a special case
- if (remoteName == null) {
- remoteName = srcRef;
- } else {
- if (!remoteName.startsWith(Constants.R_REFS)) {
- // null source is another special case (delete)
- if (srcRef != null) {
- // assume the same type of ref at the destination
- String srcPrefix = srcRef.substring(0, srcRef.indexOf('/', Constants.R_REFS.length()));
- remoteName = srcPrefix + "/" + remoteName;
- }
- }
+ String srcSpec = spec.getSource();
+ final Ref srcRef = db.getRef(srcSpec);
+ if (srcRef != null)
+ srcSpec = srcRef.getName();
+
+ String destSpec = spec.getDestination();
+ if (destSpec == null) {
+ // No destination (no-colon in ref-spec), DWIMery assumes src
+ //
+ destSpec = srcSpec;
}
- final boolean forceUpdate = spec.isForceUpdate();
- final String localName = findTrackingRefName(remoteName, fetchSpecs);
- final RemoteRefUpdate rru = new RemoteRefUpdate(db, srcRef,
- remoteName, forceUpdate, localName, null);
+ if (srcRef != null && !destSpec.startsWith(Constants.R_REFS)) {
+ // Assume the same kind of ref at the destination, e.g.
+ // "refs/heads/foo:master", DWIMery assumes master is also
+ // under "refs/heads/".
+ //
+ final String n = srcRef.getName();
+ final int kindEnd = n.indexOf('/', Constants.R_REFS.length());
+ destSpec = n.substring(0, kindEnd + 1) + destSpec;
+ }
+
+ final boolean forceUpdate = spec.isForceUpdate();
+ final String localName = findTrackingRefName(destSpec, fetchSpecs);
+ final RemoteRefUpdate rru = new RemoteRefUpdate(db, srcSpec,
+ destSpec, forceUpdate, localName, null);
result.add(rru);
}
return result;
--
1.6.2.185.g8b635
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] contrib/difftool: use a separate config namespace for difftool commands
From: Jay Soffian @ 2009-03-09 15:52 UTC (permalink / raw)
To: David Aguilar, Junio C Hamano; +Cc: git
In-Reply-To: <1236589956-13486-1-git-send-email-davvid@gmail.com>
On Mon, Mar 9, 2009 at 5:12 AM, David Aguilar <davvid@gmail.com> wrote:
> contrib/difftool/git-difftool | 6 +++---
Aside, (for Junio I guess...), what's the reason this command is in
contrib, and by what criteria might it graduate to being installed
with the rest of the git commands?
j.
^ permalink raw reply
* Re: [PATCH 1/2] Use a common function to get the pretty name of refs
From: Daniel Barkalow @ 2009-03-09 16:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903091036420.10279@pacific.mpi-cbg.de>
On Mon, 9 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 8 Mar 2009, Daniel Barkalow wrote:
>
> > The result should be consistent between fetch and push, so we ought to
> > use the same code in both cases, even though it's short.
>
> You might want to mention that we cannot use skip_prefix() here, as that
> function does not give us any clue if something was skipped at all, and we
> must _not_ skip multiple prefixes.
I didn't even know about the skip_prefix() function; I just moved code
around.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Felipe Contreras @ 2009-03-09 16:01 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <loom.20090309T143413-334@post.gmane.org>
On Mon, Mar 9, 2009 at 4:39 PM, Paolo Ciarrocchi
<paolo.ciarrocchi@gmail.com> wrote:
> Junio C Hamano <gitster <at> pobox.com> writes:
>
>>
>> Tor Arne Vestbø <torarnv <at> gmail.com> writes:
>>
>> > The options --branch and -b allow the user to override the initial
>> > branch created and checked out by git-clone (normally this is the
>> > active branch of the remote repository).
>> >
>> > If the selected branch is not found the operation aborts.
>> >
>> > Signed-off-by: Tor Arne Vestbø <torarnv <at> gmail.com>
>>
>> The semantics and desirability of the new feature have been already
>> discussed, and I am not convinced that it is necessary, in the sense that
>> I do not think I likely ever use this myself, but I am just one of git
>> users so that is not a strong basis for rejection.
>
> I wrote a comment about the --branch approach a couple of days ago, dunno why
> but this thread never reached my inbox (replying via gmame web interface).
>
> http://thread.gmane.org/gmane.comp.version-control.git/112527
>
> As I wrote in my post a friend of mine, new to git, was looking for the
> possibility of cloning a repo and automatically checkout a specific branch.
Yeah, I also would like this option... one-liner for people that don't
know git at all.
me: you want my code? just run this command.
--
Felipe Contreras
^ permalink raw reply
* push problem for new repo on repo.or.cz
From: Michael J Gruber @ 2009-03-09 16:02 UTC (permalink / raw)
To: Git Mailing List, Petr Baudis
Hi there
I have problems pushing into a new project on repo.or.cz. My user (mjg)
is added in the admin interface, the key is correct because I've been
using it for a while already for other projects (forks though). I'm
using a qualified refspec. What else could be wrong on my side, assuming
it's not the scripts on repo.or.cz? My git is 1.6.2.
Michael
git push git+ssh://repo.or.cz/srv/git/conformal.git master:master
Counting objects: 14, done.
Delta compression using 2 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (14/14), 11.50 KiB, done.
Total 14 (delta 3), reused 0 (delta 0)
error: unpack failed: unpacker exited with error code
To git+ssh://repo.or.cz/srv/git/conformal.git
! [remote rejected] master -> master (n/a (unpacker error))
error: unable to create temporary sha1 filename ./objects/a3: Permission
denied
fatal: failed to write object
error: failed to push some refs to
'git+ssh://repo.or.cz/srv/git/conformal.git'
^ permalink raw reply
* Re: [PATCH 0/2] Move push logic to transport.c
From: Daniel Barkalow @ 2009-03-09 16:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903091033330.10279@pacific.mpi-cbg.de>
On Mon, 9 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 8 Mar 2009, Daniel Barkalow wrote:
>
> > It doesn't convert http-push or the rsync transports, largely because I
> > don't have test setups for rsync or webdav to make sure that they're
> > still working.
>
> $ ls t/*http-push*
> t/t5540-http-push.sh
>
> $ git grep -n test.*rsync t/
> t/t5510-fetch.sh:195:test_expect_success 'fetch via rsync' '
> t/t5510-fetch.sh:206:test_expect_success 'push via rsync' '
> t/t5510-fetch.sh:217:test_expect_success 'push via rsync' '
>
> It should be just a matter of installing an apache and rsync.
And configuring them suitably, yes. That's the part I haven't previously
done.
> BTW thanks for the patch, I guess it will help Peff to complete "push
> --track" properly ;-)
Yes, I expect so.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/2] Use a common function to get the pretty name of refs
From: Johannes Schindelin @ 2009-03-09 16:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903091159000.19665@iabervon.org>
Hi,
On Mon, 9 Mar 2009, Daniel Barkalow wrote:
> On Mon, 9 Mar 2009, Johannes Schindelin wrote:
>
> > On Sun, 8 Mar 2009, Daniel Barkalow wrote:
> >
> > > The result should be consistent between fetch and push, so we ought
> > > to use the same code in both cases, even though it's short.
> >
> > You might want to mention that we cannot use skip_prefix() here, as
> > that function does not give us any clue if something was skipped at
> > all, and we must _not_ skip multiple prefixes.
>
> I didn't even know about the skip_prefix() function; I just moved code
> around.
But I know the function. And I had to look at the code to end the
head-scratching. Therefore I'd like the paragraph I wrote to be part of
the commit message, to save other people from going bald.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Move push logic to transport.c
From: Johannes Schindelin @ 2009-03-09 16:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903091200150.19665@iabervon.org>
Hi,
On Mon, 9 Mar 2009, Daniel Barkalow wrote:
> On Mon, 9 Mar 2009, Johannes Schindelin wrote:
>
> > On Sun, 8 Mar 2009, Daniel Barkalow wrote:
> >
> > > It doesn't convert http-push or the rsync transports, largely
> > > because I don't have test setups for rsync or webdav to make sure
> > > that they're still working.
> >
> > $ ls t/*http-push*
> > t/t5540-http-push.sh
> >
> > $ git grep -n test.*rsync t/
> > t/t5510-fetch.sh:195:test_expect_success 'fetch via rsync' '
> > t/t5510-fetch.sh:206:test_expect_success 'push via rsync' '
> > t/t5510-fetch.sh:217:test_expect_success 'push via rsync' '
> >
> > It should be just a matter of installing an apache and rsync.
>
> And configuring them suitably, yes. That's the part I haven't previously
> done.
If you have to configure apache (or rsync) for the test to run properly,
we have a serious bug in our test suite. Please share the output in that
case.
Ciao,
Dscho
^ permalink raw reply
* Re: push problem for new repo on repo.or.cz
From: Johannes Schindelin @ 2009-03-09 16:14 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Petr Baudis
In-Reply-To: <49B53DAF.9080004@drmicha.warpmail.net>
Hi,
On Mon, 9 Mar 2009, Michael J Gruber wrote:
> I have problems pushing into a new project on repo.or.cz. My user (mjg)
> is added in the admin interface, the key is correct because I've been
> using it for a while already for other projects (forks though). I'm
> using a qualified refspec. What else could be wrong on my side, assuming
> it's not the scripts on repo.or.cz? My git is 1.6.2.
I guess it is your impatience.
Users are not really added from the web interface, that would be
dangerous, as the web application would need more permissions than it
deserves. Therefore, the web application writes to a file which is
handled by a cron job with those permissions.
So, wait 10 minutes and try again; I am sure it will work then.
Ciao,
Dscho
^ permalink raw reply
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