Darrin Thompson <[EMAIL PROTECTED]> writes:
> 1. Pack files should reduce the number of http round trips.
> 2. What I'm seeing when I check out mainline git is the acquisition of a
> single large pack, then 600+ more recent objects. Better than before,
> but still hundreds of round trips.
I've pa
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
I have been looking at send-pack because some people seem to
want to push into a remote repository that names heads
differently from local. I have some questions that do not have
to do with anything about their request, but about what
the current code intends to do.
* Right now, "send-pack --all
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sat, 31 Jul 2005, Peter Osterlund wrote:
>>
>> > I bet there is a smarter way to do this, but this _should_ fix the problem
>> > Peter sees. Peter?
>>
>> Yes, it does fix the problem. Thanks.
>
> Ok, Junio, can you apply the git-merge-base patch? It
On Sat, 31 Jul 2005, Peter Osterlund wrote:
>
> > I bet there is a smarter way to do this, but this _should_ fix the problem
> > Peter sees. Peter?
>
> Yes, it does fix the problem. Thanks.
Ok, Junio, can you apply the git-merge-base patch? It's not perfect, but
it's clearly better than what's
On Sat, 30 Jul 2005, Junio C Hamano wrote:
>
> I love it I can just slow down and let others submit obviously
> correct patches, which I can just slurp in.
You're obviously doing well as a maintainer. Only stupid people try to do
everything themselves.
Personally, I spend a _lot_ of time comm
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> This patch implements Linus' idea that if you are not interested in
> pulling by HTTP, you can now say
>
> NO_CURL=1 make
>
> to compile everything except git-http-pull (thus not needing curl at all).
Thanks. Obviously this does not take ca
I have placed this, after slight reworking, in the master
branch.
[jc: This patch is a rework based on what Linus posted to the
list. The changes are:
- The original introduced four separate commands, which was
three too many, so I merged them into one with subcommands.
- Since the
This patch implements Linus' idea that if you are not interested in
pulling by HTTP, you can now say
NO_CURL=1 make
to compile everything except git-http-pull (thus not needing curl at all).
---
Makefile |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
b2e1e7eb6876b5f385
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sat, 30 Jul 2005, Linus Torvalds wrote:
> >
> > Yup, it's git-merge-base, and it is confused by the same thing that
> > confused git-rev-list.
> >
> > Thanks, I'll fix it.
>
> Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Having said that, I do not particulary think allowing push to
> write into different ref is an unreasonable thing. As you
> pointed out long time ago when send-pack was first done, the
> protocol is not so easily extensible, so this may require either
On Sat, 30 Jul 2005, Linus Torvalds wrote:
>
> Yup, it's git-merge-base, and it is confused by the same thing that
> confused git-rev-list.
>
> Thanks, I'll fix it.
Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
somebody else can come up with a better one. I think this
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.
Recently there was a discussion with binary packaging folks.
While I do not mind, and actually I would prefer, shipping gitk
as part of the
On Sat, 30 Jul 2005, Peter Osterlund wrote:
> >
> > Can you send me your HEAD and MERGE_HEAD (don't do the merge).
>
> HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2
> MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c
Bingo.
Yup, it's git-merge-base, and it is confused by the same thi
Stacked GIT 0.5 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit ob
On Sat, 30 Jul 2005, Peter Osterlund wrote:
>
> OK, but note that I didn't do any editing of any local files myself.
> Both commit ids are from your public linux kernel git tree. What I did
> was equivalent to:
>
> 1. rsync from
> rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.gi
On Sat, 30 Jul 2005, Linus Torvalds wrote:
> On Sat, 30 Jul 2005, Peter Osterlund wrote:
> >
> > OK, but note that I didn't do any editing of any local files myself.
> > Both commit ids are from your public linux kernel git tree. What I did
> > was equivalent to:
> >
> > 1. rsync from
> > rsync.k
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sat, 30 Jul 2005, Peter Osterlund wrote:
> >
> > I have problems pulling linux kernel changes from
> > 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
> > b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
> > I thought your patch wou
Junio C Hamano <[EMAIL PROTECTED]> writes:
> I have not answered this because I have not made up my mind.
> Certainly (iii) is probably the least work for me.
Certainly? Probably? Which one? I should not start typing
before having a cup of coffee. **BLUSH**
Anyway, yes I would appreciate if
Petr Baudis <[EMAIL PROTECTED]> writes:
>> (iii) Do wild things in the git-pb branch and send you patches.
>
> So I assume (iii) holds?
I have not answered this because I have not made up my mind.
Certainly (iii) is probably the least work for me.
My gut feeling is that I can deal with any of
On Sat, 30 Jul 2005, Alexander Nyberg wrote:
>
> Linus, do you think we could have something like
> patch-2.6.13-rc4-incremental-broken-out.tar.bz2 that could like Andrew's
> be placed into patches/ in a tree?
Not really. The thing is, since the git patches really _aren't_ serial,
and merging
On Sat, 30 Jul 2005, Peter Osterlund wrote:
>
> I have problems pulling linux kernel changes from
> 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
> b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
> I thought your patch would fix it, but it doesn't:
No, this is a merge confli
On Fri, 29 Jul 2005, Junio C Hamano wrote:
>
> Would this be OK? I think it is ugly but it gets the job done.
Looks ok. I'd suggest having some option to turn of "curl" too - I have
one machine that doesn't have curl installed, and I just turn the things
that depend on it off by hand by edit
On Fri, 29 Jul 2005 20:51:40 -0500 Paul Mackerras wrote:
> I have reworked the way gitk displays merges.
I have found a reproducible bug in gitk which seems to be in that new
code for merges. Run
gitk f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba
on the git or cogito repository (that commit
Introduce an asciidoc.conf file with the purpose of adding a gitlink: macro
which will improve the manpage output. Most notably this changes the following
in cogito.7
...
cg-add: cg-add.html [-N] FILE...
Add files to the GIT repository.
cg-branch-add: cg-branch-add.
Hi,
is it possible that you forgot to initialize commit_graft_nr to 0?
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
Dear diary, on Fri, Jul 29, 2005 at 10:58:19AM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> told me that...
> (i) Keep the git-pb branch polished and nice-to-merge, if you want to
> pull from it.
>
> (ii) Keep the git-pb branch polished and nice-to-merge and rebase it
> regularil
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This corner-case was triggered by a kernel commit that was not in date
> order, due to a misconfigured time zone that made the commit appear three
> hours older than it was.
I have problems pulling linux kernel changes from
33ac02aa4cef417871e128ab4a65
Hi, Junio C Hamano wrote:
> Introduce a new file $GIT_DIR/info/grafts
Nice work.
Has anybody git-imported the old tarfile+patch history yet?
If not, I'll do it over the weekend.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected rand
[EMAIL PROTECTED] writes:
> I still have the patch to make git-http-pull download packs, and I
> should be able to get it to read the objects/info/packs file without
> too much trouble.
Another thing that may help you gain more parallelism in the
initial set of requests is the rev-cache file. Yo
Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
which is a list of "fake commit parent records". Each line of
this file is a commit ID, followed by parent commit IDs, all
40-byte hex SHA1 separated by a single SP in between. The
records override the parent information we would norm
31 matches
Mail list logo
