* 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
* Re: [PATCH] Make git-pack-redundant consider alt-odbs
From: Junio C Hamano @ 2005-11-11 0:40 UTC (permalink / raw)
To: git; +Cc: Lukas =?iso-2022-jp-2?B?U2FuZHN0chsuQRtOdm0=?=
In-Reply-To: <4373E4E0.10903@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 317 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> [PATCH] Make git-pack-redundant consider alt-odbs
>
> This patch changes git-pack-redundant so that packfiles
> ...
This request is not just for Lukas, but people, please do not
duplicate what is already on the Subject: line at the top of
your message body.
^ permalink raw reply
* [PATCH] Make git-pack-redundant consider alt-odbs
From: Lukas Sandström @ 2005-11-11 0:25 UTC (permalink / raw)
To: git; +Cc: junkio, Lukas Sandström
[PATCH] Make git-pack-redundant consider alt-odbs
This patch changes git-pack-redundant so that packfiles
in alternate object directories also are considered when
deciding which objects are redundant.
This functionality is controlled by the flag '--alt-odb'.
Also convert the other flags to the long form, and update
docs and git-repack accordingly.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
On a related note; if you have unreachable objects in your
packfiles, those objects might make otherwise redundant
packfiles non-redundant.
Would it be a useful feature to be able to give git-pack-redundant
a list of bad objects on stdin, which then will be ignored?
(eg. git-fsck-objects --full --unreachable | cut -s -d ' ' -f 3 | git-pack-redundant)
Documentation/git-pack-redundant.txt | 19 +++-
git-repack.sh | 4 -
pack-redundant.c | 147 ++++++++++++++++++++++------------
3 files changed, 107 insertions(+), 63 deletions(-)
applies-to: 8f520c14677a07c01eb64f64bcd68cb174392ec9
ad7d016fcecacdfaf9cf0cc4b65fadf32e86899b
diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt
index 3829616..2e23cbc 100644
--- a/Documentation/git-pack-redundant.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -8,7 +8,7 @@ git-pack-redundant - Program used to fin
SYNOPSIS
--------
-'git-pack-redundant [ -v ] < -a | .pack filename ... >'
+'git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >'
DESCRIPTION
-----------
@@ -19,13 +19,16 @@ are redundant. The output is suitable fo
OPTIONS
-------
--v::
- Verbose. Outputs some statistics to stderr.
- Has a small performance penalty.
-
--a::
- All. Processes all the local packs. Any filenames on
- the commandline are ignored.
+
+--all::
+ Processes all packs. Any filenames on the commandline are ignored.
+
+--alt-odb::
+ Don't require objects present in packs from alternate object
+ directories to be present in local packs.
+
+--verbose::
+ Outputs some statistics to stderr. Has a small performance penalty.
Author
------
diff --git a/git-repack.sh b/git-repack.sh
index 4ce0022..f347207 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -45,7 +45,7 @@ if [ -z "$name" ]; then
if test "$remove_redandant" = t ; then
echo "Removing redundant packs."
sync
- redundant=$(git-pack-redundant -a)
+ redundant=$(git-pack-redundant --all)
if test "$redundant" != "" ; then
echo $redundant | xargs rm
fi
@@ -63,7 +63,7 @@ exit
if test "$remove_redandant" = t
then
sync
- redundant=$(git-pack-redundant -a)
+ redundant=$(git-pack-redundant --all)
if test "$redundant" != "" ; then
echo $redundant | xargs rm
fi
diff --git a/pack-redundant.c b/pack-redundant.c
index db3dcde..1f8c577 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -9,9 +9,9 @@
#include "cache.h"
static const char pack_redundant_usage[] =
-"git-pack-redundant [ -v ] < -a | <.pack filename> ...>";
+"git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | <.pack filename> ...>";
-int all = 0, verbose = 0;
+int load_all_packs = 0, verbose = 0, alt_odb = 0;
struct llist_item {
struct llist_item *next;
@@ -21,14 +21,14 @@ struct llist {
struct llist_item *front;
struct llist_item *back;
size_t size;
-} *all_objects;
+} *all_objects; /* all objects which must be present in local packfiles */
struct pack_list {
struct pack_list *next;
struct packed_git *pack;
struct llist *unique_objects;
struct llist *all_objects;
-} *pack_list;
+} *local_packs = NULL, *altodb_packs = NULL;
struct pll {
struct pll *next;
@@ -128,32 +128,35 @@ inline struct llist_item * llist_insert_
}
/* computes A\B */
-struct llist * llist_sorted_difference(struct llist_item *A,
- struct llist_item *B)
+void llist_sorted_difference_inplace(struct llist *A,
+ struct llist *B)
{
- struct llist *ret;
- llist_init(&ret);
+ struct llist_item *prev, *a, *b, *x;
- while (A != NULL && B != NULL) {
- int cmp = memcmp(A->sha1, B->sha1, 20);
+ prev = a = A->front;
+ b = B->front;
+
+ while (a != NULL && b != NULL) {
+ int cmp = memcmp(a->sha1, b->sha1, 20);
if (!cmp) {
- A = A->next;
- B = B->next;
- continue;
- }
- if(cmp > 0) { /* we'll never find this B */
- B = B->next;
- continue;
- }
- /* A has the object, B doesn't */
- llist_insert_back(ret, A->sha1);
- A = A->next;
- }
- while (A != NULL) {
- llist_insert_back(ret, A->sha1);
- A = A->next;
+ x = a;
+ if (a == A->front)
+ A->front = a->next;
+ a = prev->next = a->next;
+
+ if (a == NULL) /* end of list */
+ A->back = prev;
+ A->size--;
+ free(x);
+ b = b->next;
+ } else
+ if (cmp > 0)
+ b = b->next;
+ else {
+ prev = a;
+ a = a->next;
+ }
}
- return ret;
}
/* returns a pointer to an item in front of sha1 */
@@ -201,6 +204,16 @@ inline struct pack_list * pack_list_inse
return p;
}
+inline size_t pack_list_size(struct pack_list *pl)
+{
+ size_t ret = 0;
+ while(pl) {
+ ret++;
+ pl = pl->next;
+ }
+ return ret;
+}
+
struct pack_list * pack_list_difference(struct pack_list *A,
struct pack_list *B)
{
@@ -294,15 +307,13 @@ struct pll * get_all_permutations(struct
int is_superset(struct pack_list *pl, struct llist *list)
{
- struct llist *diff, *old;
+ struct llist *diff;
diff = llist_copy(list);
while (pl) {
- old = diff;
- diff = llist_sorted_difference(diff->front,
- pl->all_objects->front);
- llist_free(old);
+ llist_sorted_difference_inplace(diff,
+ pl->all_objects);
if (diff->size == 0) { /* we're done */
llist_free(diff);
return 1;
@@ -347,6 +358,10 @@ size_t sizeof_union(struct packed_git *p
size_t get_pack_redundancy(struct pack_list *pl)
{
struct pack_list *subset;
+
+ if (pl == NULL)
+ return 0;
+
size_t ret = 0;
while ((subset = pl->next)) {
while(subset) {
@@ -374,10 +389,10 @@ void minimize(struct pack_list **min)
struct pack_list *pl, *unique = NULL,
*non_unique = NULL, *min_perm = NULL;
struct pll *perm, *perm_all, *perm_ok = NULL, *new_perm;
- struct llist *missing, *old;
+ struct llist *missing;
size_t min_perm_size = (size_t)-1, perm_size;
- pl = pack_list;
+ pl = local_packs;
while (pl) {
if(pl->unique_objects->size)
pack_list_insert(&unique, pl);
@@ -389,13 +404,12 @@ void minimize(struct pack_list **min)
missing = llist_copy(all_objects);
pl = unique;
while (pl) {
- old = missing;
- missing = llist_sorted_difference(missing->front,
- pl->all_objects->front);
- llist_free(old);
+ llist_sorted_difference_inplace(missing,
+ pl->all_objects);
pl = pl->next;
}
+ /* return if there are no objects missing from the unique set */
if (missing->size == 0) {
*min = unique;
return;
@@ -437,7 +451,7 @@ void minimize(struct pack_list **min)
void load_all_objects()
{
- struct pack_list *pl = pack_list;
+ struct pack_list *pl = local_packs;
struct llist_item *hint, *l;
int i;
@@ -454,17 +468,34 @@ void load_all_objects()
}
pl = pl->next;
}
+ /* remove objects present in remote packs */
+ pl = altodb_packs;
+ while (pl) {
+ llist_sorted_difference_inplace(all_objects, pl->all_objects);
+ pl = pl->next;
+ }
}
/* this scales like O(n^2) */
void cmp_packs()
{
- struct pack_list *subset, *curr = pack_list;
+ struct pack_list *subset, *pl = local_packs;
- while ((subset = curr)) {
+ while ((subset = pl)) {
while((subset = subset->next))
- cmp_two_packs(curr, subset);
- curr = curr->next;
+ cmp_two_packs(pl, subset);
+ pl = pl->next;
+ }
+
+ pl = altodb_packs;
+ while (pl) {
+ subset = local_packs;
+ while (subset) {
+ llist_sorted_difference_inplace(subset->unique_objects,
+ pl->all_objects);
+ subset = subset->next;
+ }
+ pl = pl->next;
}
}
@@ -485,7 +516,10 @@ struct pack_list * add_pack(struct packe
}
/* this list will be pruned in cmp_two_packs later */
l.unique_objects = llist_copy(l.all_objects);
- return pack_list_insert(&pack_list, &l);
+ if (p->pack_local)
+ return pack_list_insert(&local_packs, &l);
+ else
+ return alt_odb ? pack_list_insert(&altodb_packs, &l) : NULL;
}
struct pack_list * add_pack_file(char *filename)
@@ -497,7 +531,6 @@ struct pack_list * add_pack_file(char *f
while (p) {
if (strstr(p->pack_name, filename))
- /* this will silently ignore packs in alt-odb */
return add_pack(p);
p = p->next;
}
@@ -509,8 +542,7 @@ void load_all()
struct packed_git *p = packed_git;
while (p) {
- if (p->pack_local) /* ignore alt-odb for now */
- add_pack(p);
+ add_pack(p);
p = p->next;
}
}
@@ -526,14 +558,18 @@ int main(int argc, char **argv)
i++;
break;
}
- if(!strcmp(arg, "-a")) {
- all = 1;
+ if(!strcmp(arg, "--all")) {
+ load_all_packs = 1;
continue;
}
- if(!strcmp(arg, "-v")) {
+ if(!strcmp(arg, "--verbose")) {
verbose = 1;
continue;
}
+ if(!strcmp(arg, "--alt-odb")) {
+ alt_odb = 1;
+ continue;
+ }
if(*arg == '-')
usage(pack_redundant_usage);
else
@@ -542,13 +578,13 @@ int main(int argc, char **argv)
prepare_packed_git();
- if(all)
+ if (load_all_packs)
load_all();
else
while (*(argv + i) != NULL)
add_pack_file(*(argv + i++));
- if (pack_list == NULL)
+ if (local_packs == NULL)
die("Zero packs found!\n");
cmp_packs();
@@ -557,6 +593,8 @@ int main(int argc, char **argv)
minimize(&min);
if (verbose) {
+ fprintf(stderr, "There are %ld packs available in alt-odbs.\n",
+ pack_list_size(altodb_packs));
fprintf(stderr, "The smallest (bytewise) set of packs is:\n");
pl = min;
while (pl) {
@@ -566,12 +604,15 @@ int main(int argc, char **argv)
fprintf(stderr, "containing %ld duplicate objects "
"with a total size of %ldkb.\n",
get_pack_redundancy(min), pack_set_bytecount(min)/1024);
+ fprintf(stderr, "A total of %ld unique objects were considered.\n",
+ all_objects->size);
fprintf(stderr, "Redundant packs (with indexes):\n");
}
- pl = red = pack_list_difference(pack_list, min);
+ pl = red = pack_list_difference(local_packs, min);
while (pl) {
printf("%s\n%s\n",
- sha1_pack_index_name(pl->pack->sha1), pl->pack->pack_name);
+ sha1_pack_index_name(pl->pack->sha1),
+ pl->pack->pack_name);
pl = pl->next;
}
---
0.99.9.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 0:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, git
In-Reply-To: <20051110234029.GE30496@pasky.or.cz>
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? If you do this, and you have no control on the upstream
> > repository, "origin" will jump randomly around after cg-pull, depending
> > on the current HEAD of the origin repository.
>
> In public repositories, you usually set the HEAD once and it stays
> there, or when you switch it, you are really careful about it.
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.
2) Check a file specifying the default branch for cloning (let's call it
e.g. .git/default_export). Record branch name.
3) If cg-switch is implemented, another file would be likely used to
specify the default branch for local operations
(e.g. .git/default_branch). Use it. Record branch name.
4) If .git/HEAD can be recognized as link (we may need to eliminate
symlinks for that to work over remote transport), use the branch it
points to. Record branch name.
5) If .git/HEAD cannot be recognized as link, use it as the branch to
clone. Don't record the branch name. (I'm not sure if we really want
that - it's good to know what branch we are using).
6) Use "master" branch. Record branch name.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: proper way to make cg-fetch work from originally git-clone'd tree
From: Randal L. Schwartz @ 2005-11-11 0:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111001148.GG30496@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
>> cg-merge 2>&1 | grep -v 'already fully merged' && make prefix=/opt/git all install && (cd Documentation && make prefix=/opt/git all install)
Petr> Any reason why you were unable to tell the main make 'doc install-doc'?
Because I didn't see it? :-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: cg-admin-setuprepo fails to make a cg-clone'able repo
From: Petr Baudis @ 2005-11-11 0:13 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Git Mailing List
In-Reply-To: <86wtjg31lo.fsf@blue.stonehenge.com>
Dear diary, on Thu, Nov 10, 2005 at 05:32:35PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> Repeat by:
>
> cg-admin-setuprepo repo
> cg-clone $(PWD)/repo myview
You should cg-init locally, then cg-admin-setuprepo the public one and
push to it. I updated cg-admin-setuprepo's description wrt. that now.
> Results:
>
> defaulting to local storage area
> Hard links don't work - using copy
> cp: illegal option -- b
> usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
> cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
> cg-fetch: unable to get the HEAD branch
> cg-clone: fetch failed
But this is actually an entirely unrelated bug, it seems - pretty
strange. I revived another few months old thread because of this, since
it seems the 'b' was actually a typo and we don't want to pass 'cp' this
argument at all, but something different. Does cloning locally otherwise
work?
--
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: proper way to make cg-fetch work from originally git-clone'd tree
From: Petr Baudis @ 2005-11-11 0:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzkc4nlu.fsf@blue.stonehenge.com>
Dear diary, on Thu, Nov 10, 2005 at 02:51:57PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> I tried git-fetch this morning, and it said I didn't have an origin,
> which makes sense because I made the tree with git-clone, not cg-clone.
>
> However, when I tried
>
> cg-branch-add origin rsync://rsync.kernel.org/pub/scm/git/git.git
>
> it complained that I already had an origin! It seems to work after
> that, but what should I have done instead? Is there a way to make
> both cg-fetch and git-fetch to default to the same things?
You should do what you did - it was just a warning. git-clone seems to
have created only a 'remotes' entry, which Cogito doesn't understand
(yet).
> By the way, my "make only if something changed" works now, because
> I've separated cg-fetch and cg-merge. My merge step looks like:
>
> cg-merge 2>&1 | grep -v 'already fully merged' && make prefix=/opt/git all install && (cd Documentation && make prefix=/opt/git all install)
Any reason why you were unable to tell the main make 'doc install-doc'?
--
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: Petr Baudis @ 2005-11-11 0:09 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Pavel Roskin
In-Reply-To: <200511110056.54476.Josef.Weidendorfer@gmx.de>
Dear diary, on Fri, Nov 11, 2005 at 12:56:54AM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> Still I think my reasoning holds: cg-clone is also used locally, thus
> cloning a repository on which you probably are working on, too.
Yes, that's a valid point, but I still think for the usual case
defaulting to HEAD is the right thing to do. But it wasn't described
in the documentation and that's indeed a bug - fixed now.
> If I want to branch off from master, I can use cg-clone to start a new
> development branch. I suppose this is the suggested Cogito way, from
> the README; and it makes Cogitos usage so simple, even with multiple
> development branches: by using a cloned repository for each branch.
Yes, this is the recommended workflow. Well, if you plan to switch
branches randomly in your "central private repository", better explicitly
specify #master in the offsprings. ;-)
--
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-10 23:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Pavel Roskin
In-Reply-To: <20051110234029.GE30496@pasky.or.cz>
On Friday 11 November 2005 00:40, 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...
> > On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:
> > > Hello!
> > >
> > > This patch changes cg-pull so that if the branch is not specified, it
> > > takes origin's .git/HEAD without first trying .git/refs/heads/master.
> > > This removes preferential treatment of the "master" branch, allowing the
> > > upstream to use another name for the default branch. To get the master
> > > branch, users would have to append "#master" to the URL.
> ...
> > Or am I missing something here?
>
> That this is from 23 August and this change was in Cogito for several
> major releases and noone ever complained. ;-)
You catched me ;-)
Still I think my reasoning holds: cg-clone is also used locally, thus
cloning a repository on which you probably are working on, too.
If I want to branch off from master, I can use cg-clone to start a new
development branch. I suppose this is the suggested Cogito way, from
the README; and it makes Cogitos usage so simple, even with multiple
development branches: by using a cloned repository for each branch.
Of course, a Git user would use "git branch ...", and switch between
branches inside of one repository.
Josef
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Petr Baudis @ 2005-11-10 23:40 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Pavel Roskin
In-Reply-To: <200511110026.18324.Josef.Weidendorfer@gmx.de>
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...
> On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:
> > Hello!
> >
> > This patch changes cg-pull so that if the branch is not specified, it
> > takes origin's .git/HEAD without first trying .git/refs/heads/master.
> > This removes preferential treatment of the "master" branch, allowing the
> > upstream to use another name for the default branch. To get the master
> > branch, users would have to append "#master" to the URL.
>
> I think this is wrong.
>
> Why would anybody want to fetch the current upstream HEAD at cg-pull
> time? If you do this, and you have no control on the upstream
> repository, "origin" will jump randomly around after cg-pull, depending
> on the current HEAD of the origin repository.
In public repositories, you usually set the HEAD once and it stays
there, or when you switch it, you are really careful about it.
> Besides, this is a incompatible change in cg-pull behavior: I am sure that
> a lot of people did a cg-clone in the past without any specific remote branch,
> and expect that cg-pull will update their origin to the remote "master".
> Now, if they update to a new Cogito with this patch, the next cg-pull
> sometimes will rebase their origin to another random branch, depending
> on remote HEAD ?!
See above. The remote HEAD is supposed to be generally stable for public
repositories, pointing to the _default_ head for public consumption.
If you want something specific, specify it by the #branchname.
> Or am I missing something here?
That this is from 23 August and this change was in Cogito for several
major releases and noone ever complained. ;-)
--
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] C implementation of the 'git' program.
From: Petr Baudis @ 2005-11-10 23:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4373CEA8.1020900@op5.se>
Dear diary, on Thu, Nov 10, 2005 at 11:50:16PM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> Linus Torvalds wrote:
> >
> >And the performance difference does seem to be quite noticeable too..
> >
>
> Yes. I was quite astonished when I noticed first, thinking the shell
> kept the parsed script in cache or some such. Apparently it doesn't.
The bulk of the time is likely not spent parsing, but executing
subprocesses, that's hideously expensive. Just for fun, you can try to
measure the improvement when you remove the $(dirname "$0"). Here, for
1000 tries it's roughly 9s normal, 7s without dirname and 3s direct
invocation, which seems to give you _very roughly_ 2s per subprocess,
and 2s other shell overhead, which is unusually right.
Actually, I can bring the git.sh runtime from 7s to 4.7s:
- case "$cmd" in
- -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+ if [[ "$cmd" = "-v" ||
+ "$cmd" = "--v" ||
+ "$cmd" = "--ve" ||
+ "$cmd" = "--ver" ||
+ "$cmd" = "--vers" ||
+ "$cmd" = "--versi" ||
+ "$cmd" = "--versio" ||
+ "$cmd" = "--version" ]]; then
echo "git version @@GIT_VERSION@@"
exit 0 ;;
- esac
+ fi
(whitespace-mangled)
Well, subconsciously I never really trusted this case thing. ;-)
This leaves ~ 1.7s to other shell overhead and execve() (the main
command call is without the fork(), while $(dirname) fork()s).
> >>The location of the GIT_LIB can be obtained by running
> >>
> >> git --lib
> >
> >
> >I think this might be a bit ambiguous. When I see "GIT_LIB", to me it
> >implies traditional libraries (ie a "libgit.a" kind of thing), not the
> >kind of "git executable plugin" directory.
> >
> >So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a "--libexec"
> >kind of flavor, if only to avoid that confusion.
>
>
> Someone said libexec was moving out (of Linux, at least), so I thought
> I'd better avoid that. Perhaps GIT_LIBDIR?
This may not necessarily have anything in common with the actual
directory name. I prefer libexec too (but personally don't care too
much).
--
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-10 23:26 UTC (permalink / raw)
To: git; +Cc: Pavel Roskin, Petr Baudis
In-Reply-To: <1124832796.23795.9.camel@dv>
On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:
> Hello!
>
> This patch changes cg-pull so that if the branch is not specified, it
> takes origin's .git/HEAD without first trying .git/refs/heads/master.
> This removes preferential treatment of the "master" branch, allowing the
> upstream to use another name for the default branch. To get the master
> branch, users would have to append "#master" to the URL.
I think this is wrong.
Why would anybody want to fetch the current upstream HEAD at cg-pull
time? If you do this, and you have no control on the upstream
repository, "origin" will jump randomly around after cg-pull, depending
on the current HEAD of the origin repository.
Besides, this is a incompatible change in cg-pull behavior: I am sure that
a lot of people did a cg-clone in the past without any specific remote branch,
and expect that cg-pull will update their origin to the remote "master".
Now, if they update to a new Cogito with this patch, the next cg-pull
sometimes will rebase their origin to another random branch, depending
on remote HEAD ?!
Or am I missing something here?
Josef
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-10 23:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vzmocw1xd.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 11:52:46PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> One thing I _don't_ like about both is there is no way for 'git
> reset --hard' to get rid of them, when the user decides to retry
> from scratch after seeing a failed merge that left too many of
> them.
Yes. You can cg-clean, but that'll wipe out other stuff as well. I plan
to fix that by adding some conflicts tracking to Cogito - I'm not yet
decided on the particular implementation (only that I certainly don't
want to require the user to manually tell Cogito about resolved
conflicts).
--
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: rsync deprecated but promoted?
From: Petr Baudis @ 2005-11-10 23:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <Pine.LNX.4.58.0509260941340.3308@g5.osdl.org>
Dear diary, on Mon, Sep 26, 2005 at 06:43:08PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
>
>
> On Mon, 26 Sep 2005, Petr Baudis wrote:
> >
> > Actually, it would be nice to be able to tell git-fsck-objects to only
> > verify objects which are referenced between given two commits (perhaps
> > just make it support the ^object notation). Then I wouldn't mind running
> > that after each rsync fetch in Cogito.
>
> You can kind of do it.
>
> Do
>
> git-rev-list --objects $oldheads --not $newheads >& /dev/null
> echo "$?"
>
> and it _should_ largely work. Untested, of course, but I _hope_ that if
> any object is missing, git-rev-list should die with an error. And if it
> doesn't, I should fix it ;)
It should obviously be
git-rev-list $(git-rev-parse $newheads --not $oldheads) >& /dev/null
but it is indeed broken:
$ git-rev-list --objects ... ^... && echo ':)'
001439c6a797461c3e75018d95744d463077ae33
841e3297d8df764da417da81dbfe1044e24d4082
cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f file
:)
$ git-cat-file -t cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f
error: unable to find cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f
fatal: git-cat-file cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f: bad file
Currently I just modified it so that I iterate through all the sha1s
git-rev-list spits out, and test them by git-cat-file -t.
Thanks for the hint,
--
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: Expected Behavior?
From: Junio C Hamano @ 2005-11-10 22:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, git
In-Reply-To: <20051110203411.GX30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Wed, Nov 09, 2005 at 09:19:06AM CET, I got a letter
> where Fredrik Kuivinen <freku045@student.liu.se> said that...
>> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:
>> > Fredrik Kuivinen <freku045@student.liu.se> writes:
>> >
>> Oups, I haven't thought about that. I kind of like the idea that you
>> can see the branch name in the file names though. How about replacing
>> any slashes in the branch names with underscores? So the branch
>> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and
>> '_foo_bar_<number>'.
>
> I like it too. :-)
>
> Now, this would look like file3~master in Cogito (or file3~~master in
> case of name conflict, etc.).
One thing I like about Cogito's is the use of tilde instead of
underscore -- much much less likely to clash with real filenames
and easiliy recognizable as throwaway copies.
One thing I _don't_ like about both is there is no way for 'git
reset --hard' to get rid of them, when the user decides to retry
from scratch after seeing a failed merge that left too many of
them.
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Andreas Ericsson @ 2005-11-10 22:50 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511101133550.4627@g5.osdl.org>
Linus Torvalds wrote:
>
> And the performance difference does seem to be quite noticeable too..
>
Yes. I was quite astonished when I noticed first, thinking the shell
kept the parsed script in cache or some such. Apparently it doesn't.
>
>>The location of the GIT_LIB can be obtained by running
>>
>> git --lib
>
>
> I think this might be a bit ambiguous. When I see "GIT_LIB", to me it
> implies traditional libraries (ie a "libgit.a" kind of thing), not the
> kind of "git executable plugin" directory.
>
> So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a "--libexec"
> kind of flavor, if only to avoid that confusion.
Someone said libexec was moving out (of Linux, at least), so I thought
I'd better avoid that. Perhaps GIT_LIBDIR?
Btw, I re-visited ye ole "git binary directory?" thread and noticed the
nifty trick you did with PATH from the wrapper. I'll add that to git.c
and, unless I get a better suggestion, rename GIT_LIB to GIT_LIBDIR (and
git --libdir).
> Even if the actual
> directory ends up being /usr/lib/git-<version>/ as in my original
> suggestion, I think it's good to make it clear that it's not just some
> kind of "link type" library, but more of a combination of libraries and
> plugins and executables.
>
> But maybe that's just me?
>
It's not just you, but GIT_DIR was taken and I felt lazy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-archimport
From: Martin Langhoff @ 2005-11-10 22:21 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <20051110214959.GO9131@raven.localdomain>
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
^ permalink raw reply
* Re: git-archimport
From: Kevin Geiss @ 2005-11-10 21:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511101332r3389734uc1aa1effd2898e15@mail.gmail.com>
ok. I tried this:
git-archimport kevin@desertsol.com--files/scripts--base kevin@desertsol.com--files/scripts--oco
and it always complains:
Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784
I don't have any spaces or funny characters in filenames.
On Fri, Nov 11, 2005 at 10:32:12AM +1300, Martin Langhoff wrote:
> If the two branches are related, and you want the imported git
> branches to be related, do
>
> git-archimport arch-eduforge@catalyst.net.nz--2004/scripts
>
> that will bring all the stuff under scripts. If there are other
> branches or projects there that aren't related or you don't want to
> pull, do
>
> git-archimport arch-eduforge@catalyst.net.nz--2004/scripts--base \
> arch-eduforge@catalyst.net.nz--2004/scripts--oco
>
> In any case, you shoud never pass the last token (base-0). Also, if
> you have filenames with spaces or funny chars, you'll want a patch
> that I'm about to post.
>
> If you don't mind having this discussion on git@vger, could you
> forward it there?
>
> cheers,
>
>
> martin
>
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > hello, I was trying out the git-archimport script, I have a question.
> >
> > say I have two branches in tla (in the same archive):
> >
> > scripts--base--0
> > scripts--oco--0
> >
> > and scripts--oco--0--base-0 was tagged from scripts--base--0--patch-2.
> >
> > I first tried importing only the base branch, that worked fine. then
> > I started a new directory, and tried this:
> >
> > git arch-import -v archive/scripts--base--0 archive/scripts--oco--0
> >
> > and it keeps complaning about not being able to find scripts--oco--0--
> > patch-1. patch-1 is just a regular commit in the tla archive.
> > (patch-2 and patch-3 are merges from scripts--base)
> >
> > anyway, am I understanding the paradigm of the git-archimport script?
> > that I should expect it to be able to create a git repository for me
> > from these 2 branches?
> >
> > thanks for any info
> >
>
^ permalink raw reply
* Re: Do I misunderstand cg-merge --squash option
From: Petr Baudis @ 2005-11-10 21:16 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511102036.06484.alan@chandlerfamily.org.uk>
Dear diary, on Thu, Nov 10, 2005 at 09:36:06PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> On Thursday 10 Nov 2005 19:29, Petr Baudis wrote:
>
> >
> > Right now, what about trying to manually select the merge base?
> >
> > public$ cg-merge -b v1.0 master
>
> Actually, that does merge very nicely. However, I don't think its what I
> want. From gitk I get both routes back to my initial commit, both the fast
> track one and the slow train via all stations en-route.
>
> I have had more success with grafting (which you kindly informed me about
> yesterday)
>
> something like
>
> echo `cg-object-id v1.0` `cg-object-id initial_commit` >.git/info/grafts
>
> lf I make a branch out of the parent of v1.0 before doing this, I end up with
> there being a side branch of the old history and my master branch headed back
> through a quick route to the initial_commit.
Huh. But you still have the history cluttered and both routes to your
initial commit, don't you? I'm now confused - I fear I don't know what
you want anymore. But well, whatever is working out for you... ;-)
> Something strange (well actually not that unexpected, the more I think about
> it) has happened though.
>
> I was trying to see if cg-clone would effectively me make a new repository
> without the grafts in it (ie with real commit object with a parent as
> specified via the graft) but it doesn't - it just looses the graft and
> rebrings all the old history back in
>
> Is that a bug?
So far grafts were considered a private thing to enable some cool things
like tying ancient history to your current history tree, etc. But if you
want to do some persistent changes in the DAG, you are really best off
just rebuilding the whole history.
--
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
* [PATCH] cg-log: ignore merges by default, and add --show-merges option
From: Frank Sorenson @ 2005-11-10 21:03 UTC (permalink / raw)
To: Petr Baudis, Git Mailing List
In-Reply-To: <4373B1A6.8000706@tuxrocks.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This patch allows cg-log to ignore merges by default,but will display
them if requested (with "--show-merges").
Signed-off-by: Frank Sorenson <frank@tuxrocks.com>
cg-log | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/cg-log b/cg-log
index 7d955e3..ed2278e 100755
- --- a/cg-log
+++ b/cg-log
@@ -58,6 +58,9 @@
# by their author. This is also known as a "shortlog", suitable
# e.g. for contribution summaries of announcements.
#
+# --show-merges::
+# Display merges in the log as well (ignored by default).
+#
# -uUSERNAME::
# List only commits where author or committer contains 'USERNAME'.
# The search for 'USERNAME' is case-insensitive.
@@ -255,6 +258,7 @@ user=
mergebase=
date_from=
date_to=
+no_merges="--no-merges"
while optparse; do
if optparse -c; then
@@ -300,6 +304,8 @@ while optparse; do
summary=1
elif optparse --summary; then
shortlog=1
+ elif optparse --show-merges; then
+ no_merges=""
else
optfail
fi
@@ -315,9 +321,9 @@ if [ "$mergebase" ]; then
fi
if [ "$shortlog" ]; then
- - revls="git-rev-list --pretty=short $date_from $date_to"
+ revls="git-rev-list --pretty=short $no_merges $date_from $date_to"
else
- - revls="git-rev-list --pretty=raw $date_from $date_to"
+ revls="git-rev-list --pretty=raw $no_merges $date_from $date_to"
fi
revls="$revls $date_from $date_to"
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDc7WOaI0dwg4A47wRAsPuAJ0W0s82jfxu+c/oHRPULaa5l9ITagCdEkhz
NZAE2w8SnNbHl3/8MDtFT3w=
=4cRS
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-10 20:48 UTC (permalink / raw)
To: Andreas Ericsson, Jim Radford; +Cc: git
In-Reply-To: <4373AE02.9050909@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Jim Radford wrote:
>> On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:
>>
>>> I think archimport part needs to be split out just like its
>>> svn/cvs cousins,
>> I don't agree...
>
> How is this different for when svnimport and cvsimport was moved out?..
>
>> The main reason I see for splitting cvs and email import out is the
>> non-standard dependencies, cvsps and perl(Email::Valid).
>
> Define "non-standard". String::ShellQuote isn't installed by default on
> Fedora Core 3 but is required by git-archimport.
I am with Andreas here.
If you are using git to manage development in a tightly knitted
group (e.g. company internal project) and are unlikely to be
exchanging email patches, not having to pull Email::Valid into
your system is a good thing, because you would not be using
git-mail. If you are not dealing with development history
stored in svn or tla, not having to install git-svn nor git-tla
is a good thing.
Technical reasons like package availablity and required package
size count, but I do not think we should be doing the split
purely for technical reasons. The split should aim primarily
to give convenience for the users.
That reminds me, Andreas, you said something about feeding me
spec updates last week but Jim beated you. I am open to
improvements from both of you. Obviously the invitation is not
limited to two of you ;-).
^ permalink raw reply
* [PATCH] cg-log: add --no-merges option to be passed to git-rev-list
From: Frank Sorenson @ 2005-11-10 20:46 UTC (permalink / raw)
To: Petr Baudis, Git Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This patch allows cg-log to ignore merges.
Signed-off-by: Frank Sorenson <frank@tuxrocks.com>
cg-log | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/cg-log b/cg-log
index 7d955e3..2cebf04 100755
- --- a/cg-log
+++ b/cg-log
@@ -58,6 +58,9 @@
# by their author. This is also known as a "shortlog", suitable
# e.g. for contribution summaries of announcements.
#
+# --no-merges::
+# Don't display merges in the log.
+#
# -uUSERNAME::
# List only commits where author or committer contains 'USERNAME'.
# The search for 'USERNAME' is case-insensitive.
@@ -255,6 +258,7 @@ user=
mergebase=
date_from=
date_to=
+no_merges=
while optparse; do
if optparse -c; then
@@ -300,6 +304,8 @@ while optparse; do
summary=1
elif optparse --summary; then
shortlog=1
+ elif optparse --no-merges; then
+ no_merges="--no-merges"
else
optfail
fi
@@ -315,9 +321,9 @@ if [ "$mergebase" ]; then
fi
if [ "$shortlog" ]; then
- - revls="git-rev-list --pretty=short $date_from $date_to"
+ revls="git-rev-list --pretty=short $no_merges $date_from $date_to"
else
- - revls="git-rev-list --pretty=raw $date_from $date_to"
+ revls="git-rev-list --pretty=raw $no_merges $date_from $date_to"
fi
revls="$revls $date_from $date_to"
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDc7GmaI0dwg4A47wRAosOAJ4k7ObTH9dc0me1SEGZFib0KsceqQCdHxX8
w7WXZzCR5dLKgyA0LV49YFU=
=6kA3
-----END PGP SIGNATURE-----
^ permalink raw reply
* Getting rid of symlinks in .git?
From: Petr Baudis @ 2005-11-10 20:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
I'm deliberately breaking up the thread here, not to make the list
reading even more difficult for all the poor readers not so interested
in electronic archaeology (but I feel better after I began taking my
new meds, I can even resist this huge urge to start replying to mails
from June).
In-Reply-To: <1131653507.11283.31.camel@dv>
7261 N T Nov 10 Pavel Roskin ( 1.8K)
Re: [PATCH] cg-pull to stop treating "master" specially,
fix fetch_local for .git/HEAD
(deliberately quoted in entirety)
Dear diary, on Thu, Nov 10, 2005 at 09:11:47PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Thu, 2005-11-10 at 20:24 +0100, Petr Baudis wrote:
> > can you still remember why did you introduce this? In GNU cp
> > documentation, I can see just
> >
> > -b, --backup
> > Make backups of files that are about to be overwritten or removed.
> >
> > which doesn't make sense to me - -L dereferences symlinks.
>
> You are right, it must be my error. Anyway, it was so long ago that I
> would need to review and retest it.
Is it correct that all there is to it is to check if cloning locally
works properly with symlinked HEAD in the remote repository?
> While at that, let's stop using symlinks. git doesn't use symlinks on
> Cygwin. I think git should use that code on all OSes, since the
> benefits of using symlinks are minimal (I think the only benefits are
> their atomicity and resolving the reference in the kernel rather than in
> userspace). Having more uniform code for all platforms would simplify
> development and testing. It could also reduce requirements for the
> transport protocols. Finally, symlinks could be still used by the users
> (if they know what they are doing) - git and cogito would simply become
> symlink agnostic.
>
> When files are copied around, symlinks are pain to deal with. They
> require special handling to be preserved both for remote operation and
> dereferenced for local operation (that's what my patch was intended to
> do). I'm not even considering what would happen when cloning from Linux
> to Windows or vice versa.
I personally would not mind getting rid of symlinks completely, but we
will still have to support them for some reasonable time period (several
major releases, as far as Cogito is concerned - actually, there is
plenty of people still using 0.13 and such).
If more people think this is good idea, I could even again introduce
some compatibility code to cg-Xlib which will rewrite symlinkish HEAD
when it hits it (the kind of stuff we did in the old times).
> Sure, it can wait until git 1.0, but it would be great to keep this goal
> in mind.
>
> Disclaimer - I'm not reading the git mailing list, so if it was
> discussed, I'm sorry, I don't intend to restart that discussion - just
> give me the pointer and I'll read it.
I didn't notice such a discussion yet.
--
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
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