* Re: "GIT_INDEX_FILE" environment variable
From: Junio C Hamano @ 2005-04-22 20:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504221147050.2344@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> ... The fact is, you can do _exactly_ what you are talking
LT> about by just wrapping the calls in
LT> ( cd $WORKING_DIR && git-cmd )
LT> which simply doesn't have any downsides that I can see.
Almost, with a counter-example. Please try this yourself:
$ cd mozilla-sha1
$ echo '/* garbage */' >>sha1.c
$ sh -c 'cd .. && show-diff "$0" "$@"' sha1.c
$ cd .. && show-diff mozilla-sha1/sha1.c
Some commands that take working tree relative paths do strange
things without the path munging I discussed in the original
message ("$R- prefixing") if you chdir to the $WORKING_DIR. The
jit-update-cache wrapper I sent in the previous message is an
example of how Cogito layer can work it around. It does not
break my "yuck" meter but I think it probably makes most people
barf ;-). I was trying to make this path munging part easier
for the upper layer by making the core aware of WORKING_DIR.
Here is an updated set of commands that needs such path munging:
check-files paths...
show-diff [-R] [-q] [-s] [-z] [paths...]
update-cache [--add] [--remove] [--refresh]
[--cacheinfo mode blob-id] paths...
checkout-cache [-f] [-a] paths...
That said, I do not think the above set is too many to warrant a
core surgery (I am agreeing with your conclusion here). Unless
we also normalize path to support something like:
$ cd mozilla-sha1
$ echo '/* garbage */' >>cache.h
$ sh -c 'cd .. && show-diff "$0" "$@"' ../cache.h
in the core, that is.
^ permalink raw reply
* [PATCH] More docs
From: David Greaves @ 2005-04-22 19:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Removed Cogito stuff
Updated:
checkout-cache
commit-tree
diff-cache
diff-tree
fsck-cache
git-export
init-db
read-tree
show-files
update-cache
write-tree
Thanks also to Junio C Hamano <junio@siamese.dyndns.org>
More eyes please :)
There are ???s where I'd _especially_ appreciate comments
Also note that much of this is simply edited emails from the list or
comments cross checked with the source.
Signed-off-by: David Greaves <david@dgreaves.com>
---
[-- Attachment #2: README.reference.patch3 --]
[-- Type: text/plain, Size: 22687 bytes --]
Index: README.reference
===================================================================
--- 5f61aecb06c2f2579bbb5951b1b53e0dedc434eb/README.reference (mode:100644 sha1:8186a561108d3c62625614272bd5e2f7d5826b4b)
+++ bc80a76ad52f0cdf28c4e10a2490da3558f5def6/README.reference (mode:100644 sha1:810f4990448fbee57490a945d03a5e8a3eaadec0)
@@ -53,7 +53,7 @@
################################################################
checkout-cache
- checkout-cache [-q] [-a] [-f] [--] <file>...
+ checkout-cache [-q] [-a] [-f] [--prefix=<string>] [--] <file>...
Will copy all files listed from the cache to the working directory
(not overwriting existing files). Note that the file contents are
@@ -69,6 +69,13 @@
checks out all files in the cache before processing listed
files.
+--prefix=<string>
+ When creating files, prepend this <string> (usually a
+ directory including a trailing /)
+
+--
+ Do not interpret any more arguments as options.
+
Note that the order of the flags matters:
checkout-cache -a -f file.c
@@ -96,6 +103,22 @@
problems (not possible in the above example, but get used to it in
scripting!).
+The prefix ability basically makes it trivial to use checkout-cache as
+a "export as tree" function. Just read the desired tree into the
+index, and do a
+
+ checkout-cache --prefix=export-dir/ -a
+
+and checkout-cache will "export" the cache into the specified
+directory.
+
+NOTE! The final "/" is important. The exported name is literally just
+prefixed with the specified string, so you can also do something like
+
+ checkout-cache --prefix=.merged- Makefile
+
+to check out the currently cached copy of "Makefile" into the file
+".merged-Makefile".
################################################################
commit-id
@@ -109,12 +132,340 @@
################################################################
commit-tree
- commit-tree <sha1> [-p <sha1>]* < changelog
+ commit-tree <sha1> [-p <parent sha1>]* < changelog
+
+Creates a new commit object based on the provided tree object and
+emits the new commit object id on stdout. If no parent is given then
+it is considered to be an initial tree.
+
+A commit object usually has 1 parent (a commit after a change) or up
+to 16 parents. More than one parent represents merge of branches that
+led to them.
+
+While a tree represents a particular directory state of a working
+directory, a commit represents that state in "time", and explains how
+to get there.
+
+Normally a commit would identify 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.
+
+Options
+
+<sha1>
+ An existing tree object
+
+-p <parent sha1>
+ Each -p indicates a the id of a parent commit object.
+
+
+Commit Information
+
+A commit encapsulates:
+ all parent object ids
+ author name, email and date
+ committer name and email and the commit time.
+
+If not provided, commit-tree uses your name, hostname and domain to
+provide author and committer info. This can be overridden using the
+following environment variables.
+ AUTHOR_NAME
+ AUTHOR_EMAIL
+ AUTHOR_DATE
+ COMMIT_AUTHOR_NAME
+ COMMIT_AUTHOR_EMAIL
+(nb <,> and '\n's are stripped)
+
+A commit comment is read from stdin (max 999 chars)
+
+see also: write-tree
################################################################
+diff-cache
+ diff-cache [-r] [-z] [--cached] <tree/commit sha1>
+
+Compares the content and mode of the blobs found via a tree object
+with the content of the current cache and, optionally ignoring the
+stat state of the file on disk.
+
+(This is basically a special case of diff-tree that works with the
+current cache as the first tree.)
+
+<tree sha1>
+ The id of a tree or commit object to diff against.
+
+-r
+ recurse
+
+-z
+ /0 line termination on output
+
+--cached
+ do not consider the on-disk file at all
+
+Output format:
+
+For files in the tree but not in the cache
+-<mode>\t <type>\t <sha1>\t <path><filename>
+
+For files in the cache but not in the tree
++<mode>\t <type>\t <sha1>\t <path><filename>
+
+For files that differ:
+*<tree-mode>-><cache-mode>\t <type>\t <tree sha1>-><cache sha1>\t <path><filename>
+
+In the special case of the file being changed on disk and out of sync
+with the cache, the sha1 is all 0's. Example:
+
+ *100644->100660 blob 5be4a414b32cf4204f889469942986d3d783da84->0000000000000000000000000000000000000000 file.c
+
+
+Operating Modes
+You can choose whether you want to trust the index file entirely
+(using the "--cached" flag) or ask the diff logic to show any files
+that don't match the stat state as being "tentatively changed". Both
+of these operations are very useful indeed.
+
+Cached Mode
+If --cached is specified, it allows you to ask:
+ show me the differences between HEAD and the current index
+ contents (the ones I'd write with a "write-tree")
+
+For example, let's say that you have worked on your index file, 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
+
+ diff-cache --cached $(cat .git/HEAD)
+
+Example: let's say I had renamed "commit.c" to "git-commit.c", and I had
+done an "upate-cache" to make that effective in the index file.
+"show-diff" wouldn't show anything at all, since the index file matches
+my working directory. But doing a diff-cache does:
+ torvalds@ppc970:~/git> diff-cache --cached $(cat .git/HEAD)
+ -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+ +100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
+
+And as you can see, the output matches "diff-tree -r" output (we
+always do "-r", since the index is always fully populated
+??CHECK??).
+You can trivially see that the above is a rename.
+
+In fact, "diff-tree --cached" _should_ always be entirely equivalent to
+actually doing a "write-tree" and comparing that. Except this one is much
+nicer for the case where you just want to check where you are.
+
+So doing a "diff-cache --cached" is basically very useful when you are
+asking yourself "what have I already marked for being committed, and
+what's the difference to a previous tree".
+
+Non-cached Mode
+
+The "non-cached" mode takes a different approach, and is potentially
+the even more useful of the two in that what it does can't be emulated
+with a "write-tree + diff-tree". Thus that's the default mode. The
+non-cached version asks the question
+
+ "show me the differences between HEAD and the currently checked out
+ tree - index contents _and_ files that aren't up-to-date"
+
+which is obviously a very useful question too, since that tells you what
+you _could_ commit. Again, the output matches the "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 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 an update-cache on it yet - there is no "object" associated
+with the new state, and you get:
+
+ torvalds@ppc970:~/v2.6/linux> diff-cache $(cat .git/HEAD )
+ *100644->100664 blob 7476bbcfe5ef5a1dd87d745f298b831143e4d77e->0000000000000000000000000000000000000000 kernel/sched.c
+
+ie it shows that the tree has changed, and that "kernel/sched.c" has is
+not up-to-date and may contain new stuff. The all-zero sha1 means that to
+get the real diff, you need to look at the object in the working directory
+directly rather than do an object-to-object diff.
+
+NOTE! As with other commands of this type, "diff-cache" does not 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 upate-cache it to make the cache be in sync.
+
+NOTE 2! 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 tell
+which file is in which state, since the "has been updated" ones show a
+valid sha1, and the "not in sync with the index" ones will always have the
+special all-zero sha1.
+
+################################################################
diff-tree
- diff-tree [-r] [-z] <tree sha1> <tree sha1>
+ diff-tree [-r] [-z] <tree/commit sha1> <tree/commit sha1>
+
+Compares the content and mode of the blobs found via two tree objects.
+
+Note that diff-tree can use the tree encapsulated in a commit object.
+
+<tree sha1>
+ The id of a tree or commit object.
+
+-r
+ recurse
+
+-z
+ /0 line termination on output
+
+--cached
+ Cached only (private?)
+
+Output format:
+
+For files in tree1 but not in tree2
+-<mode>\t <type>\t <sha1>\t <path><filename>
+
+For files not in tree1 but in tree2
++<mode>\t <type>\t <sha1>\t <path><filename>
+
+For files that differ:
+*<tree1-mode>-><tree2-mode>\t <type>\t <tree1 sha1>-><tree2 sha1>\t <path><filename>
+
+
+An example of normal usage is:
+
+ torvalds@ppc970:~/git> diff-tree 5319e4d609cdd282069cc4dce33c1db559539b03 b4e628ea30d5ab3606119d2ea5caeab141d38df7
+ *100664->100664 blob ac348b7d5278e9d04e3a1cd417389379c32b014f->a01513ed4d4d565911a60981bfb4173311ba3688 fsck-cache.c
+
+which tells you that the last commit changed just one file (it's from
+this one:
+
+ commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
+ tree 5319e4d609cdd282069cc4dce33c1db559539b03
+ parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
+ author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+ committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+
+ Make "fsck-cache" print out all the root commits it finds.
+
+ Once I do the reference tracking, I'll also make it print out all the
+ HEAD commits it finds, which is even more interesting.
+
+in case you care).
+
+
+################################################################
+fsck-cache
+ fsck-cache [[--unreachable] <head-sha1>*]
+
+Verifies the connectivity and validity of the objects in the database.
+
+<head-sha1>
+ A commit object to begin an unreachability trace
+
+--unreachable
+ print out objects that exist but that aren't readable from any
+ of the specified root nodes
+
+It tests SHA1 and general object sanity, but it does full tracking of
+the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+"--unreachable" flag it will also print out objects that exist but
+that aren't readable from any of the specified root nodes.
+
+So for example
+
+ fsck-cache --unreachable $(cat .git/HEAD)
+
+or, for Cogito users:
+
+ fsck-cache --unreachable $(cat .git/heads/*)
+
+will do quite a _lot_ of verification on the tree. There are a few
+extra validity tests to be added (make sure that tree objects are
+sorted properly etc), but on the whole if "fsck-cache" is happy, you
+do have a valid tree.
+
+Any corrupt objects you will have to find in backups or other archives
+(ie you can just remove them and do an "rsync" with some other site in
+the hopes that somebody else has the object you have corrupted).
+
+Of course, "valid tree" doesn't mean that it wasn't generated by some
+evil person, and the end result might be crap. Git is a revision
+tracking system, not a quality assurance system ;)
+
+Extracted Diagnostics
+expect dangling commits - potential heads - due to lack of head information
+ You haven't specified any nodes as heads so it won't be
+ possible to differentiate between un-parented commits and
+ root nodes.
+
+missing sha1 directory '<dir>'
+ The directory holding the sha1 objects is missing.
+
+unreachable <type> <sha1>
+ The <type> object <sha1>, isn't actually referred to directly
+ or indirectly in any of the trees or commits seen. This can
+ mean that there's another root na SHA1_ode that you're not specifying
+ or that the tree is corrupt. If you haven't missed a root node
+ then you might as well delete unreachable nodes since they
+ can't be used.
+
+missing <type> <sha1>
+ The <type> object <sha1>, is referred to but isn't present in
+ the database.
+
+dangling <type> <sha1>
+ The <type> object <sha1>, is present in the database but never
+ _directly_ used. A dangling commit could be a root node.
+
+warning: fsck-cache: tree <tree> has full pathnames in it
+ And it shouldn't...
+
+sha1 mismatch <sha1>
+ The database has an object who's sha1 doesn't match the
+ database value.
+ This indicates a ??serious?? data integrity problem.
+ (note: this error occured during early git development when
+ the database format changed.)
+
+Environment Variables
+
+SHA1_FILE_DIRECTORY
+ used to specify the object database root (usually .git/objects)
+
+################################################################
+git-export
+ git-export top [base]
+
+probably deprecated:
+On Wed, 20 Apr 2005, Petr Baudis wrote:
+>> I will probably not buy git-export, though. (That is, it is merged, but
+>> I won't make git frontend for it.) My "git export" already does
+>> something different, but more importantly, "git patch" of mine already
+>> does effectively the same thing as you do, just for a single patch; so I
+>> will probably just extend it to do it for an (a,b] range of patches.
+
+
+That's fine. It was a quick hack, just to show that if somebody wants to,
+the data is trivially exportable.
+
+ Linus
+
+
+################################################################
+init-db
+ init-db
+
+This simply creates an empty git object database - basically a .git
+directory.
+
+If the object storage directory is specified via the
+SHA1_FILE_DIRECTORY environment variable then the sha1 directories are
+created underneath - otherwise the default .git/objects directory is
+used.
+
+init-db won't hurt an existing repository.
################################################################
@@ -134,7 +485,108 @@
################################################################
read-tree
- read-tree [-m] <sha1>
+ read-tree (<sha> | -m <sha1> [<sha2> <sha3>])"
+
+Reads the tree information given by <sha> into the directory cache,
+but does not actually _update_ any of the files it "caches". (see:
+checkout-cache)
+
+Optionally, it can merge a tree into the cache or perform a 3-way
+merge.
+
+Trivial merges are done by read-tree itself. Only conflicting paths
+will be in unmerged state when read-tree returns.
+
+
+-m
+ Perform a merge, not just a read
+
+<sha#>
+ The id of the tree object(s) to be read/merged.
+
+
+Merging
+Each "index" entry has two bits worth of "stage" state. stage 0 is the
+normal one, and is the only one you'd see in any kind of normal use.
+
+However, when you do "read-tree" with multiple trees, the "stage"
+starts out at 0, but increments for each tree you read. And in
+particular, the old "-m" flag (which used to be "merge with old
+state") has a new meaning: it now means "start at stage 1" instead.
+
+This means that you can do
+
+ read-tree -m <tree1> <tree2> <tree3>
+
+and you will end up with an index with all of the <tree1> entries in
+"stage1", all of the <tree2> entries in "stage2" and all of the
+<tree3> entries in "stage3".
+
+Furthermore, "read-tree" has this special-case logic that says: if you
+see a file that matches in all respects in all three states, it
+"collapses" back to "stage0".
+
+Write-tree refuses to write a nonsensical tree, so write-tree will
+complain about unmerged entries if it sees a single entry that is not
+stage 0".
+
+Ok, this all sounds like a collection of totally nonsensical rules,
+but it's actually exactly what you want in order to do a fast
+merge. The different stages represent the "result tree" (stage 0, aka
+"merged"), the original tree (stage 1, aka "orig"), and the two trees
+you are trying to merge (stage 2 and 3 respectively).
+
+In fact, the way "read-tree" works, it's entirely agnostic about how
+you assign the stages, and you could really assign them any which way,
+and the above is just a suggested way to do it (except since
+"write-tree" refuses to write anything but stage0 entries, it makes
+sense to always consider stage 0 to be the "full merge" state).
+
+So what happens? Try it out. Select the original tree, and two trees
+to merge, and look how it works:
+
+ - if a file exists in identical format in all three trees, it will
+ automatically collapse to "merged" state by the new read-tree.
+
+ - a file that has _any_ difference what-so-ever in the three trees
+ will stay as separate entries in the index. It's up to "script
+ policy" to determine how to remove the non-0 stages, and insert a
+ merged version. But since the index is always sorted, they're easy
+ to find: they'll be clustered together.
+
+ - the index file saves and restores with all this information, so you
+ can merge things incrementally, but as long as it has entries in
+ stages 1/2/3 (ie "unmerged entries") you can't write the result.
+
+So now the merge algorithm ends up being really simple:
+
+ - you walk the index in order, and ignore all entries of stage 0,
+ since they've already been done.
+
+ - if you find a "stage1", but no matching "stage2" or "stage3", you
+ know it's been removed from both trees (it only existed in the
+ original tree), and you remove that entry. - if you find a
+ matching "stage2" and "stage3" tree, you remove one of them, and
+ turn the other into a "stage0" entry. Remove any matching "stage1"
+ entry if it exists too. .. all the normal trivial rules ..
+
+NOTE NOTE NOTE! although read-tree coule do some of these nontrivial
+merges, only the "matches in all three states" thing collapses by
+default. This is because even though there are other trivial cases
+("matches in both merge trees but not in the original one"), those
+cases might actually be interesting for the merge logic to know about,
+so that information is left around. It should be fairly rare anyway,
+so a few extra index entries are written out to disk so that the merge
+can be annotated.
+
+Incidentally - it also means that you don't even have to have a separate
+subdirectory for this. All the information literally is in the index file,
+which is a temporary thing anyway. There is no need to worry about what is in
+the working directory, since it is never shown and never used.
+
+see also:
+write-tree
+show-files
################################################################
@@ -151,8 +603,145 @@
show-files
show-files [-z] [-t] (--[cached|deleted|others|ignored|stage])*
+This merges the file listing in the directory cache index with the
+actual working directory list, and shows different combinations of the
+two.
+
+--cached
+ Show cached files in the output (default)
+
+--deleted
+ Show deleted files in the output
+
+--others
+ Show other files in the output
+
+--ignored
+ Show ignored files in the output
+
+--stage
+ Show stage files in the output
+
+-t
+ Show the following tags (followed by a space) at the start of
+ each line:
+ H cached
+ M unmerged
+ R removed/deleted
+ ? other
+
+-z
+ /0 line termination on output
+
+Output
+show files just outputs the filename unless --stage is specified in
+which case it outputs:
+
+[<tag> ]<mode> <sha1> <stage> <filename>
+
+show-files --unmerged" and "show-files --stage " can be used to examine
+detailed information on unmerged paths.
+
+For an unmerged path, instead of recording a single mode/SHA1 pair,
+the dircache records up to three such pairs; one from tree O in stage
+1, A in stage 2, and B in stage 3. This information can be used by
+the user (or Cogito) to see what should eventually be recorded at the
+path. (see read-cache for more information on state)
+
+see also:
+read-cache
+
################################################################
unpack-file
unpack-file.c <sha1>
+################################################################
+update-cache
+ update-cache [--add] [--remove] [--refresh] [--cacheinfo <mode> <sha1> <path>]* [--] [<file>]*
+
+Modifies the index or directory cache. Each file mentioned is updated
+into the cache and any 'unmerged' or 'needs updating' state is
+cleared.
+
+The way update-cache handles files it is told about can be modified
+using the various options:
+
+--add
+ If a specified file isn't in the cache 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
+ removed.
+ Default behaviour is to ignore removed file.
+
+--refresh
+ Looks at the current cache and checks to see if merges or
+ updates are needed by checking stat() information.
+
+--cacheinfo <mode> <sha1> <path>
+ Directly insert the specified info into the cache.
+
+--
+ Do not interpret any more arguments as options.
+
+<file>
+ Files to act on.
+ Note that files begining with '.' are discarded. This includes
+ "./file" and "dir/./file". If you don't want this, then use
+ cleaner names.
+ The same applies to directories ending '/' and paths with '//'
+
+
+Using --refresh
+
+--refresh" does not calculate a new sha1 file or bring the cache
+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
+the stat entry is out of date.
+
+For example, you'd want to do this after doing a "read-tree", to link
+up the stat cache details with the proper files.
+
+Using --cacheinfo
+--cacheinfo is used to register a file that is not in the current
+working directory. This is useful for minimum-checkout merging.
+
+To pretend you have a file with mode and sha1 at path, say:
+
+ $ update-cache --cacheinfo mode sha1 path
+
+
+################################################################
+write-tree
+ write-tree
+
+Creates a tree object using the current cache.
+
+The cache must be merged.
+
+Conceptually, write-tree sync()s the current directory cache 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 "update-cache" phase before you did the
+"write-tree".
+
+
+################################################################
+
+
+
+git Environment Variables
+AUTHOR_NAME
+AUTHOR_EMAIL
+AUTHOR_DATE
+COMMIT_AUTHOR_NAME
+COMMIT_AUTHOR_EMAIL
+GIT_DIFF_CMD
+GIT_DIFF_OPTS
+GIT_INDEX_FILE
+SHA1_FILE_DIRECTORY
+
Index: contrib/gitfeedmaillist.sh
===================================================================
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Daniel Barkalow @ 2005-04-22 19:46 UTC (permalink / raw)
To: tony.luck; +Cc: Brad Roberts, Petr Baudis, git
In-Reply-To: <200504212205.j3LM5J005103@unix-os.sc.intel.com>
On Thu, 21 Apr 2005 tony.luck@intel.com wrote:
> On Wed, 20 Apr 2005, Brad Roberts wrote:
> > How about fetching in the inverse order. Ie, deepest parents up towards
> > current. With that method the repository is always self consistent, even
> > if not yet current.
>
> Daniel Barkalow replied:
> > You don't know the deepest parents to fetch until you've read everything
> > more recent, since the history you'd have to walk is the history you're
> > downloading.
>
> You "just" need to defer adding tree/commit objects to the repository until
> after you have inserted all objects on which they depend. That's what my
> "wget" based version does ... it's very crude, in that it loads all tree
> & commit objects into a temporary repository (.gittmp) ... since you can
> only use "cat-file" and "ls-tree" on things if they live in objects/xx/xxx..xxx
> The blobs can go directly into the real repo (but to be really safe you'd
> have to ensure that the whole blob had been pulled from the network before
> inserting it ... it's probably a good move to validate everything that you
> pull from the outside world too).
The problem with this general scheme is that it means that you have to
start over if something goes wrong, rather than resuming from where you
left off (and being able to use what you got until then). I think a better
solution is to track what things you mean to have and what things you
expect you could get from where.
As for validation, I now have my programs (which I haven't gotten a chance
to send out recently) checking everything as it is downloaded to make sure
it is complete (zlib likes it) and has the correct hash.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Linus Torvalds @ 2005-04-22 19:43 UTC (permalink / raw)
To: Chris Mason; +Cc: Krzysztof Halasa, git
In-Reply-To: <200504221458.36300.mason@suse.com>
On Fri, 22 Apr 2005, Chris Mason wrote:
>
> The problem I see for git is that once you have enough data, it should degrade
> over and over again somewhat quickly.
I really doubt that.
There's a more or less constant amount of new data added all the time: the
number of changes does _not_ grow with history. The number of changes
grows with the amount of changes going on in the tree, and while that
isn't exactly constant, it definitely is not something that grows very
fast.
Btw, this is how git is able to be so fast in the first place. Git is fast
because it knows that the "size of the change" is a lot smaller than the
"size of the repository", so it fundamentally at all points tries to make
sure that it only ever bothers with stuff that has changed.
Stuff that hasn't changed, it ignores very _very_ efficiently.
That's really the whole point of the index file: it's a way to quickly
ignore the stuff that hasn't changed - both for simple operations like
"show-diff", but also for complex operations like "merge these three
trees".
And it works exactly because the number of changes does _not_ grow at all
linearly with the history of the project. In fact, in most projects, the
rate of change does _down_ when the project grows, because the projects
matures and generally gets more complicated and thus harder to change.
(The kernel _really_ is pretty special. I am willing to bet that there are
not a lot of big projects that have been able to continue to take changes
at the kind of pace that the kernel does. But we've had to work at it a
lot, including obviously using SCM tools that are very much geared towards
scaling. Why do you think the kernel puts more pressure on SCM's than
other projects? It's exactly because we're trying to scale our change
acceptance to bigger numbers).
So when you say "once you have enough data, it will degrade quickly"
ignores the fact that the rate of change isn't (the "second derivative of
the size of the project in time") really isn't that high.
> I grabbed Ingo's tarball of 28,000 patches since 2.4.0 and applied them all
> into git on ext3 (htree). It only took ~2.5 hrs to apply.
Ok, I'd actually wish it took even less, but that's still a pretty
impressive average of three patches a second.
> Anyway, I ended up with a 2.6GB .git directory. Then I:
>
> rm .git/index
> umount ; mount again
> time read-tree `tree-id` (24.45s)
> time checkout-cache --prefix=../checkout/ -a -f (4m30s)
>
> --prefix is neat ;)
That sounds pretty acceptable. Four minutes is a long time, but I assume
that the whole point of the exercise was to try to test worst-case
behaviour. We can certainly make sure that real usage gets lower numbers
than that (in particular, my "real usage" ends up being 100% in the disk
cache ;)
Linus
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Linus Torvalds @ 2005-04-22 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzmvr72j6.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Apr 2005, Junio C Hamano wrote:
>
> The commands I would want to take paths relative to the user cwd
> are quite limited; note that I just want these available to the
> user and I do not care which one, the core or Cogito, groks the
> cwd relative paths:
I've thought about this, and looked at the sources, and it wouldn't be
horrible.
HOWEVER, the more I thought about it, the less sense it made. The fact is,
you can do _exactly_ what you are talking about by just wrapping the calls
in
( cd $WORKING_DIR && git-cmd )
which simply doesn't have any downsides that I can see. It always does the
right thing, and it means that the tools will never have to care about
what the base is. Keeping the core tools is important, because if they
mess up, you're in serious trouble. In contrast, if higher levels mess up,
you're not likely to have caused anything irrevocable.
In fact, I probably shouldn't even have done the "--prefix=" stuff for
check-out, since the common "check out in a new directory" case (not the
"prefix file" case can be pretty easily emulated with a fairly trivial
script, something like
#!/bin/sh
CURRENT_DIR=$(pwd)
GIT_INDEX_FILE=${GIT_INDEX_FILE:-$CURRENT_DIR/.git/index}
SHA1_FILE_DIRECTORY=${SHA1_FILE_DIRECTORY:-$CURRENT_DIR/.git/objects}
TARGET=$1
shift 1
mkdir $TARGET && cd $TARGET && checkout-cache "$@"
but since it was (a) very easy to add to that particular program, and (b)
exporting a while directory is pretty fundamental, I'll just leave that
strange special case around.
So to the core tools, there really _are_ just two special things: the
index file, and the place where to find the sha1 objects. The working
directory is really nothing but "pwd", which can be trivially changed
before invocation, ie the addition of a new environment variable really
doesn't _buy_ anything except for complexity.
Linus
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 19:06 UTC (permalink / raw)
To: kyle; +Cc: Petr Baudis, GIT Mailing Lists
In-Reply-To: <1114192702.31076.428.camel@axer.marchex.com>
[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]
On Fri, 2005-04-22 at 10:58 -0700, Kyle Hayes wrote:
> On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
> > where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > > Meaning, if they use a ',' in one of the fields (and it is a linux
> > > system with the chfn most probably from the shadow package), then they
> > > are looking for trouble. The only reason I added the ';' was because
> > > somebody said whatever OS used it instead of a ','.
> >
> > What about just swapping the two tests so that ; is cut off and , only
> > when no ; is around?
>
> Even nicer. I like it. Very clean!
>
Right, but ';' is not cutoff on linux for one, and from what you said
freebsd as well. How about this rather (note that I assumed that the
use of ';' as delimiter will be in the minority, but we can switch
things around if it turns out the other way):
----
(not signed off, etc, as just for comments)
Index: commit-tree.c
===================================================================
--- 5f61aecb06c2f2579bbb5951b1b53e0dedc434eb/commit-tree.c (mode:100644 sha1:c0b07f89286c3f6cceae8122b4c3142c8efaf8e1)
+++ uncommitted/commit-tree.c (mode:100644)
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -311,6 +296,17 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /*
+ * The GECOS fields are seperated via ',' on Linux, FreeBSD, etc,
+ * and ';' on AIX.
+ */
+#if defined(__aix__)
+ if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
+#else
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+#endif
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Chris Mason @ 2005-04-22 18:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Krzysztof Halasa, git
In-Reply-To: <Pine.LNX.4.58.0504220916060.2344@ppc970.osdl.org>
On Friday 22 April 2005 12:22, Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Chris Mason wrote:
> > We can sort by the files before reading them in, but even if we order
> > things perfectly, we're spreading the io out too much across the drive.
>
> No we don't.
>
> It's easy to just copy the repository in a way where this just isn't true:
> you sort the objects by how far they are from the current HEAD, and you
> just copy the repository in that order ("furthest" objects first - commits
> last).
>
> That's what I meant by defragmentation - you can actually do this on your
> own, even if your filesystem doesn't support it.
This certainly can help. Based on some ideas from andrea I made a poor man's
defrag script last year that was similar. It worked by copying files into a
flat dir in the order you expected to read them in, deleting the original,
then hard linking them into their original name.
Copying in order straight into a new git tree doesn't help much when the
filesystem is using the subdirectory as a hint to block allocation. So
you'll probably have to copy them all into a flat directory and then hard
link back into the git tree (the flat dir can then be deleted of course).
The problem I see for git is that once you have enough data, it should degrade
over and over again somewhat quickly. My own guess is that you'll need to
run the script at least monthly. If we're designing the thing now and say
'wow, that's going to be really slow without help', it doesn't hurt to look
at alternatives.
I grabbed Ingo's tarball of 28,000 patches since 2.4.0 and applied them all
into git on ext3 (htree). It only took ~2.5 hrs to apply. I did use my
write-tree patch where you had to give write-tree a list of directories to
search, but I don't think this helped much since the operation was mostly
disk write bound.
Anyway, I ended up with a 2.6GB .git directory. Then I:
rm .git/index
umount ; mount again
time read-tree `tree-id` (24.45s)
time checkout-cache --prefix=../checkout/ -a -f (4m30s)
--prefix is neat ;)
The tree that ended up in checkout was 239456k, giving us an effective io rate
for checkout-cache of 885k/s. (this drive gets 24MB/s sequential reads).
I'll have numbers for the packed files later on today. No, I don't really
expect the numbers will convince you to implement some kind of packing ;)
But it's still a good data point to have, and generating them here is just
poking the box every 2 hours or so.
-chris
^ permalink raw reply
* Re: [git pasky] tarball question
From: Martin Schlemmer @ 2005-04-22 18:51 UTC (permalink / raw)
To: Greg KH; +Cc: GIT Mailing Lists, Petr Baudis
In-Reply-To: <20050422182353.GA599@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Fri, 2005-04-22 at 11:23 -0700, Greg KH wrote:
> On Fri, Apr 22, 2005 at 04:31:43PM +0200, Martin Schlemmer wrote:
Hi,
> > How about ripping the .git directory from the next release, and just
> > have a un-numbered tarball (like you used to) that have the latest
> > snapshot of the .git directory for those that want to do git-pasky
> > development? Should even make things easier your side, as you could
> > just do a cron to update it one a day/whatever.
>
> Why? The .git directory doesn't hurt anything that gentoo would do, we
> would just update the ebuild for the major releases.
>
True, but the tarball was already nearing 2mb (the one before the
versioned tarballs I still have here, is about 1.8mb), and I was just
afraid of what might have happened size wise by the time it hit version
1.0 :)
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-pasky debian dir
From: Chris Wright @ 2005-04-22 18:45 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: Chris Wright, git
In-Reply-To: <200504221400.11507.jcorbin@wunjo.org>
* Joshua T. Corbin (jcorbin@wunjo.org) wrote:
> On 22 April 2005 12:16, Chris Wright <chrisw@osdl.org> wrote:
> > This whole bit should be formalized.
> Agreed, hence why I did it as a package-build-time patch instead of changing
> directly in my repository.
>
> > Ideally, I'd like to do /usr/bin/git frontend, with all scripts
> > in /usr/libexec/git/.
> How standard is this '/usr/libexec'? I have no such directory on my Debian
> boxes. If /usr/share rubs you the wroung way, what of
> simply /usr/lib/git-pasky?
Hrm, it's not in FHS, but it's certainly in use on my install:
$ find /usr/libexec | wc -l
122
I don't care too much, I imagine distros wind up customizing this
anyway.
> > However, this requires something more than hardcoding paths.
> Definately, and it may not play well with the simpler method of installing to
> $HOME/bin. This was just a quick hack as not to pollute /usr/bin with files
> that aren't directly executed by the user.
Yup, that's why I dropped 'em in /usr/local/bin for now.
> > You get the idea ;-) I certainly see how it makes sense for a first
> > run to get it going. But this will need fixing upstream.
> This will all be moot when cogito goes the way of cg-* ;-)
Hrm...good point.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: [git pasky] tarball question
From: Greg KH @ 2005-04-22 18:23 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists, Petr Baudis
In-Reply-To: <1114180303.29271.25.camel@nosferatu.lan>
On Fri, Apr 22, 2005 at 04:31:43PM +0200, Martin Schlemmer wrote:
> Hi,
>
> I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with
> the .git database included as well (btw, great stuff renaming it to
> something more distributable), but its going to be a pita for users of
> source based distro's like us (Gentoo), as well as our mirrors if it
> gets much bigger. (Already asked r3pek to add it to portage).
Ah good, I was already makeing a ebuild for it, I'll let others do it
then :)
> How about ripping the .git directory from the next release, and just
> have a un-numbered tarball (like you used to) that have the latest
> snapshot of the .git directory for those that want to do git-pasky
> development? Should even make things easier your side, as you could
> just do a cron to update it one a day/whatever.
Why? The .git directory doesn't hurt anything that gentoo would do, we
would just update the ebuild for the major releases.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Martin Uecker @ 2005-04-22 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <m3vf6frvxu.fsf@defiant.localdomain>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Fri, Apr 22, 2005 at 11:40:29AM +0200, Krzysztof Halasa wrote:
> > This is why I absolutely do not believe in arguments like "if your
> > filesystem doesn't do tail packing, you shouldn't use it" or "if your
> > don't have name hashing enabled in your filesystem it's broken".
>
> Of course. But one may consider using a filesystem with, say, different
> settings. Or a special filesystem for this task, such as CNFS used by
> news servers (it seems news servers do quite the same what git does,
> except they also purge old contents, i.e., container files don't grow up).
and nttp would give a nice transfer method for git objects...
Martin
--
One night, when little Giana from Milano was fast asleep,
she had a strange dream.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Constify
From: Morten Welinder @ 2005-04-22 18:08 UTC (permalink / raw)
To: GIT Mailing List
Hi!
This patch makes strings type "const char *" and keeps people honest.
[Here's to hoping that nothing in this email setup mangles whitespace...]
Signed-off-by: Morten Welinder (mwelinder@gmail.com)
Index: Makefile
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/Makefile (mode:100644
sha1:2d7e4cf0464c45b7c5b169bff7e5c4e7768c13a1)
+++ uncommitted/Makefile (mode:100664)
@@ -12,7 +12,7 @@
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
-CFLAGS=-g -O2 -Wall
+CFLAGS=-g -O2 -Wall -Wwrite-strings
# Should be changed to /usr/local
prefix=$(HOME)
Index: commit-tree.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/commit-tree.c
(mode:100644 sha1:c0b07f89286c3f6cceae8122b4c3142c8efaf8e1)
+++ uncommitted/commit-tree.c (mode:100664)
@@ -62,7 +62,7 @@
return i;
}
-static void finish_buffer(char *tag, char **bufp, unsigned int *sizep)
+static void finish_buffer(const char *tag, char **bufp, unsigned int *sizep)
{
int taglen;
int offset;
@@ -273,7 +273,7 @@
*/
#define MAXPARENT (16)
-static char *commit_tree_usage = "commit-tree <sha1> [-p <sha1>]* < changelog";
+static const char *commit_tree_usage = "commit-tree <sha1> [-p
<sha1>]* < changelog";
int main(int argc, char **argv)
{
Index: diff-cache.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/diff-cache.c
(mode:100644 sha1:5e1d1a6e6d83291964dca82e6969e576f6a839ec)
+++ uncommitted/diff-cache.c (mode:100664)
@@ -215,7 +215,7 @@
return 0;
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static const char *diff_cache_usage = "diff-cache [-r] [-z]
[--cached] <tree sha1>";
int main(int argc, char **argv)
{
Index: diff-tree.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/diff-tree.c (mode:100644
sha1:0f370927dd2496a420af53d137676b6c3c445f75)
+++ uncommitted/diff-tree.c (mode:100664)
@@ -178,7 +178,7 @@
return retval;
}
-static char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1> <tree sha1>";
+static const char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1>
<tree sha1>";
int main(int argc, char **argv)
{
Index: fsck-cache.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/fsck-cache.c
(mode:100644 sha1:96b8eb161107cd3219975d93a44874a5455b702e)
+++ uncommitted/fsck-cache.c (mode:100664)
@@ -134,7 +134,7 @@
int main(int argc, char **argv)
{
int i, heads;
- char *sha1_dir;
+ const char *sha1_dir;
sha1_dir = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
for (i = 0; i < 256; i++) {
Index: init-db.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/init-db.c (mode:100644
sha1:dad06351ca35d0d2f68cd9e719c49805386f96fa)
+++ uncommitted/init-db.c (mode:100664)
@@ -5,7 +5,7 @@
*/
#include "cache.h"
-void safe_create_dir(char *dir)
+void safe_create_dir(const char *dir)
{
if (mkdir(dir, 0755) < 0) {
if (errno != EEXIST) {
@@ -23,7 +23,8 @@
*/
int main(int argc, char **argv)
{
- char *sha1_dir, *path;
+ const char *sha1_dir;
+ char *path;
int len, i;
safe_create_dir(".git");
Index: read-tree.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/read-tree.c (mode:100644
sha1:7c938491ad358582c610edac4a36a03868f8631d)
+++ uncommitted/read-tree.c (mode:100664)
@@ -221,7 +221,7 @@
}
}
-static char *read_tree_usage = "read-tree (<sha> | -m <sha1> [<sha2> <sha3>])";
+static const char *read_tree_usage = "read-tree (<sha> | -m <sha1>
[<sha2> <sha3>])";
int main(int argc, char **argv)
{
Index: sha1_file.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/sha1_file.c (mode:100644
sha1:f356acc9e6ce705fdfb947a5f36bba66fd9cd797)
+++ uncommitted/sha1_file.c (mode:100664)
@@ -61,7 +61,7 @@
static char *name, *base;
if (!base) {
- char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? :
DEFAULT_DB_ENVIRONMENT;
+ const char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? :
DEFAULT_DB_ENVIRONMENT;
int len = strlen(sha1_file_directory);
base = malloc(len + 60);
memcpy(base, sha1_file_directory, len);
Index: show-diff.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/show-diff.c (mode:100644
sha1:da364e26e28823f951a6be1b686a458575f28ea1)
+++ uncommitted/show-diff.c (mode:100664)
@@ -5,10 +5,10 @@
*/
#include "cache.h"
-static char *diff_cmd = "diff -L 'a/%s' -L 'b/%s' ";
-static char *diff_opts = "-p -u";
-static char *diff_arg_forward = " - '%s'";
-static char *diff_arg_reverse = " '%s' -";
+static const char *diff_cmd = "diff -L 'a/%s' -L 'b/%s' ";
+static const char *diff_opts = "-p -u";
+static const char *diff_arg_forward = " - '%s'";
+static const char *diff_arg_reverse = " '%s' -";
static void prepare_diff_cmd(void)
{
@@ -35,15 +35,16 @@
* a b ==> a b ==> 'a b'
* a'b ==> a'\''b ==> 'a'\''b'
*/
-static char *sq_expand(char *src)
+static char *sq_expand(const char *src)
{
static char *buf = NULL;
int cnt, c;
char *cp;
+ const char *sp;
/* count bytes needed to store the quoted string. */
- for (cnt = 1, cp = src; *cp; cnt++, cp++)
- if (*cp == '\'')
+ for (cnt = 1, sp = src; *sp; cnt++, sp++)
+ if (*sp == '\'')
cnt += 3;
if (! (buf = malloc(cnt)))
@@ -61,13 +62,13 @@
return buf;
}
-static void show_differences(char *name, char *label, void *old_contents,
+static void show_differences(const char *name, char *label, void *old_contents,
unsigned long long old_size, int reverse)
{
FILE *f;
char *name_sq = sq_expand(name);
char *label_sq = (name != label) ? sq_expand(label) : name_sq;
- char *diff_arg = reverse ? diff_arg_reverse : diff_arg_forward;
+ const char *diff_arg = reverse ? diff_arg_reverse : diff_arg_forward;
int cmd_size = strlen(name_sq) + strlen(label_sq) * 2 +
strlen(diff_cmd) + strlen(diff_opts) + strlen(diff_arg);
char *cmd = malloc(cmd_size);
Index: update-cache.c
===================================================================
--- 9f6f9ee7ad29cafe4265eae5050ce712b00bfce0/update-cache.c
(mode:100644 sha1:9ad4ae278703ee621b723afc65f3a51038e30f52)
+++ uncommitted/update-cache.c (mode:100664)
@@ -25,9 +25,11 @@
void *in;
SHA_CTX c;
- in = "";
if (size)
in = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+ else
+ in = (void *)"";
+
close(fd);
if (!out || (int)(long)in == -1)
return -1;
^ permalink raw reply
* [FYI] Cogito rsync/download location moved
From: Petr Baudis @ 2005-04-22 18:00 UTC (permalink / raw)
To: git
Hello,
I'm happy to announce that the Cogito rsync location changed to
rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
Please update your .git/remotes accordingly.
Also please note that the Cogito download location changed too. From
now on, Cogito releases will appear at
http://www.kernel.org/pub/software/scm/cogito
or
ftp://ftp.kernel.org/pub/software/scm/cogito
Please update your bookmarks, if you have any.
This will hopefully make me fit to my bandwidth limit until the end of
the month, and should make things significantly faster for you. Thanks a
lot to the kernel.org folks who made it possible!
--
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] git-pasky debian dir
From: Joshua T. Corbin @ 2005-04-22 18:00 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050422161635.GA5324@shell0.pdx.osdl.net>
On 22 April 2005 12:16, Chris Wright <chrisw@osdl.org> wrote:
> This whole bit should be formalized.
Agreed, hence why I did it as a package-build-time patch instead of changing
directly in my repository.
> Ideally, I'd like to do /usr/bin/git frontend, with all scripts
> in /usr/libexec/git/.
How standard is this '/usr/libexec'? I have no such directory on my Debian
boxes. If /usr/share rubs you the wroung way, what of
simply /usr/lib/git-pasky?
> However, this requires something more than hardcoding paths.
Definately, and it may not play well with the simpler method of installing to
$HOME/bin. This was just a quick hack as not to pollute /usr/bin with files
that aren't directly executed by the user.
> You get the idea ;-) I certainly see how it makes sense for a first
> run to get it going. But this will need fixing upstream.
This will all be moot when cogito goes the way of cg-* ;-)
Cheers,
Josh
--
Regards,
Joshua T. Corbin <jcorbin@wunjo.org>
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-22 17:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Schlemmer, GIT Mailing Lists
In-Reply-To: <20050422171818.GE7173@pasky.ji.cz>
On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Meaning, if they use a ',' in one of the fields (and it is a linux
> > system with the chfn most probably from the shadow package), then they
> > are looking for trouble. The only reason I added the ';' was because
> > somebody said whatever OS used it instead of a ','.
>
> What about just swapping the two tests so that ; is cut off and , only
> when no ; is around?
Even nicer. I like it. Very clean!
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: (anal) Q: Are there any coding styles or development guidelines?
From: Linus Torvalds @ 2005-04-22 17:50 UTC (permalink / raw)
To: Klaus Robert Suetterlin; +Cc: Git Mailing List
In-Reply-To: <20050422155845.GC52771@xdt04.mpe-garching.mpg.de>
On Fri, 22 Apr 2005, Klaus Robert Suetterlin wrote:
>
> I'm currently doing a source audit of the git core components.
> Mainly I want to check if I can spot some left over memory leaks.
>
> Unfortunately ;) I didn't find any so far (after reading five files).
>
> Still I did find quite a lot of stuff that lint would most likely
> complain about. Like not checking return values. Should this be
> fixed now or isn't it time to do the cleanup, yet?
I personally don't think we're quite there yet. You'll note that a lot of
routines just call "die()" when they don't find the data they want etc.
All things that we probably will need to clean up eventually, but is fine
for now.
> I also found several literal copies of the same function including
> function name, parameter list, etc. Wouldn't it be better do clean
> those up and put them in a utility.{c,h} file?
Yes, we can start doing things like that, especially if they really _do_
end up making sense in a bigger picture.
Some of that is because I didn't clean up the Makefile until fairly
recently, so it used to be harder than it is now to have a shared object
file. In contrast, now you just add it to the list of library objects, and
off you go.
> A similar problem
> is the continous reimplementation of linked lists, dynamic memory,
> smart strings / vectors, etc.
Sometimes specific duplication is just _easier_ than trying to be clever
and having some generic shared version. For example, there's a few
data-specific versions of "insert into sorted array" there, and the fact
is, they are so simple that it's likely less work to keep them that way
than it would be to create some "generic" thing that did it and was passed
in some descriptor of the data.
Generic routines aren't always good. Sometimes the abstraction ends up
adding more of a mental burden than just doing the thing in a simple way
in the first place.
> And then there are some stale files (i.e. revision.*) that the Changelog
> already mentions as removed, but which are still active in HEAD.
They definitely are _not_ active in HEAD, at least not in my version.
You may have stale copies in your directory, but they should show up as
being stale when you do "show-files --others".
Linus
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-22 17:43 UTC (permalink / raw)
To: azarah; +Cc: GIT Mailing Lists
In-Reply-To: <1114189105.29271.36.camel@nosferatu.lan>
On Fri, 2005-04-22 at 18:58 +0200, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 09:16 -0700, Kyle Hayes wrote:
> > Suppose that the GECOS field is:
> >
> > Hayes, Kyle; Room 42; 424-424-4242; foo bar baz...
> >
> > You'll search for the first comma, find it, truncate my name to "Hayes",
> > and continue.
> >
> > I have seen this kind of GECOS in larger environments where the
> > individual users are not the ones that administrate their machines.
> > Using the LastName, FirstName style of name is not rare.
> >
>
> What OS? With Linux at least, this is what chfn's manpage say:
Can't remember, it's been a while (years). We had AIX, Solaris, Linux
and BSD machines at the time. Might have been AIX, I think. The memory
of which OS is vague, but not the annoyance of finding the problem :-(
> ----
> The only restriction placed on the contents of the fields is that no control characters may be present,
> nor any of comma, colon, or equal sign. The other field does not have this restriction, and is used to
> store accounting information used by other applications.
> ----
>
> Meaning, if they use a ',' in one of the fields (and it is a linux
> system with the chfn most probably from the shadow package), then they
> are looking for trouble. The only reason I added the ';' was because
> somebody said whatever OS used it instead of a ','.
>From the AIX version of chfn:
----
You can use any printable characters in the gecos information string
except a : (colon), which is an attribute delimiter.
----
The AIX examples show use of semicolon as a separator.
So, at least on AIX, it is appears valid to use the style I showed
above. I don't have access to Solaris machines right now. The BSD
(FreeBSD 4.11) version of man 5 passwd:
----
The gecos field normally contains comma (`,') separated subfields as
follows:...
----
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Edésio Costa e Silva @ 2005-04-22 17:39 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.58.0504220844390.2344@ppc970.osdl.org>
On 4/22/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 21 Apr 2005, Tomas Mraz wrote:
> >
> > However you're right that the original structure proposed by Linus is
> > too flat.
>
> You're wrong.
>
> The thing is, having 256 sybdirectories already eats one _megabyte_ of
> diskspace on common filessystems. If you expand that to be either deeper
> (ie subdirectories within subdirectories), or use more than 8 bits for the
> first level, you'll be using much more.
>
> A megabyte of diskspace is peanuts for a project like Linux, but I think
> it matters for small projects. I want git to work reasonably even for
> really trivial stuff.
>
> For example, if you just expand the fan-out to use 12 bits instead of 8,
> you're now using 16MB of diskspace just for the directory structure, even
> for a trivially small project. I just think that sucks.
What if the directory structure is sparse?
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 17:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: kyle, GIT Mailing Lists
In-Reply-To: <20050422171818.GE7173@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Fri, 2005-04-22 at 19:18 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Meaning, if they use a ',' in one of the fields (and it is a linux
> > system with the chfn most probably from the shadow package), then they
> > are looking for trouble. The only reason I added the ';' was because
> > somebody said whatever OS used it instead of a ','.
>
> What about just swapping the two tests so that ; is cut off and , only
> when no ; is around?
>
Actually, maybe just leave it. Its not a train smash, and in theory on
linux ';' is a valid char in the gecos.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Petr Baudis @ 2005-04-22 17:18 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: kyle, GIT Mailing Lists
In-Reply-To: <1114189105.29271.36.camel@nosferatu.lan>
Dear diary, on Fri, Apr 22, 2005 at 06:58:25PM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Meaning, if they use a ',' in one of the fields (and it is a linux
> system with the chfn most probably from the shadow package), then they
> are looking for trouble. The only reason I added the ';' was because
> somebody said whatever OS used it instead of a ','.
What about just swapping the two tests so that ; is cut off and , only
when no ; is around?
--
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: [git-pasky] updating tree and source files
From: Petr Baudis @ 2005-04-22 17:16 UTC (permalink / raw)
To: Rhys Hardwick; +Cc: git
In-Reply-To: <200504221750.24188.rhys@rhyshardwick.co.uk>
Dear diary, on Fri, Apr 22, 2005 at 06:50:23PM CEST, I got a letter
where Rhys Hardwick <rhys@rhyshardwick.co.uk> told me that...
> Hi
Hello,
> I have been looking through the scripts, but cannot find out whether when
> running: git pull, checkout-cache will be run if the tree is different.
>
> My main question is, if there is a new version on the git server, and i do a
> git pull, will this update the source files. Do I have to carry out some
> more commands in order for this to happen?
>
> Sorry if this is a really newb question, but hopefully I should catch up soon!
git pull will update your working tree if your working tree branch is
tracking the pulled remote branch. If you do just 'git pull', this is
always the case.
--
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] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 16:58 UTC (permalink / raw)
To: kyle; +Cc: GIT Mailing Lists
In-Reply-To: <1114186599.31076.409.camel@axer.marchex.com>
[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]
On Fri, 2005-04-22 at 09:16 -0700, Kyle Hayes wrote:
> On Fri, 2005-04-22 at 16:23 +0200, Martin Schlemmer wrote:
> > Hi,
> >
> > This still applies - any reason for not doing this?
>
> Seems like this will break on certain kinds of data. See below.
>
> > if (!pw)
> > die("You don't exist. Go away!");
> > realgecos = pw->pw_gecos;
> > + /* The name is seperated from the room no., tel no, etc via [,;] */
> > + if (strchr(realgecos, ','))
> > + *strchr(realgecos, ',') = 0;
> > + else if (strchr(realgecos, ';'))
> > + *strchr(realgecos, ';') = 0;
> > len = strlen(pw->pw_name);
> > memcpy(realemail, pw->pw_name, len);
> > realemail[len] = '@';
>
> Suppose that the GECOS field is:
>
> Hayes, Kyle; Room 42; 424-424-4242; foo bar baz...
>
> You'll search for the first comma, find it, truncate my name to "Hayes",
> and continue.
>
> I have seen this kind of GECOS in larger environments where the
> individual users are not the ones that administrate their machines.
> Using the LastName, FirstName style of name is not rare.
>
What OS? With Linux at least, this is what chfn's manpage say:
----
The only restriction placed on the contents of the fields is that no control characters may be present,
nor any of comma, colon, or equal sign. The other field does not have this restriction, and is used to
store accounting information used by other applications.
----
Meaning, if they use a ',' in one of the fields (and it is a linux
system with the chfn most probably from the shadow package), then they
are looking for trouble. The only reason I added the ';' was because
somebody said whatever OS used it instead of a ','.
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [git-pasky] updating tree and source files
From: Rhys Hardwick @ 2005-04-22 16:50 UTC (permalink / raw)
To: git
Hi
I have been looking through the scripts, but cannot find out whether when
running: git pull, checkout-cache will be run if the tree is different.
My main question is, if there is a new version on the git server, and i do a
git pull, will this update the source files. Do I have to carry out some
more commands in order for this to happen?
Sorry if this is a really newb question, but hopefully I should catch up soon!
Rhys
^ permalink raw reply
* Re: [PATCH] git-pasky: Add .gitrc directory to allow command defaults like with .cvsrc
From: Petr Baudis @ 2005-04-22 16:38 UTC (permalink / raw)
To: Fabian Franz; +Cc: git
In-Reply-To: <200504221828.51752.FabianFranz@gmx.de>
Dear diary, on Fri, Apr 22, 2005 at 06:28:48PM CEST, I got a letter
where Fabian Franz <FabianFranz@gmx.de> told me that...
> Hi,
Hello,
> PS: Should the commandline parsing be cleaned up or do you want to do that
> after first release of cogito? And if yes, do you want to use "getopts" or
> would this be not supported on some systems?
I want to go for Perl in the longer term.
> PPS: I'm fairly new to git, how do I create a diff with the signed-by fields
> and with what do I need to sign it?
Put
Signed-off-by: Fabian Franz <FabianFranz@gmx.de>
in front of your patch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH] git-pasky: Add .gitrc directory to allow command defaults like with .cvsrc
From: Fabian Franz @ 2005-04-22 16:28 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
one thing I liked about CVS was its way to configure default parameters for
commands.
And as I really like the colored log output, I wanted it as default.
While .cvsrc parsing would be quite expensive, using a directory + files
should be fairly cheap and result just in one additional stat-call.
So I added "-c" to ~/.gitrc/log and some code to parse this.
Index: git
===================================================================
- --- 0a9ee5a4d947b998a7ce489242800b39f98eeee5/git (mode:100755
sha1:39969debd59ed51c57973c819cdcc3ca8a7da819)
+++ uncommitted/git (mode:100755)
@@ -67,6 +67,7 @@
exit 1
fi
+[ -e "$HOME/.gitrc/$cmd" ] && set -- $(cat "$HOME/.gitrc/$cmd") "$@"
case "$cmd" in
"add") gitadd.sh "$@";;
cu
Fabian
PS: Should the commandline parsing be cleaned up or do you want to do that
after first release of cogito? And if yes, do you want to use "getopts" or
would this be not supported on some systems?
PPS: I'm fairly new to git, how do I create a diff with the signed-by fields
and with what do I need to sign it?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCaSZDI0lSH7CXz7MRAoq8AJwM2lxPfl0ej32WU7q6bh6WIq5+EACgghGn
mvJzbvg6/bxWLFKfsP1ZEeI=
=03wm
-----END PGP SIGNATURE-----
^ 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