Re: Why is there no git-update-cache --modified (aka I give up)
On Tue, Jul 12, 2005 at 01:14:24AM -0700, Junio C Hamano wrote: Marc Singer [EMAIL PROTECTED] writes: # git-diff-cache HEAD is really nice. But, do I really have to invoke git-update-cache with every modified file? I could write a script to cul the filenames from git-diff-cache, but I'm having a hard time believing that that is how others are preparing their commits. Me too. By the way, I think you mean diff-files not diff-cache. No, I mean git-diff-cache. I find that this works pretty well, though. # git-update-cache `git-diff-cache | cut -f2` It looks like the same thing works for git-diff-files. # git-update-cache `git-diff-files | cut -f2` This seems to agree with the way you handle things. Similarly, there is the need to determine which files are new to the tree. This isn't much of a burden when creating files in the tree, but can be bothersome when using patch since git-apply is conservative about fuzz. - 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: Compilation troubles
On Tue, Jul 12, 2005 at 11:33:36AM -0700, Dan Kohn wrote: I apologize for what are probably obvious compilation questions, but I suspect other newbies are encountering them as well. I'm having trouble installing cogito 0.12.1 on both a vanilla Ubuntu box and on my account on a FreeBSD machine. I'm used to autoconf-built programs, so there's probably just some simple library path I'm not setting up right. But I'd appreciate your suggestions, and perhaps we can add the answer to the INSTALL file. UBUNTU 5.04 I used synaptics to install openssl, zlib, and curl, but cogito can't seem to see them. Perhaps you need the openssl-dev and zlib-dev packages. Just a guess since I don't know ubuntu. [EMAIL PROTECTED]:/usr/local/src/cogito-0.12.1 # make cc -g -O2 -Wall '-DSHA1_HEADER=openssl/sha.h' -c -o read-cache.o read-cache.c In file included from read-cache.c:6: cache.h:21:21: openssl/sha.h: No such file or directory cache.h:22:18: zlib.h: No such file or directory In file included from read-cache.c:6: cache.h:169: error: syntax error before '*' token read-cache.c: In function `verify_hdr': read-cache.c:339: error: `SHA_CTX' undeclared (first use in this function) read-cache.c:339: error: (Each undeclared identifier is reported only once read-cache.c:339: error: for each function it appears in.) read-cache.c:339: error: syntax error before c read-cache.c:346: warning: implicit declaration of function `SHA1_Init' read-cache.c:346: error: `c' undeclared (first use in this function) read-cache.c:347: warning: implicit declaration of function `SHA1_Update' read-cache.c:348: warning: implicit declaration of function `SHA1_Final' read-cache.c: At top level: read-cache.c:408: error: syntax error before '*' token read-cache.c: In function `ce_write': read-cache.c:410: error: `len' undeclared (first use in this function) read-cache.c:415: error: `data' undeclared (first use in this function) read-cache.c:418: error: `context' undeclared (first use in this function) read-cache.c:419: error: `fd' undeclared (first use in this function) read-cache.c: At top level: read-cache.c:430: error: syntax error before '*' token read-cache.c: In function `ce_flush': read-cache.c:436: error: `context' undeclared (first use in this function) read-cache.c:442: error: `fd' undeclared (first use in this function) read-cache.c: In function `write_cache': read-cache.c:449: error: `SHA_CTX' undeclared (first use in this function) read-cache.c:449: error: syntax error before c read-cache.c:461: error: `c' undeclared (first use in this function) make: *** [read-cache.o] Error 1 [EMAIL PROTECTED]:/usr/local/src/cogito-0.12.1 # locate openssl /etc/ssl/openssl.cnf [long list of python and docs elided] /usr/share/man/man1/openssl.1ssl.gz /usr/bin/openssl /usr/bin/openssl_fips_fingerprint /usr/lib/libgnutls-openssl.so.11.1.16 /usr/lib/libgnutls-openssl.so.11 /usr/lib/ssl/openssl.cnf /usr/local/ssl/man/man1/openssl.1 /usr/local/ssl/bin/openssl /usr/local/ssl/lib/pkgconfig/openssl.pc /usr/local/ssl/include/openssl /usr/local/ssl/include/openssl/e_os2.h /usr/local/ssl/include/openssl/crypto.h /usr/local/ssl/include/openssl/tmdiff.h /usr/local/ssl/include/openssl/opensslv.h /usr/local/ssl/include/openssl/opensslconf.h /usr/local/ssl/include/openssl/ebcdic.h /usr/local/ssl/include/openssl/symhacks.h /usr/local/ssl/include/openssl/ossl_typ.h /usr/local/ssl/include/openssl/objects.h /usr/local/ssl/include/openssl/obj_mac.h /usr/local/ssl/include/openssl/md2.h /usr/local/ssl/include/openssl/md4.h /usr/local/ssl/include/openssl/md5.h /usr/local/ssl/include/openssl/sha.h /usr/local/ssl/include/openssl/hmac.h /usr/local/ssl/include/openssl/ripemd.h /usr/local/ssl/include/openssl/des.h /usr/local/ssl/include/openssl/des_old.h /usr/local/ssl/include/openssl/aes.h /usr/local/ssl/include/openssl/rc2.h /usr/local/ssl/include/openssl/rc4.h /usr/local/ssl/include/openssl/idea.h /usr/local/ssl/include/openssl/blowfish.h /usr/local/ssl/include/openssl/cast.h /usr/local/ssl/include/openssl/bn.h /usr/local/ssl/include/openssl/ec.h /usr/local/ssl/include/openssl/rsa.h /usr/local/ssl/include/openssl/dsa.h /usr/local/ssl/include/openssl/ecdsa.h /usr/local/ssl/include/openssl/dh.h /usr/local/ssl/include/openssl/ecdh.h /usr/local/ssl/include/openssl/dso.h /usr/local/ssl/include/openssl/engine.h /usr/local/ssl/include/openssl/buffer.h /usr/local/ssl/include/openssl/bio.h /usr/local/ssl/include/openssl/stack.h /usr/local/ssl/include/openssl/safestack.h /usr/local/ssl/include/openssl/lhash.h /usr/local/ssl/include/openssl/rand.h /usr/local/ssl/include/openssl/err.h /usr/local/ssl/include/openssl/evp.h /usr/local/ssl/include/openssl/asn1.h /usr/local/ssl/include/openssl/asn1_mac.h /usr/local/ssl/include/openssl/asn1t.h /usr/local/ssl/include/openssl/pem.h /usr/local/ssl/include/openssl/pem2.h /usr/local/ssl/include/openssl/x509.h
git clone rsync:... ?
[EMAIL PROTECTED] /git git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 defaulting to local storage area ssh: rsync: Name or service not known fatal: unexpected EOF I've read several messages that this is changing, but it still isn't clear where we should be starting. Moreover, I'd like to be able to keep one repo that is just pulling from the net and then clone it for different working directories. Why? Sometimes, in my ignorance, I break my working repo. It's handy to have one that I know is OK without pulling from the net each time. - 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: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 06:43:23PM -0700, Linus Torvalds wrote: On Mon, 11 Jul 2005, Linus Torvalds wrote: No, git-checkout-script _shouldn't_ have done that. It will do the read-tree on the tag (which will do the right thing), but it won't change the HEAD itself. In preparation of actually updating the HEAD, I just made git checkout verify that it only checks out a commit, not a tree tag or something like that. Too late for Marc, but next time around a git checkout v2.6.11 :-) will result in [EMAIL PROTECTED] linux]$ git checkout v2.6.11 error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Needed a single revision On the other hand, creating a new branch might be a but surprising to people: But I just wanted to check it out. But as far as I can see, it's the only safe thing to do, and it has the advantage that you can then go back to the old state with a simple git checkout master. But what about the branch name? Should we just ask the user? Together with a flag, like git checkout -b new-branch v2.6.12 for somebody who wants to specify the branch name? Or should we pick a random name and add a helper function to rename a branch later? Opinions? From my POV, what I want is a branch with the tag v2.6.12 as the basis of the branch. I'm guessing that -b means make me a branch and call it this. # git checkout -b BRANCH_NAME [TAG] If the TAG is omitted, the branch is made from the current HEAD or some other reasonable point defined by the current working directory. Are uncommitted changes present in the working directory maintained? Discarded? I wont't care since I'll never be doing that. At least, not on purpose. - 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: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 09:34:33PM -0700, Linus Torvalds wrote: On Mon, 11 Jul 2005, Linus Torvalds wrote: Of course, if you want to create a new branch my-branch and _not_ check it out, you could have done so with just git-rev-parse v2.6.12^0 .git/refs/heads/my-branch which I think I will codify as git branch. And now we have that git branch. It's a trivial one-liner, except with the setup and error checking it's actually more like six lines. Does it make sense to think about this branch as an flow of commits? Or is it just a starting point for a line of development? If I make a branch, check it out, commit changes to it, and then clobber the working directory, can I later resume that branch of development without creating a new branch? Do I need to set a tag to mark the last commit on that branch? - 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
How to get a directory filled with v2.6.11?
I switched to using the git version in source control. Checkout/branching works great. :-) But, this version of git doesn't let me do # git checkout -f v2.6.11 error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Needed a single revision which I suspect is protection added to prevent my special sort of shenanigans. If I cannot perform the checkout anymore, is there another way to fill a directory with the contents of that particular tree? What am I doing? I've got some updates against 2.6.11 orphaned in another develpment directory. I could just upack a tar.bz2 file for 2.6.11, but git is more clever. I want to perform a diff against the tagged v2.6.11 and my development tree. - 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
Bootstrapping into git, commit gripes at me
In working through a usage example on my way to producing bonafide patches, I've found that commit is complaining. Here's what I've done. o Fetched and built cogito-0.12 o Fetched (rsync) Linus' tree o Created a working directory, linux-2.6 o linked .git in the working directory to the .git directory fetched from the net. o # git checkout -f v2.6.11 o # cat ../old-patch-file | patch -p1 Then, according to Jeff's instructions, I have to perform get-update-cache with the name of each file I changed. Is that really the way? o # git-update-cache LIST_OF_CHANGED_FILES Now I commit. o # git commit I am presented with an editor session with the list of changed files already present. IfI add a comment and leave the editor, I'm told fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object If I don't edit the comment, it doesn't give an error but I don't think the changes are committed because I can invoke git commit again. Am I off track? Cheers. P.S. vger isn't letting me subscribe ATM. Please copy me with replies. - 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: Bootstrapping into git, commit gripes at me
$ git checkout -f v2.6.11 ;# fixed one warning: v2.6.11 is not a commit -- not updating your HEAD $ git commit ;# to have his own baseline at v2.6.11 $ git-apply --index --stat --summary --apply ../old-patch-file $ : do the usual tests $ git commit ;# create a commit based on the baseline v2.6.11 Interesting note. I tried the git-apply command and found that it complained and wouldn't succeed. [EMAIL PROTECTED] ~...embedded/linux-2.6 git-apply --index --stat --summary --apply ../ms16/ide.patch error: patch failed: drivers/ide/ide-io.c:129 error: drivers/ide/ide-io.c: patch does not apply Yet, patch does apply. [EMAIL PROTECTED] ~...embedded/linux-2.6 patch -p1 ../ms16/ide.patch patching file drivers/ide/arm/ide_arm.c patching file drivers/ide/arm/ide-lpd7952x.c patching file drivers/ide/arm/ide-lpd7a40x.c patching file drivers/ide/arm/Makefile patching file drivers/ide/ide-disk.c Hunk #1 succeeded at 282 (offset 41 lines). Hunk #2 succeeded at 294 (offset 41 lines). patching file drivers/ide/ide-io.c Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines). Hunk #2 succeeded at 1227 (offset 189 lines). Hunk #3 succeeded at 1388 (offset 189 lines). Hunk #4 succeeded at 1689 (offset 187 lines). patching file drivers/ide/ide-iops.c patching file drivers/ide/ide-probe.c Hunk #1 succeeded at 422 (offset 51 lines). Hunk #2 succeeded at 784 (offset 59 lines). Hunk #3 succeeded at 847 (offset 59 lines). Hunk #4 succeeded at 1112 (offset 64 lines). Hunk #5 succeeded at 1172 (offset 64 lines). patching file drivers/ide/Kconfig Hunk #1 succeeded at 272 (offset -1 lines). Hunk #2 succeeded at 781 (offset 5 lines). patching file drivers/ide/legacy/ht6560b.c patching file drivers/ide/legacy/qd65xx.c patching file drivers/ide/pci/ns87415.c patching file drivers/ide/pci/sl82c105.c patching file drivers/ide/pci/trm290.c patching file drivers/ide/ppc/pmac.c Hunk #1 succeeded at 572 (offset 61 lines). Hunk #2 succeeded at 596 (offset 61 lines). patching file include/linux/ide.h Hunk #1 succeeded at 961 (offset 1 line). Hunk #2 succeeded at 1497 (offset -14 lines). It should be obvious that a patch that doesn't apply cleanly, i.e. without rejects, is still useful to apply so that I can fix the places where it fails. o Why does patch work and git-apply fail? o Is there a way to force git to apply and safe the rejects? - 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: Bootstrapping into git, commit gripes at me
On Fri, Jul 08, 2005 at 06:08:52PM -0700, Junio C Hamano wrote: MS == Marc Singer [EMAIL PROTECTED] writes: MS Does this preclude symlinking .git? I'd like to keep one .git which MS is mirrored from the net and allow for more than one working MS directory. I think people typically do this by symlinking .git/objects, not .git/ itself. Presumably the reason you would want to have more than one working tree is so that you can keep more than one topic of development, one for each working tree, and make commits independently, right? Which commit is the latest in each work tree is, unsurprisingly, stored in .git/refs/heads/master file in each work tree, so usually you would _not_ want to share things other than .git/objects/ under .git/ directory across work trees. One major downside of this, which I was burned once myself (which is the reason for me to stop doing it), is that git-fsck-cache and git-prune-script would not know anything about the objects in the shared .git/objects reachable from other work trees, and can happily garbage collect objects necessary for other work trees. Hmm. Seems, then, that this precludes any sharing at all. It isn't so serious with git as it was wth BK. The latter being disk hungry. I gather that the approved solution is to have complete replicas of the git master from Linus for each line of development. - 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
Converting commits to patch files? HEAD vs HEAD^
Jeff Garzik's guide doesn't appear to explain how to get patches back out of the system. I've successfully commited a set of changes. # git diff HEAD^ HEAD This command will produce a diff of the changes I've made. What is the HEAD^? Does it refer to the commit before the last one made? If I've made several commits, I'd like to be able to gather several together and produce a patch file. Better still, I'd like to be able to pick a set of discontiguous commits an bundle them into a single patch. Ought I be using tags? Finally, given that the upstream repository is git, what is the way to push commits upstream? - 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
