On Sat, 30 Jul 2005, Junio C Hamano wrote:
* Right now, send-pack --all into an empty repository does
not do anything, but send-pack --all master into an empty
repository pushes all local heads. This is because we do not
check send_all when deciding if we want to call try_match
This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
all the nice things a good subsystem maintainer does when forwarding a patch or
50 upstream:
All the prior handlers of the patch, as determined by the
Signed-off-by: lines, and/or the author of the
Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
---
Documentation/git-send-email-script.txt | 61 +++
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-send-email-script.txt
799a6320d3b07347869093beec303afbc005cf26
diff --git
Hi, Ryan Anderson wrote:
And yes, I did generate this thread with this script - so I have proof
that it works nicely.
It might make sense to create a Patch 0/N with a short explanation, and
have the actual patches be replies to that -- or to patch 1/N if that's
not necessary.
As it is, patch
Junio C Hamano writes:
It appears that gitk gets wider test coverage only after it is
pulled into git.git repository. I think it would be a good idea
for me to pull from you often.
Yes, I agree. I'm happy to send you an email when I have committed
changes to gitk if that will help.
Johannes Schindelin [EMAIL PROTECTED] writes:
Maybe we should decide on a common terminology before kicking out 1.0, and
look through all files in Documentation/ to have a consistent vocabulary.
And poor me does not get confused no more.
Glad to see you started the discussion on this one. I
Oh, another thing. Could you refrain from doing
quoted-printable when possible? Thanks.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
This series adds support for downloading pack files when appropriate in
http-pull. When it finds that a needed object is not available, it
downloads info/packs (into memory), identifies any pack files it doesn't
have from there, downloads indices of any of these that it doesn't have,
and
On Sun, 31 Jul 2005, Josef Weidendorfer wrote:
Added hook in git-receive-pack
After successful update of a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha2
is called if present. This allows e.g sending of a mail
with pushed commits on the remote repository.
Documentation update
Josef Weidendorfer [EMAIL PROTECTED] writes:
+It is assured that sha1-old is an ancestor of sha1-new (otherwise,
+the update would have not been allowed). refname is relative to
+$GIT_DIR; e.g. for the master head this is refs/heads/master.
I think this description is inaccurate; the
Linus Torvalds [EMAIL PROTECTED] writes:
This looks sane. However, I also get the strong feeling that
git-update-server-info should be run as part of a hook and not be built
into receive-pack..
Personally, I simply don't want to update any dumb server info stuff for
my own local
Hi,
I tried to avoid the work. But I'll do it.
Ciao,
Dscho
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 31 Jul 2005, Junio C Hamano wrote:
But you are. I can run this just fine:
No I'm not. Try all the machines behind my firewall.
kernel.org is just the place I put things to when I publish them. It
doesn't have any of my working directories on it.
Linus
-
To
On Sunday 31 July 2005 22:15, Junio C Hamano wrote:
Josef Weidendorfer [EMAIL PROTECTED] writes:
+It is assured that sha1-old is an ancestor of sha1-new (otherwise,
+the update would have not been allowed). refname is relative to
+$GIT_DIR; e.g. for the master head this is
Linus Torvalds [EMAIL PROTECTED] writes:
No I'm not. Try all the machines behind my firewall.
Ah, that's true. Do you push into them?
Let's yank out the update_server_info() call when Josef's patch
can handle a single hook call at the end of the run, in addition
to one call per each ref
On Sun, 31 Jul 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
No I'm not. Try all the machines behind my firewall.
Ah, that's true. Do you push into them?
Yup, I do. I have this thing that I don't do backups, but I end up having
redundancy instead, so I keep
Hi,
On Sun, 31 Jul 2005, Junio C Hamano wrote:
Let's yank out the update_server_info() call when Josef's patch
can handle a single hook call at the end of the run, in addition
to one call per each ref getting updated.
How about executing update_server_info() if no hook was found? That way,
Daniel, I would really have liked to merge this immediately, but
somehow the patch is whitespace damaged. Depressingly enough,
almost all patches I got from various people today had different
whitespace damages, and I started to suspect if there is
something wrong on my end, but it does not
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote:
Ryan Anderson [EMAIL PROTECTED] writes:
All emails are sent as a reply to the previous email, making it easy to
skip a collection of emails that are uninteresting.
I understand why _some_ people consider this
Linus Torvalds [EMAIL PROTECTED] writes:
In the central repo model you have another issue - you have potentially
parallell pushes to different branches with no locking what-so-ever (and
that's definitely _supposed_ to work), and I have this suspicion that the
update for dumb servers code
This adds support to http-pull for finding the list of pack files
available on the server, downloading the index files for those pack
files, and downloading pack files when they contain needed objects not
available individually. It retains the index files even if the pack
files were not needed,
This adds support for reading an uninstalled index, and installing a
pack file that was added while the program was running, as well as
functions for determining where to put the file.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
cache.h | 13 ++
sha1_file.c | 123
This series makes the core of the pull programs parallel. It should not
actually make any difference yet. It arranges to call prefetch() for each
object as soon as it is determined to be needed, and then call fetch() on
each object once there is nothing left to prefetch. By implementing
This adds support for calling lookup_object_type() with NULL for the type,
which will cause it to allocate enough memory for the largest type. This
allows struct object_lists for objects that need to be fetched to find out
what they are.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
This patch makes the core pull algorithm request all of the objects it can
(with prefetch()) before actually reading them (with fetch()). Future
patches (in a later series) will make use of this behavior to have
multiple requests in flight at the same time, reducing the need for
round-trips.
On a new machine, trying to boostrap into latest cogito, I download
and make cogito 0.12.1, and then...
$ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git cogito
defaulting to local storage area
14:48:53 URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master
[41/41] -
26 matches
Mail list logo
