* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-11 8:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050511012626.GL26384@pasky.ji.cz>
On Wed, 2005-05-11 at 03:26 +0200, Petr Baudis wrote:
> Hello,
>
> I would be very happy if you could extend the gitweb scripts a little.
> Basically, what I need is to have ability to create a permanent link to
> a given file in the repository, which stays same across revisions (as
> long as the file stays with the given name, obviously).
>
> E.g. I would like to have something like
>
> http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib/ciabot.pl
>
> for file contrib/ciabot.pl in the latest Cogito tree, and
>
> http://www.kernel.org/git/gitweb.cgi?p=cogito%2Fcogito.git;n=contrib
>
> for the list of the contrib/ directory in the latest Cogito tree.
With the next round I will try to introduce a real browser through the
tree instead of the current damn simple tree-object list. It would be
nice if it can show the the current path and provide a "up to parent"
way. Along with that it should be easy to add the stuff you asked for.
> I think I would prefer the link from the repository index to go not to
> the log page, but some "summary" page, which would have some short
> information about the repository (owner, description, list of branches
> if gitweb supports that, list of tags, link to the latest tree and link
> to the log).
>
> BTW, why are people using ';' in the URIs for separators instead of
> good old '&'s? Hmm, actually it just occurred to me that it might be to
> workaround entity string problems?
Yes, but it's "bad old" not "good". :)
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
Thanks,
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: Jan-Benedict Glaw @ 2005-05-11 9:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <20050511012626.GL26384@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
On Wed, 2005-05-11 03:26:26 +0200, Petr Baudis <pasky@ucw.cz> wrote:
> I would be very happy if you could extend the gitweb scripts a little.
> Basically, what I need is to have ability to create a permanent link to
> a given file in the repository, which stays same across revisions (as
> long as the file stays with the given name, obviously).
I've got another one. I'd like to see st_mtime on the file lists to see
when a file was last touched...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: Alexey Nezhdanov @ 2005-05-11 9:32 UTC (permalink / raw)
To: git
In-Reply-To: <4281BBC4.8060709@dgreaves.com>
Wensday, 11 May 2005 12:01 David Greaves wrote:
> Alexey Nezhdanov wrote:
> >Hello. GIT refuses to compile on Debian sarge on sparc64.
> >Probably some compile flag is incompartible but can't figure out which.
>
> read the error message:
> >/usr/bin/ld: skipping
> >incompatible /usr/lib/gcc-lib/sparc-linux/3.3.3/../../../libz.so when
>
> hmm...
> libz.so
>
> >/usr/bin/ld: cannot find -lz
>
> Can't find often equals "not installed"
webmaster@www:/tmp/cogito-0.10$ ls -l /usr/lib/libz.so
lrwxr-xr-x 1 root root 9 2005-05-11 11:18 /usr/lib/libz.so
-> libz.so.1
webmaster@www:/tmp/cogito-0.10$ ls -l /usr/lib/libz.a
-rw-r--r-- 1 root root 83610 2004-12-07 21:38 /usr/lib/libz.a
>
> So go to aptitude, search for zlib
> You'll find libz-dev
> Install it
>
> Or just run
> apt-get install libz-dev
>
> And try again
Nope, not helped.
www:/home/snake# apt-get install libz-dev
Reading Package Lists... Done
Building Dependency Tree... Done
Note, selecting zlib1g-dev instead of libz-dev
zlib1g-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 307 not upgraded.
www:/home/snake#
>
> David
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [ANNOUNCE] git tracker online
From: Jan-Benedict Glaw @ 2005-05-11 9:55 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: git
In-Reply-To: <1115794878.22180.27.camel@tglx>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Wed, 2005-05-11 07:01:18 +0000, Thomas Gleixner <tglx@linutronix.de> wrote:
> http://www.tglx.de/gittracker
>
> It does:
> - multi repository tracking
> - Tree browsing
> - File revision history
> - File diffs
> - File annotation
> - commit viewer with filtering (e.g. all commits in a tree which are not
> in another tree)
Very nice. One (personal) preference: I'd like to see not only the
check-in date, but also the actual time (resolution of one second is
enough, no need to display the µsec parts:-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: David Woodhouse @ 2005-05-11 11:01 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: Git Mailing List
In-Reply-To: <200505111141.27725.snake@penza-gsm.ru>
On Wed, 2005-05-11 at 11:41 +0400, Alexey Nezhdanov wrote:
> /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
> /usr/bin/ld: cannot find -lz
Libraries which are in /usr/lib as opposed to /usr/lib64 are presumably
64-bit. Since the linker is claiming that they're incompatible, I assume
your compiler is defaulting to 64-bit output. Try adding '-m32' to
CFLAGS, or installing 64-bit libz.
--
dwmw2
^ permalink raw reply
* Re: Core and Not-So Core
From: Noel Grandin @ 2005-05-11 11:21 UTC (permalink / raw)
To: jon; +Cc: Git Mailing List
In-Reply-To: <2cfc40320505100800426d38ca@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3510 bytes --]
Hi
Note that eclipse in particular has a fairly complicated repository
provider interface.
The subversion plugin developers (the subclipse project) took quite a
while to implement their stuff.
Basing your stuff off of their code would be a good idea.
Also, they worked in 2 stages - in the first stage, they created
something called the JavaHL interface, behind which they talked to the
subversion C libraries using JNI.
Then they created a pure-java implemenation of the subversion C
libraries which also implemented the JavaHL interface, allowing them to
compare and contrast the behaviour.
Regards,
Noel Grandin
Jon Seymour wrote:
>I have been experimenting with pure-Java implementation of GIT
>concepts with a goal of eventually providing plugins to Eclipse to
>allow the Eclipse GUI to interact with GIT repositories.
>
>One thing I noticed when doing this is that the present index/cache
>structure is rather arbitrary and the optimum index structure is
>determined by the structure of the tools that use a GIT repository
>rather than the structure of the GIT repository itself.
>
>To give a concrete example: the cache currently contains most of the
>posix stat structure primarily to allow quick change detection. In the
>Java world, most of the posix stat structure is not directly
>accessible via the pure-Java file system abstractions. However, for
>most purposes detecting changes to files modification time and file
>size would be enough. Given this is the case, a Java-GIT client
>doesn't need to bother getting access to a posix stat structure and
>could therefore get away with a simpler index structure, provided it
>doesn't need to interoperate with a 'C'-GIT client that shared the
>same workspace. A Java-GIT client might also choose to represent an
>index cache as a complex serialized Java object graph or (perhaps) an
>XML document.
>
>Another example: I can imagine a variant of the index file structure
>that recorded all the parents which have been merged into the cache
>and automatically include this information when performing the commit.
>
>The point is that many different index file structures are possible
>and will be determined in part by the tooling created in the porcelain
>layer - there really is no one true index file format as there is a
>one true repository format. Different tools can use different index
>file formats and still interoperate at the repository level because
>only the repository format needs to have a solid, unchanging
>definition.
>
>Currently the GIT stack is structured as follows:
>
>cogito
>git-core
>
>I think it would be worthwhile if care was taken to draw a distinction
>between the repository and the cache aspects of the git core, perhaps
>even going to the extreme of moving all knowledge of the cache into
>cogito itself. By clearly drawing this distinction, we will more
>easily enable the creation of different kind of tools sets atop the
>foundation of the GIT repository format.
>
>e.g., either:
>
>cogito
>git-cache
>git-respository
>
>or:
>
>cogito-tools
>cogito-cache
>git-repository
>
>Anyway, I offer this as food for thought - chew or flame away as appropriate!
>
>jon.
>
>
NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html
If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com
^ permalink raw reply
* [ANNOUNCE] Git Documentation online
From: David Greaves @ 2005-05-11 11:55 UTC (permalink / raw)
To: git
Thanks to hpa we now have online browseable docs
http://www.kernel.org/pub/software/scm/git/docs/
For now these are based around Junio/Petr's trees.
As soon as Linus returns and merges things into his tree I'll keep them
tracking that.
David
--
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: David Woodhouse @ 2005-05-11 11:58 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: Git Mailing List
In-Reply-To: <1115809273.16187.493.camel@hades.cambridge.redhat.com>
On Wed, 2005-05-11 at 12:01 +0100, David Woodhouse wrote:
> Libraries which are in /usr/lib as opposed to /usr/lib64 are presumably
> 64-bit.
Der.... I mean 32-bit, obviously; otherwise the rest wouldn't make
sense:
> Since the linker is claiming that they're incompatible, I assume
> your compiler is defaulting to 64-bit output. Try adding '-m32' to
> CFLAGS, or installing 64-bit libz.
--
dwmw2
^ permalink raw reply
* Re: [ANNOUNCE] Git Documentation online
From: Martijn Kuipers @ 2005-05-11 12:02 UTC (permalink / raw)
To: David Greaves; +Cc: git
In-Reply-To: <4281F2B0.4060308@dgreaves.com>
Great,but ...
"The README contains much useful definition and clarification info -
read that first."
But then going to README give you:
"Not Found
The requested URL /pub/software/scm/git/docs/README was not found on
this server."
Otherwise, very nice.
/Martijn
David Greaves wrote:
>Thanks to hpa we now have online browseable docs
>
> http://www.kernel.org/pub/software/scm/git/docs/
>
>For now these are based around Junio/Petr's trees.
>As soon as Linus returns and merges things into his tree I'll keep them
>tracking that.
>
>David
>
>
>
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: Mark Brown @ 2005-05-11 12:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: Alexey Nezhdanov, Git Mailing List
In-Reply-To: <1115812736.16187.494.camel@hades.cambridge.redhat.com>
On Wed, May 11, 2005 at 12:58:56PM +0100, David Woodhouse wrote:
> On Wed, 2005-05-11 at 12:01 +0100, David Woodhouse wrote:
> > Libraries which are in /usr/lib as opposed to /usr/lib64 are presumably
> > 64-bit.
> Der.... I mean 32-bit, obviously; otherwise the rest wouldn't make
> sense:
Yes, that is the case for Debian.
> > Since the linker is claiming that they're incompatible, I assume
> > your compiler is defaulting to 64-bit output. Try adding '-m32' to
> > CFLAGS, or installing 64-bit libz.
...provided in the lib64z1-dev package. I'm not sure if there is a 64
bit libssl package, though.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: Alexey Nezhdanov @ 2005-05-11 12:57 UTC (permalink / raw)
To: git
In-Reply-To: <1115809273.16187.493.camel@hades.cambridge.redhat.com>
Wensday, 11 May 2005 15:01 David Woodhouse wrote:
> On Wed, 2005-05-11 at 11:41 +0400, Alexey Nezhdanov wrote:
> > /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for
> > -lz /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for
> > -lz /usr/bin/ld: cannot find -lz
>
> Libraries which are in /usr/lib as opposed to /usr/lib64 are presumably
> 64-bit. Since the linker is claiming that they're incompatible, I assume
> your compiler is defaulting to 64-bit output. Try adding '-m32' to
> CFLAGS, or installing 64-bit libz.
Thank you very much.
-m32 helped.
64bits libz and libcurl are missing.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: GIT compile error on Sun Sparc SB2000
From: Alexey Nezhdanov @ 2005-05-11 13:01 UTC (permalink / raw)
To: git
In-Reply-To: <200505111657.14424.snake@penza-gsm.ru>
Wensday, 11 May 2005 16:57 Alexey Nezhdanov wrote:
> 64bits libz and libcurl are missing.
Just to be correct:
libssl and libcurl actually.
But this already makes no sense.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: Core and Not-So Core
From: Jon Seymour @ 2005-05-11 14:40 UTC (permalink / raw)
To: Noel Grandin; +Cc: Git Mailing List
In-Reply-To: <4281EAB5.3020006@peralex.com>
On 5/11/05, Noel Grandin <noel@peralex.com> wrote:
> Hi
>
> Note that eclipse in particular has a fairly complicated repository
> provider interface.
> The subversion plugin developers (the subclipse project) took quite a
> while to implement their stuff.
> Basing your stuff off of their code would be a good idea.
>
Noel,
Thanks for the info. I'll certainly have a look at what the subclipse
folks did as I am sure it will be helpful to understand the strategy.
I do think we are in a slightly different situation here as we don't
quite have a stable library interface to git yet - Brad Roberts work
notwithstanding.
The repository API in pure Java is almost a no-brainer since Linus has
done such a good job in keeping the repository specification simple
and unambiguous.
A Java workspace API can take advantage of the abstraction and GUI
facilities that Java and Eclipse afford so will naturally be different
in form to the existing command line tools for manipulating the git
index. Certainly, there will be similarities - aspects of the 3-way
merge, for example, but there will be differences too - workspace
change detection will be somewhat assisted by the change notification
framework in Eclipse and won't require as much manual intervention.
> Also, they worked in 2 stages - in the first stage, they created
> something called the JavaHL interface, behind which they talked to the
> subversion C libraries using JNI.
> Then they created a pure-java implemenation of the subversion C
> libraries which also implemented the JavaHL interface, allowing them to
> compare and contrast the behaviour.
>
At this stage, my thoughts are to implement a listener pattern to keep
the git index up to date, and I may well implement that by calling out
the the C git-update-cache executable. This can run in a background
thread so it needn't be a huge drag on interactive user performance.
Anyway, thanks for your input.
jon.
^ permalink raw reply
* [PATCH] update README and #include in git.txt
From: David Greaves @ 2005-05-11 15:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing Lists
Makefile understands the includes git.txt #includes README
README reformatted to asciidoc to allow inclusion in git.txt
Signed-off-by: David Greaves <david@dgreaves.com>
---
commit 14d464865c5e204793c2244bdc4aba0ecd6d593d
tree e0e578bb02a7d8db1c105fddf5b5168ad0c79088
parent d81ed1b591b1db413c91e29b66de6a14dc543ffc
author David Greaves <david@dgreaves.com> Wed, 11 May 2005 16:20:23 +0100
committer David Greaves <david@dgreaves.com> Wed, 11 May 2005 16:20:23 +0100
Documentation/Makefile | 8
Documentation/git.txt | 19 -
README | 728 +++++++++++++++++++++++++------------------------
3 files changed, 390 insertions(+), 365 deletions(-)
Index: Documentation/Makefile
===================================================================
--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/Documentation/Makefile (mode:100644)
+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/Documentation/Makefile (mode:100644)
@@ -8,8 +8,12 @@
man: $(DOC_MAN)
-git-%: %.c $(LIB_FILE)
- $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
+# 'include' dependencies
+git.txt: ../README
+ touch git.txt
+
+git-diff-*.txt: diff-format.txt
+ touch $@
clean:
rm -f *.xml *.html *.1
Index: Documentation/git.txt
===================================================================
--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/Documentation/git.txt (mode:100644)
+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/Documentation/git.txt (mode:100644)
@@ -16,9 +16,10 @@
This is reference information for the core git commands.
-The link:README[] contains much useful definition and clarification
-info - read that first. And of the commands, I suggest reading
-'git-update-cache' and 'git-read-tree' first - I wish I had!
+The Discussion section below contains much useful definition and
+clarification info - read that first. And of the commands, I suggest
+reading link:git-update-cache.html[git-update-cache] and
+link:git-read-tree.html[git-read-tree] first - I wish I had!
David Greaves <david@dgreaves.com>
08/05/05
@@ -230,18 +231,12 @@
Terminology
-----------
-Each line contains terms used interchangeably
+Each line contains terms which you may see used interchangeably
object database, .git directory
directory cache, index
id, sha1, sha1-id, sha1 hash
type, tag
- blob, blob object
- tree, tree object
- commit, commit object
- parent
- root object
- changeset
Environment Variables
@@ -295,6 +290,10 @@
link:git-diff-files.html[git-diff-files];
link:git-diff-tree.html[git-diff-tree]
+Discussion
+----------
+include::../README[]
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
Index: README
===================================================================
--- 3c79088f1832d78012ccdb63e5da1ab88fcf408e/README (mode:100644)
+++ e0e578bb02a7d8db1c105fddf5b5168ad0c79088/README (mode:100644)
@@ -1,9 +1,13 @@
+////////////////////////////////////////////////////////////////
+ GIT - the stupid content tracker
-
- GIT - the stupid content tracker
+Note that this README is written in asciidoc format and is #include'd
+in the git.txt docs
+The rest of this README is #included in the git.txt file
+////////////////////////////////////////////////////////////////
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
@@ -23,21 +27,19 @@
"current directory cache" aka "index".
-
- The Object Database (GIT_OBJECT_DIRECTORY)
-
-
+The Object Database
+~~~~~~~~~~~~~~~~~~~
The object database is literally just a content-addressable collection
of objects. All objects are named by their content, which is
approximated by the SHA1 hash of the object itself. Objects may refer
-to other objects (by referencing their SHA1 hash), and so you can build
-up a hierarchy of objects.
+to other objects (by referencing their SHA1 hash), and so you can
+build up a hierarchy of objects.
All objects have a statically determined "type" aka "tag", which is
determined at object creation time, and which identifies the format of
-the object (i.e. how it is used, and how it can refer to other objects).
-There are currently three different object types: "blob", "tree" and
-"commit".
+the object (ie how it is used, and how it can refer to other objects).
+There are currently four different object types: "blob", "tree",
+"commit" and "tag".
A "blob" object cannot refer to any other object, and is, like the tag
implies, a pure storage object containing some user data. It is used to
@@ -48,7 +50,7 @@
directory structure. In addition, a tree object can refer to other tree
objects, thus creating a directory hierarchy.
-Finally, a "commit" object ties such directory hierarchies together into
+A "commit" object ties such directory hierarchies together into
a DAG of revisions - each "commit" is associated with exactly one tree
(the directory hierarchy at the time of the commit). In addition, a
"commit" refers to one or more "parent" commit objects that describe the
@@ -62,12 +64,17 @@
just going to confuse people. So aim for the notion of "one root object
per project", even if git itself does not enforce that.
+A "tag" object symbolically identifies and can be used to sign other
+objects. It contains the identifier and type of another object, a
+symbolic name (of course!) and, optionally, a signature.
+
Regardless of object type, all objects are share the following
characteristics: they are all in deflated with zlib, and have a header
that not only specifies their tag, but also size information about the
data in the object. It's worth noting that the SHA1 hash that is used
-to name the object is always the hash of this _compressed_ object, not
-the original data.
+to name the object is the hash of the original data (historical note:
+in the dawn of the age of git this was the sha1 of the _compressed_
+object)
As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
@@ -76,157 +83,179 @@
forms a sequence of <ascii tag without space> + <space> + <ascii decimal
size> + <byte\0> + <binary object data>.
-The structured objects can further have their structure and connectivity
-to other objects verified. This is generally done with the "fsck-cache"
-program, which generates a full dependency graph of all objects, and
-verifies their internal consistency (in addition to just verifying their
-superficial consistency through the hash).
+The structured objects can further have their structure and
+connectivity to other objects verified. This is generally done with
+the "git-fsck-cache" program, which generates a full dependency graph
+of all objects, and verifies their internal consistency (in addition
+to just verifying their superficial consistency through the hash).
The object types in some more detail:
- BLOB: A "blob" object is nothing but a binary blob of data, and
- doesn't refer to anything else. There is no signature or any
- other verification of the data, so while the object is
- consistent (it _is_ indexed by its sha1 hash, so the data itself
- is certainly correct), it has absolutely no other attributes.
- No name associations, no permissions. It is purely a blob of
- data (i.e. normally "file contents").
-
- In particular, since the blob is entirely defined by its data,
- if two files in a directory tree (or in multiple different
- versions of the repository) have the same contents, they will
- share the same blob object. The object is totally independent
- of it's location in the directory tree, and renaming a file does
- not change the object that file is associated with in any way.
-
- TREE: The next hierarchical object type is the "tree" object. A tree
- object is a list of mode/name/blob data, sorted by name.
- Alternatively, the mode data may specify a directory mode, in
- which case instead of naming a blob, that name is associated
- with another TREE object.
-
- Like the "blob" object, a tree object is uniquely determined by
- the set contents, and so two separate but identical trees will
- always share the exact same object. This is true at all levels,
- i.e. it's true for a "leaf" tree (which does not refer to any
- other trees, only blobs) as well as for a whole subdirectory.
-
- For that reason a "tree" object is just a pure data abstraction:
- it has no history, no signatures, no verification of validity,
- except that since the contents are again protected by the hash
- itself, we can trust that the tree is immutable and its contents
- never change.
-
- So you can trust the contents of a tree to be valid, the same
- way you can trust the contents of a blob, but you don't know
- where those contents _came_ from.
-
- Side note on trees: since a "tree" object is a sorted list of
- "filename+content", you can create a diff between two trees
- without actually having to unpack two trees. Just ignore all
- common parts, and your diff will look right. In other words,
- you can effectively (and efficiently) tell the difference
- between any two random trees by O(n) where "n" is the size of
- the difference, rather than the size of the tree.
-
- Side note 2 on trees: since the name of a "blob" depends
- entirely and exclusively on its contents (i.e. there are no names
- or permissions involved), you can see trivial renames or
- permission changes by noticing that the blob stayed the same.
- However, renames with data changes need a smarter "diff" implementation.
-
-CHANGESET: The "changeset" object is an object that introduces the
- notion of history into the picture. In contrast to the other
- objects, it doesn't just describe the physical state of a tree,
- it describes how we got there, and why.
-
- A "changeset" is defined by the tree-object that it results in,
- the parent changesets (zero, one or more) that led up to that
- point, and a comment on what happened. Again, a changeset is
- not trusted per se: the contents are well-defined and "safe" due
- to the cryptographically strong signatures at all levels, but
- there is no reason to believe that the tree is "good" or that
- the merge information makes sense. The parents do not have to
- actually have any relationship with the result, for example.
-
- Note on changesets: unlike real SCM's, changesets do not contain
- rename information or file mode change information. All of that
- is implicit in the trees involved (the result tree, and the
- result trees of the parents), and describing that makes no sense
- in this idiotic file manager.
-
-TRUST: The notion of "trust" is really outside the scope of "git", but
- it's worth noting a few things. First off, since everything is
- hashed with SHA1, you _can_ trust that an object is intact and
- has not been messed with by external sources. So the name of an
- object uniquely identifies a known state - just not a state that
- you may want to trust.
-
- Furthermore, since the SHA1 signature of a changeset refers to
- the SHA1 signatures of the tree it is associated with and the
- signatures of the parent, a single named changeset specifies
- uniquely a whole set of history, with full contents. You can't
- later fake any step of the way once you have the name of a
- changeset.
-
- So to introduce some real trust in the system, the only thing
- you need to do is to digitally sign just _one_ special note,
- which includes the name of a top-level changeset. Your digital
- signature shows others that you trust that changeset, and the
- immutability of the history of changesets tells others that they
- can trust the whole history.
-
- In other words, you can easily validate a whole archive by just
- sending out a single email that tells the people the name (SHA1
- hash) of the top changeset, and digitally sign that email using
- something like GPG/PGP.
-
- In particular, you can also have a separate archive of "trust
- points" or tags, which document your (and other peoples) trust.
- You may, of course, archive these "certificates of trust" using
- "git" itself, but it's not something "git" does for you.
-
-Another way of saying the last point: "git" itself only handles content
-integrity, the trust has to come from outside.
-
-
-
- The "index" aka "Current Directory Cache" (".git/index")
+Blob Object
+~~~~~~~~~~~
+A "blob" object is nothing but a binary blob of data, and doesn't
+refer to anything else. There is no signature or any other
+verification of the data, so while the object is consistent (it _is_
+indexed by its sha1 hash, so the data itself is certainly correct), it
+has absolutely no other attributes. No name associations, no
+permissions. It is purely a blob of data (ie normally "file
+contents").
+
+In particular, since the blob is entirely defined by its data, if two
+files in a directory tree (or in multiple different versions of the
+repository) have the same contents, they will share the same blob
+object. The object is toally independent of it's location in the
+directory tree, and renaming a file does not change the object that
+file is associated with in any way.
+
+A blob is created with link:git-write-blob.html[git-write-blob] and
+it's data can be accessed by link:git-cat-file.html[git-cat-file]
+
+Tree Object
+~~~~~~~~~~~
+The next hierarchical object type is the "tree" object. A tree object
+is a list of mode/name/blob data, sorted by name. Alternatively, the
+mode data may specify a directory mode, in which case instead of
+naming a blob, that name is associated with another TREE object.
+
+Like the "blob" object, a tree object is uniquely determined by the
+set contents, and so two separate but identical trees will always
+share the exact same object. This is true at all levels, ie it's true
+for a "leaf" tree (which does not refer to any other trees, only
+blobs) as well as for a whole subdirectory.
+
+For that reason a "tree" object is just a pure data abstraction: it
+has no history, no signatures, no verification of validity, except
+that since the contents are again protected by the hash itself, we can
+trust that the tree is immutable and its contents never change.
+
+So you can trust the contents of a tree to be valid, the same way you
+can trust the contents of a blob, but you don't know where those
+contents _came_ from.
+
+Side note on trees: since a "tree" object is a sorted list of
+"filename+content", you can create a diff between two trees without
+actually having to unpack two trees. Just ignore all common parts,
+and your diff will look right. In other words, you can effectively
+(and efficiently) tell the difference between any two random trees by
+O(n) where "n" is the size of the difference, rather than the size of
+the tree.
+
+Side note 2 on trees: since the name of a "blob" depends entirely and
+exclusively on its contents (ie there are no names or permissions
+involved), you can see trivial renames or permission changes by
+noticing that the blob stayed the same. However, renames with data
+changes need a smarter "diff" implementation.
+
+A tree is created with link:git-write-tree.html[git-write-tree] and
+it's data can be accessed by link:git-ls-tree.html[git-ls-tree]
+
+Commit Object
+~~~~~~~~~~~~~
+The "commit" object is an object that introduces the notion of
+history into the picture. In contrast to the other objects, it
+doesn't just describe the physical state of a tree, it describes how
+we got there, and why.
+
+A "commit" is defined by the tree-object that it results in, the
+parent commits (zero, one or more) that led up to that point, and a
+comment on what happened. Again, a commit is not trusted per se:
+the contents are well-defined and "safe" due to the cryptographically
+strong signatures at all levels, but there is no reason to believe
+that the tree is "good" or that the merge information makes sense.
+The parents do not have to actually have any relationship with the
+result, for example.
+
+Note on commits: unlike real SCM's, commits do not contain
+rename information or file mode chane information. All of that is
+implicit in the trees involved (the result tree, and the result trees
+of the parents), and describing that makes no sense in this idiotic
+file manager.
+
+A commit is created with link:git-commit-tree.html[git-commit-tree] and
+it's data can be accessed by link:git-cat-file.html[git-cat-file]
+
+Trust
+~~~~~
+An aside on the notion of "trust". Trust is really outside the scope
+of "git", but it's worth noting a few things. First off, since
+everything is hashed with SHA1, you _can_ trust that an object is
+intact and has not been messed with by external sources. So the name
+of an object uniquely identifies a known state - just not a state that
+you may want to trust.
+
+Furthermore, since the SHA1 signature of a commit refers to the
+SHA1 signatures of the tree it is associated with and the signatures
+of the parent, a single named commit specifies uniquely a whole set
+of history, with full contents. You can't later fake any step of the
+way once you have the name of a commit.
+
+So to introduce some real trust in the system, the only thing you need
+to do is to digitally sign just _one_ special note, which includes the
+name of a top-level commit. Your digital signature shows others
+that you trust that commit, and the immutability of the history of
+commits tells others that they can trust the whole history.
+
+In other words, you can easily validate a whole archive by just
+sending out a single email that tells the people the name (SHA1 hash)
+of the top commit, and digitally sign that email using something
+like GPG/PGP.
+
+To assist in this, git also provides the tag object...
+
+Tag Object
+~~~~~~~~~~
+Git provides the "tag" object to simplify creating, managing and
+exchanging symbolic and signed tokens. The "tag" object at its
+simplest simply symbolically identifies another object by containing
+the sha1, type and symbolic name.
+
+However it can optionally contain additional signature information
+(which git doesn't care about as long as there's less than 8k of
+it). This can then be verified externally to git.
+
+Note that despite the tag features, "git" itself only handles content
+integrity; the trust framework (and signature provision and
+verification) has to come from outside.
+A tag is created with link:git-mktag.html[git-mktag] and
+it's data can be accessed by link:git-cat-file.html[git-cat-file]
+The "index" aka "Current Directory Cache"
+-----------------------------------------
The index is a simple binary file, which contains an efficient
representation of a virtual directory content at some random time. It
does so by a simple array that associates a set of names, dates,
permissions and content (aka "blob") objects together. The cache is
always kept ordered by name, and names are unique (with a few very
specific rules) at any point in time, but the cache has no long-term
-meaning, and can be partially updated at any time.
+meaning, and can be partially updated at any time.
In particular, the index certainly does not need to be consistent with
the current directory contents (in fact, most operations will depend on
different ways to make the index _not_ be consistent with the directory
hierarchy), but it has three very important attributes:
- (a) it can re-generate the full state it caches (not just the directory
- structure: it contains pointers to the "blob" objects so that it
- can regenerate the data too)
-
- As a special case, there is a clear and unambiguous one-way mapping
- from a current directory cache to a "tree object", which can be
- efficiently created from just the current directory cache without
- actually looking at any other data. So a directory cache at any
- one time uniquely specifies one and only one "tree" object (but
- has additional data to make it easy to match up that tree object
- with what has happened in the directory)
-
- (b) it has efficient methods for finding inconsistencies between that
- cached state ("tree object waiting to be instantiated") and the
- current state.
-
- (c) it can additionally efficiently represent information about merge
- conflicts between different tree objects, allowing each pathname to
- be associated with sufficient information about the trees involved
- that you can create a three-way merge between them.
+'(a) it can re-generate the full state it caches (not just the
+directory structure: it contains pointers to the "blob" objects so
+that it can regenerate the data too)'
+
+As a special case, there is a clear and unambiguous one-way mapping
+from a current directory cache to a "tree object", which can be
+efficiently created from just the current directory cache without
+actually looking at any other data. So a directory cache at any one
+time uniquely specifies one and only one "tree" object (but has
+additional data to make it easy to match up that tree object with what
+has happened in the directory)
+
+'(b) it has efficient methods for finding inconsistencies between that
+cached state ("tree object waiting to be instantiated") and the
+current state.'
+
+'(c) it can additionally efficiently represent information about merge
+conflicts between different tree objects, allowing each pathname to be
+associated with sufficient information about the trees involved that
+you can create a three-way merge between them.'
Those are the three ONLY things that the directory cache does. It's a
cache, and the normal operation is to re-generate it completely from a
@@ -245,216 +274,209 @@
- The Workflow
-
-
+The Workflow
+------------
Generally, all "git" operations work on the index file. Some operations
-work _purely_ on the index file (showing the current state of the
+work *purely* on the index file (showing the current state of the
index), but most operations move data to and from the index file. Either
from the database or from the working directory. Thus there are four
main combinations:
- 1) working directory -> index
-
- You update the index with information from the working directory
- with the "update-cache" command. You generally update the index
- information by just specifying the filename you want to update,
- like so:
-
- update-cache filename
-
- but to avoid common mistakes with filename globbing etc, the
- command will not normally add totally new entries or remove old
- entries, i.e. it will normally just update existing cache entries.
-
- To tell git that yes, you really do realize that certain files
- no longer exist in the archive, or that new files should be
- added, you should use the "--remove" and "--add" flags
- respectively.
-
- NOTE! A "--remove" flag does _not_ mean that subsequent
- filenames will necessarily be removed: if the files still exist
- in your directory structure, the index will be updated with
- their new status, not removed. The only thing "--remove" means
- is that update-cache will be considering a removed file to be a
- valid thing, and if the file really does not exist any more, it
- will update the index accordingly.
-
- As a special case, you can also do "update-cache --refresh",
- which will refresh the "stat" information of each index to match
- the current stat information. It will _not_ update the object
- status itself, and it will only update the fields that are used
- to quickly test whether an object still matches its old backing
- store object.
-
- 2) index -> object database
-
- You write your current index file to a "tree" object with the
- program
-
- write-tree
-
- that doesn't come with any options - it will just write out the
- current index into the set of tree objects that describe that
- state, and it will return the name of the resulting top-level
- tree. You can use that tree to re-generate the index at any time
- by going in the other direction:
-
- 3) object database -> index
-
- You read a "tree" file from the object database, and use that to
- populate (and overwrite - don't do this if your index contains
- any unsaved state that you might want to restore later!) your
- current index. Normal operation is just
-
- read-tree <sha1 of tree>
-
- and your index file will now be equivalent to the tree that you
- saved earlier. However, that is only your _index_ file: your
- working directory contents have not been modified.
-
- 4) index -> working directory
-
- You update your working directory from the index by "checking
- out" files. This is not a very common operation, since normally
- you'd just keep your files updated, and rather than write to
- your working directory, you'd tell the index files about the
- changes in your working directory (i.e. "update-cache").
-
- However, if you decide to jump to a new version, or check out
- somebody else's version, or just restore a previous tree, you'd
- populate your index file with read-tree, and then you need to
- check out the result with
-
- checkout-cache filename
-
- or, if you want to check out all of the index, use "-a".
-
- NOTE! checkout-cache normally refuses to overwrite old files, so
- if you have an old version of the tree already checked out, you
- will need to use the "-f" flag (_before_ the "-a" flag or the
- filename) to _force_ the checkout.
-
-
-Finally, there are a few odds and ends which are not purely moving from
-one representation to the other:
-
- 5) Tying it all together
-
- To commit a tree you have instantiated with "write-tree", you'd
- create a "commit" object that refers to that tree and the
- history behind it - most notably the "parent" commits that
- preceded it in history.
-
- Normally a "commit" has one parent: the previous state of the
- tree before a certain change was made. However, sometimes it can
- have two or more parent commits, in which case we call it a
- "merge", due to the fact that such a commit brings together
- ("merges") two or more previous states represented by other
- commits.
-
- In other words, while a "tree" represents a particular directory
- state of a working directory, a "commit" represents that state
- in "time", and explains how we got there.
-
- You create a commit object by giving it the tree that describes
- the state at the time of the commit, and a list of parents:
-
- commit-tree <tree> -p <parent> [-p <parent2> ..]
-
- and then giving the reason for the commit on stdin (either
- through redirection from a pipe or file, or by just typing it at
- the tty).
-
- commit-tree will return the name of the object that represents
- that commit, and you should save it away for later use.
- Normally, you'd commit a new "HEAD" state, and while git doesn't
- care where you save the note about that state, in practice we
- tend to just write the result to the file ".git/HEAD", so that
- we can always see what the last committed state was.
-
- 6) Examining the data
-
- You can examine the data represented in the object database and
- the index with various helper tools. For every object, you can
- use "cat-file" to examine details about the object:
-
- cat-file -t <objectname>
-
- shows the type of the object, and once you have the type (which
- is usually implicit in where you find the object), you can use
-
- cat-file blob|tree|commit <objectname>
-
- to show its contents. NOTE! Trees have binary content, and as a
- result there is a special helper for showing that content,
- called "ls-tree", which turns the binary content into a more
- easily readable form.
-
- It's especially instructive to look at "commit" objects, since
- those tend to be small and fairly self-explanatory. In
- particular, if you follow the convention of having the top
- commit name in ".git/HEAD", you can do
-
- cat-file commit $(cat .git/HEAD)
-
- to see what the top commit was.
-
- 7) Merging multiple trees
-
- Git helps you do a three-way merge, which you can expand to
- n-way by repeating the merge procedure arbitrary times until you
- finally "commit" the state. The normal situation is that you'd
- only do one three-way merge (two parents), and commit it, but if
- you like to, you can do multiple parents in one go.
-
- To do a three-way merge, you need the two sets of "commit"
- objects that you want to merge, use those to find the closest
- common parent (a third "commit" object), and then use those
- commit objects to find the state of the directory ("tree"
- object) at these points.
-
- To get the "base" for the merge, you first look up the common
- parent of two commits with
-
- merge-base <commit1> <commit2>
-
- which will return you the commit they are both based on. You
- should now look up the "tree" objects of those commits, which
- you can easily do with (for example)
-
- cat-file commit <commitname> | head -1
-
- since the tree object information is always the first line in a
- commit object.
-
- Once you know the three trees you are going to merge (the one
- "original" tree, aka the common case, and the two "result" trees,
- aka the branches you want to merge), you do a "merge" read into
- the index. This will throw away your old index contents, so you
- should make sure that you've committed those - in fact you would
- normally always do a merge against your last commit (which
- should thus match what you have in your current index anyway).
- To do the merge, do
-
- read-tree -m <origtree> <target1tree> <target2tree>
-
- which will do all trivial merge operations for you directly in
- the index file, and you can just write the result out with
- "write-tree".
-
- NOTE! Because the merge is done in the index file, and not in
- your working directory, your working directory will no longer
- match your index. You can use "checkout-cache -f -a" to make the
- effect of the merge be seen in your working directory.
+1) working directory -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- NOTE2! Sadly, many merges aren't trivial. If there are files
- that have been added.moved or removed, or if both branches have
- modified the same file, you will be left with an index tree that
- contains "merge entries" in it. Such an index tree can _NOT_ be
- written out to a tree object, and you will have to resolve any
- such merge clashes using other tools before you can write out
- the result.
+You update the index with information from the working directory with
+the link:git-update-cache.html[git-update-cache] command. You
+generally update the index information by just specifying the filename
+you want to update, like so:
+
+ git-update-cache filename
+
+but to avoid common mistakes with filename globbing etc, the command
+will not normally add totally new entries or remove old entries, ie it
+will normally just update existing cache entryes.
+
+To tell git that yes, you really do realize that certain files no
+longer exist in the archive, or that new files should be added, you
+should use the "--remove" and "--add" flags respectively.
+
+NOTE! A "--remove" flag does _not_ mean that subsequent filenames will
+necessarily be removed: if the files still exist in your directory
+structure, the index will be updated with their new status, not
+removed. The only thing "--remove" means is that update-cache will be
+considering a removed file to be a valid thing, and if the file really
+does not exist any more, it will update the index accordingly.
+
+As a special case, you can also do "git-update-cache --refresh", which
+will refresh the "stat" information of each index to match the current
+stat information. It will _not_ update the object status itself, and
+it wil only update the fields that are used to quickly test whether an
+object still matches its old backing store object.
+
+2) index -> object database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You write your current index file to a "tree" object with the program
+
+ git-write-tree
+
+that doesn't come with any options - it will just write out the
+current index into the set of tree objects that describe that state,
+and it will return the name of the resulting top-level tree. You can
+use that tree to re-generate the index at any time by going in the
+other direction:
+
+3) object database -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You read a "tree" file from the object database, and use that to
+populate (and overwrite - don't do this if your index contains any
+unsaved state that you might want to restore later!) your current
+index. Normal operation is just
+
+ git-read-tree <sha1 of tree>
+
+and your index file will now be equivalent to the tree that you saved
+earlier. However, that is only your _index_ file: your working
+directory contents have not been modified.
+
+4) index -> working directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You update your working directory from the index by "checking out"
+files. This is not a very common operation, since normally you'd just
+keep your files updated, and rather than write to your working
+directory, you'd tell the index files about the changes in your
+working directory (ie "git-update-cache").
+
+However, if you decide to jump to a new version, or check out somebody
+elses version, or just restore a previous tree, you'd populate your
+index file with read-tree, and then you need to check out the result
+with
+ git-checkout-cache filename
+
+or, if you want to check out all of the index, use "-a".
+
+NOTE! git-checkout-cache normally refuses to overwrite old files, so
+if you have an old version of the tree already checked out, you will
+need to use the "-f" flag (_before_ the "-a" flag or the filename) to
+_force_ the checkout.
+
+
+
+Finally, there are a few odds and ends which are not purely moving
+from one representation to the other:
+
+5) Tying it all together
+~~~~~~~~~~~~~~~~~~~~~~~~
+To commit a tree you have instantiated with "git-write-tree", you'd
+create a "commit" object that refers to that tree and the history
+behind it - most notably the "parent" commits that preceded it in
+history.
+
+Normally a "commit" has one parent: the previous state of the tree
+before a certain change was made. However, sometimes it can have two
+or more parent commits, in which case we call it a "merge", due to the
+fact that such a commit brings together ("merges") two or more
+previous states represented by other commits.
+
+In other words, while a "tree" represents a particular directory state
+of a working directory, a "commit" represents that state in "time",
+and explains how we got there.
+
+You create a commit object by giving it the tree that describes the
+state at the time of the commit, and a list of parents:
+
+ git-commit-tree <tree> -p <parent> [-p <parent2> ..]
+
+and then giving the reason for the commit on stdin (either through
+redirection from a pipe or file, or by just typing it at the tty).
+
+git-commit-tree will return the name of the object that represents
+that commit, and you should save it away for later use. Normally,
+you'd commit a new "HEAD" state, and while git doesn't care where you
+save the note about that state, in practice we tend to just write the
+result to the file ".git/HEAD", so that we can always see what the
+last committed state was.
+
+6) Examining the data
+~~~~~~~~~~~~~~~~~~~~~
+You can examine the data represented in the object database and the
+index with various helper tools. For every object, you can use
+link:git-cat-file.html[git-cat-file] to examine details about the
+object:
+
+ git-cat-file -t <objectname>
+
+shows the type of the object, and once you have the type (which is
+usually implicit in where you find the object), you can use
+
+ git-cat-file blob|tree|commit <objectname>
+
+to show its contents. NOTE! Trees have binary content, and as a result
+there is a special helper for showing that content, called
+"git-ls-tree", which turns the binary content into a more easily
+readable form.
+
+It's especially instructive to look at "commit" objects, since those
+tend to be small and fairly self-explanatory. In particular, if you
+follow the convention of having the top commit name in ".git/HEAD",
+you can do
+
+ git-cat-file commit $(cat .git/HEAD)
+
+to see what the top commit was.
+
+7) Merging multiple trees
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Git helps you do a three-way merge, which you can expand to n-way by
+repeating the merge procedure arbitrary times until you finally
+"commit" the state. The normal situation is that you'd only do one
+three-way merge (two parents), and commit it, but if you like to, you
+can do multiple parents in one go.
+
+To do a three-way merge, you need the two sets of "commit" objects
+that you want to merge, use those to find the closest common parent (a
+third "commit" object), and then use those commit objects to find the
+state of the directory ("tree" object) at these points.
+
+To get the "base" for the merge, you first look up the common parent
+of two commits with
+
+ git-merge-base <commit1> <commit2>
+
+which will return you the commit they are both based on. You should
+now look up the "tree" objects of those commits, which you can easily
+do with (for example)
+
+ git-cat-file commit <commitname> | head -1
+
+since the tree object information is always the first line in a commit
+object.
+
+Once you know the three trees you are going to merge (the one
+"original" tree, aka the common case, and the two "result" trees, aka
+the branches you want to merge), you do a "merge" read into the
+index. This will throw away your old index contents, so you should
+make sure that you've committed those - in fact you would normally
+always do a merge against your last commit (which should thus match
+what you have in your current index anyway).
+
+To do the merge, do
+
+ git-read-tree -m <origtree> <target1tree> <target2tree>
+
+which will do all trivial merge operations for you directly in the
+index file, and you can just write the result out with "git-write-tree".
+
+NOTE! Because the merge is done in the index file, and not in your
+working directory, your working directory will no longer match your
+index. You can use "git-checkout-cache -f -a" to make the effect of
+the merge be seen in your working directory.
+
+NOTE2! Sadly, many merges aren't trivial. If there are files that have
+been added.moved or removed, or if both branches have modified the
+same file, you will be left with an index tree that contains "merge
+entries" in it. Such an index tree can _NOT_ be written out to a tree
+object, and you will have to resolve any such merge clashes using
+other tools before you can write out the result.
- [ fixme: talk about resolving merges here ]
+[ fixme: talk about resolving merges here ]
^ permalink raw reply
* Re: [ANNOUNCE] Git Documentation online
From: David Greaves @ 2005-05-11 15:46 UTC (permalink / raw)
To: Martijn Kuipers; +Cc: git
In-Reply-To: <4281F448.7060607@gmail.com>
Fixed - and somewhat extended...
Martijn Kuipers wrote:
> Great,but ...
>
> "The README contains much useful definition and clarification info -
> read that first."
>
> But then going to README give you:
>
> "Not Found
> The requested URL /pub/software/scm/git/docs/README was not found on
> this server."
>
> Otherwise, very nice.
>
> /Martijn
>
> David Greaves wrote:
>
>> Thanks to hpa we now have online browseable docs
>>
>> http://www.kernel.org/pub/software/scm/git/docs/
>>
>> For now these are based around Junio/Petr's trees.
>> As soon as Linus returns and merges things into his tree I'll keep them
>> tracking that.
>>
>> David
>>
>>
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
^ permalink raw reply
* Re: Core and Not-So Core
From: Daniel Barkalow @ 2005-05-11 16:45 UTC (permalink / raw)
To: jon; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <2cfc403205051016205d722f23@mail.gmail.com>
On Wed, 11 May 2005, Jon Seymour wrote:
> The repository API would contain functionality equivalent to cat-file,
> ls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of
> the transport code - things that don't involve use of the index.
>
> The workspace API would contain read-tree, write-tree, commit-tree,
> etc - things that do involve use of the the index.
Unfortunately for this idea, you can't actually check files into or out of
the repository using the git tools without the index (in memory at least,
if not on disk). This is a bit like having a libc with all the system
calls except read and write. Sure, there are a number of programs that
would be fine that way, but it makes the API unintuitive, and most serious
programs need the extension anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: History messup
From: Thomas Gleixner @ 2005-05-11 17:09 UTC (permalink / raw)
To: Sean; +Cc: H. Peter Anvin, David Woodhouse, git, Linus Torvalds
In-Reply-To: <3772.10.10.10.24.1115676539.squirrel@linux1>
On Mon, 2005-05-09 at 18:08 -0400, Sean wrote:
> On Mon, May 9, 2005 3:34 pm, H. Peter Anvin said:
> Seems the only solution is a full search of the history, unless there is
> some clever way to label branches or detect fast forward heads.
You can apply some heuristic guessing to detect fast forward heads, but
at the very end you will end up with manual selection puzzles.
On one hand we keep care to track the source of a change in the kernel
code by adding signed,acked but on the other hand we don't care about
history correctness. If you look at some file revisions, which you read
from the tree history then you just have patches applied in the wrong
order.
Maybe nobody cares, but for maintaining customer trees with a bugfix,
stable and experimental branch it's necessary to keep track of
information in a consistent way especially if you have to deal with the
QA department.
I know that there is no simple and fool proof solution for this problem,
but some band-aid to make the reconstruction of history simpler would be
not too bad.
tglx
^ permalink raw reply
* cg-add does not understand symlinks
From: Morten Welinder @ 2005-05-11 18:25 UTC (permalink / raw)
To: GIT Mailing List, Petr "Pasky" Baudis
It looks like cg-add does not understand symlinks.
Morten
ln -s dir yyy
ls -l yyy
lrwxrwxrwx 1 welinder research 3 May 11 14:21 yyy -> dir
cg-add yyy
cg-add: yyy does not exist
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Morten Welinder @ 2005-05-11 18:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git, Linus Torvalds
In-Reply-To: <7vsm0us5p5.fsf@assigned-by-dhcp.cox.net>
Here's the symlink version. Note, that git does not complain but
simply creates (or
overwrites) the wrong file.
Morten
cd /tmp
mkdir xxx
cd xxx
rm -rf .git dir yyy
mkdir dir
touch dir/empty
cg-init </dev/null
cg-tag initial
mkdir yyy
touch yyy/zzz
cg-add yyy/zzz
cg-commit </dev/null
cg-tag dir
rm -rf yyy
rm -f .git/HEAD
cat .git/refs/tags/initial > .git/HEAD
git-read-tree -m HEAD
git-checkout-cache -f -a
ln -s dir yyy
git-update-cache --add -- yyy
cg-commit </dev/null
cg-tag symlink
# Got that?
# yyy is a symlink right now.
git-read-tree `cat .git/refs/tags/dir`
git-checkout-cache -f -a
ls -l dir
total 0
-rw-rw-r-- 1 welinder research 0 May 11 14:20 empty
-rw-rw-r-- 1 welinder research 0 May 11 14:26 zzz
# dir/zzz should not exist at ths point!
^ permalink raw reply
* [ANNOUNCE] No more git-jc tree at cox.net
From: Junio C Hamano @ 2005-05-11 19:12 UTC (permalink / raw)
To: git; +Cc: pasky, david
As some of you may already know, for the past couple of weeks
I've been keeping changes to the core GIT that came from
discussion and review on the mailing list in git-jc tree. The
intent was to keep the things organized to save time for Linus
when he wants to integrate those good bits.
The purpose Petr stated for git-pb tree is a superset of the
purpose of git-jc tree, and currently git-pb tree is fully
synched up with git-jc. I do not see much point in duplicated
effort, and also git-jc tree housed at my ISP webspace is
nearing the disc quota. So I'm removing git-jc tree from there,
at least until I find it a new home.
JIT (my own Porcelain layer) will still be at the same address,
<http://members.cox.net/junkio/jit.git/>.
Thanks.
^ permalink raw reply
* [PATCH] Stop git-rev-list at sha1 match
From: Thomas Gleixner @ 2005-05-11 19:24 UTC (permalink / raw)
To: git
The patch adds an option to stop the output of git-rev-list
on a sha1 match.
Signed-Off: Thomas Gleixner <tglx@linutronix.de>
--- a/rev-list.c
+++ b/rev-list.c
@@ -7,6 +7,8 @@ int main(int argc, char **argv)
struct commit_list *list = NULL;
struct commit *commit;
char *commit_arg = NULL;
+ char *sha1hex;
+ char *to_sha1 = NULL;
int i;
unsigned long max_age = -1;
unsigned long min_age = -1;
@@ -21,6 +23,8 @@ int main(int argc, char **argv)
max_age = atoi(arg + 10);
} else if (!strncmp(arg, "--min-age=", 10)) {
min_age = atoi(arg + 10);
+ } else if (!strncmp(arg, "--to_sha1=", 10)) {
+ to_sha1 = arg + 10;
} else {
commit_arg = arg;
}
@@ -30,7 +34,8 @@ int main(int argc, char **argv)
usage("usage: rev-list [OPTION] commit-id\n"
" --max-count=nr\n"
" --max-age=epoch\n"
- " --min-age=epoch\n");
+ " --min-age=epoch\n"
+ " --to-sha1=sha1\n");
commit = lookup_commit(sha1);
if (!commit || parse_commit(commit) < 0)
@@ -46,7 +51,10 @@ int main(int argc, char **argv)
break;
if (max_count != -1 && !max_count--)
break;
- printf("%s\n", sha1_to_hex(commit->object.sha1));
+ sha1hex = sha1_to_hex(commit->object.sha1);
+ if (to_sha1 != NULL && strcmp(to_sha1, sha1hex) == 0)
+ break;
+ printf("%s\n", sha1hex);
} while (list);
return 0;
}
^ permalink raw reply
* Re: cg-add does not understand symlinks
From: Petr Baudis @ 2005-05-11 19:55 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc050511112528a768ce@mail.gmail.com>
Dear diary, on Wed, May 11, 2005 at 08:25:32PM CEST, I got a letter
where Morten Welinder <mwelinder@gmail.com> told me that...
> It looks like cg-add does not understand symlinks.
Thanks, fixed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Junio C Hamano @ 2005-05-11 20:03 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1115839456.22180.79.camel@tglx>
>>>>> "TG" == Thomas Gleixner <tglx@linutronix.de> writes:
TG> The patch adds an option to stop the output of git-rev-list
TG> on a sha1 match.
One minor nit and two suggestions. Otherwise looks good.
TG> Signed-Off: Thomas Gleixner <tglx@linutronix.de>
Nit. Please spell it "Signed-off-by: ". I have seen some
people spell "off" with capital "O" so I guess it is also
permitted.
TG> } else if (!strncmp(arg, "--min-age=", 10)) {
TG> min_age = atoi(arg + 10);
TG> + } else if (!strncmp(arg, "--to_sha1=", 10)) {
TG> + to_sha1 = arg + 10;
Suggestion. How about renaming "--to_sha1" to "--since"? If
you do not like "--since", then "--stop-at" would also be good.
The point being that I do not think we need to emphasize that
the 40-character object IDs are produced by an algorithm that
happens to use SHA1 hash in one of the steps of the computation.
That is just an implementation detail and irrelevant to the
user. What you are accepting here is really the object ID of
the commit object.
At the very least, "--to-sha1" (hyphen not underscore) for
consistency, please.
TG> + sha1hex = sha1_to_hex(commit->object.sha1);
TG> + if (to_sha1 != NULL && strcmp(to_sha1, sha1hex) == 0)
TG> + break;
Suggestion. Instead of running sha1_to_hex on the SHA1 of the
commit and comparing strings for every commit you encounter, how
about keeping 20-byte raw SHA1 of to_sha1 and doing memcmp of
20-byte? That way you would also detect malformed --to-sha1
parameter when you do the initial conversion upon argument
parsing. Also the argument parsing using get_sha1() would give
you an added benefit of using mnemonics (tag and heads).
What do you think about this revision?
----------------------------------------
[PATCH] Introduce "rev-list --stop-at=<commit>".
Additional option, --stop-at=<commit>, is introduced. The
rev-list output stops after showing the named commit.
This is based on Thoms Gleixner's patch but slightly reworked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- a/rev-list.c
+++ b/rev-list.c
@@ -1,12 +1,21 @@
#include "cache.h"
#include "commit.h"
+static const char *rev_list_usage =
+"usage: rev-list [OPTION] commit-id\n"
+" --max-count=nr\n"
+" --max-age=epoch\n"
+" --min-age=epoch\n"
+" --stop-at=commit\n";
+
int main(int argc, char **argv)
{
unsigned char sha1[20];
struct commit_list *list = NULL;
struct commit *commit;
char *commit_arg = NULL;
+ unsigned char stop_at[20];
+ int has_stop_at = 0;
int i;
unsigned long max_age = -1;
unsigned long min_age = -1;
@@ -21,16 +30,17 @@ int main(int argc, char **argv)
max_age = atoi(arg + 10);
} else if (!strncmp(arg, "--min-age=", 10)) {
min_age = atoi(arg + 10);
+ } else if (!strncmp(arg, "--stop-at=", 10)) {
+ if (get_sha1(arg + 10, stop_at))
+ usage(rev_list_usage);
+ has_stop_at = 1;
} else {
commit_arg = arg;
}
}
if (!commit_arg || get_sha1(commit_arg, sha1))
- usage("usage: rev-list [OPTION] commit-id\n"
- " --max-count=nr\n"
- " --max-age=epoch\n"
- " --min-age=epoch\n");
+ usage(rev_list_usage);
commit = lookup_commit(sha1);
if (!commit || parse_commit(commit) < 0)
@@ -47,6 +57,8 @@ int main(int argc, char **argv)
if (max_count != -1 && !max_count--)
break;
printf("%s\n", sha1_to_hex(commit->object.sha1));
+ if (has_stop_at && !memcmp(stop_at, commit->object.sha1, 20))
+ break;
} while (list);
return 0;
}
^ permalink raw reply
* Re: [PATCH] Stop git-rev-list at sha1 match
From: Thomas Gleixner @ 2005-05-11 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy8alr0mz.fsf@assigned-by-dhcp.cox.net>
On Wed, 2005-05-11 at 13:03 -0700, Junio C Hamano wrote:
> Suggestion. How about renaming "--to_sha1" to "--since"? If
> you do not like "--since", then "--stop-at" would also be good.
No preference here :)
> Suggestion. Instead of running sha1_to_hex on the SHA1 of the
> commit and comparing strings for every commit you encounter, how
> about keeping 20-byte raw SHA1 of to_sha1 and doing memcmp of
> 20-byte? That way you would also detect malformed --to-sha1
> parameter when you do the initial conversion upon argument
> parsing. Also the argument parsing using get_sha1() would give
> you an added benefit of using mnemonics (tag and heads).
Makes sense. I just used the sha1_to_hex as it is called anyway for the
printf
> What do you think about this revision?
You moved the stop behind the printf which is inconsistent to the other
stop conditions, but thats a pure cosmetic question as long as it stays
that way for ever.
Otherwise not objections.
tglx
^ permalink raw reply
* Re: History messup
From: Petr Baudis @ 2005-05-11 20:31 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, tglx, git, Linus Torvalds
In-Reply-To: <1115665598.12012.422.camel@baythorne.infradead.org>
Dear diary, on Mon, May 09, 2005 at 09:06:38PM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> On Mon, 2005-05-09 at 12:01 -0700, H. Peter Anvin wrote:
> > Seems like a UUID or a SHA-1 identifier would be better.
> >
> > However, one can definitely argue that even the meaning of "a
> > repository" isn't well-defined in the context of git.
>
> Of course it isn't. But neither is the meaning "a committer" or
> "an author" or even "a date".
>
> Including some kind of repo-specific identifier with each commit would
> help us to make sense of the history, just as those other fields do.
FWIW, I recently added .git/branch-name to Cogito, since I needed some
identifier through which to differentiate between the branches
(repositories - it's all blurred in Cogito view) when sending commits
to CIA.
It is strictly per-branch (never to be shared by multiple repositories),
optional, informative and more of a temporary solution for now I had to
cook together in a minute.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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