* type in cg-merge?
From: Alan Chandler @ 2005-11-11 7:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
I am just reading the code in cg-merge to see how it works (taking your advice
to see how to re-write my history properly - see early threads about this
subject)
At line there is an echo 0 that looks suspiciously like it should be an exit
0.
Of course I may just have egg on my face - its my first attempt at looking at
the code.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* [PATCH] Do not lose author name information to locale gotchas.
From: Junio C Hamano @ 2005-11-11 7:42 UTC (permalink / raw)
To: git
I noticed format-patch loses authorship information of Lukas' patch
when I run git tools with LC_LANG set to ja_JP. It turns out that
the sed script to set environment variables were not working on his
name (encoded in UTF-8), which is unfortunate but technically correct.
Force sed invocation under C locale because we always want literal byte
semantics.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I might have screwed up people's names already without
noticing; if that happened to you, please forgive me. I
think this patch fixes all the problematic places...
git-commit.sh | 2 +-
git-format-patch.sh | 2 +-
git-revert.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
applies-to: 8eacf17303188e55375f76bea8051555ba1baf02
0375d39e7d3052bdb9b21f984a7b7d2b02e627a5
diff --git a/git-commit.sh b/git-commit.sh
index daf90f1..41955e8 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -184,7 +184,7 @@ then
}
'
set_author_env=`git-cat-file commit "$use_commit" |
- sed -ne "$pick_author_script"`
+ LANG=C LC_ALL=C sed -ne "$pick_author_script"`
eval "$set_author_env"
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 548d2d5..7ee5d32 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -201,7 +201,7 @@ process_one () {
;;
esac
- eval "$(sed -ne "$whosepatchScript" $commsg)"
+ eval "$(LANG=C LC_ALL=C sed -ne "$whosepatchScript" $commsg)"
test "$author,$au" = ",$me" || {
mailScript="$mailScript"'
a\
diff --git a/git-revert.sh b/git-revert.sh
index dfd914c..4154fe0 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -112,7 +112,7 @@ cherry-pick)
q
}'
set_author_env=`git-cat-file commit "$commit" |
- sed -ne "$pick_author_script"`
+ LANG=C LC_ALL=C sed -ne "$pick_author_script"`
eval "$set_author_env"
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] C implementation of the 'git' program.
From: Junio C Hamano @ 2005-11-11 7:40 UTC (permalink / raw)
To: Raja R Harinath, Andreas Ericsson; +Cc: git
In-Reply-To: <m3lkzv4qnz.fsf@harinath.blr.novell.com>
Raja R Harinath <rharinath@novell.com> writes:
> This is bad, since it does the wrong thing for the correct way:
>
> make prefix=/usr
> sudo make prefix=/usr install
>
> With your patch 'git' will be compiled as root.
You are correct.
We should allow building as user and installing as root, with
the installation step _not_ touching the build directory at all.
A good litmus test is that you should be able to build and
install from a root-squashed NFS mounted working tree, without
giving write permissions to NFS-nobody user (obviously you need
to give read and search permissions).
Andreas?
^ permalink raw reply
* Something looks like CVS modules
From: Alexander Litvinov @ 2005-11-11 7:13 UTC (permalink / raw)
To: git
Does anybody can guide me how to replace CVS modules in the git enviroment ?
Currently we have few (~5) projects that can be used by others. At cvs world
we have modules and everything works fine. There are external links in the
svn word - almost the same except tags and branches.
What can I do to make similar functionality with git ?
^ permalink raw reply
* Should have been what is cg-clone doing (Re: What is cg-clone)
From: Alan Chandler @ 2005-11-11 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <200511110656.29553.alan@chandlerfamily.org.uk>
On Friday 11 Nov 2005 06:56, Alan Chandler wrote:
> Just trying to set up my public repository and test it.
>
> cg-clone http://www.chandlerfamily.org.uk/git/famtree.git new
>
> When I get near the end the following happens:
>
> http://www.chandlerfamily.org.uk/git/famtree.git/refs/tags/:
> 05:46:53 ERROR 403: Forbidden.
>
> I suspect its trying to get a list of tags, but is the ":" part of the
> error message, or was that what it was trying to receive.
>
> Does it require that apache serves the directories properly, because at the
> moment I have DirectoryIndex on these set to gitweb.cgi (although thats
> giving me 403 errors at the moment, hence my suspicions)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Raja R Harinath @ 2005-11-11 6:58 UTC (permalink / raw)
To: git
In-Reply-To: <20051110182631.3C5615BF90@nox.op5.se>
Hi,
exon@op5.se (Andreas Ericsson) writes:
[snip]
> As a nice side-effect, the patch also fixes the problem with
> make
> make prefix=/usr install
>
> Signed-off-by: Andreas Ericsson <ae@op5.se>
[snip]
> +# Force rebuild so that "make prefix=<something> install" Just Works.
> +.PHONY: git
This is bad, since it does the wrong thing for the correct way:
make prefix=/usr
sudo make prefix=/usr install
With your patch 'git' will be compiled as root.
- Hari
^ permalink raw reply
* What is cg-clone
From: Alan Chandler @ 2005-11-11 6:56 UTC (permalink / raw)
To: git
Just trying to set up my public repository and test it.
cg-clone http://www.chandlerfamily.org.uk/git/famtree.git new
When I get near the end the following happens:
http://www.chandlerfamily.org.uk/git/famtree.git/refs/tags/:
05:46:53 ERROR 403: Forbidden.
I suspect its trying to get a list of tags, but is the ":" part of the error
message, or was that what it was trying to receive.
Does it require that apache serves the directories properly, because at the
moment I have DirectoryIndex on these set to gitweb.cgi (although thats
giving me 403 errors at the moment, hence my suspicions)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: merge-base: fully contaminate the well.
From: Junio C Hamano @ 2005-11-11 6:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511102125510.4627@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So the cheap test is to just say
>
> /* Do we have multiple results? */
> if (result->next)
> contaminate_well(result);
>
> no?
Correct. And this is only for really artificial corner case so
we should try to avoid for normal cases as much as possible,
cheaply.
> Btw, I don't think your contamination logic is necessarily complete. We
> may not even have parsed some of the commits that end up being on that
> strange corner case.
I haven't tried walking any other test cases, but wouldn't that
be arguing that the our assumption that the current merge-base
is at least complete if not optimum?
^ permalink raw reply
* Re: git-archimport
From: Martin Langhoff @ 2005-11-11 5:58 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <20051111051910.GP9131@raven.localdomain>
On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1
I've never imported a signed changeset, perhaps that's the problem. Is
the repo public so I can test it myself?
cheers,
martin
^ permalink raw reply
* [PATCH] cg-fetch: support for active symbols in rsync path
From: Pavel Roskin @ 2005-11-11 5:49 UTC (permalink / raw)
To: git, Petr Baudis
t9112-fetch-rsync.sh breaks if cogito is located in a directory
containing e.g. spaces. The test uses its own rsync replacement
(localrsync) and supplies it to cg-fetch with full patch. cg-fetch
doesn't quote rsync sufficiently to prevent interpreting the path to
localrsync by the shell.
This bug is unlikely to be a problem in real life, but it's important to
have cogito tests run properly in directories with unusual names, since
it allows to catch a number of more serious problems.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-fetch b/cg-fetch
index 8fa34ce..6dfd02f 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -102,7 +102,7 @@ get_rsync()
shift
fi
- eval ${RSYNC:-rsync} $RSYNC_FLAGS $rsync_flags_l -v -Lr \
+ eval '"${RSYNC:-rsync}"' $RSYNC_FLAGS $rsync_flags_l -v -Lr \
"$1$appenduri" "$2$appenduri" $redir | $filter
return ${PIPESTATUS[0]}
}
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: merge-base: fully contaminate the well.
From: Linus Torvalds @ 2005-11-11 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmobuc00.fsf@assigned-by-dhcp.cox.net>
On Thu, 10 Nov 2005, Junio C Hamano wrote:
>
> The discussion on the list demonstrated a pathological case where
> an ancestor of a merge-base can be left interesting. This commit
> introduces a postprocessing phase to fix it.
Hmm. I'd suggest only doing this for the (relatively unlikely) case of
there being more than one merge-base..
You don't even have to be exact about it: just see if the result list is
bigger than one. (ie "result->next != NULL"). Yeah, sometimes there are
result commits that get turned UNINTERESTING after they are added to the
result list, and your "contaminate" phase would be strictly not needed
then, but that's already a pretty unusual case.
So the cheap test is to just say
/* Do we have multiple results? */
if (result->next)
contaminate_well(result);
no?
Btw, I don't think your contamination logic is necessarily complete. We
may not even have parsed some of the commits that end up being on that
strange corner case. I think you catch the particular case you tried, but
I think that in theory, with long chains of commits out of date order, you
could be in the situation of having determined that everything was
uninteresting before you even parsed enough to see the chain from one
merge-base to another.
In fact, I think it would happen with your pathological example if it had
just one more commit out-of-order in the E-D-C-B chain. But I didn't walk
it through.
Linus
^ permalink raw reply
* Re: git-archimport
From: Kevin Geiss @ 2005-11-11 5:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Kevin Geiss, git
In-Reply-To: <46a038f90511101421o7988a1bfi89eb0e33bd34e4bb@mail.gmail.com>
On Fri, Nov 11, 2005 at 11:21:12AM +1300, Martin Langhoff wrote:
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784
>
> Hmmm. The script uses tla itself to get the patch. What happens if you do
>
> tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1
>
> In short, you must have a recent tla configured and with the archive
> registered.
>
> cheers,
>
>
>
> martin
I've got tla 1.3, and the changeset seems to be there:
10:15pm0raven>tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1 /tmp
usage: tla get-changeset [options] revision [dir]
try get-changeset --help
10:15pm1raven>tla get-changeset kevin@desertsol.com--files/scripts--oco--0--patch-1 /tmp
gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1
gpg: Good signature from "Kevin Geiss <kevin@desertsol.com>"
10:15pm0raven>tla get-changeset --help /tmp
retrieve a changeset from an archive
usage: tla get-changeset [options] revision [dir]
-h, --help Display a help message and exit.
-H Display a verbose help message and exit.
-V, --version Display a release identifier string
and exit.
-A, --archive Override `my-default-archive'
10:16pm0raven>tla --version /tmp
tla lord@emf.net--gnu-arch-2004/dists--tla--1.3--version-0(configs/gnu/This-release) from regexps.com
^ permalink raw reply
* [PATCH] git-clone: quote destination directory name
From: Pavel Roskin @ 2005-11-11 5:19 UTC (permalink / raw)
To: git
git-clone doesn't quote the full path to the destination directory,
which causes it to fail if the path contains spaces or other characters
interpreted by the shell.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/git-clone.sh b/git-clone.sh
index 4fdd652..0f37dff 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -163,7 +163,7 @@ yes,yes)
rm -f "$D/.git/TMP_ALT"
if test -f "$D/.git/TMP_ALT"
then
- ( cd $D &&
+ ( cd "$D" &&
. git-parse-remote &&
resolve_alternates "$repo" <"./.git/TMP_ALT" ) |
while read alt
@@ -191,7 +191,7 @@ yes,yes)
;;
esac
-cd $D || exit
+cd "$D" || exit
if test -f ".git/HEAD"
then
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: tracking a tree that doesn't progress linearly
From: Martin Langhoff @ 2005-11-11 4:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17268.3463.252020.591687@cargo.ozlabs.ibm.com>
On 11/11/05, Paul Mackerras <paulus@samba.org> wrote:
> I want to be able to publish a git tree for others to follow but I
> also want to be retain the freedom to remove commits and/or rebase
> commits in the tree.
I sometimes want that too, but git doesn't have a 'rewind' semantics,
and probably for a good reason. The approach I am studying is to
create a thousand throaway short-lived branches. It is safe to publish
them as long as people following your branches _know_ that they'll be
orphaned, and that any commits they have on top of them they'll have
to rebase.
So you could publish your tree with devel-<datestamp> heads, and
announce when you're moving to a newer one. People tracking your
branches can tend register & checkout the new branches, and do a
git-merge to rebase their patches to your new branch, or replay them
with git-format-patch and git-am.
On the other hand, if StGIT grows better support for sharing patches,
it could make all this look like the stone age.
cheers,
martin
^ permalink raw reply
* [PATCH] archimport: handle pika escaping
From: Martin Langhoff @ 2005-11-11 5:00 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Arch uses pika escaping in some places (but not all!). Specifically, commits of
the type 'patch' use pika escaping in the log entries, which we parse to know
what to add/delete and what to commit.
This patch checks for hints of pika escaping and asks tla to unescape for us.
Originally implemented by Penny Leach <penny@catalyst.net.nz>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-archimport.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
applies-to: 6466c53ae80cddbb581c5fdb2332f9321fade867
b9d1055507ebce7f1ae1706feb79619cb03cf078
diff --git a/git-archimport.perl b/git-archimport.perl
index 980e827..e22c816 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -565,6 +565,11 @@ sub parselog {
next if $t =~ m!\{arch\}/!;
next if $t =~ m!\.arch-ids/!;
next if $t =~ m!\.arch-inventory$!;
+ # tla cat-archive-log will give us filenames with spaces as file\(sp)name - why?
+ # we can assume that any filename with \ indicates some pika escaping that we want to get rid of.
+ if ($t =~ /\\/ ){
+ $t = `tla escape --unescaped '$t'`;
+ }
push (@tmp, shell_quote($t));
}
@$ref = @tmp;
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Pavel Roskin @ 2005-11-11 4:53 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Petr Baudis, git
In-Reply-To: <200511110213.54846.Josef.Weidendorfer@gmx.de>
On Fri, 2005-11-11 at 02:13 +0100, Josef Weidendorfer wrote:
> > Correct. But if it's a concern, I think we could make some
> > improvements. Following approaches could be tried (starting from top,
> > using following steps as a fallback):
> >
> > 1) Use recorded branch, i.e. the branch name that was used in cg-clone.
>
> This is the "#..." part in .git/branches/origin, and it is already used.
I'm not sure if we understand each other, but "recorded" refers to
automatically determined branch name. If cg-clone can determine the
branch name, that name should be saved and used for updates.
Whether the branch name is saved in .git/branches/ using hash notation
(old style) or in .git/remotes/ (new style) is irrelevant.
If cg-clone cannot determine the branch name, we may either support it,
or revert to "master". I'm ambivalent about that. Probably reverting
to "master" is better to simplify the code. On the other hand, I can
imagine public repositories without the "master" branch.
> I have nothing against using HEAD for cloning, but the branch name should
> be recorded, such that cg-pull always fetches from the same branch.
To use HEAD, we'll need to port git from Cygwin, since readlink doesn't
work over http.
> I think 1) is enough if we add the detected branch name in the #... part
> in .git/branches/origin at cg-clone time.
I agree that the branch name should be saved explicitly using already
supported notation (if that's what you mean).
> And "detectable" covers the local case, which was my concern here [*1*]
>
> Josef
>
> [*1*] after being told about the "stable HEAD" property of public repositories,
> which is correct. I am not even sure that a HEAD makes sense
> in public repositories: in my opinion HEAD has something to do with checked out
> files, and a public repository usually does not have these. But perhaps
> that's only me...
That's why I mentioned the idea of having a separate file to indicate
the default branch for export.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Martin Langhoff @ 2005-11-11 4:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051110102043.GQ30496@pasky.or.cz>
On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> Interesting. Could you check what the merge base is?
>
> git-merge-base local remote
>
> It should be the merge from (1).
It seems to be actually one of the parents, not the merge itself.
> > For an example, clone
> > http://locke.catalyst.net.nz/git/moodle.git#mdl-artena-tairawhiti and
> > register also the
> > http://locke.catalyst.net.nz/git/moodle.git#mdl-local branch. Create
> > two heads:
>
> Could you please run git-update-server-info over there?
Should be fixed now...
cheers,
martin
^ permalink raw reply
* tracking a tree that doesn't progress linearly
From: Paul Mackerras @ 2005-11-11 3:18 UTC (permalink / raw)
To: git
I want to be able to publish a git tree for others to follow but I
also want to be retain the freedom to remove commits and/or rebase
commits in the tree. For example, if someone sends me a patch and I
put it in the tree, then they send me a revised version, I want to be
able to roll back to just before I applied the older patch and start
again from there.
What this means, AFAICS, is that the head of the published tree won't
always be a descendent of all previous values of the head. If
somebody is following the state of the tree by doing a git pull every
so often, and I have rolled back the tree and applied some new
patches, then the git pull will try to merge the old and new state,
which is not what we want. What we want is something that just gets
the local tree to the same state as the remote tree.
Is there a git command which does the equivalent of a git fetch,
followed by setting the head and checking it out?
Or is this an incredibly stupid idea for some reason that hasn't
occurred to me yet? :)
Thanks,
Paul.
^ permalink raw reply
* merge-base: fully contaminate the well.
From: Junio C Hamano @ 2005-11-11 2:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511091348530.4627@g5.osdl.org>
The discussion on the list demonstrated a pathological case where
an ancestor of a merge-base can be left interesting. This commit
introduces a postprocessing phase to fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 9 Nov 2005, Junio C Hamano wrote:
>
>> But the point of well-poisoning you did in merge-base was to
>> detect that E is an ancestor of B and exclude it in the first
>> place.
>
> Ahh, you're right, and I'm wrong. That "E" is not a real merge-base, since
> there _is_ a valid merge-base that is a direct descendant of it and thus
> objectively better.
>
> Which means that sometimes it can stop with too _many_ merge heads, just
> because it hasn't realized that they are reachable through a chain that is
> otherwise provably uninteresting.
I am not particularly proud of this change, but here is an
attempt to fully contaminate the well without going all the
way down to root. It adds a postprocessing phase which does
not parse any new commits.
> The thing is, I don't see what guarantees that the show-branch brhaviour
> is safe or conservative.
You are right about this; I have a separate patch to fix it.
merge-base.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 77 insertions(+), 1 deletions(-)
applies-to: 8eacf17303188e55375f76bea8051555ba1baf02
a2fd94f707128f3f390362725c8d8b0802940111
diff --git a/merge-base.c b/merge-base.c
index 286bf0e..43a6818 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -80,6 +80,45 @@ static struct commit *interesting(struct
* Now, list does not have any interesting commit. So we find the newest
* commit from the result list that is not marked uninteresting. Which is
* commit B.
+ *
+ *
+ * Another pathological example how this thing can fail to mark an ancestor
+ * of a merge base as UNINTERESTING without the postprocessing phase.
+ *
+ * 2
+ * H
+ * 1 / \
+ * G A \
+ * |\ / \
+ * | B \
+ * | \ \
+ * \ C F
+ * \ \ /
+ * \ D /
+ * \ | /
+ * \| /
+ * E
+ *
+ * list A B C D E F G H
+ * G1 H2 - - - - - - 1 2
+ * H2 E1 B1 - 1 - - 1 - 1 2
+ * F2 E1 B1 A2 2 1 - - 1 2 1 2
+ * E3 B1 A2 2 1 - - 3 2 1 2
+ * B1 A2 2 1 - - 3 2 1 2
+ * C1 A2 2 1 1 - 3 2 1 2
+ * D1 A2 2 1 1 1 3 2 1 2
+ * A2 2 1 1 1 3 2 1 2
+ * B3 2 3 1 1 3 2 1 2
+ * C7 2 3 7 1 3 2 1 2
+ *
+ * At this point, unfortunately, everybody in the list is
+ * uninteresting, so we fail to complete the following two
+ * steps to fully marking uninteresting commits.
+ *
+ * D7 2 3 7 7 3 2 1 2
+ * E7 2 3 7 7 7 2 1 2
+ *
+ * and we end up showing E as an interesting merge base.
*/
static int show_all = 0;
@@ -88,6 +127,7 @@ static int merge_base(struct commit *rev
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
+ struct commit_list *tmp = NULL;
if (rev1 == rev2) {
printf("%s\n", sha1_to_hex(rev1->object.sha1));
@@ -104,9 +144,10 @@ static int merge_base(struct commit *rev
while (interesting(list)) {
struct commit *commit = list->item;
- struct commit_list *tmp = list, *parents;
+ struct commit_list *parents;
int flags = commit->object.flags & 7;
+ tmp = list;
list = list->next;
free(tmp);
if (flags == 3) {
@@ -130,6 +171,41 @@ static int merge_base(struct commit *rev
if (!result)
return 1;
+ /*
+ * Postprocess to fully contaminate the well.
+ */
+ for (tmp = result; tmp; tmp = tmp->next) {
+ struct commit *c = tmp->item;
+ /* Reinject uninteresting ones to list,
+ * so we can scan their parents.
+ */
+ if (c->object.flags & UNINTERESTING)
+ commit_list_insert(c, &list);
+ }
+ while (list) {
+ struct commit *c = list->item;
+ struct commit_list *parents;
+
+ tmp = list;
+ list = list->next;
+ free(tmp);
+
+ /* Anything taken out of the list is uninteresting, so
+ * mark all its parents uninteresting. We do not
+ * parse new ones (we already parsed all the relevant
+ * ones).
+ */
+ parents = c->parents;
+ while (parents) {
+ struct commit *p = parents->item;
+ parents = parents->next;
+ if (!(p->object.flags & UNINTERESTING)) {
+ p->object.flags |= UNINTERESTING;
+ commit_list_insert(p, &list);
+ }
+ }
+ }
+
while (result) {
struct commit *commit = result->item;
result = result->next;
---
0.99.9.GIT
^ permalink raw reply related
* Re: The host:remote syntax mess
From: Junio C Hamano @ 2005-11-11 1:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111012216.GJ30496@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> I've just noticed that host:remote syntax seems to have been hijacked
> again and is now attached to the GIT protocol in
>
> Documentation/pull-fetch-param.txt
>
> (which BTW misses git+ssh). I said "seems", because connect.c still
> appears to assume it is SSH. So what is the plan?
Sorry about that. Thanks for noticing.
There is no plan to change that. This documentation gotcha was
just that yours truly stupidly merged documentation changes
without reading every single line.
-- >8 -- cut here -- >8 --
[PATCH] Documentation: "host:path/to/repo" is git native over ssh.
You could also spell it ssh://host:/path/to/repo (or git+ssh,
ssh+git), but without method:// is shorter to type, so mention
only that one in the short and sweet list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 5c2888e..ddd5823 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -8,7 +8,7 @@
- Rsync URL: rsync://remote.machine/path/to/repo.git/
- HTTP(s) URL: http://remote.machine/path/to/repo.git/
- git URL: git://remote.machine/path/to/repo.git/
- or remote.machine:/path/to/repo.git/
+- ssh URL: remote.machine:/path/to/repo.git/
- Local directory: /path/to/repo.git/
===============================================================
+
^ permalink raw reply related
* Re: [PATCH] Change 'cache' to 'index' in the docs
From: Junio C Hamano @ 2005-11-11 1:34 UTC (permalink / raw)
To: Lukas =?iso-2022-jp-2?B?U2FuZHN0chsuQRtOdm0=?=; +Cc: git, junkio
In-Reply-To: <4373EFFB.6060802@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 410 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> git-update-index.txt says:
> "Modifies the index or directory cache."
>
> I thought the index was the directory cache.
> Is git-update-index.txt badly worded or is there something
> I'm missing?
Nothing. Just 'cache' is so ingrained to the brain of some/many
of us that we let it go unnoticed, with an excuse that somewhere
we say "index aka cache".
^ permalink raw reply
* The host:remote syntax mess
From: Petr Baudis @ 2005-11-11 1:22 UTC (permalink / raw)
To: git
Hello,
I've just noticed that host:remote syntax seems to have been hijacked
again and is now attached to the GIT protocol in
Documentation/pull-fetch-param.txt
(which BTW misses git+ssh). I said "seems", because connect.c still
appears to assume it is SSH. So what is the plan? One possible
explanation is just that the git+ssh line should have been between the
git line and the : line in the documentation.
But if you really intend to change it, please don't. It's enough mess
as it is now, and I'm actually not convinced at all that we should
support it at all (god forbid promote it). When you have a location
specifier, you don't want it to randomly switch protocols, especially
such significantly different ones as ssh and git.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Josef Weidendorfer @ 2005-11-11 1:13 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, git
In-Reply-To: <1131668075.3987.5.camel@dv>
On Friday 11 November 2005 01:14, Pavel Roskin wrote:
> On Fri, 2005-11-11 at 00:40 +0100, Petr Baudis wrote:
> > Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter
> > where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > > Why would anybody want to fetch the current upstream HEAD at cg-pull
> > > time?
> ...
> Correct. But if it's a concern, I think we could make some
> improvements. Following approaches could be tried (starting from top,
> using following steps as a fallback):
>
> 1) Use recorded branch, i.e. the branch name that was used in cg-clone.
This is the "#..." part in .git/branches/origin, and it is already used.
I have nothing against using HEAD for cloning, but the branch name should
be recorded, such that cg-pull always fetches from the same branch.
I think 1) is enough if we add the detected branch name in the #... part
in .git/branches/origin at cg-clone time.
And "detectable" covers the local case, which was my concern here [*1*]
Josef
[*1*] after being told about the "stable HEAD" property of public repositories,
which is correct. I am not even sure that a HEAD makes sense
in public repositories: in my opinion HEAD has something to do with checked out
files, and a public repository usually does not have these. But perhaps
that's only me...
^ permalink raw reply
* [PATCH] Change 'cache' to 'index' in the docs
From: Lukas Sandström @ 2005-11-11 1:12 UTC (permalink / raw)
To: git; +Cc: junkio, Lukas Sandström
This patch makes the documentation refer to the index
as index instead of cache, but some references still
remain. (eg. git-update-index.txt)
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
git-update-index.txt says:
"Modifies the index or directory cache."
I thought the index was the directory cache.
Is git-update-index.txt badly worded or is there something
I'm missing?
Documentation/diff-format.txt | 8 ++++----
Documentation/diff-options.txt | 2 +-
Documentation/git-checkout-index.txt | 14 +++++++-------
Documentation/git-cvsimport.txt | 2 +-
Documentation/git-diff-files.txt | 6 +++---
Documentation/git-diff-index.txt | 14 +++++++-------
Documentation/git-fsck-objects.txt | 4 ++--
Documentation/git-hash-object.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-merge-index.txt | 4 ++--
Documentation/git-read-tree.txt | 20 ++++++++++----------
Documentation/git-svnimport.txt | 2 +-
Documentation/git-update-index.txt | 24 ++++++++++++------------
Documentation/git-write-tree.txt | 8 ++++----
Documentation/git.txt | 18 +++++++++---------
Documentation/glossary.txt | 6 +++---
Documentation/tutorial.txt | 6 +++---
17 files changed, 71 insertions(+), 71 deletions(-)
applies-to: 6466c53ae80cddbb581c5fdb2332f9321fade867
aa312f087d645cff65c7f86c91b5232898ec4f97
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index d1d0d2d..b426a14 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -8,13 +8,13 @@ git-diff-index <tree-ish>::
compares the <tree-ish> and the files on the filesystem.
git-diff-index --cached <tree-ish>::
- compares the <tree-ish> and the cache.
+ compares the <tree-ish> and the index.
git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
compares the trees named by the two arguments.
git-diff-files [<pattern>...]::
- compares the cache and the files on the filesystem.
+ compares the index and the files on the filesystem.
An output line is formatted this way:
@@ -47,7 +47,7 @@ That is, from the left to the right:
. an LF or a NUL when '-z' option is used, to terminate the record.
<sha1> is shown as all 0's if a file is new on the filesystem
-and it is out of sync with the cache.
+and it is out of sync with the index.
Example:
@@ -104,7 +104,7 @@ where:
The file parameters can point at the user's working file
(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
when a new file is added), or a temporary file (e.g. `old-file` in the
-cache). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
+index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 32005b0..8eef86e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -50,7 +50,7 @@
<orderfile>, which has one shell glob pattern per line.
-R::
- Swap two inputs; that is, show differences from cache or
+ Swap two inputs; that is, show differences from index or
on-disk file to tree contents.
For more detailed explanation on these common options, see also
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 589dc9a..94b283a 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -3,7 +3,7 @@ git-checkout-index(1)
NAME
----
-git-checkout-index - Copy files from the cache to the working directory
+git-checkout-index - Copy files from the index to the working directory
SYNOPSIS
@@ -13,23 +13,23 @@ SYNOPSIS
DESCRIPTION
-----------
-Will copy all files listed from the cache to the working directory
+Will copy all files listed from the index to the working directory
(not overwriting existing files).
OPTIONS
-------
-u::
update stat information for the checked out entries in
- the cache file.
+ the index file.
-q::
- be quiet if files exist or are not in the cache
+ be quiet if files exist or are not in the index
-f::
forces overwrite of existing files
-a::
- checks out all files in the cache. Cannot be used
+ checks out all files in the index. Cannot be used
together with explicit filenames.
-n::
@@ -57,7 +57,7 @@ supposed to be able to do things like:
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
-force-refresh everything in the cache, which was not the point.
+force-refresh everything in the index, which was not the point.
To update and refresh only the files already checked out:
@@ -74,7 +74,7 @@ desired tree into the index, and do a
git-checkout-index --prefix=git-export-dir/ -a
-and git-checkout-index will "export" the cache into the specified
+and git-checkout-index will "export" the index into the specified
directory.
NOTE The final "/" is important. The exported name is literally just
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 4b62256..88bd3b0 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -35,7 +35,7 @@ OPTIONS
-i::
Import-only: don't perform a checkout after importing. This option
- ensures the working directory and cache remain untouched and will
+ ensures the working directory and index remain untouched and will
not create them if they do not exist.
-k::
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
index e387388..3b04bfe 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -3,7 +3,7 @@ git-diff-files(1)
NAME
----
-git-diff-files - Compares files in the working tree and the cache
+git-diff-files - Compares files in the working tree and the index
SYNOPSIS
@@ -12,9 +12,9 @@ SYNOPSIS
DESCRIPTION
-----------
-Compares the files in the working tree and the cache. When paths
+Compares the files in the working tree and the index. When paths
are specified, compares only those named paths. Otherwise all
-entries in the cache are compared. The output format is the
+entries in the index are compared. The output format is the
same as "git-diff-index" and "git-diff-tree".
OPTIONS
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
index 2fc3eed..d8fc78f 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -3,7 +3,7 @@ git-diff-index(1)
NAME
----
-git-diff-index - Compares content and mode of blobs between the cache and repository
+git-diff-index - Compares content and mode of blobs between the index and repository
SYNOPSIS
@@ -13,10 +13,10 @@ SYNOPSIS
DESCRIPTION
-----------
Compares the content and mode of the blobs found via a tree
-object with the content of the current cache and, optionally
+object with the content of the current index and, optionally
ignoring the stat state of the file on disk. When paths are
specified, compares only those named paths. Otherwise all
-entries in the cache are compared.
+entries in the index are compared.
OPTIONS
-------
@@ -49,11 +49,11 @@ Cached Mode
-----------
If '--cached' is specified, it allows you to ask:
- show me the differences between HEAD and the current cache
+ show me the differences between HEAD and the current index
contents (the ones I'd write with a "git-write-tree")
For example, let's say that you have worked on your working directory, updated
-some files in the cache and are ready to commit. You want to see eactly
+some files in the index and are ready to commit. You want to see eactly
*what* you are going to commit is without having to write a new tree
object and compare it that way, and to do that, you just do
@@ -92,7 +92,7 @@ which is obviously a very useful questio
you *could* commit. Again, the output matches the "git-diff-tree -r"
output to a tee, but with a twist.
-The twist is that if some file doesn't match the cache, we don't have
+The twist is that if some file doesn't match the index, we don't have
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited `kernel/sched.c`, but
have not actually done a "git-update-index" on it yet - there is no
@@ -110,7 +110,7 @@ NOTE: As with other commands of this typ
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
-"git-upate-cache" it to make the cache be in sync.
+"git-upate-index" it to make the index be in sync.
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
index 5dc9dbd..37e8055 100644
--- a/Documentation/git-fsck-objects.txt
+++ b/Documentation/git-fsck-objects.txt
@@ -33,7 +33,7 @@ index file and all SHA1 references in .g
Report tags.
--cache::
- Consider any object recorded in the cache also as a head node for
+ Consider any object recorded in the index also as a head node for
an unreachability trace.
--standalone::
@@ -125,7 +125,7 @@ GIT_OBJECT_DIRECTORY::
used to specify the object database root (usually $GIT_DIR/objects)
GIT_INDEX_FILE::
- used to specify the index file of the cache
+ used to specify the index file of the index
GIT_ALTERNATE_OBJECT_DIRECTORIES::
used to specify additional object database roots (usually unset)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index 9239f11..07d2c42 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -16,7 +16,7 @@ Computes the object ID value for an obje
with the contents of the named file (which can be outside of the
work tree), and optionally writes the resulting object into the
object database. Reports its object ID to its standard output.
-This is used by "git-cvsimport" to update the cache
+This is used by "git-cvsimport" to update the index
without modifying files in the work tree. When <type> is not
specified, it defaults to "blob".
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 8c1784d..2f308ec 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -3,7 +3,7 @@ git-ls-files(1)
NAME
----
-git-ls-files - Information about files in the cache/working directory
+git-ls-files - Information about files in the index/working directory
SYNOPSIS
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index d072fda..6030642 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
-This looks up the <file>(s) in the cache and, if there are any merge
+This looks up the <file>(s) in the index and, if there are any merge
entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty
argument if no file), and <file> as argument 4. File modes for the three
files are passed as arguments 5, 6 and 7.
@@ -23,7 +23,7 @@ OPTIONS
Interpret all following arguments as filenames.
-a::
- Run merge against all files in the cache that need merging.
+ Run merge against all files in the index that need merging.
-o::
Instead of stopping at the first failed merge, do all of them
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 7db5fb5..e219c6a 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -3,7 +3,7 @@ git-read-tree(1)
NAME
----
-git-read-tree - Reads tree information into the directory cache
+git-read-tree - Reads tree information into the index
SYNOPSIS
@@ -13,11 +13,11 @@ SYNOPSIS
DESCRIPTION
-----------
-Reads the tree information given by <tree-ish> into the directory cache,
+Reads the tree information given by <tree-ish> into the index,
but does not actually *update* any of the files it "caches". (see:
git-checkout-index)
-Optionally, it can merge a tree into the cache, perform a
+Optionally, it can merge a tree into the index, perform a
fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m
flag. When used with -m, the -u flag causes it to also update
the files in the work tree with the result of the merge.
@@ -59,10 +59,10 @@ provided.
Single Tree Merge
~~~~~~~~~~~~~~~~~
If only 1 tree is specified, git-read-tree operates as if the user did not
-specify '-m', except that if the original cache has an entry for a
+specify '-m', except that if the original index has an entry for a
given pathname, and the contents of the path matches with the tree
-being read, the stat info from the cache is used. (In other words, the
-cache's stat()s take precedence over the merged tree's).
+being read, the stat info from the index is used. (In other words, the
+index's stat()s take precedence over the merged tree's).
That means that if you do a "git-read-tree -m <newtree>" followed by a
"git-checkout-index -f -u -a", the "git-checkout-index" only checks out
@@ -96,7 +96,7 @@ Here are the "carry forward" rules:
-------------------------------------------------------
0 nothing nothing nothing (does not happen)
1 nothing nothing exists use M
- 2 nothing exists nothing remove path from cache
+ 2 nothing exists nothing remove path from index
3 nothing exists exists use M
clean I==H I==M
@@ -109,7 +109,7 @@ Here are the "carry forward" rules:
8 yes N/A no nothing exists fail
9 no N/A no nothing exists fail
- 10 yes yes N/A exists nothing remove path from cache
+ 10 yes yes N/A exists nothing remove path from index
11 no yes N/A exists nothing fail
12 yes no N/A exists nothing fail
13 no no N/A exists nothing fail
@@ -128,7 +128,7 @@ Here are the "carry forward" rules:
20 yes yes no exists exists use M
21 no yes no exists exists fail
-In all "keep index" cases, the cache entry stays as in the
+In all "keep index" cases, the index entry stays as in the
original index file. If the entry were not up to date,
git-read-tree keeps the copy in the work tree intact when
operating under the -u flag.
@@ -245,7 +245,7 @@ since you pulled from him:
Your work tree is still based on your HEAD ($JC), but you have
some edits since. Three-way merge makes sure that you have not
-added or modified cache entries since $JC, and if you haven't,
+added or modified index entries since $JC, and if you haven't,
then does the right thing. So with the following sequence:
$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 88bdc08..fcc79fa 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -44,7 +44,7 @@ When importing incementally, you might n
-i::
Import-only: don't perform a checkout after importing. This option
- ensures the working directory and cache remain untouched and will
+ ensures the working directory and index remain untouched and will
not create them if they do not exist.
-t <trunk_subdir>::
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 58b9e49..52874c8 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -21,7 +21,7 @@ SYNOPSIS
DESCRIPTION
-----------
Modifies the index or directory cache. Each file mentioned is updated
-into the cache and any 'unmerged' or 'needs updating' state is
+into the index and any 'unmerged' or 'needs updating' state is
cleared.
The way "git-update-index" handles files it is told about can be modified
@@ -30,26 +30,26 @@ using the various options:
OPTIONS
-------
--add::
- If a specified file isn't in the cache already then it's
+ If a specified file isn't in the index already then it's
added.
Default behaviour is to ignore new files.
--remove::
- If a specified file is in the cache but is missing then it's
+ If a specified file is in the index but is missing then it's
removed.
Default behaviour is to ignore removed file.
--refresh::
- Looks at the current cache and checks to see if merges or
+ Looks at the current index and checks to see if merges or
updates are needed by checking stat() information.
-q::
- Quiet. If --refresh finds that the cache needs an update, the
+ Quiet. If --refresh finds that the index needs an update, the
default behavior is to error out. This option makes
git-update-index continue anyway.
--unmerged::
- If --refresh finds unmerged changes in the cache, the default
+ If --refresh finds unmerged changes in the index, the default
behavior is to error out. This option makes git-update-index
continue anyway.
@@ -57,7 +57,7 @@ OPTIONS
Ignores missing files during a --refresh
--cacheinfo <mode> <object> <path>::
- Directly insert the specified info into the cache.
+ Directly insert the specified info into the index.
--index-info::
Read index info from stdin.
@@ -68,7 +68,7 @@ OPTIONS
--info-only::
Do not create objects in the object database for all
<file> arguments that follow this flag; just insert
- their object IDs into the cache.
+ their object IDs into the index.
--force-remove::
Remove the file from the index even when the working directory
@@ -106,14 +106,14 @@ OPTIONS
Using --refresh
---------------
-'--refresh' does not calculate a new sha1 file or bring the cache
+'--refresh' does not calculate a new sha1 file or bring the index
up-to-date for mode/content changes. But what it *does* do is to
-"re-match" the stat information of a file with the cache, so that you
-can refresh the cache for a file that hasn't been changed but where
+"re-match" the stat information of a file with the index, so that you
+can refresh the index for a file that hasn't been changed but where
the stat entry is out of date.
For example, you'd want to do this after doing a "git-read-tree", to link
-up the stat cache details with the proper files.
+up the stat index details with the proper files.
Using --cacheinfo or --info-only
--------------------------------
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
index 51be44d..abee05f 100644
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -3,7 +3,7 @@ git-write-tree(1)
NAME
----
-git-write-tree - Creates a tree object from the current cache
+git-write-tree - Creates a tree object from the current index
SYNOPSIS
@@ -12,11 +12,11 @@ SYNOPSIS
DESCRIPTION
-----------
-Creates a tree object using the current cache.
+Creates a tree object using the current index.
-The cache must be merged.
+The index must be merged.
-Conceptually, "git-write-tree" sync()s the current directory cache contents
+Conceptually, "git-write-tree" sync()s the current index contents
into a set of tree files.
In order to have that match what is actually in your directory right
now, you need to have done a "git-update-index" phase before you did the
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 2f9622f..b7bc4fb 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -40,7 +40,7 @@ reflect recent changes.
Commands Overview
-----------------
The git commands can helpfully be split into those that manipulate
-the repository, the cache and the working fileset, those that
+the repository, the index and the working fileset, those that
interrogate and compare them, and those that moves objects and
references between repositories.
@@ -59,7 +59,7 @@ gitlink:git-apply[1]::
applies it to the working tree.
gitlink:git-checkout-index[1]::
- Copy files from the cache to the working directory
+ Copy files from the index to the working directory
gitlink:git-commit-tree[1]::
Creates a new commit object
@@ -86,7 +86,7 @@ gitlink:git-prune-packed[1]::
Remove extra objects that are already in pack files.
gitlink:git-read-tree[1]::
- Reads tree information into the directory cache
+ Reads tree information into the directory index
gitlink:git-unpack-objects[1]::
Unpacks objects out of a packed archive.
@@ -95,7 +95,7 @@ gitlink:git-update-index[1]::
Modifies the index or directory cache
gitlink:git-write-tree[1]::
- Creates a tree from the current cache
+ Creates a tree from the current index
Interrogation commands
@@ -105,10 +105,10 @@ gitlink:git-cat-file[1]::
Provide content or type information for repository objects
gitlink:git-diff-index[1]::
- Compares content and mode of blobs between the cache and repository
+ Compares content and mode of blobs between the index and repository
gitlink:git-diff-files[1]::
- Compares files in the working tree and the cache
+ Compares files in the working tree and the index
gitlink:git-diff-stages[1]::
Compares two "merge stages" in the index file.
@@ -120,7 +120,7 @@ gitlink:git-fsck-objects[1]::
Verifies the connectivity and validity of the objects in the database
gitlink:git-ls-files[1]::
- Information about files in the cache/working directory
+ Information about files in the index/working directory
gitlink:git-ls-tree[1]::
Displays a tree object in human readable form
@@ -490,8 +490,8 @@ git so take care if using Cogito etc
'GIT_INDEX_FILE'::
This environment allows the specification of an alternate
- cache/index file. If not specified, the default of
- `$GIT_DIR/index` is used.
+ index file. If not specified, the default of `$GIT_DIR/index`
+ is used.
'GIT_OBJECT_DIRECTORY'::
If the object storage directory is specified via this
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index eb7b471..07df6b4 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -43,14 +43,14 @@ DAG::
index::
A collection of files with stat information, whose contents are
- stored as objects. The cache is a stored version of your working
+ stored as objects. The index is a stored version of your working
tree. Truth be told, it can also contain a second, and even a third
version of a working tree, which are used when merging.
index entry::
The information regarding a particular file, stored in the index.
An index entry can be unmerged, if a merge was started, but not
- yet finished (i.e. if the cache contains multiple versions of
+ yet finished (i.e. if the index contains multiple versions of
that file).
unmerged index:
@@ -75,7 +75,7 @@ checkout::
stored in the object database.
commit::
- As a verb: The action of storing the current state of the cache in the
+ As a verb: The action of storing the current state of the index in the
object database. The result is a revision.
As a noun: Short hand for commit object.
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 95ed852..03eb421 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -131,7 +131,7 @@ actually check in your hard work, you wi
The first step is trivial: when you want to tell git about any changes
to your working tree, you use the `git-update-index` program. That
program normally just takes a list of filenames you want to update, but
-to avoid trivial mistakes, it refuses to add new entries to the cache
+to avoid trivial mistakes, it refuses to add new entries to the index
(or remove existing ones) unless you explicitly tell it that you're
adding a new entry with the `\--add` flag (or removing an entry with the
`\--remove`) flag.
@@ -199,7 +199,7 @@ was just to show that `git-update-index`
actually saved away the contents of your files into the git object
database.
-Updating the cache did something else too: it created a `.git/index`
+Updating the index did something else too: it created a `.git/index`
file. This is the index that describes your current working tree, and
something you should be very aware of. Again, you normally never worry
about the index file itself, but you should be aware of the fact that
@@ -440,7 +440,7 @@ a bit about what you have done.
Write whatever message you want, and all the lines that start with '#'
will be pruned out, and the rest will be used as the commit message for
the change. If you decide you don't want to commit anything after all at
-this point (you can continue to edit things and update the cache), you
+this point (you can continue to edit things and update the index), you
can just leave an empty message. Otherwise `git commit` will commit
the change for you.
---
0.99.9.GIT
^ permalink raw reply related
* GIT maintenance on ia64 test tree
From: Luck, Tony @ 2005-11-11 0:59 UTC (permalink / raw)
To: linux-ia64, git; +Cc: Andrew Morton
The way that I'm using GIT to maintain my test/release
trees results in the test tree building a history of
extra fluff (lots of auto-updates from Linus, plus all
the merge-commits to bring in each of the patch-sets, plus
some mistakes from when I goofed with GIT).
So, I'm going to periodically blow away the test branch
and re-create a clean version. This mail is advance
notice that I'm going to do this when Linus releases
2.6.15-rc1 (a convenient point since I just sent everything
that was cooking in test to Linus ... so the test tree is
currently empty).
What this means is that the new "test" branch won't have
any connection to the old "test" branch. So a "git pull"
or "git fetch" will fail. To fix this in native git I *think*
you need to run (git list copied in the hope that if this is
tragically wrong, or overly complex, someone will take pity
and explain how it should be done):
$ git checkout
{any-branch-other-than-the-one-you-track-my-test-tree-with}
$ git branch -D test
$ git branch test v2.6.15-rc1
Note that this will orphan all the objects relating to the
history of the test branch. You can clean up with:
$ git prune
BUT, this will also throw away any other orphaned stuff too, so
only do this if you are ok with ditching this. You could run
$ git fsck-objects
before any of the above to see whether you have any orphans.
Cogito users ... I have no idea. First one to figure it out
please post a recipe.
-Tony
^ 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