* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-05 23:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Chris Lee
In-Reply-To: <Pine.LNX.4.64.0701051457020.3661@woody.osdl.org>
On Fri, 5 Jan 2007, Linus Torvalds wrote:
>
> Yeah, it's mainly a "safety thing" - have the default be the "don't waste
> memory".
Btw, I'm not at all certain whether it's necessary or a good thing. I just
decided to see how many people really seem to use the commit messages at
all. So feel free to throw the patch away if you don't think this is
worthwhile, I won't push it.
Linus
^ permalink raw reply
* New way of tracking remote branches -- question
From: Luben Tuikov @ 2007-01-05 23:02 UTC (permalink / raw)
To: git
I can see that the remote heads are where they are supposed to be
but no local tracking heads are created (by default). I had
to do this manually.
Old behavior was that git did that for you automatically.
So I suppose this is another newbie protection.
What is the now the new, accepted way of tracking locally
remote branches? (other than creating them manually in
refs/heads?)
Thanks,
Luben
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-05 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Linus Torvalds
In-Reply-To: <7vtzz5duk1.fsf@assigned-by-dhcp.cox.net>
On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:
> Subject: [PATCH] builtin-prune: memory diet.
>
> Somehow we forgot to turn save_commit_buffer off while walking
> the reachable objects. Releasing the memory for commit object
> data that we do not use matters for large projects (for example,
> about 90MB is saved while traversing linux-2.6 history).
Is git-verify-pack supposed to mmap the entire packfile? Because the
version I have maps 2.3GB into RAM and keeps it there until it's done.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Junio C Hamano @ 2007-01-05 23:09 UTC (permalink / raw)
To: Chris Lee; +Cc: Shawn O. Pearce, git, Linus Torvalds
In-Reply-To: <204011cb0701051503m3a431e07qc12662eecc08884f@mail.gmail.com>
"Chris Lee" <chris133@gmail.com> writes:
> On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:
>> Subject: [PATCH] builtin-prune: memory diet.
>>
>> Somehow we forgot to turn save_commit_buffer off while walking
>> the reachable objects. Releasing the memory for commit object
>> data that we do not use matters for large projects (for example,
>> about 90MB is saved while traversing linux-2.6 history).
>
> Is git-verify-pack supposed to mmap the entire packfile? Because the
> version I have maps 2.3GB into RAM and keeps it there until it's done.
Yes -- we need to hash the whole thing as well as doing other
checks on it. Sliding mmap() in "next" will mmap that in chunks
of 32MB or 1GB, but its needing to read every byte of it does
not change.
The problem Linus pointed out was that your SHA1_Update()
implementations may not be prepared to hash the whole 2.3GB in
one go. The one in "master" (and "maint", although I haven't
done a v1.4.4.4 maintenance release yet) calls SHA1_Update()
in chunks to work around that potential issue.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-05 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <7vtzz9usyp.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
>
> Because [remote] is NOT about mapping. It asks the fetch
> mechanism to fetch from that remote, so the primary thing you
> should look at is .url, not RHS of colon on .fetch lines. Use
> of tracking branches is strictly optional.
Remote
------
Please help me understand. Here is a sample remote from
an actual repo (actual names changed):
[remote "origin"]
url = http://blah/bleah.git
fetch = +refs/heads/*:refs/remotes/origin/*
This basically says: "Get it" from such and such url, where
on the repo at that url, i.e. the remote side, you will
find stuff in "refs/heads/", and when you get it here, locally,
put it in refs/remotes/origin/.
Now if this isn't a mapping, then please can someone
explain to me what a "mapping" is?
The "fetch = <remote>:<local>" is inherently a mapping,
its syntax dictates it, as does the actual actions
it performs: "fetch" from "remote" and "put in local <local>".
Branch
------
Here is an actual example:
[branch "branchA"]
remote = origin
merge = refs/heads/branchA
Yeah, but by default "refs/heads/branchA" doesn't exist (see
my previous email). It doesn't have to, since it specifies
the "remote part", but that has already been handled by
"[remote]".
Unless of course "[branch "..."]" specifies the _remote_ branch
being tracked in refs/remotes/origin. Is this the case.
Does "[branch]" apply to local branches too? If so,
then what happens when refs/heads/branchA does exist and is
the same as the one it describes -- i.e. completely old behavior.
Thanks,
Luben
^ permalink raw reply
* Re: New way of tracking remote branches -- question
From: Junio C Hamano @ 2007-01-05 23:17 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <776323.21089.qm@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> I can see that the remote heads are where they are supposed to be
> but no local tracking heads are created (by default). I had
> to do this manually.
>
> Old behavior was that git did that for you automatically.
> So I suppose this is another newbie protection.
A very fuzzily stated question which is hard to answer, but I do
not think it is another newbie protection, if it apparently is
actively hurting you. Also the documentation may need to be
updated to teach you enough about how to achieve what you want.
You can see where remote heads are by doing what? ls-remote?
"Old behaviour" for what configuration?
A fresh clone made with a recent version sets things up to track
all remote branches from the repository you cloned from under
remotes/origin/, and it even tracks new ones as they are added
at the remote, so you probably are doing something different
from the default configuration that has:
remotes.origin.fetch = +refs/heads/*:refs/remotes/origin/*
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-05 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Lee, Shawn O. Pearce, git
In-Reply-To: <7v64bldqas.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 Jan 2007, Junio C Hamano wrote:
>
> The problem Linus pointed out was that your SHA1_Update()
> implementations may not be prepared to hash the whole 2.3GB in
> one go. The one in "master" (and "maint", although I haven't
> done a v1.4.4.4 maintenance release yet) calls SHA1_Update()
> in chunks to work around that potential issue.
Well, I think Chris is worried about having it all mapped at the same
time.
It does actually end up forcing the kernel to do more work (it's harder to
re-use a mapped page than it is to reuse one that isn't), and in that
sense, if you have less than <n> GB of RAM and can't just keep it all in
memory at the same time, doing one large mmap is possibly more expensive
than chunking things up.
That said, I doubt it's a huge problem. If you can't fit the whole file in
memory, your real performance issue is going to be the IO, not the fact
that the kernel has to work a bit harder at unmapping pages ;)
Linus
^ permalink raw reply
* [RFC] Adding stack-level logging/undo to StGIT
From: Yann Dirson @ 2007-01-05 23:19 UTC (permalink / raw)
To: Catalin Marinas, GIT list
This mail is a draft collection of design ideas to hopefully progress
towards full "undo" functionnality in StGIT. The issue is not
trivial, so I'd prefer to hear from users before starting to code
anything :)
The main goal with this feature is to provide a log of what happenned
to a stgit stack, with sufficient details to be able to undo any
number of operations. A "stg undo" (and fellow "stg redo") would
replace current --undo flags that only a couple of commands implement.
Another command (maybe "stg slog" ?) would allow to examine this log.
Since some existing stgit operations are already made of several more
elementary operations, the log will most likely have to record sort of
BEGIN/END events, which will pave the way to transactions.
What I'm thinking of is to use a mechanism similar to the one already
used for patch logs: the stack log would use its own head ref pointing
to a commit describing the operation, with the stacklog commit for the
previous operation as parent.
Information to be available from a stacklog commit include:
- the series file
- the current top patchname
- the relevant patchlog commits
The current top can be put into a "Current:" pseudo-header in the
commit message.
The series file seems a good candidate to be history-tracked by GIT
(in its own tree if necessary - a tree would even provide some place
to extend the mechanism when needed).
The list of patchlog commits, ordered by the series file, may or may
not be useful to history-track. It could be kept in a blob alongside
the series file, or could be part of the stacklog commit message. The
latter would allow to jump from stacklog to patchlog in gitk at no
cost (although that's hardly an excuse per se ;).
Which patchlogs should be referenced by a stacklog entry ?
I would rule out those for patches left unapplied by the operation,
which (unless I miss some point) are by definition not touched by that
operation (I'm talking about elementary operations like
push/pop/new/delete here - compound operations can obviously have
side-effects, recorded in the elementary stacklogs that build them up).
For elementary operations as well, it looks like just recording the
patchlog for the patch left at the top by the operation could be
enough. Or do I miss something ?
Maybe maintainance of the stacklog requires a separate index file ?
For compound operations, I'd like to be able to handle them as a
single operation for most purpose - ie, "stg undo" after a "stg push
p1" would both undo the push like "stg push --undo" currently does,
and as well revert the series order to put p1 back where it was
located.
That is, a compound operation would be represented in the stack log by
a single commit. That commit would in turn point to the sequence of
elementary commits that make the compound, probably by a "Sublogs:"
pseudo-header in the compound stacklog message.
Until a compound operation has been finalized, we would store in the
stacklog the operations that will make the compound, using a special
"BEGIN" operation to mark the start of the transaction. When
finalizing the transaction, those would be moved from the main
stacklog to the compound stacklog entry, which would replace them.
Problem: with this design, the first operation in the compound will
point to the BEGIN op as its parent; I would prefer to have it point
to the compound's parent (ie. the previous real operation on the
stack). That would allow to easily "break a transaction", either
before it's finished, or afterwards by "undoing into it".
So probably we should keep the BEGIN marker somewhere else.
Any strong ideas out there ?
Best regards,
--
Yann.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-05 23:20 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <826.67287.qm@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>>
>> Because [remote] is NOT about mapping. It asks the fetch
>> mechanism to fetch from that remote, so the primary thing you
>> should look at is .url, not RHS of colon on .fetch lines. Use
>> of tracking branches is strictly optional.
>
> Remote
> ------
>
> Please help me understand. Here is a sample remote from
> an actual repo (actual names changed):
>
> [remote "origin"]
> url = http://blah/bleah.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> This basically says: "Get it" from such and such url, where
> on the repo at that url, i.e. the remote side, you will
> find stuff in "refs/heads/", and when you get it here, locally,
> put it in refs/remotes/origin/.
[remote "origin"]
url = http://blah/blah.git
fetch = refs/heads/master
is also fine. The point is that you do not have to use tracking
branches. ", and when you get it here, ..." part is optional.
> Branch
> ------
>
> Here is an actual example:
>
> [branch "branchA"]
> remote = origin
> merge = refs/heads/branchA
>
> Yeah, but by default "refs/heads/branchA" doesn't exist (see
> my previous email). It doesn't have to, since it specifies
> the "remote part", but that has already been handled by
> "[remote]".
Obviously fetch needs to handle the remote part because that is
the only name it exists at the remote. branch.*.merge is used
by pull, not fetch, and fetch communicates with pull by using
the remote name, because use of local tracking branches is
optional.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-05 23:32 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <7vvejlcb6z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> --- Junio C Hamano <junkio@cox.net> wrote:
>>>
>>> Because [remote] is NOT about mapping. It asks the fetch
>>> mechanism to fetch from that remote, so the primary thing you
>>> should look at is .url, not RHS of colon on .fetch lines. Use
>>> of tracking branches is strictly optional.
>>
>> [remote "origin"]
>> url = http://blah/bleah.git
>> fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> This basically says: "Get it" from such and such url, where
>> on the repo at that url, i.e. the remote side, you will
>> find stuff in "refs/heads/", and when you get it here, locally,
>> put it in refs/remotes/origin/.
>
> [remote "origin"]
> url = http://blah/blah.git
> fetch = refs/heads/master
>
> is also fine. The point is that you do not have to use tracking
> branches. ", and when you get it here, ..." part is optional.
In other words, remote.*.fetch could be spelled as mapping to
cause them locally stored in tracking branches, but the storing
in tracking branches is merely a side effect of a fetch, not the
primary one. The primary effect is to fetch the necessary
objects and leave what was fetched in .git/FETCH_HEAD to
communicate with later 'git pull'. The side effect is optional,
so is spelling remote.*.fetch as a mapping.
>> Yeah, but by default "refs/heads/branchA" doesn't exist (see
>> my previous email). It doesn't have to, since it specifies
>> the "remote part", but that has already been handled by
>> "[remote]".
>
> Obviously fetch needs to handle the remote part because that is
> the only name it exists at the remote. branch.*.merge is used
> by pull, not fetch, and fetch communicates with pull by using
> the remote name, because use of local tracking branches is
> optional.
In other words, the remote name is the only thing that can be
used between fetch and pull to communicate. Fetch tells pull "I
fetched these from the remote", and pull uses that information
to make a merge, and the merge comment says "this merges the
branch xyz from that repository", using the 'xyz' name used at
the remote side, not your local tracking branch, which you may
or may not be using.
^ permalink raw reply
* Re: New way of tracking remote branches -- question
From: Junio C Hamano @ 2007-01-05 23:39 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <7vzm8xcbcp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> I can see that the remote heads are where they are supposed to be
>> but no local tracking heads are created (by default). I had
>> to do this manually.
>>
>> Old behavior was that git did that for you automatically.
>> So I suppose this is another newbie protection.
>
> A very fuzzily stated question which is hard to answer, but I do
> not think it is another newbie protection, if it apparently is
> actively hurting you. Also the documentation may need to be
> updated to teach you enough about how to achieve what you want.
Can you state the problem you observed about the recent git in a
way that is easier to debug?
For example, you could state:
With older git (I verified that v1.3.0 still works like
this), I used to be able to just say:
$ git fetch
(this is the exact command line -- I am not giving a URL
nor even "origin" after "git fetch"). When the upstream
created a new branch 'blah', the above command created a
new local branch 'blah' automatically for me. With the
tip of 'master' (e27e609), this does not happen anymore.
My configuration is that I have .git/remotes/origin file
whose contents is .... I do not have any remote.*.url,
remote.*.fetch, nor branch.*.remote configuration variables.
to be more helpful.
I am not dismissing your message as whining. You probably have
hit a regression while we adopted the BCP to encourage separate
remote layout, and I would like to understand the issue.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Junio C Hamano @ 2007-01-05 23:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git, Chris Lee
In-Reply-To: <Pine.LNX.4.64.0701051457020.3661@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> Ah, there are those annoying "using this as the merge base whose
>> commit log is..." business. I wonder if anybody is actually
>> reading them (I once considered squelching that output).
>
> "output_commit_title()" used it. Not just for the merge base, but for the
> regular "merging X and Y" messages, I think.
Yes, what I really was wondering were (1) if the messages are
useful, and (2) if so should that belong to git-merge not
git-merge-recursive.
^ permalink raw reply
* Re: New way of tracking remote branches -- question
From: Junio C Hamano @ 2007-01-05 23:50 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <776323.21089.qm@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> I can see that the remote heads are where they are supposed to be
> but no local tracking heads are created (by default). I had
> to do this manually.
Ah, after firing off a few messages, I think I now guessed
what you are talking about correctly.
You are talking about the separate remote layout "git clone"
creates, and talking about the fact that there is nothing in
refs/heads/ except master while refs/remotes/origin/ mirrors
what the remote side has faithfully, aren't you?
If that is the case, I can explain. It is a good topic to talk
about.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Junio C Hamano @ 2007-01-05 23:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Lee, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0701051515000.3661@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> It does actually end up forcing the kernel to do more work (it's harder to
> re-use a mapped page than it is to reuse one that isn't), and in that
> sense, if you have less than <n> GB of RAM and can't just keep it all in
> memory at the same time, doing one large mmap is possibly more expensive
> than chunking things up.
Even if it is a read-only private mapping? Would MAP_SHARED
help?
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-05 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Chris Lee
In-Reply-To: <7virflca43.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 Jan 2007, Junio C Hamano wrote:
>
> Yes, what I really was wondering were (1) if the messages are
> useful, and (2) if so should that belong to git-merge not
> git-merge-recursive.
I kind of like them, but I don't really look _too_ much at them, so ..
I guess it would make more sense to do that at a higher level, and have
the low-level merger just do the actual merge itself.
Linus
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Johannes Schindelin @ 2007-01-06 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Shawn O. Pearce, git, Chris Lee
In-Reply-To: <7virflca43.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 5 Jan 2007, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> >> Ah, there are those annoying "using this as the merge base whose
> >> commit log is..." business. I wonder if anybody is actually
> >> reading them (I once considered squelching that output).
> >
> > "output_commit_title()" used it. Not just for the merge base, but for the
> > regular "merging X and Y" messages, I think.
>
> Yes, what I really was wondering were (1) if the messages are
> useful, and (2) if so should that belong to git-merge not
> git-merge-recursive.
Since recursive merge performs possibly more than one merge, it belongs
into merge-recursive.c, _if_ we want that message.
I found it helpful for "debugging" failed _recursive_ merges. I.e. I knew
which of the recursive merges introduced the many, many conflicts. But I
cannot remember off-hand if that was a test merge, and if it was before,
or after, I sorted the merge bases by date.
Since the conflict markers now say which commit the conflicts came from, I
am okay with removing the message, though.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-06 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Lee, Shawn O. Pearce, git
In-Reply-To: <7vac0xc9g8.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 Jan 2007, Junio C Hamano wrote:
>
> Even if it is a read-only private mapping? Would MAP_SHARED
> help?
mmap is mmap, and it all boils down to having to remove it from the page
tables.
But it really shouldn't be a problem.
Linus
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-06 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Lee, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0701051610290.3661@woody.osdl.org>
On Fri, 5 Jan 2007, Linus Torvalds wrote:
>
> But it really shouldn't be a problem.
Basically, this boils down to the same old issue: if you have a fixed
access pattern (like SHA1_Update() over the whole buffer), you're actually
likely to perform better with a loop of read() calls than with mmap.
So if we ONLY did the SHA1 thing, we shouldn't do mmap, we should just
chunk things up into 16kB buffers or something, and read them.
But the mmap in pack-check _also_ ends up being for the subsequent object
checking (with unpacking etc), so the mmap here actually is probably the
right thing to do. I really wouldn't worry, unless we get people who
report real problems (and I think the problems with svn-import of the huge
KDE repos are all elsewhere, notably in teh SVN import itself, not in any
pack handling ;)
Linus
^ permalink raw reply
* Re: New way of tracking remote branches -- question
From: Luben Tuikov @ 2007-01-06 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm8xcbcp.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > I can see that the remote heads are where they are supposed to be
> > but no local tracking heads are created (by default). I had
> > to do this manually.
> >
> > Old behavior was that git did that for you automatically.
> > So I suppose this is another newbie protection.
>
> A very fuzzily stated question which is hard to answer, but I do
> not think it is another newbie protection, if it apparently is
> actively hurting you. Also the documentation may need to be
> updated to teach you enough about how to achieve what you want.
>
> You can see where remote heads are by doing what? ls-remote?
> "Old behaviour" for what configuration?
>
> A fresh clone made with a recent version sets things up to track
> all remote branches from the repository you cloned from under
> remotes/origin/, and it even tracks new ones as they are added
> at the remote, so you probably are doing something different
> from the default configuration that has:
>
> remotes.origin.fetch = +refs/heads/*:refs/remotes/origin/*
That's exactly what I have, but "git branch" shows only "master".
The other branches are indeed in refs/remotes/origin/ but I want
them in refs/heads/ so I had to do that manually by creating
the head and add this into .git/config.
Old behavior was more _convenient_.
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-06 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvejlcb6z.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > --- Junio C Hamano <junkio@cox.net> wrote:
> >>
> >> Because [remote] is NOT about mapping. It asks the fetch
> >> mechanism to fetch from that remote, so the primary thing you
> >> should look at is .url, not RHS of colon on .fetch lines. Use
> >> of tracking branches is strictly optional.
> >
> > Remote
> > ------
> >
> > Please help me understand. Here is a sample remote from
> > an actual repo (actual names changed):
> >
> > [remote "origin"]
> > url = http://blah/bleah.git
> > fetch = +refs/heads/*:refs/remotes/origin/*
> >
> > This basically says: "Get it" from such and such url, where
> > on the repo at that url, i.e. the remote side, you will
> > find stuff in "refs/heads/", and when you get it here, locally,
> > put it in refs/remotes/origin/.
>
> [remote "origin"]
> url = http://blah/blah.git
> fetch = refs/heads/master
>
> is also fine. The point is that you do not have to use tracking
> branches. ", and when you get it here, ..." part is optional.
Ok. So then in this case "fetch = refs/heads/master" describes
.git/refs/heads/master or something else?
If it does, then this is a local map.
I guess this is the case where one wants to automate
"git-pull . OtherBranch", but shouldn't this be handled
by [branch], i.e. the "merge" part of [branch].
> > Branch
> > ------
> >
> > Here is an actual example:
> >
> > [branch "branchA"]
> > remote = origin
> > merge = refs/heads/branchA
> >
> > Yeah, but by default "refs/heads/branchA" doesn't exist (see
> > my previous email). It doesn't have to, since it specifies
> > the "remote part", but that has already been handled by
> > "[remote]".
>
> Obviously fetch needs to handle the remote part because that is
> the only name it exists at the remote. branch.*.merge is used
> by pull, not fetch, and fetch communicates with pull by using
> the remote name, because use of local tracking branches is
> optional.
Does this mean that "fetch = <remote>:" is legal? Shouldn't the
RHS always exist? Is the RHS of "fetch = :" what you mean
by local tracking branches?
Luben
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Junio C Hamano @ 2007-01-06 0:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Lee, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0701051611550.3661@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 5 Jan 2007, Linus Torvalds wrote:
>>
>> But it really shouldn't be a problem.
>
> Basically, this boils down to the same old issue: if you have a fixed
> access pattern (like SHA1_Update() over the whole buffer), you're actually
> likely to perform better with a loop of read() calls than with mmap.
>
> So if we ONLY did the SHA1 thing, we shouldn't do mmap, we should just
> chunk things up into 16kB buffers or something, and read them.
While I have your attention, there is a patch for the sliding
mmap() thing that raises the mmap window to 1GB (which means a
pack smaller than that is mmap'ed in its entirety, whle 2.3GB
pack will be mapped perhaps as three separate chunks) and the
total mmap window to 8GB (and any overflows we LRU out) on
places where sizeof(void*) == 8 (i.e. git compiled for 64-bit).
Currently these limits are 32MB and 256MB respectively on
platforms with real mmap().
Do you have any comments on it?
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-06 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6u9cann.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> --- Junio C Hamano <junkio@cox.net> wrote:
> >>>
> >>> Because [remote] is NOT about mapping. It asks the fetch
> >>> mechanism to fetch from that remote, so the primary thing you
> >>> should look at is .url, not RHS of colon on .fetch lines. Use
> >>> of tracking branches is strictly optional.
> >>
> >> [remote "origin"]
> >> url = http://blah/bleah.git
> >> fetch = +refs/heads/*:refs/remotes/origin/*
> >>
> >> This basically says: "Get it" from such and such url, where
> >> on the repo at that url, i.e. the remote side, you will
> >> find stuff in "refs/heads/", and when you get it here, locally,
> >> put it in refs/remotes/origin/.
> >
> > [remote "origin"]
> > url = http://blah/blah.git
> > fetch = refs/heads/master
> >
> > is also fine. The point is that you do not have to use tracking
> > branches. ", and when you get it here, ..." part is optional.
>
> In other words, remote.*.fetch could be spelled as mapping to
> cause them locally stored in tracking branches, but the storing
> in tracking branches is merely a side effect of a fetch, not the
> primary one. The primary effect is to fetch the necessary
> objects and leave what was fetched in .git/FETCH_HEAD to
> communicate with later 'git pull'. The side effect is optional,
> so is spelling remote.*.fetch as a mapping.
Oh ok -- I forgot about .git/FETCH_HEAD.
> >> Yeah, but by default "refs/heads/branchA" doesn't exist (see
> >> my previous email). It doesn't have to, since it specifies
> >> the "remote part", but that has already been handled by
> >> "[remote]".
> >
> > Obviously fetch needs to handle the remote part because that is
> > the only name it exists at the remote. branch.*.merge is used
> > by pull, not fetch, and fetch communicates with pull by using
> > the remote name, because use of local tracking branches is
> > optional.
>
> In other words, the remote name is the only thing that can be
> used between fetch and pull to communicate. Fetch tells pull "I
> fetched these from the remote", and pull uses that information
> to make a merge, and the merge comment says "this merges the
> branch xyz from that repository", using the 'xyz' name used at
> the remote side, not your local tracking branch, which you may
> or may not be using.
Ok.
Luben
^ permalink raw reply
* Re: New way of tracking remote branches -- question
From: Luben Tuikov @ 2007-01-06 0:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz4xcacr.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> I can see that the remote heads are where they are supposed to be
> >> but no local tracking heads are created (by default). I had
> >> to do this manually.
> >>
> >> Old behavior was that git did that for you automatically.
> >> So I suppose this is another newbie protection.
> >
> > A very fuzzily stated question which is hard to answer, but I do
> > not think it is another newbie protection, if it apparently is
> > actively hurting you. Also the documentation may need to be
> > updated to teach you enough about how to achieve what you want.
>
> Can you state the problem you observed about the recent git in a
> way that is easier to debug?
>
> For example, you could state:
>
> With older git (I verified that v1.3.0 still works like
> this), I used to be able to just say:
>
> $ git fetch
>
> (this is the exact command line -- I am not giving a URL
> nor even "origin" after "git fetch"). When the upstream
> created a new branch 'blah', the above command created a
> new local branch 'blah' automatically for me. With the
> tip of 'master' (e27e609), this does not happen anymore.
>
> My configuration is that I have .git/remotes/origin file
> whose contents is .... I do not have any remote.*.url,
> remote.*.fetch, nor branch.*.remote configuration variables.
>
> to be more helpful.
>
> I am not dismissing your message as whining. You probably have
> hit a regression while we adopted the BCP to encourage separate
> remote layout, and I would like to understand the issue.
And I'm not whining. It just that when I've done something 1000
times and all of a sudden I do the same thing and didn't see the
expected behaviour, I posted.
"git-pull" didn't "create" the branches in the place I was
expecting. I.e. while they are in .git/refs/remotes/origin/
they are not in .git/refs/heads.
Then I manually created the heads in .git/refs/heads
and manually added that to .git/config, i.e. the [branch]
part.
I was hoping I wouldn't need to do that at all, as old
git-pull exposed remote branches, or I was expecting to
at least find a git command to do this 2nd additional
manual step for me.
Luben
^ permalink raw reply
* Re: New way of tracking remote branches -- question
From: Junio C Hamano @ 2007-01-06 1:11 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <7vejq9c9tf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> I can see that the remote heads are where they are supposed to be
>> but no local tracking heads are created (by default). I had
>> to do this manually.
>
> Ah, after firing off a few messages, I think I now guessed
> what you are talking about correctly.
>
> You are talking about the separate remote layout "git clone"
> creates, and talking about the fact that there is nothing in
> refs/heads/ except master while refs/remotes/origin/ mirrors
> what the remote side has faithfully, aren't you?
>
> If that is the case, I can explain. It is a good topic to talk
> about.
Disclaimer. I am not very good at defending what I do not fully
agree with, and the separate remote is one of them, but because
it has become the default layout, let me try.
When cloning from a repository with a single branch (like
Linus's linux-2.6), the traditional layout created
heads/{origin,master}. Origin is a tracking branch that you
were not supposed to build on top of (or reset to move around,
for that matter), and master is where you do your work (or you
do your work elsewhere and use master to integrate them).
The separate remote layout creates remotes/origin/{HEAD,master}
that you can still refer to with "origin" (because sha1_name
knows about "refs/remotes/%s/HEAD") and is a tracking branch.
It also creates heads/master which is where you do your work (or
integration).
So from the high level view, the usage has not changed for the
simplest case with the new layout.
When the other side have more than one branch (say, 'master' and
'next'), the story is different. The traditional layout created
heads/next in addition. This _is_ a tracking branch that you
were not supposed to build on top of or reset.
The problem is that "git branch" listing does not tell you the
differences between 'master' and 'next' with the traditional
layout. They happen to be the same name as what the remote side
has, but they are VASTLY different. 'master' is *your* local
branch you can freely use to do whatever you want, and does not
have to have ANYTHING to do with the remote 'master' ('origin'
is the mirror of remote 'master', not 'master'). While 'next'
is the mirror of remote 'next' and you are not even supposed to
touch it.
The separate remote layout instead adds remotes/origin/next. It
does not fork heads/next from it when a clone is made. I guess
we could do that, and I do not have a strong preference myself.
I think other poeple on the list (especially the ones who wanted
separate remote layout) prefer not to have the automatic fork of
all remote branches.
I think the current way reflects the distributed nature of git
better.
* You may not necessarily care what happens on the non-primary
branch at the remote side. You are not forced to have the
same branch structure as the remote has. People who happily
track 'master' can even forget about other branches tracked
in remotes/origin/ and have heads/master and nothing else in
the local branch namespace.
* Your heads/ namespace is of your own. The repository clone
sets up arranges the master branch to start from the same
commit as where you cloned from, and sets up so that changes
made on the master at the remote is merged into your master,
but that is merely a convention that was deemed as the most
common and the most convenient.
One inconvenience for disciplined people is that traditional
layout allowed "git checkout next" to compile and install what
the remote side placed on a non-primary branch 'next'.
If you wanted to do _ANY_ development on top of it (even if that
was just to set '#define DEBUG 1'), however, you would need to
branch off of it, say "git checkout -b my-next next", so the
above inconvenience is arguably very minor. On the other hand,
the downside are the pollution of your own heads/ namespace
(having your forked branch and remote tracking branch means
heads/ would have next and pu from me and my-next and my-pu you
work on), and some people are not as careful and disciplined as
you are and have made mistakes of committing their own changes
while on such remote tracking branches (you can call the latter
part "newbie protection"). The next 'git fetch', especially
when it was forced _and_ was done while on 'next', was rather
unpleasant. Of course, discipined people like you and me would
never do that, but we are not the only two people in the
universe ;-).
The issue of "checking the tracking branch out to look-and-see"
is going to be addressed by the upcoming detached HEAD support,
so personally I do not think it will be a huge problem. You
would have to say "git checkout origin/next" for it with the new
layout.
Another thing the separate remote gives us is to make it easier
to interact with more than one remote, by having a new directory
next to remotes/origin/ directory. If you used the traditional
layout, your heads/ namespace would explode because you would
have to have something like:
heads/origin -- from linux-2.6's master
heads/origin-libata -- from jgarzik libata ALL
heads/origin-sii-lbt -- from jgarzik libata sii-lbt
...
in a flat namespace intermixed with your own development
branches, instead of:
remotes/origin/master -- from linux-2.6's master
remotes/libata/ALL
remotes/libata/sii-lbt
...
grouped together by where they come from (and they cannot
possibly be mucked around directly thanks to being in remotes/
hierarchy), separated from any of your own development branches
that are in heads/.
Also, this is only about the default layout clone makes, and the
refs are not packed, so you can easily move remotes/origin/*
(except 'HEAD') to heads/ immediately after making a clone and
set up remotes.*.fetch configuration to match the traditional
layout if that is what you find more convenient. The operation
in a repository layed out in the traditional way is still fully
supported (and will continue to be -- that's what old timers
use), and there is not even a reason to change your work habit
by converting an existing repository.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-06 1:17 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <594263.16987.qm@web31811.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> [remote "origin"]
>> url = http://blah/blah.git
>> fetch = refs/heads/master
>>
>> is also fine. The point is that you do not have to use tracking
>> branches. ", and when you get it here, ..." part is optional.
>
> Ok. So then in this case "fetch = refs/heads/master" describes
> .git/refs/heads/master or something else?
It names http://blah/blah.git/refs/heads/master (unless blah.git
repository uses packed refs then has pruned the loose refs).
> If it does, then this is a local map.
No, it is just a list of remote refs (one element list because
there is only one "fetch =" line).
> Does this mean that "fetch = <remote>:" is legal? Shouldn't the
> RHS always exist?
Documentation/pull-fetch-param.txt
^ 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