Re: updating the git documentation on http://www.kernel.org/pub/software/scm/git/docs/
Junio C Hamano wrote: Thomas Glanzmann [EMAIL PROTECTED] writes: I hope you're the right contact person for this. Could you please update the documentation on http://www.kernel.org/pub/software/scm/git/docs/ . It is a bit outdated. I just wanted to send a co-worker a link to the 'migration from cvs' URL and couldn't find one. Thomas, I suspect you have a wrong David, and would want to ask David Greaves instead. quite right. I've dropped out somewhat since moving house/job. I'll fix it. David -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wit suggestion
Hi Christian Can I suggest a 'summary diff' option It's basically a diff between the tree of the commit and the tree of the parent commit It would show what files have changed rather than the diff of the files that have changed. (kinda like diffstat without the for now) (or maybe just do a diffstat if it's easier) Of course you could click through to a per-file diff eventually... David -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add help details to git help command. (This time with Perl)
We've decided to go for the individual scripts directly. :-) Just to clarify - individual scripts or $0 name handling? I kinda like one big script - also means we don't need to 'install' it to get access to Cogito.pm... Unfortunately, you didn't send the attachments inline, so I can't comment on them sensibly. I'm not sure what you want here; last time you said: Thanks. Could you please send the patches signed off and either with content-disposition: inline or in the mail body? So I dug around Thunderbird's config and, this time, from my email on the git list: --050206040606040908050407 Content-Type: application/x-perl; name=gitadd.pl Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=gitadd.pl Perhaps my main problem is now style. I'd prefer you do format it alike the C sources of git, with 8-chars indentation and such. Also make sure you use spaces around (or after) operators. Also, for just few short functions I prefer putting the functions before the code itself. will do David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve usage messages
Petr Baudis wrote: Dear diary, on Thu, Apr 21, 2005 at 02:41:52PM CEST, I got a letter where Matthias Urlichs [EMAIL PROTECTED] told me that... This patch adds somewhat-improved usage messages to some of Linus' programs. Specifically, they now handle -? / --help. just so you know, the intention of doing the README.reference was to get all the docs in one place and then go back to the c and update the usage() to be consistent. I started by doing grep usage *.c :) I'm actually working on diff-cache as we speak... David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Some documentation...
Hi I'm starting to write some docs... Comments... even yep, looks OK, carry on :) I plan on putting the 'git command' ones into the 'git help ...' structure once Petr accepts it. I guess the low level ones go into a README.reference until they stabilise and become man pages... In doing this I noticed a couple of points: * update-cache won't accept ./file or fred/./file * checkout-cache doesn't seem to preserve mode Are these bugs or should they be documented? I've taken the approach of documenting behaviour for now. Signed-off-by: David Greaves [EMAIL PROTECTED] --- Index: README.reference === --- /dev/null (tree:cf6a46a2199777c3dac32fa4479b97c0752cdf07) +++ 30de093673d44c7ea8c56a0194fb792e47225ac8/README.reference (mode:100644 sha1:2ec6683b22e5672ea46d27770fcb1a4b4c37aa0e) @@ -0,0 +1,158 @@ +Terminology: - see README for description +Each line contains terms used interchangeably + +object database, .git directory +directory cache, index +id, sha1, sha1-id, sha1 hash +type, tag, tagname +blob, blob object +tree, tree object +commit, commit object +parent +root object +changeset + + +cat-file + cat-file -t | tagname sha1 + +Provide contents or type of objects in the repository. The tagname is +required if it is not being interrogated. + + +sha1 + The sha1 identifier of the object. + (This is the sha1 of the uncompressed content.) + +-t + show the object type identified by sha1 + One of: blob/tree/commit + +tagname + One of: blob/tree/commit + + + +check-files + check-files file... + +Check that a list of files are up-to-date between the filesystem and +the cache. Used to verify a patch target before doing a patch. + +Files that do not exist on the filesystem are considered up-to-date +(whether or not they are in the cache). + +Emits an error message on failure. + +exits with a status code indicating success if all files are +up-to-date. + + +see also: update-cache + + + +checkout-cache + checkout-cache [-q] [-a] [-f] [--] file... + +Will copy all files listed from the cache to the working directory +(not overwriting existing files). Note that the file contents are +restored - NOT the file permissions. + +-q + be quiet if files exist or are not in the cache + +-f + forces overwrite of existing files + +-a + checks out all files in the cache before processing listed + files. + +Note that the order of the flags matters: + + checkout-cache -a -f file.c + +will first check out all files listed in the cache (but not overwrite +any old ones), and then force-checkout file.c a second time (ie that +one _will_ overwrite any old contents with the same filename). + +Also, just doing checkout-cache does nothing. You probably meant +checkout-cache -a. And if you want to force it, you want +checkout-cache -f -a. + +Intuitiveness is not the goal here. Repeatability is. The reason for +the no arguments means no work thing is that from scripts you are +supposed to be able to do things like + + find . -name '*.h' -print0 | xargs -0 checkout-cache -f -- + +which will force all existing *.h files to be replaced with their +cached copies. If an empty command line implied all, then this would +force-refresh everything in the cache, which was not the point. + +Oh, and the -- is just a good idea when you know the rest will be +filenames. Just so that you wouldn't have a filename of -a causing +problems (not possible in the above example, but get used to it in +scripting!). + + + +commit-id + commit-id [tag] + +Returns the sha1-id of the commit object associated with given tag. + +tag + tag of commit object - defaults to the current HEAD. + + + +commit-tree + commit-tree sha1 [-p sha1]* changelog + + + +diff-tree + diff-tree [-r] [-z] tree sha1 tree sha1 + + + +ls-tree + ls-tree [-r] [-z] key + + + +merge-base + merge-base commit-id commit-id + + + +merge-cache + merge-cache merge-program (-a | filename*) + + + +read-tree + read-tree [-m] sha1 + + + +rev-tree + rev-tree [--edges] [--cache cache-file] commit-id [commit-id] + + + +show-diff + show-diff [-q] [-s] [-z] [paths...] + + + +show-files + show-files [-z] [-t] (--[cached|deleted|others
Re: [PATCH] Some documentation...
C. Scott Ananian wrote: On Wed, 20 Apr 2005, David Greaves wrote: In doing this I noticed a couple of points: * update-cache won't accept ./file or fred/./file The comment in update-cache.c reads: /* * We fundamentally don't like some paths: we don't want * dot or dot-dot anywhere, and in fact, we don't even want * any other dot-files (.git or anything else). They * are hidden, for chist sake. * * Also, we don't want double slashes or slashes at the * end that can make pathnames ambiguous. */ It could be argued that './' is a special case... but at the moment this is definitely a designed 'feature' not a 'bug'. Indeed - I've been reading the code to document it as correctly as possible. But I actually found this by running: find . -type f | xargs git add for a new project - so I'd class it as user unfriendly... Yes, I know how to get round it :) I have ensured that my next perl version of gitadd.pl (that I submitted to Petr) doesn't allow these files to be added - and it could even cleanse leading ./ and any /./ constructs. So maybe it's left as documented behaviour and higher level tools must manage the data they feed to it... I hope it's useful to raise these niggles now before changing them is too hard. David -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git hangs while executing commit-tree
Linus Torvalds wrote: On Wed, 20 Apr 2005, Rhys Hardwick wrote: [EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree c80156fafbac377ab35beb076090c8320f874f91 Committing initial tree c80156fafbac377ab35beb076090c8320f874f91 At this point, the command seems to be just waiting. That's _exactly_ what it's doing. It's waiting for you to write a commit message. Something like This is my initial commit of Hello World! ^D will make it happy. Alternatively, you can certainly just write your message beforehand with an editor and just pipe it into commit-tree. Linus When someone commits the docs I'll submit the next patch for the README: commit-tree 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 comment is read from stdin (max 999 chars) A commit object usually has 1 parent (a commit after a change) or 2 parents (a merge) although there is no reason it cannot have more than 2 parents. 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 CRs are stripped) see also: write-tree David -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
David A. Wheeler wrote: I propose changing pull to ONLY download, and update to pull AND merge. Why? It seems oddly inconsistent that pull sometimes merges in changes, but at other times it doesn't. true I propose that there be two subcommands, pull and update (now that update isn't a reserved word again). A git pull ONLY downloads; a git update pulls AND merges. What's the most common thing to do? pull or update? which is easier to type? what are people used to? I'm not sure but I suggest that pull and get would be better choices. git pull git get is it rare enough to justify: git --download-only pull David -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)
Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... Here is perhaps a better way to provide detailed help for each git command. A command.help file for each command can be written in the style of a man page. I don't like it. I think the 'help' command should serve primarily as a quick reference, which does not blend so well with a manual page - it's too long and too convoluted by repeated output. I'd just print the top comment from each file. :-) On the other hand, having more complete docs seems like an excellent idea (and other threads support that) I'd certainly like to see more specification oriented documentation... (even if it turns out to be disposable) Steven, if you carry on sending more verbose docs I'll certainly read and work with you on editing them... Nb kernel-doc doesn't seem appropriate for user level docs. maybe, whilst there's so much flux, have: git man command that just outputs text If Petr wants the top comment to be extracted by help then maybe a bottom comment block could contain the more complete text? I *really* think that the user docs should live in the source for now (hence I think that git man is better than going straight to man/docbook). I wasn't sure whether to perlise the code or do a shell-lib - but looking at the algorithms needed in things like git status I reckon the shell will end up becoming a hackish mess of awk/sed/tr/sort/uniq/pipe (ie perl) anyway. So I'm going to have a go at that - Petr, if you have a minute could you send me, off list, a bit of perl code that epitomises the style you like? David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add help details to git help command. (This time with Perl)
Steven Cole wrote: Speaking of I think, the name cogito was suggested for the SCM layer, but IIRC Linus suggested staying with just plain git. Petr suggested tig, perhaps because it looks at git from another point of view. I haven't read _all_ the mails - I thought cogito was kinda selected and I got the feeling that Linus wasn't exactly bothered what it was called. Anyway, git has a rename that needs testing at some point... legitSince git is GPLv2, but perhaps a little too French. That made me smile. Quite a few entendres in there... It's Petr's baby - he gets to name it. David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
First git-pasky bug report? :) error: bad signature/verify header failed
Hi I'm just starting to look at git (and cogito). Earlier this morning I got and built http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2 I then did a git pull pasky and a make. All went well. A couple of hours later I did another git pull pasky and had the problem shown below. I moved the directory to one side and reissued the commands and all was well: 723 tar xvfj git-pasky-base.tar.bz2 724 cd git-pasky-0.4/ 725 make 726 git pull pasky 727 make 728 git pull pasky 729 history | tail -10 This is just a heads up in case there's anything useful here. It may just have been locking issues and me pulling whilst the repo was being updated or something... I'll hold the bad directory for a day or two in case anyone wants any diagnostics running. David [EMAIL PROTECTED]:/everything/devel/git/git-pasky-0.4$ git pull pasky MOTD: Welcome to Petr Baudis' rsync archive. MOTD: MOTD: If you are pulling my git branch, please do not repeat that MOTD: every five minutes or so - new stuff is likely not going to MOTD: appear so fast, and my line is not that thick. Nothing wrong MOTD: with pulling every half an hour or so, of course. MOTD: MOTD: Feel free to contact me at [EMAIL PROTECTED], shall you have MOTD: any questions or suggestions. Tree change: c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a *100644-100644 blob 222bce21788308e1bf567304b474225b1681b03b-ad44415110ab63f1daa93e07dc496193d8006d81 Makefile *100755-100755 blob 667f877ae836c418294ef085e91efcb48d30cabb-035a1f470003c8b0963d0eb5f0eb457155f415ad git *100755-100755 blob fadd17e52845c5656ba344a9413b29b641c9ff5f-67e97fb71094693929f56d74bc13e572420d99d4 gitcommit.sh *100755-100755 blob 7ea441e584d603463fb1b83991b88f63a3895cff-18478101980f630f0e9fd95365c6d9f46bf27bfd gitmerge.sh *100755-100755 blob 9bda6555a1dafc1db762bc46db60d2a9485dc523-8e016f7d3aeb0244c8a6524ddaa4b2cb1ff8015f gitpull.sh +100755 blobb6e318b31eb2ed6d2e137833a2064327331504b4gitseek.sh *100755-100755 blob 30654380c10edde32def8e5fa2e2c956fbff3d58-ce44c1d4ce3b949b8ac99f1b90927da4e698e3de gittrack.sh -100755 blob2488078570c4a5709332d92d7a1b5b65036ff3a0gitupdate.sh Tracked branch, applying changes... error: bad signature error: verify header failed read_cache: Invalid argument error: bad signature error: verify header failed error: bad signature error: verify header failed At this point I moved the directory aside... -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add + Status patches
Junio C Hamano wrote: DG It allows: DG find src -type f | git add - I am slow today, but have you considered using xargs? yep thanks :) I know you _could_ do it with xargs - but you _could_ use the raw git commands too. This is a be nice to the user layer and I was 'surprised' that neither git add . nor git add -r . worked. That meant that I had to fix it so I started with the ability to handle a list and, since I got a friendly response, I can hopefully move on to help make git nicer to use for mere mortals. David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
