* Re: www.kernel.org/git
From: Martin Langhoff @ 2007-01-02 7:25 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git, warthog19
In-Reply-To: <459A05F7.4060405@gmail.com>
On 1/2/07, Aneesh Kumar K.V <aneesh.kumar@gmail.com> wrote:
> The gitweb summary page at www.kernel.org/git have wrong git:// links.
I have just checked, and the URLs were correct. For example, I took
the git-tools url and successfully did
git-clone git://git.kernel.org/pub/scm/git/git-tools.git
Which URLs are failing for you?
>Also the search feature is not working properly. It generates the search
> results but then immediately loads a wrong page.
This does look broken... I'll see if I can find out more.
cheers,
martin
^ permalink raw reply
* www.kernel.org/git
From: Aneesh Kumar K.V @ 2007-01-02 7:12 UTC (permalink / raw)
To: git, warthog19
Hi,
The gitweb summary page at www.kernel.org/git have wrong git:// links. Also the search feature is not working properly. It generates the search results but then immediately loads a wrong page.
-aneesh
^ permalink raw reply
* infinite loop with git branch -D and packed-refs
From: Nicholas Miell @ 2007-01-02 6:44 UTC (permalink / raw)
To: git
# this is with 1.4.4.2, spearce says master is also affected.
# (not subscribed, please Cc:)
mkdir test
cd test
git init-db
touch blah
git add blah
git commit -m "blah"
git checkout -b A
git checkout -b B
git checkout master
git pack-refs --all --prune
git branch -D A B # --> infinite loop in lockfile.c:remove_lock_file()
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-02 6:32 UTC (permalink / raw)
To: Luben Tuikov; +Cc: J. Bruce Fields, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <65526.67561.qm@web31806.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> ...
>> Remote branches are stored in separate namespaces under
>> .git/refs/remotes/, so that they don't muck up your view of your local
>> branches, and so git can enforce different policies for them (such as
>> forbidding committing to them).
>
> Smells like another "newbie" protection.
>
> Let me understand, someone here installed git, didn't read the then
> man page of git-clone/pull/fetch, screwed up their repo, and decided
> to change established behavior.
You smelled and understood wrongly in this case. Another point
in separate-remote layout is that it makes it easier to interact
with more than one remotes, and we do not have to treat 'master'
and 'origin' as branch names any more specially than necessary.
^ permalink raw reply
* Re: git not tracking changes
From: Shawn O. Pearce @ 2007-01-02 5:59 UTC (permalink / raw)
To: Deepak Barua; +Cc: git
In-Reply-To: <b5a19cd20701012152n4f496198h93cab1b9b85a9a45@mail.gmail.com>
Deepak Barua <dbbarua@gmail.com> wrote:
> Hi,
> When i do a git add of a config.h file then make some changes and
> then do git commit it does not reflect the changes..
> eg
> dep@zion:~/programs/elinks/elinks-0.11-20061220$ git add config.h
Here you told Git to take the current contents of config.h and
stage it into the index. That content will be in the next
commit.
> dep@zion:~/programs/elinks/elinks-0.11-20061220$ vi config.h
Then you modify it. Git doesn't know about those changes to
config.h, nor does it care at this point.
> dep@zion:~/programs/elinks/elinks-0.11-20061220$ git commit
> nothing to commit
This is occuring because the content staged in the index does not
differ from the content in HEAD (the last commit on this branch).
You need to run `git add config.h` again now that you have modified
it to restage the modified file.
Basically I'm assuming that when you ran `git add config.h` the
first time the content must have matched HEAD, which meant you
didn't actually stage anything.
--
Shawn.
^ permalink raw reply
* git not tracking changes
From: Deepak Barua @ 2007-01-02 5:52 UTC (permalink / raw)
To: git
Hi,
When i do a git add of a config.h file then make some changes and
then do git commit it does not reflect the changes..
eg
dep@zion:~/programs/elinks/elinks-0.11-20061220$ git add config.h
dep@zion:~/programs/elinks/elinks-0.11-20061220$ vi config.h
dep@zion:~/programs/elinks/elinks-0.11-20061220$ git commit
nothing to commit
dep@zion:~/programs/elinks/elinks-0.11-20061220$ git commit
nothing to commit
dep@zion:~/programs/elinks/elinks-0.11-20061220$ ls
ABOUT-NLS autogen.sh config.h configure debian
INSTALL Makefile.lib SITES TODO
acinclude.m4 BUGS config.h.in configure.in doc
Makefile NEWS src Unicode
aclocal.m4 ChangeLog config.log contrib features.conf
Makefile.config po test
AUTHORS config config.status COPYING features.log
Makefile.config.in README THANKS
dep@zion:~/programs/elinks/elinks-0.11-20061220$
I am working on the hooks part modifying the perl script in the same
in the pre-commit hook but that is not related to this ...
what could be the problem...?
Also another file which you can see in the directory called "NEWS" is
being taken in to consideration...
the hook "pre-commit" is enabled and am adding a spell checker to it...
Regards
Deepak
--
Code Code Code Away
^ permalink raw reply
* Pushing into a repository with working directory?
From: Shawn O. Pearce @ 2007-01-02 4:51 UTC (permalink / raw)
To: git
So tonight on #git I think I answered for the 10th time why the
working directory doesn't update after a push to its associated
repository.
We all know its somewhat dangerous to push into the current branch
of a working directory, especially if that working directory contains
uncommitted changes, as HEAD no longer matches the index.
But we all also know its incredibly useful to be able to push into
a repository with a working directory, so we certainly don't want
to disallow it entirely.
What about refusing a push to the current branch (branch listed in
$GIT_DIR/HEAD) and the repository appears to have a working directory
(is_bare_git_dir is false)?
--
Shawn.
^ permalink raw reply
* Re: A note from the maintainer
From: Shawn O. Pearce @ 2007-01-02 3:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pra14ve.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I usually read all patches posted to the list, and follow almost
> all the discussions on the list, unless the topic is about an
> obscure corner that I do not personally use. But I am obviously
> not perfect. If you sent a patch that you did not hear from
> anybody for three days, that is a very good indication that it
> was dropped on the floor --- please do not hesitate to remind
> me.
Though a contributor should probably check the `maint`, `master`,
`next` or `pu` branches of git.git before sending a reminder.
Often we find that you have accepted a patch without comment (as
the patch is obviously correct and nobody else had a reason to
comment on it). In this case the patch will just appear in one of
the git.git branches, with no email indicating that.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-02 3:45 UTC (permalink / raw)
To: ltuikov
Cc: Theodore Tso, git, Shawn Pearce, Johannes Schindelin,
J. Bruce Fields
In-Reply-To: <926020.70066.qm@web31802.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> It is in this sense that I do "cd <branch>; git-pull . <branch>"
> in a sequence, and I'd rather do "cd <branch>; git-pull <symbolic-ref>"
> to define which branch is the merge coming from given the current branch
> _and_ the symbolic ref.
If I am reading you correctly, you have multiple directories,
each with its own .git/ directory but major parts of these .git/
directories are shared (namely, objects/ and refs/). You would
not be able to have separate checkout in these directories if
you shared .git/HEAD and .git/index, so at least each of these
directories has these two files for its own.
Is that what you are doing?
If that is the case, I think you do not even have to have the
"branch spec" to express the patchflow among them. Essentially
you are using "one branch, one directory, one repository"
workflow (my understanding is that this is how BK worked but I
haven't seen it) but with your own improvements. The reason
this is an improvement is because such a shared .git/refs/
allows you to do diff and log across branches this way, so if
you have a separate .git/config just like you already have
separate .git/HEAD and .git/index in these directories, you can
use [remote "xyz"] sections in each of them to achieve what you
called 'symbolic'.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-02 3:36 UTC (permalink / raw)
To: ltuikov; +Cc: git, J. Bruce Fields
In-Reply-To: <405044.6078.qm@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Questions:
>
> What is the reasonining of defining branch.<name>.merge to point
> to the "remote's setup"?
See list archives.
Because you are not required to use remote tracking branches.
By the way, I think we allow the name of the remote tracking
branch as well, but we do not advertise it -- always using
remote's name consistently is much less confusing.
> The reasoning is that the remote's setup should only leak into
> [remote] and no further. I.e. [remote] is the only one concerned
> with the mapping between the remote repo and the local repo.
No. Remote is not about mapping -- if mapping is there you can
talk about it, but that is optional.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2007-01-02 3:31 UTC (permalink / raw)
To: git
It has been a while since I sent this message out the last time,
and there seem to be some new people on the git list.
This message talks about how git.git is managed, and how you can
work with it.
* IRC and Mailing list
Many active members of development community hang around on #git
IRC channel. Its log is available at:
http://colabti.de/irclogger/irclogger_logs/git
[jc: Does anybody know a shortcut for "Today's" page on this
site? It irritates me having to click the latest link on this
page to get to the latest]
The development however is primarily done on this mailing list
you are reading right now. If you have patches, please send
them to the list, following Documentation/SubmittingPatches.
I usually read all patches posted to the list, and follow almost
all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use. But I am obviously
not perfect. If you sent a patch that you did not hear from
anybody for three days, that is a very good indication that it
was dropped on the floor --- please do not hesitate to remind
me.
The list from time to time gets messages that either
- state something incorrect, with a certain authoritative tone,
without doing minimum homework.
- try to rehash issues that have been ruled some time ago
without bringing anything new to the table,
I used to try responding to such messages quickly with pointers
to archived list messages and/or the name of the commit object
that settled the issue, in order to save other readers from
wasting time on them, but that has been a huge timesink for me,
so I'll stop doing so and simply ignore them.
This does not apply to messages from new people (the definition
of new is rather subjective --- if I cannot connect your name
with a specific contribution you made to the git community, you
are still new); I would welcome questions and comments from new
people on the list. They are good sources for us to learn which
parts of git's concepts are harder to learn and which
documentation can be improved.
The list is available at a few public sites as well:
http://marc.theaimsgroup.com/?l=git
http://news.gmane.org/gmane.comp.version-control.git
nntp://news.gmane.org/gmane.comp.version-control.git
* Repositories and branches.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
It is mirrored at Pasky's repo.or.cz as well.
There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man". The
first one is meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
I would have liked. It also contains some helper scripts I
use to maintain it.
The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The script to auto-maintain these two documentation branches are
found in "todo" branch as dodoc.sh script, if you are interested.
There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are reasonably
tested and ready to be used in a production setting. There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major. Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The
last such release was v1.4.4 done on Nov 14th last year.
Whenever a feature release is made, "maint" branch is forked off
from "master" at that point. Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it. The maintenance releases
are typically named with four dotted decimal, named after the
feature release they are updates to; the last such release was
v1.4.4.3. Usually new development will never go to this branch.
This branch is also pulled into "master" to propagate the fixes
forward.
A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody found his or her own itch to scratch, does not usually
happen on "master", however. Instead, it is forked into a
separate topic branch from the tip of "master", and first tested
in isolation; I may make minimum fixups at this point. Usually
there are a handful such topic branches that are running ahead
of "master" in git.git repository. I do not publish the tip of
these branches in my public repository, however, partly to keep
the number of branches that downstream developers need to worry
about and primarily because I am lazy.
I judge the quality of topic branches, taking advices from the
mailing list discussions. Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience". Luckily,
most of them start out in the latter, better shape.
The "next" branch is to merge and test topic branches in the
latter category with "master". In general it should always
contain the tip of "master". They may not be quite production
ready, but are expected to work more or less without major
breakage. I usually use "next" version of git for my own work.
"next" is where new and exciting things take place.
The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (that means
the topics that have been merged into "next" are not rebased).
The "pu" (proposed updates) branch bundles all the remaining
topic branches. The topic branches and "pu" are subject to
rebasing in general. Especially "pu" is almost always rewound
to the tip of "next" and reconstructed to contain the remaining
topic branches.
When a topic that was in "pu" proves to be in testable shape, it
graduates to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.
A topic that is in "next" is _expected_ to be tweaked and fixed
to perfection before it is merged to "master". I do this with:
git checkout master
git merge that-topic-branch
git branch -d that-topic-branch
However, being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in _any_
future release. There even was a case that a topic needed a few
reverting before graduating to "master".
^ permalink raw reply
* Re: Draft v1.5.0 release notes
From: Shawn O. Pearce @ 2007-01-02 2:57 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <4599C3E8.5060209@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> Junio C Hamano wrote:
> > - There is a configuration variable core.legacyheaders that
> > changes the format of loose objects so that they are more
> > efficient to pack and to send out of the repository over git
> > native protocol, since v1.4.2. However, this format cannot
> > be read by git older than that version; people fetching from
> > your repository using older clients over dumb transports
> > (e.g. http) using older versions of git will also be
> > affected. This is not enabled by default.
> >
> > - Since v1.4.3, configuration repack.usedeltabaseoffset allows
> > packfile to be created in more space efficient format, which
> > cannot be read by git older than that version. This is not
> > enabled by default.
> >
>
> For people in non-public development environments where there's
> absolutely no possibility of someone hitting a repo with an old client,
> presumably these options should both be enabled.
Or even in public ones, but where access by dumb clients isn't
offered (only anonymous or ssh based git native protocol is used).
> I wonder if it makes
> sense to add an option to git-init-db to create a configuration file
> with all the latest stuff enabled -- or better still, something like
>
> git-init-db --min-version=1.4.2
That's an interesting idea. Most users don't invoke init-db directly
however, they are using clone to copy someone else's repository.
But that option could easily be offered on both commands, with
clone just passing it through to init-db.
> that would enable all the non-backward-compatible stuff in the newly
> created repository. And then a special case "--min-version=current" to
> use all the most optimal settings for the current release, useful in
> environments like corporate LANs where the tool versions are centrally
> managed.
Actually I wonder if "--min-version=current" shouldn't just be the
default. Most users are going to init-db or clone locally and use
only the current version of Git (or later) against that repository.
Though that probably would break someone who runs multiple versions
of Git on the same system, because they have some strange reason
for doing so[*1*]. And it would certainly cause problems for
users who then rsync that repository (or scp it) to a webhost and
expect users with older versions of Git to be able to access it
with a commit-walker client. But that would be less of a problem
if we could teach users to first clone their repository before
publishing it, e.g.:
git clone --bare --min-version=1.2 . ../myproj.git
*1*: I'm not talking about Git developers here. I think most Git
developers run a `production` version of Git that they use for
actual revisioning, and other versions for testing, and those
testing versions are only used against testing repositories
that hold non-live data.
--
Shawn.
^ permalink raw reply
* Re: Draft v1.5.0 release notes
From: Steven Grimm @ 2007-01-02 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkkm47eg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> - There is a configuration variable core.legacyheaders that
> changes the format of loose objects so that they are more
> efficient to pack and to send out of the repository over git
> native protocol, since v1.4.2. However, this format cannot
> be read by git older than that version; people fetching from
> your repository using older clients over dumb transports
> (e.g. http) using older versions of git will also be
> affected. This is not enabled by default.
>
> - Since v1.4.3, configuration repack.usedeltabaseoffset allows
> packfile to be created in more space efficient format, which
> cannot be read by git older than that version. This is not
> enabled by default.
>
For people in non-public development environments, where there's
absolutely no possibility of someone hitting a repo with an old client,
presumably these options should both be enabled. I wonder if it makes
sense to add an option to git-init-db to create a configuration file
with all the latest stuff enabled -- or better still, something like
git-init-db --min-version=1.4.2
that would enable all the non-backward-compatible stuff in the newly
created repository. And then a special case "--min-version=current" to
use all the most optimal settings for the current release, useful in
environments like corporate LANs where the tool versions are centrally
managed.
Likewise, something like
git-repo-config --min-version=1.5.0
could be used to set all the options in an existing repo (presumably
this would not allow you to move backwards, just upgrade) for cases
where clients are known to have all upgraded to at least a particular
version.
Maybe that last purpose would be better served by a "git-upgrade"
command that, for example, could rebuild old packfiles in the new more
efficient format and write out the appropriate configuration. Though one
would have to take pains to point out that running that command was NOT
a required step when upgrading to a new git release, and would in fact
be a bad idea for projects being accessed by older clients.
-Steve
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-02 2:17 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin,
J. Bruce Fields
In-Reply-To: <20070102010816.GB4253@thunk.org>
--- Theodore Tso <tytso@mit.edu> wrote:
> Well, yes; since git-pull is implemented in terms of git-fetch
> followed by a git-merge, that's why I talked about git-fetch. It is
> git-fetch which uses remote.<non-URL>.{url,fetch}, not git-merge or
> git-pull (since it just passes those arguments over to git-fetch).
>
> > More specifically,
> > branch.<branch-match>.<symbolic-ref match>.{fetch,merge}.
>
> What do you mean by <branch-match> and <symbolic-ref match>?
>
> Are you assuming some kind of glob match? If so, what are the
> specific rules of the match that you are proposing?
Yes. I've outlined them at least twice in this thread
already as well as in that same email of mine which you're replying
to, which I'm replying to.
> > branch.<branch-match>..{fetch,merge} is allowed and defalts
> > to already implemented "git-pull".
>
> What do you mean by ".." here?
I mean "git-pull", as opposed to "git-pull <symbolic-ref>".
I.e. "branch.<branch-match>..{fetch,merge}" matches no symbolic
ref given, exactly what it defines.
> > Think of "git-pull", not just of "git-fetch". As well as think
> > of a setup where there are more than one branch implementing
> > software dependency, resolving to a software product.
>
> git-pull is implemented in terms of git-fetch. So if we make the
> change to git-fetch, the changes naturally follow to git-pull. Or are
> you proposing to change that?
No, not at all.
Please see my last email to Junio in this thread. Depending on
how this new functionlity is implemented for git 1.5, the concept
of "branch spec" can be had by using a "dummy" [remote] spec,
used only as a command line match, and specifying the merge
dependency in the [branch] spec, refering to "remote" and
identifying what to merge. See that email please.
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-02 2:09 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <20070102001044.GB32148@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Jan 01, 2007 at 04:01:15PM -0800, Luben Tuikov wrote:
> > --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > -The common `Pull: master:origin` mapping of a remote `master`
> > > -branch to a local `origin` branch, which is then merged to a
> > > -local development branch, again typically named `master`, is made
> > > -when you run `git clone` for you to follow this pattern.
> >
> > So is this no longer the case?
>
> Right; that mapping is no longer what git clone sets up for you.
>
> > Can someone please bring me up to date?
> >
> > What is going on?
>
> The simplest way to understand the current behavior is probably to
> install the latest git, read the git-clone man page, clone a new
> repository, and take a look at it.
I don't like "learning by observation" when there is an
intention -- i.e. I'd rather see a well written justification
of the intentions and design, as opposed to "poke at the black
box and try to figure it out".
It's like learning math by trying to memorize the formulas
as opposed to knowing how to derive them and why they are
the way they are.
I'm expecting a well written man page on the new stuff
_compared_ to the old stuff, similarly to Junio's response
to this very same email.
Luben
>
> Remote branches are stored in separate namespaces under
> .git/refs/remotes/, so that they don't muck up your view of your local
> branches, and so git can enforce different policies for them (such as
> forbidding committing to them).
>
> --b.
>
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-02 2:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <7vd55y46ta.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> What's going on is clean-up towards v1.5.0-rc1 ;-).
>
> - 'git clone' does not create a file that has a line that looks
> like "Pull: master:origin" anywhere anymore.
>
> - 'git clone' also does not create the traditional "'master' is
> special and we map that to origin, others are mapped as is
> under refs/heads/, and we have to drop 'origin' from the
> remote side because that name we want to use to store their
> 'master'" layout.
>
> So after a clone, you would get:
>
> [remote "origin"]
> url = ....
> fetch = refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> This configuration still causes "git pull" or "git pull origin"
> while on "master" to fetch and store the remote side's master as
> what you can refer to as 'origin' (because it expands to
> 'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),
> and then merges that to your current branch, so there is no
> change in the user experience in the big picture, but what is
> created to achieve that effect is different from what was
> described.
Ah, I see. Thanks Junio.
... And this is why I see some objections as to what I'm proposing
because it extends too far the extension itself of the old
behavior. (See below.)
Questions:
What is the reasonining of defining branch.<name>.merge to point
to the "remote's setup"? I would much, much rather stop the leak
of the remote's setup right at [remote] and contain it there,
while everything in [branch] would refer to local stuff.
So the above configuration would become:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
# merge gives the place and name of the remote branch locally mapped
merge = refs/heads/origin/master
# OR, better yet
# merge gives the name only of the remote branch to be merged
# the local mapping can be found from "remote = " above
merge = master
The reasoning is that the remote's setup should only leak into
[remote] and no further. I.e. [remote] is the only one concerned
with the mapping between the remote repo and the local repo.
Then, [branch] only talks about local relationships. Now
since [branch] does refer to _where_ the local mapping resolves
to, i.e. the right hand part of `:', then there is a redundancy
in branch.<name>.merge, since branch.<name>.remote _does refer_
to [remote] where we can find where it is locally mapped.
Thus, by reducibility, branch.name.merge should only contain
a name. Here is the dependency graph:
branch.name.merge <- (gives a local name)
branch.name.remote <- (gives the remote)
remote.rname.fetch <- (gives the remote:local name mapping)
remote.rname.url (gives the URL).
Now as to what I'm talking about, should be able to be had with:
[remote "parent"]
url = .
fetch = :
[branch "A"]
remote = parent
merge = master
[branch "B"]
remote = parent
merge = A
[branch "C"]
remote = parent
merge = B
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Luben Tuikov @ 2007-01-02 1:28 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <20070102001044.GB32148@fieldses.org>
--- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Jan 01, 2007 at 04:01:15PM -0800, Luben Tuikov wrote:
> > --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > -The common `Pull: master:origin` mapping of a remote `master`
> > > -branch to a local `origin` branch, which is then merged to a
> > > -local development branch, again typically named `master`, is made
> > > -when you run `git clone` for you to follow this pattern.
> >
> > So is this no longer the case?
>
> Right; that mapping is no longer what git clone sets up for you.
>
> > Can someone please bring me up to date?
> >
> > What is going on?
>
> The simplest way to understand the current behavior is probably to
> install the latest git, read the git-clone man page, clone a new
> repository, and take a look at it.
>
> Remote branches are stored in separate namespaces under
> .git/refs/remotes/, so that they don't muck up your view of your local
> branches, and so git can enforce different policies for them (such as
> forbidding committing to them).
Smells like another "newbie" protection.
Let me understand, someone here installed git, didn't read the then
man page of git-clone/pull/fetch, screwed up their repo, and decided
to change established behavior.
Regardless, I think addressable (named) branch specs are the way to go.
This will as well, unify/reconcile remotes/ and local stuff, since
it is already implemented for remotes/ .
Luben
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Theodore Tso @ 2007-01-02 1:08 UTC (permalink / raw)
To: Luben Tuikov
Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin,
J. Bruce Fields
In-Reply-To: <926020.70066.qm@web31802.mail.mud.yahoo.com>
On Mon, Jan 01, 2007 at 03:56:05PM -0800, Luben Tuikov wrote:
> > Currently, today, if you type:
> >
> > git fetch <non-URL>
> >
> > ... it will look up "<non-URL>" in a single global namespace, which
> > (using only the new config scheme) is looked up in remote.<non-URL>
> > and remote.<non-URL>.{url,fetch} is used to control the operation of
> > git-fetch.
>
> I'm talking about more in terms of git-merge, but since git-pull
> is a git-fetch and git-merge, I've been using git-pull for completeness.
Well, yes; since git-pull is implemented in terms of git-fetch
followed by a git-merge, that's why I talked about git-fetch. It is
git-fetch which uses remote.<non-URL>.{url,fetch}, not git-merge or
git-pull (since it just passes those arguments over to git-fetch).
> More specifically,
> branch.<branch-match>.<symbolic-ref match>.{fetch,merge}.
What do you mean by <branch-match> and <symbolic-ref match>?
Are you assuming some kind of glob match? If so, what are the
specific rules of the match that you are proposing?
> branch.<branch-match>..{fetch,merge} is allowed and defalts
> to already implemented "git-pull".
What do you mean by ".." here?
> Think of "git-pull", not just of "git-fetch". As well as think
> of a setup where there are more than one branch implementing
> software dependency, resolving to a software product.
git-pull is implemented in terms of git-fetch. So if we make the
change to git-fetch, the changes naturally follow to git-pull. Or are
you proposing to change that?
- Ted
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Theodore Tso @ 2007-01-02 0:57 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Luben Tuikov, Junio C Hamano, git, Shawn Pearce,
Johannes Schindelin
In-Reply-To: <20070102001044.GB32148@fieldses.org>
On Mon, Jan 01, 2007 at 07:10:44PM -0500, J. Bruce Fields wrote:
>
> The simplest way to understand the current behavior is probably to
> install the latest git, read the git-clone man page, clone a new
> repository, and take a look at it.
This should be mentioned in the 1.5 release notes --- that you won't
see a lot of the power the new git unless you create a new repository
using git-clone. For example, the man page for git-branch says that
"git branch -r" will list remote branches won't print anything if the
repository was originally cloned using an older version of git.
(I was using the version that shipped with Ubuntu Edgy before I
recently upgraded to the bleeding edge "next" branch so I could try
out the latest and greatest git features that was being discussed on
the mailing list. :-)
- Ted
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Jakub Narebski @ 2007-01-02 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vd55y46ta.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> So after a clone, you would get:
>
> [remote "origin"]
> url = ....
> fetch = refs/heads/*:refs/remotes/origin/*
By the way, I have thought that you would also get (to avoid nasty
"we don't know which branch is first in glob")
fetch = refs/heads/master:refs/remotes/origin/master
or
fetch = refs/heads/master:refs/remotes/origin/HEAD
(if master was current branch)
> [branch "master"]
> remote = origin
> merge = refs/heads/master
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-02 0:21 UTC (permalink / raw)
To: ltuikov; +Cc: git, J. Bruce Fields
In-Reply-To: <182318.86313.qm@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> ...
>> -The common `Pull: master:origin` mapping of a remote `master`
>> -branch to a local `origin` branch, which is then merged to a
>> -local development branch, again typically named `master`, is made
>> -when you run `git clone` for you to follow this pattern.
>
> So is this no longer the case?
>
> Can someone please bring me up to date?
>
> What is going on?
What's going on is clean-up towards v1.5.0-rc1 ;-).
- 'git clone' does not create a file that has a line that looks
like "Pull: master:origin" anywhere anymore.
- 'git clone' also does not create the traditional "'master' is
special and we map that to origin, others are mapped as is
under refs/heads/, and we have to drop 'origin' from the
remote side because that name we want to use to store their
'master'" layout.
So after a clone, you would get:
[remote "origin"]
url = ....
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
This configuration still causes "git pull" or "git pull origin"
while on "master" to fetch and store the remote side's master as
what you can refer to as 'origin' (because it expands to
'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),
and then merges that to your current branch, so there is no
change in the user experience in the big picture, but what is
created to achieve that effect is different from what was
described.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-02 0:12 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Shawn Pearce, Johannes Schindelin, Luben Tuikov
In-Reply-To: <20070102000606.GA32148@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Jan 01, 2007 at 03:59:44PM -0800, Luben Tuikov wrote:
>> --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
>> > +git pull origin next::
>>
>> No.
>>
>> > + Merge into the current branch the remote branch `next`;
>>
>> So, "origin" now means "current branch".
>
> No, "origin" refers to the remote repository that you originally cloned
> from.
>
> Pulls always merge into the current branch. So it wouldn't make sense
> to specify the current branch on the command line.
I was also somewhat confused by these examples. I think the
description is fine as long as we make it clear that they are
not meant to describe what an advanced user _could_ do with
various customizations, but to describe what happens with the
default configuration set up by git-clone.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: J. Bruce Fields @ 2007-01-02 0:10 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git, Shawn Pearce, Johannes Schindelin
In-Reply-To: <182318.86313.qm@web31812.mail.mud.yahoo.com>
On Mon, Jan 01, 2007 at 04:01:15PM -0800, Luben Tuikov wrote:
> --- "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > -The common `Pull: master:origin` mapping of a remote `master`
> > -branch to a local `origin` branch, which is then merged to a
> > -local development branch, again typically named `master`, is made
> > -when you run `git clone` for you to follow this pattern.
>
> So is this no longer the case?
Right; that mapping is no longer what git clone sets up for you.
> Can someone please bring me up to date?
>
> What is going on?
The simplest way to understand the current behavior is probably to
install the latest git, read the git-clone man page, clone a new
repository, and take a look at it.
Remote branches are stored in separate namespaces under
.git/refs/remotes/, so that they don't muck up your view of your local
branches, and so git can enforce different policies for them (such as
forbidding committing to them).
--b.
^ permalink raw reply
* Draft v1.5.0 release notes
From: Junio C Hamano @ 2007-01-02 0:08 UTC (permalink / raw)
To: git
The latest draft is kept as 'todo:v1.5.0.txt'. Since I've
merged the shallow clone changes, I've added a few sentences for
the series as well.
--
GIT v1.5.0 Release Notes
========================
Old news
--------
This section is for people who are upgrading from ancient
versions of git. Although all of the changes in this section
happened before the current v1.4.4 release, they are summarized
here in the v1.5.0 release notes for people who skipped earlier
versions.
In general, you should not have to worry about incompatibility,
and there is no need to perform "repository conversion" if you
are updating to v1.5.0. However, some of the changes are
one-way street upgrades; once you use them your repository
can no longer be used with ancient git.
- There is a configuration variable core.legacyheaders that
changes the format of loose objects so that they are more
efficient to pack and to send out of the repository over git
native protocol, since v1.4.2. However, this format cannot
be read by git older than that version; people fetching from
your repository using older clients over dumb transports
(e.g. http) using older versions of git will also be
affected. This is not enabled by default.
- Since v1.4.3, configuration repack.usedeltabaseoffset allows
packfile to be created in more space efficient format, which
cannot be read by git older than that version. This is not
enabled by default.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native clients can
still fetch from a repository that packed and pruned refs
(the server side needs to run the up-to-date version of git),
but older dumb transports cannot. Packing of refs is done by
an explicit user action, either by use of "git pack-refs
--prune" command or by use of "git gc" command.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
this may surprise old timers.
- 'git archive' superseded 'git tar' in v1.4.3;
- 'git cvsserver' was new invention in v1.3.0;
- 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
seriously enhanced during v1.4.0 timeperiod.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- reflog is an v1.4.0 invention. This alows you to name a
revision that a branch used to be at (e.g. "git diff
master@{yesterday} master" allows you to see changes since
yesterday's tip of the branch).
Updates in v1.5.0 since v1.4.4 series
-------------------------------------
* Index manipulation
- git-add is to add contents to the index (aka "staging area"
for the next commit), whether the file the contents happen to
be is an existing one or a newly created one.
- git-add without any argument does not add everything
anymore. Use 'git-add .' instead. Also you can add
otherwise ignored files with an -f option.
- git-add tries to be more friendly to users by offering an
interactive mode.
- git-commit <path> used to refuse to commit if <path> was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset <tree> <paths>... can be used to revert index
entries for selected paths.
- git-update-index is much less visible.
* Repository layout and objects transfer
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
created clones. The latter is still supported and there is
no need to convert your existing repository if you are
already comfortable with your workflow with the layout.
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree;
i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
used to track branches from the origin. New branches that
appear on the origin side after a clone is made are also
tracked automatically.
- git-branch and git-show-branch know remote tracking branches.
- git-push can now be used to delete a remote branch or a tag.
This requires the updated git on the remote side.
- git-push more agressively keeps the transferred objects
packed. Earlier we recommended to monitor amount of loose
objects and repack regularly, but you should repack when you
accumulated too many small packs this way as well. Updated
git-count-objects helps you with this.
* Reflog
- Reflog records the history of where the tip of each branch
was at each moment. This facility is enabled by default for
repositories with working trees, and can be accessed with the
"branch@{time}" and "branch@{Nth}" notation.
- "git show-branch" learned showing the reflog data with the
new --reflog option.
- The commits referred to by reflog entries are now protected
against pruning. The new command "git reflog expire" can be
used to truncate older reflog entries and entries that refer
to commits that have been pruned away previously with older
versions of git.
Existing repositories that have been using reflog may get
complaints from fsck-objects; please run "git reflog expire
--all" first to remove reflog entries that refer to commits
that are no longer in the repository before attempting to
repack it.
- git-branch knows how to rename branches and moves existing
reflog data from the old branch to the new one.
* Packed refs
- Repositories with hundreds of tags have been paying large
overhead, both in storage and in runtime. A new command,
git-pack-refs, can be used to "pack" them in more efficient
representation.
- Clones and fetches over dumb transports are now aware of
packed refs and can download from repositories that use
them.
* Configuration
- configuration related to colorize setting are consolidated
under color.* namespace (older diff.color.*, status.color.*
are still supported).
* Less external dependency
- We no longer require the "merge" program from the RCS suite.
All 3-way file-level merges are now done internally.
- The original implementation of git-merge-recursive which was
in Python has been removed; we have C implementation of it
now.
- git-shortlog is no longer a Perl script. It no longer
requires output piped from git-log; it can accept revision
parameters directly on the command line.
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects. This will continue to be the
case. However, a non UTF-8 commit encoding _must_ be
explicitly set with i18n.commitencoding in the repository
where a commit is made; otherwise git-commit-tree will
complain if the log message does not look like a valid UTF-8
string.
- The value of i18n.commitencoding in the originating
repository is recorded in the commit object on the "encoding"
header, if it is not UTF-8. git-log and friends notice this,
and reencodes the message to the log output encoding when
displaying, if they are different. The log output encoding
is determined by "git log --encoding=<encoding>",
i18n.logoutputencoding configuration, or i18n.commitencoding
configuration, in the decreasing order of preference, and
defaults to UTF-8.
* Foreign SCM interfaces
- git-svn now requires the Perl SVN:: libraries, the
command-line backend was too slow and limited.
- the 'commit' command has been renamed to 'set-tree', and
'dcommit' is the recommended replacement for day-to-day
work.
* User support
- Quite a lot of documentation updates.
- Bash completion scripts have been updated heavily.
- Better error messages for often used Porcelainish commands.
* Shallow clones
- There is a partial support for 'shallow' repositories that
keeps only recent history now. A 'shallow clone' is created
by specifying how deep that truncated history should be.
Currently a shallow repository has number of limitations:
- Cloning and fetching _from_ a shallow clone are not
supported (nor tested -- so they might work by accident but
they are not expected to).
- Pushing from nor into a shallow clone are not expected to
work.
- Merging inside a shallow repository would work as long as a
merge base is found in the recent history, but otherwise it
will be like merging unrelated histories and may result in
huge conflicts.
but this would be more than adequate for people who want to
look at near the tip of a big project with a deep history and
send patches in e-mail format.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-01-02 0:07 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
+ Update packedGit config option documentation.
+ mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
+ pack-objects: fix use of use_pack().
+ Fix random segfaults in pack-objects.
+ Cleanup read_cache_from error handling.
+ Replace mmap with xmmap, better handling MAP_FAILED.
+ Release pack windows before reporting out of memory.
+ Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
+ Test suite for sliding window mmap implementation.
+ Create pack_report() as a debugging aid.
+ Support unmapping windows on 'temporary' packfiles.
+ Improve error message when packfile mmap fails.
+ Ensure core.packedGitWindowSize cannot be less than 2 pages.
+ Load core configuration in git-verify-pack.
+ Fully activate the sliding window pack access.
+ Unmap individual windows rather than entire files.
+ Document why header parsing won't exceed a window.
+ Loop over pack_windows when inflating/accessing data.
+ Replace use_packed_git with window cursors.
+ Refactor how we open pack files to prepare for multiple windows.
+ Create read_or_die utility routine.
+ Use off_t for index and pack file lengths.
+ Refactor packed_git to prepare for sliding mmap windows.
+ Introduce new config option for mmap limit.
+ Replace unpack_entry_gently with unpack_entry.
This is what I was looking at on Cygwin on my wife's box today
(I do not have an easy access to Windows boxes otherwise so my
Cygwin testing is limited to only weekends when I am at home).
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
Johannes's suggestion to record a tree object instead of
LOCAL_DIFF is roger but not wilco yet --- I haven't thought
through the issue to see an improvement in the suggestion. We
will be clobbering both index and the working tree, and I think
"diff --binary HEAD" and "write-tree" record the equivalent
amount of information given a HEAD for recovery.
* sp/merge (Sun Dec 31 00:02:13 2006 -0500) 3 commits
- Refresh the index before starting merge-recursive.
- Improve merge performance by avoiding in-index merges.
- Avoid git-fetch in `git-pull .` when possible.
Three patches in the earlier part of this series have graduated
to 'master' as I think they are useful.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
These are on hold.
^ 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