[PATCH] remove special HPET_EMULATE_RTC config option
tree 3f19ec2917f15fdf2428b60941a4d5c9d7e0422d parent 1c5ad84516ae7ea4ec868436a910a6bd8d20215a author Venkatesh Pallipadi [EMAIL PROTECTED] Fri, 05 Aug 2005 05:36:10 -0700 committer Linus Torvalds [EMAIL PROTECTED] Fri, 05 Aug 2005 06:27:58 -0700 [PATCH] remove special HPET_EMULATE_RTC config option We had a user whose apps weren't working correctly because his rtc wasn't working fully. For the sake of simplicity, it seems sensible to always enable HPET RTC emulation. Remove a special config option for HPET_EMULATE_RTC and make it directly depend on HPET_TIMER and RTC. This will avoid the hangs when EMULATE_RTC is not configured and when some userlevel script depends on RTC interrupt, as in: http://bugzilla.kernel.org/show_bug.cgi?id=4904 Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] arch/i386/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -454,8 +454,9 @@ config HPET_TIMER Choose N to continue using the legacy 8254 timer. config HPET_EMULATE_RTC - bool Provide RTC interrupt + bool depends on HPET_TIMER RTC=y + default y config SMP bool Symmetric multi-processing support - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] md: yet another attempt to get bitmap-based resync to do the right thing in all cases...
tree f9b62479cd7062c65e54641cc6190975f529a08b
parent 193f1c931517592ec4188d15bf261e4bff368207
author NeilBrown [EMAIL PROTECTED] Fri, 05 Aug 2005 02:53:34 -0700
committer Linus Torvalds [EMAIL PROTECTED] Fri, 05 Aug 2005 03:00:54 -0700
[PATCH] md: yet another attempt to get bitmap-based resync to do the right
thing in all cases...
Firstly, R1BIO_Degraded was being set in a number of places in the resync
code, but is never used there, so get rid of those settings.
Then: When doing a resync, we want to clear the bit in the bitmap iff the
array will be non-degraded when the sync has completed. However the current
code would clear the bitmap if the array was non-degraded when the resync
*started*, which obviously isn't right (it is for 'resync' but not for
'recovery' - i.e. rebuilding a failed drive).
This patch calculated 'still_degraded' and uses the to tell bitmap_start_sync
whether this sync should clear the corresponding bit.
Signed-off-by: Neil Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
drivers/md/raid1.c | 29 +++--
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -893,7 +893,6 @@ static int end_sync_read(struct bio *bio
if (!uptodate) {
md_error(r1_bio-mddev,
conf-mirrors[r1_bio-read_disk].rdev);
- set_bit(R1BIO_Degraded, r1_bio-state);
} else
set_bit(R1BIO_Uptodate, r1_bio-state);
rdev_dec_pending(conf-mirrors[r1_bio-read_disk].rdev, conf-mddev);
@@ -918,10 +917,9 @@ static int end_sync_write(struct bio *bi
mirror = i;
break;
}
- if (!uptodate) {
+ if (!uptodate)
md_error(mddev, conf-mirrors[mirror].rdev);
- set_bit(R1BIO_Degraded, r1_bio-state);
- }
+
update_head_pos(mirror, r1_bio);
if (atomic_dec_and_test(r1_bio-remaining)) {
@@ -1109,6 +1107,7 @@ static sector_t sync_request(mddev_t *md
int i;
int write_targets = 0;
int sync_blocks;
+ int still_degraded = 0;
if (!conf-r1buf_pool)
{
@@ -1137,7 +1136,10 @@ static sector_t sync_request(mddev_t *md
return 0;
}
- if (!bitmap_start_sync(mddev-bitmap, sector_nr, sync_blocks,
mddev-degraded)
+ /* before building a request, check if we can skip these blocks..
+* This call the bitmap_start_sync doesn't actually record anything
+*/
+ if (!bitmap_start_sync(mddev-bitmap, sector_nr, sync_blocks, 1)
!conf-fullsync) {
/* We can skip this block, and probably several more */
*skipped = 1;
@@ -1203,24 +1205,23 @@ static sector_t sync_request(mddev_t *md
if (i == disk) {
bio-bi_rw = READ;
bio-bi_end_io = end_sync_read;
- } else if (conf-mirrors[i].rdev
- !conf-mirrors[i].rdev-faulty
- (!conf-mirrors[i].rdev-in_sync ||
- sector_nr + RESYNC_SECTORS mddev-recovery_cp)) {
+ } else if (conf-mirrors[i].rdev == NULL ||
+ conf-mirrors[i].rdev-faulty) {
+ still_degraded = 1;
+ continue;
+ } else if (!conf-mirrors[i].rdev-in_sync ||
+ sector_nr + RESYNC_SECTORS mddev-recovery_cp) {
bio-bi_rw = WRITE;
bio-bi_end_io = end_sync_write;
write_targets ++;
} else
+ /* no need to read or write here */
continue;
bio-bi_sector = sector_nr + conf-mirrors[i].rdev-data_offset;
bio-bi_bdev = conf-mirrors[i].rdev-bdev;
bio-bi_private = r1_bio;
}
- if (write_targets + 1 conf-raid_disks)
- /* array degraded, can't clear bitmap */
- set_bit(R1BIO_Degraded, r1_bio-state);
-
if (write_targets == 0) {
/* There is nowhere to write, so all non-sync
* drives must be failed - so we are finished
@@ -1243,7 +1244,7 @@ static sector_t sync_request(mddev_t *md
break;
if (sync_blocks == 0) {
if (!bitmap_start_sync(mddev-bitmap, sector_nr,
- sync_blocks, mddev-degraded)
+ sync_blocks, still_degraded)
!conf-fullsync)
break;
if (sync_blocks (PAGE_SIZE9))
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a
[PATCH] Update in-kernel zlib routines
tree c313006c1e59a41914a96c0c0b5b2b557736a0a9
parent 00a5dfdb93f74e4d95fb0d83c890728e331f8810
author Tim Yamin [EMAIL PROTECTED] Mon, 25 Jul 2005 23:16:13 +0100
committer Linus Torvalds [EMAIL PROTECTED] Sat, 06 Aug 2005 06:23:21 -0700
[PATCH] Update in-kernel zlib routines
These bugs have been fixed in the standard zlib for a while.
See for example
a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
b) http://bugs.gentoo.org/show_bug.cgi?id=94584
Signed-off-by: Tim Yamin [EMAIL PROTECTED]
Signed-off-by: Tavis Ormandy [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/ppc64/boot/zlib.c |3 ++-
lib/inflate.c | 16 +---
lib/zlib_inflate/inftrees.c |2 +-
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/ppc64/boot/zlib.c b/arch/ppc64/boot/zlib.c
--- a/arch/ppc64/boot/zlib.c
+++ b/arch/ppc64/boot/zlib.c
@@ -1307,7 +1307,7 @@ local int huft_build(
{
*t = (inflate_huft *)Z_NULL;
*m = 0;
-return Z_OK;
+return Z_DATA_ERROR;
}
@@ -1351,6 +1351,7 @@ local int huft_build(
if ((j = *p++) != 0)
v[x[j]++] = i;
} while (++i n);
+ n = x[g];/* set n to length of v */
/* Generate the Huffman codes and for each, make the table entries */
diff --git a/lib/inflate.c b/lib/inflate.c
--- a/lib/inflate.c
+++ b/lib/inflate.c
@@ -326,7 +326,7 @@ DEBG(huft1 );
{
*t = (struct huft *)NULL;
*m = 0;
-return 0;
+return 2;
}
DEBG(huft2 );
@@ -374,6 +374,7 @@ DEBG(huft5 );
if ((j = *p++) != 0)
v[x[j]++] = i;
} while (++i n);
+ n = x[g]; /* set n to length of v */
DEBG(h6 );
@@ -410,12 +411,13 @@ DEBG1(1 );
DEBG1(2 );
f -= a + 1; /* deduct codes from patterns left */
xp = c + k;
- while (++j z) /* try smaller tables up to z bits */
- {
-if ((f = 1) = *++xp)
- break;/* enough codes to use up j bits */
-f -= *xp; /* else deduct codes from patterns */
- }
+ if (j z)
+while (++j z) /* try smaller tables up to z bits */
+{
+ if ((f = 1) = *++xp)
+break;/* enough codes to use up j bits */
+ f -= *xp; /* else deduct codes from patterns */
+}
}
DEBG1(3 );
z = 1 j; /* table entries for j-bit table */
diff --git a/lib/zlib_inflate/inftrees.c b/lib/zlib_inflate/inftrees.c
--- a/lib/zlib_inflate/inftrees.c
+++ b/lib/zlib_inflate/inftrees.c
@@ -141,7 +141,7 @@ static int huft_build(
{
*t = NULL;
*m = 0;
-return Z_OK;
+return Z_DATA_ERROR;
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ppc32: fix ppc440 pagetable attributes
tree 7a10674e549b63257d9c95405f258480267efea8 parent 4aad724d3e52238e1ce005f166fbba5b4072a7f6 author Matt Porter [EMAIL PROTECTED] Sat, 06 Aug 2005 06:10:10 -0700 committer Linus Torvalds [EMAIL PROTECTED] Sat, 06 Aug 2005 06:53:03 -0700 [PATCH] ppc32: fix ppc440 pagetable attributes This patch fixes a bug in the PPC440 pagetable attributes that breaks swap support. It also adds some notes on the PPC440 attribute fields. Signed-off-by: Geoff Levand [EMAIL PROTECTED] for CELF Signed-off-by: Matt Porter [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] include/asm-ppc/pgtable.h | 52 +++--- 1 files changed, 49 insertions(+), 3 deletions(-) diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h --- a/include/asm-ppc/pgtable.h +++ b/include/asm-ppc/pgtable.h @@ -202,18 +202,64 @@ extern unsigned long ioremap_bot, iorema * * Note that these bits preclude future use of a page size * less than 4KB. + * + * + * PPC 440 core has following TLB attribute fields; + * + * TLB1: + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 + * RPN. - - - - - - ERPN... + * + * TLB2: + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 + * - - - - -- U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR + * + * There are some constrains and options, to decide mapping software bits + * into TLB entry. + * + * - PRESENT *must* be in the bottom three bits because swap cache + * entries use the top 29 bits for TLB2. + * + * - FILE *must* be in the bottom three bits because swap cache + * entries use the top 29 bits for TLB2. + * + * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it + * doesn't support SMP. So we can use this as software bit, like + * DIRTY. + * + * PPC Book-E Linux implementation uses PPC HW PTE bit field definition, + * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory + * protection-related function. (See PTE structure in include/asm-ppc/mmu.h) + * Definition of _PAGE_XXX in include/asm-ppc/pagetable.h stands for + * above bits. Note that those bits values are CPU dependent, not + * architecture. + * + * Kernel PTE entry holds arch-dependent swp_entry structure under certain + * situation. In other words, in such situation, some portion of PTE bits + * are used as swp_entry. In PPC implementation, 3-24th LSB are shared with + * swp_entry, however 0-2nd three LSB still hold protection values. + * That means three protection bits are reserved for both PTE and SWAP + * entry at the most three LSBs. + * + * There are three protection bits available for SWAP entry; + * _PAGE_PRESENT + * _PAGE_FILE + * _PAGE_HASHPTE (if HW has) + * + * So those three bits have to be inside of 0-2nd LSB of PTE. + * */ + #define _PAGE_PRESENT 0x0001 /* S: PTE valid */ #define_PAGE_RW0x0002 /* S: Write permission */ -#define_PAGE_DIRTY 0x0004 /* S: Page dirty */ +#define _PAGE_FILE 0x0004 /* S: nonlinear file mapping */ #define _PAGE_ACCESSED 0x0008 /* S: Page referenced */ #define _PAGE_HWWRITE 0x0010 /* H: Dirty RW */ #define _PAGE_HWEXEC 0x0020 /* H: Execute permission */ #define_PAGE_USER 0x0040 /* S: User page */ #define_PAGE_ENDIAN0x0080 /* H: E bit */ #define_PAGE_GUARDED 0x0100 /* H: G bit */ -#define_PAGE_COHERENT 0x0200 /* H: M bit */ -#define _PAGE_FILE 0x0400 /* S: nonlinear file mapping */ +#define_PAGE_DIRTY 0x0200 /* S: Page dirty */ #define_PAGE_NO_CACHE 0x0400 /* H: I bit */ #define_PAGE_WRITETHRU 0x0800 /* H: W bit */ - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Experiences with git-clone-pack and rsync
Johannes Schindelin [EMAIL PROTECTED] writes: But maybe I just cried wolf... I do not think you are crying wolf. I shared the same concern from the beginning and that was partly why I was pushing for the dumb server approach. - 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] git homepage
On Fri, Aug 05, 2005 at 04:12:14AM +0200, Petr Baudis wrote: Dear diary, on Fri, Aug 05, 2005 at 04:00:03AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... Petr Baudis [EMAIL PROTECTED] writes: http://git.or.cz/ Wonderful. Once the page contents stabilizes, it would be a good idea to get it added in the page top links of http://www.kernel.org/git page. Sorry, I do not know who is in charge of configuring the gitweb there. I tend to harass Kay Sievers, with measurable effects. :-) You are welcome to do so. :) BTW, it may be technically correct, but the combination of rsync and www on the 3rd line of http://www.kernel.org/git caught my attention there ;-). cg-clone rsync://www.kernel.org/pub/scm/ + project path Actually, HTTP should be working again now; but it's rather fresh yet so we should keep it rsync anyway for a while yet for the users of older GIT/Cogito versions. Changed both to rsync now. Let me know, when we want to switch to http again. Best, Kay - 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: Tree tags again..
Sorry about the breakage. I pushed out a fix. Since you always give me hard time with this tree-tag, I decided to trump it with an even weirder tag myself. We will see what else would break shortly ;-). - 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
Template files location
Dear diary, on Fri, Aug 05, 2005 at 06:37:11AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... We install files in $(HOME)/etc/git-core/templates/ directory. In the standard binary distribution scheme, it should probably go to either /usr/share or /etc; the former if the distribution prefers static boilerplate files in /usr/share, latter if we consider them site-specific conffiles. I just discussed this privately with a Debian person on the list today, and we are in favor of installing it under /usr/share/git-core/templates, because we do not expect the contents of the standard templates directory will not be a per-site customization [*1*]. In any case, this means that the make drivers like spec.in and debian/rules would need to override some make variables when they invoke the main Makefile. Any reason why that's not the default destination then? Or you can try /etc/git-core/ and fall back to /usr/share/git-core :-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - 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
git-cvs-import-script problems
I just tried importing a large CVS repository to git, using git cvsimport. It managed to import a lot of files and revisions, but half-way through, it stopped with this message: Unknown: F As far as I can till, this F probably came from the CVS server process. Could it be that my CVS is too new or too old? I'm using git b03e2d2091153d239063cfc086a840d74a9eadde, cvs 1.11.20, cvsps 2.1, and the CVS repository is a local directory. Also, when the process stops, I have .git/HEAD pointing to refs/heads/master (which doesn't exist). I thought it would be pointing to refs/heads/origin. -- David Kågedal - 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: Display of merges in gitk
On Fri, 29 Jul 2005, Paul Mackerras wrote: I have reworked the way gitk displays merges. Ok, goodie. It works fine in my environment, with most merges showing up as not interesting. But a merge like 3e0777b8fa96f7073ed5d13d3bc1d573b766bef9 shows an example of where there was actually both real content merges, and some real clashes. However, most of the content merges were trivial, and they often hide the real clashes. For example, if you click on that merge, a _lot_ of it looks like it might be clashes, even though most of it was auto-merged. This is not really a problem, but I get the feeling that it could be improved somehow - maybe a button that hides the parts that don't have clashes? In the usual case of two parents, lines from the first parent are in red and lines from the second parent are in blue. Lines in the result that don't correspond to either parent are in bold black. To get the alternate output, maybe something like: - run merge on the original/parent1/parent2 (the same way the git-merge-one-file-script does) - anything that merged fine is in black (regardless of which parent it came from), and then mark the merge rejects are in red/blue depending on parent? I don't know how doable that would be. Linus - 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
gitk hyperlinks (was Re: Display of merges in gitk)
[ Also Kay Sievers, because the clickability thing sounds like a potentially good thing for webgit too.. ] For 2.6.13 we've been reverting some stuff lately, to make sure we get a stable release. That's fine, and when I revert something I try to mention the commit ID of the thing I revert in the message. Apparently others do too, as indicated by a patch I just got from Petr Vandovec. So we've got for example: 889371f61fd5bb914d0331268f12432590cf7e85: Author: Linus Torvalds [EMAIL PROTECTED] 2005-07-30 13:41:56 Committer: Linus Torvalds [EMAIL PROTECTED] 2005-07-30 13:41:56 Revert yenta free_irq on suspend ACPI is wrong. Devices should not release their IRQ's on suspend and re-aquire them on resume. ACPI should just re-init the IRQ controller instead of breaking most drivers very subtly. Breakage reported by Hugh Dickins [EMAIL PROTECTED] Undo: d8c4b4195c7d664baf296818bf756775149232d3 Signed-off-by: Linus Torvalds [EMAIL PROTECTED] and 403fe5ae57c831968c3dbbaba291ae825a1c5aaa: Author: Petr Vandrovec [EMAIL PROTECTED] 2005-08-05 06:50:07 Committer: Linus Torvalds [EMAIL PROTECTED] 2005-08-05 06:57:44 [PATCH] rtc: msleep() cannot be used from interrupt Since the beginning of July my Opteron box was randomly crashing and being rebooted by hardware watchdog. Today it finally did it in front of me, and this patch will hopefully fix it. The problem is that at the end of June (the 28th, to be exact: commit 47f176fdaf8924bc83fddcf9658f2fd3ef60d573, [PATCH] Using msleep() instead of HZ) rtc_get_rtc_time ... and when I use gitk, it would be just too damn cool for words if I could easily follow the SHA1's mentioned in the commit message. I can just cut-and-paste the SHA1, and I've verified that it works fine. However, as you'v enoticed, I'm of the whiny kind, and I thought it could be easier. So I'm whining again. whineMommy, mommy, can you make my life easier/whine So I noticed that I really would like two things: - clickable SHA1's in commit messages would be really really cool if something like that is even possible with tcl/tk. Now, if you can highlight them when showing the message, that would be extra cool, but even without any highlighing, the thing actually _almost_ works fine already: you can double-click the SHA1, and it will select it. You then have to move the mouse to the goto window, and paste in the SHA1 there. And this is where it would be good if this sequence could be simplified a bit. Even if it's something as simple as accepting the SHA1 paste into the same window (not having to go to the goto window: just double-click on the SHA1, and then right-click to paste it back). - I'd like to have a back button. Not just for the above kind of thing, but in general too: when searching for something, it would just be very nice if gitk just kept a list of the n last commits that have been selected, and there was a web-browser-like button that went back/forward in history. But especially when looking at a revert, I just want to first go to the thing we revert, see what's going on there (get the historical perspective - commit log for why the original was done etc), and then I'd want to go back (and possibly forth and back again ;). And while the revert mentioned the thing it reverted (so I could cut-and-paste), the thing it reverted obviously does _not_ mention the thing that reverted it, so now I have to manually just scroll back. This same thing happens for a failed search (I search for xyz, and it actually finds it, and I realize that that was the wrong search, but now I'm two months back..) whineMommy, mommy, plase/whine Linus - 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: Terminology
Hi, I am finally finished with my preliminary survey: I took what you sent as a strawman, and inserted what I found (I tried to say only something about ambiguous naming): - The unit of storage in GIT is called object; no other word is used and the word object is used only for this purpose so this one is OK. - A 20-byte SHA1 to uniquely identify objects; README and early Linus messages call this object name so does tutorial. Many places say object SHA1 or just SHA1. Object is short for immutable object. git-cat-file.txt says repository object. - An object database stores a set of objects, and an individial object can be retrieved by giving it its object name. Tutorial calls it an object store. git-fsck-cache.txt names it database at first, but then also uses object pool. - Storing a regular file or a symlink in the object database results in a blob object created. You cannot directly store filesystem directory, but a collection of blob objects and other tree objects can be recorded as a tree object which corresponds to this notion. - $GIT_INDEX_FILE is index file, which is a collection of cache entries. The former is sometimes called cache file, the latter just cache. Tutorial says cache aka index. Though technically, a cache is the index file _plus_ the related objects in the object database. git-update-cache.txt even makes the difference between the index and the directory cache. - the directory which corresponds to the top of the hierarchy described in the index file; I've seen words like working tree, working directory, work tree used. The tutorial initially says working tree, but then working directory. Usually, a directory does not include its subdirectories, though. git-apply-patch-script.txt, git-apply.txt, git-hash-object.txt, git-read-tree.txt use work tree. git-checkout-cache.txt, git-commit-tree.txt, git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain working directory. git-diff-files.txt talks about a working tree. - When the stat information a cache entry records matches what is in the work tree, the entry is called clean or up-to-date. The opposite is dirty or not up-to-date. - An index file can be in merged or unmerged state. The former is when it does not have anything but stage 0 entries, the latter otherwise. That seems to be unambiguous (sometimes it's called index, sometimes index file; I don't think that matters). - An merged index file can be written as a tree object, which is technically a set of interconnected tree objects but we equate it with the toplevel tree object with this set. - A tree object can be recorded as a part of a commit object. The tree object is said to be associated with the commit object. In diffcore.txt, changeset is used in place of commit. - A tag object can be recorded as a pointer to another object of any type. The act of following the pointer a tag object holds (this can go recursively) until we get to a non-tag object is sometimes called resolving the tag. - The following objects are collectively called tree-ish: a tree object, a commit object, a tag object that resolves to either a commit or a tree object, and can be given to commands that expect to work on a tree object. We could call this category an ent. - The files under $GIT_DIR/refs record object names, and are called refs. What is under refs/heads/ are called heads, refs/tags/ tags. Typically, they are either object names of commit objects or tag objects that resolve to commit objects, but a tag can point at any object. The tutorial never calls them refs, but instead references. - A head is always an object name of a commit, and marks the latest commit in one line of development. A line of development is often called a branch. We sometimes use the word branch head to stress the fact that we are talking about a single commit that is the latest one in a branch. In the tutorial, the latter is used in reverse: it talks about a HEAD development branch and a HEAD branch. I find it a little bit troublesome that $GIT_DIR/branches does not really refer to a branch, but rather to a (possibly remote) repository. - Combining the states from more than one lines of developments is called merging and typically done between two branch heads. This is called resolving in the tutorial and there is git-resolve-script command for it. - A set of refs with the set of objects reachable from them constitute a repository. Although currently there is no provision for a repository to say that its objects are stored in this and that object database, multiple repositories can share the same object database, and there is not a conceptual limit that a repository must retrive its objects from a single object database. This is referred to as git archive in the tutorial at first, and later as repository. However, in Copying
Re: git-cvs-import-script problems
David Kågedal [EMAIL PROTECTED] writes: I just tried importing a large CVS repository to git, using git cvsimport. It managed to import a lot of files and revisions, but half-way through, it stopped with this message: Unknown: F As far as I can till, this F probably came from the CVS server process. Could it be that my CVS is too new or too old? Upgrading to CVS 1.12.1 seems to have helped. -- David Kågedal - 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] Assorted documentation patches
Hi, while sifting through the documentation to find different namings for the same concepts, I saw a few things here and there, which I fixed. Since the sifting was quite numbing, there might be some wrong fixes. Sorry, patch is attached, because I still can't convince my pine (version 4.63) to send single space lines :-( Ciao, Dscho diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -62,7 +62,7 @@ customization also applies to git-diff- 1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set, these commands internally invoke diff like this: - diff -L a/path -L a/path -pu old new + diff -L a/path -L b/path -pu old new + For added files, `/dev/null` is used for old. For removed files, `/dev/null` is used for new @@ -101,7 +101,7 @@ For a path that is unmerged, 'GIT_EXTERN parameter, path. -Git specific extention to diff format +Git specific extension to diff format - What -p option produces is slightly different from the diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -5,9 +5,9 @@ Synonym for -p. -r:: - Look recursivelly in subdirectories; this flag does not + Look recursively in subdirectories; this flag does not mean anything to commands other than git-diff-tree; - other commands always looks at all the subdirectories. + other diff commands always look at all the subdirectories. -z:: \0 line termination on output diff --git a/Documentation/git-diff-cache.txt b/Documentation/git-diff-cache.txt --- a/Documentation/git-diff-cache.txt +++ b/Documentation/git-diff-cache.txt @@ -50,13 +50,13 @@ Cached Mode --- If '--cached' is specified, it allows you to ask: - show me the differences between HEAD and the current index + show me the differences between HEAD and the current cache contents (the ones I'd write with a git-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 +For example, let's say that you have worked on your working directory, updated +some files in the cache and are ready to commit. You want to see eactly +*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 git-diff-cache --cached $(cat .git/HEAD) diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt --- a/Documentation/git-diff-tree.txt +++ b/Documentation/git-diff-tree.txt @@ -86,7 +86,7 @@ Or if you are searching for what changed and it will ignore all differences to other files. The pattern is always the prefix, and is matched exactly. There are no -wildcards. Even stricter, it has to match complete path comonent. +wildcards. Even stricter, it has to match a complete path component. I.e. foo does not pick up `foobar.h`. foo does match `foo/bar.h` so it can be used to name subdirectories. diff --git a/Documentation/git-fsck-cache.txt b/Documentation/git-fsck-cache.txt --- a/Documentation/git-fsck-cache.txt +++ b/Documentation/git-fsck-cache.txt @@ -39,17 +39,17 @@ OPTIONS --standalone:: Limit checks to the contents of GIT_OBJECT_DIRECTORY - (.git/objects), making sure that it is consistent and + ($GIT_DIR/objects), making sure that it is consistent and complete without referring to objects found in alternate object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, - nor packed GIT archives found in .git/objects/pack; + nor packed GIT archives found in $GIT_DIR/objects/pack; cannot be used with --full. --full:: Check not just objects in GIT_OBJECT_DIRECTORY - (.git/objects), but also the ones found in alternate + ($GIT_DIR/objects), but also the ones found in alternate object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, - and in packed GIT archives found in .git/objects/pack + and in packed GIT archives found in $GIT_DIR/objects/pack and corresponding pack subdirectories in alternate object pools; cannot be used with --standalone. @@ -69,11 +69,7 @@ that aren't readable from any of the spe So for example - git-fsck-cache --unreachable $(cat .git/HEAD) - -or, for Cogito users: - - git-fsck-cache --unreachable $(cat .git/refs/heads/*) + git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/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 @@ -122,18 +118,18 @@ sha1 mismatch object:: The database has an
Re: bisect gives strange answer
If you see any sort of evidence that this would hold true I really like to know. I haven't found any evidence. When I rebuilt the kernels from scratch (exporting them into an empty directory using cg-export), I got reliable data and bisected down to a patch that probably was a problem. I will redo those tests but rebuilding in place after each bisection (with -f added to all the git checkout uses in git-bisect-script) and see whether I get the same results. If I don't, it could be due to git or git-bisect (but not so likely with the -f switch) or to the build system. Will keep you and Junio posted. -Sanjoy - 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: [ANNOUNCE] Cogito-0.13
Um, guys... If you want to have a dependency on git-core = 0.99.3 you need to actually like, you know, put it on-line as well. Just did a yum update, fails with: error: Failed dependencies: git-core = 0.99.3 is needed by cogito-0.13-1 But on the git repository the git-core == 0.99.1 might wanna fix that. (and man is google fast) Jay -- * Jay Denebeim Moderator rec.arts.sf.tv.babylon5.moderated * * newsgroup submission address: [EMAIL PROTECTED]* * moderator contact address:[EMAIL PROTECTED]* * personal contact address: [EMAIL PROTECTED] * - 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: Template files location
Petr Baudis [EMAIL PROTECTED] writes: Any reason why that's not the default destination then? Inertia, installing things under $HOME, is why it is not the default. It may be that the project is mature enough that it is time to move away from default installation in HOME, IOW to change the Makefile to say prefix=/usr/local (or prefix=/usr) to match practices of other projects [*1*]. Or you can try /etc/git-core/ and fall back to /usr/share/git-core :-) If the template files are to become something that always have to exist, /etc first and then falling back on /usr/share would make a lot of sense. But as Johannes Schindelin correctly argued against the Use the template mechanism to set up refs/ hierarchy as well. patch [*2*], I think git-init-db should work when there is no template directory. In other words, its primary purpose is to help local project administrators ensure newly created repositories have hooks and probably info/exclude that they recommend to the project members. The reason to have a sample one shipped as part of the core package is just to help newbies --- they would get a boilerplate hooks/update that explains how they can set it up when they do git-init-db even when they do not have their own customized set of templates yet. For this kind of use, I do not think one default falling back to another is needed. Come to think of it, GIT_TEMPLATE_DIRECTORY environment variable does not make _ANY_ sense; I am an idiot. It is used only by git-init-db and the reason to have it is to override the default. It should become the command line parameter of it. I'll fix up this breakage soonish. [Footnote] *1* This would probably break Linus, myself and others --- everybody has to say make prefix=$HOME, so I do not think I am actually going to do it any time soon, if ever. Having prefix=/usr/local as default only helps people who are installing system-wide from the source, and nobody else. People who are writing spec.in and/or debian/rules need to override it to prefix=/usr anyway, and it forces people who are installing to their home to say prefix=$HOME/. I suspect it is an inertia from the good old days when nobody used binary distributions. *2* And I am sure many others shared the same objection but did not even bother to say anything because what Johannes said made a lot of sense and what the patch did was obviously wrong. - 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: Template files location
Junio C Hamano wrote: ... If the template files are to become something that always have to exist, /etc first and then falling back on /usr/share would make a lot of sense. But as Johannes Schindelin correctly argued against the Use the template mechanism to set up refs/ hierarchy as well. patch [*2*], I think git-init-db should work when there is no template directory. In other words, its primary purpose is to help local project administrators ensure newly created repositories have hooks and probably info/exclude that they recommend to the project members. So templates are project specific. The reason to have a sample one shipped as part of the core package is just to help newbies --- they would get a boilerplate hooks/update that explains how they can set it up when they do git-init-db even when they do not have their own customized set of templates yet. For this kind of use, I do not think one default falling back to another is needed. Shipping samples with the plumbing makes sense, especially when the documentation in is insufficient. But installing the samples as part of the default install process seems less than desirable. Or, alternately, install the samples in with the documentation as (non-executable) examples. ... *1* This would probably break Linus, myself and others --- everybody has to say make prefix=$HOME, so I do not think I am actually going to do it any time soon, if ever. Having prefix=/usr/local as default only helps people who are installing system-wide from the source, and nobody else. People who are writing spec.in and/or debian/rules need to override it to prefix=/usr anyway, and it forces people who are installing to their home to say prefix=$HOME/. I suspect it is an inertia from the good old days when nobody used binary distributions. Rather than changing the default install location in such a way as to make half the user unhappy, make everybody (un)happy by removing the default and forcing it to be specified when make is executed. - 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: [ANNOUNCE] Cogito-0.13
* Jay Denebeim ([EMAIL PROTECTED]) wrote: Um, guys... If you want to have a dependency on git-core = 0.99.3 you need to actually like, you know, put it on-line as well. Just did a yum update, fails with: error: Failed dependencies: git-core = 0.99.3 is needed by cogito-0.13-1 But on the git repository the git-core == 0.99.1 might wanna fix that. (and man is google fast) I've uploaded the rpms yesterday, but they haven't been staged for mirroring yet. thanks, -chris - 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: Terminology
On Fri, 5 Aug 2005, Johannes Schindelin wrote: Tutorial says cache aka index. Though technically, a cache is the index file _plus_ the related objects in the object database. git-update-cache.txt even makes the difference between the index and the directory cache. I think we should globally rename it to index. The directory cache and later cache naming came from when I started doing the work - before git was even git at all, and had no backing store what-so-ever, I started out writing cache.h and read-cache.c, and it was really first a trial at doing a totally SCM-neutral directory cache front-end. You don't even see that in the git revision history, because that was before git was self-hosting - the project was partly started to also work as possibly just a fast front-end to something that wasn't as fast (ie think something like a front-end to make monotone work better). So the directory cache and cache naming comes from that historical background: it was really started as a front-end cache, and in fact the .git directory was called .dircache initially. You can see some of that in the very earliest git releases: by then I had already done the backing store, and the thing was already called git, but the dircache naming still remains in places. For example, here's my backup target in the initial checkin: backup: clean cd .. ; tar czvf dircache.tar.gz dir-cache which shows that not only did I call the resulting tar file dircache, the directory I was developing stuff in was called dir-cache as well ;) The index obviously ended up doing a lot more, and especially with the different stages it became much more than just a directory cache thing: it's integral to how git does the fast part of a merge. So we should call it index and edit out the old cache and director cache naming entirely. - the directory which corresponds to the top of the hierarchy described in the index file; I've seen words like working tree, working directory, work tree used. The tutorial initially says working tree, but then working directory. Usually, a directory does not include its subdirectories, though. git-apply-patch-script.txt, git-apply.txt, git-hash-object.txt, git-read-tree.txt use work tree. git-checkout-cache.txt, git-commit-tree.txt, git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain working directory. git-diff-files.txt talks about a working tree. I think we should use working tree throughout, since working directory is unix-speak for pwd and has a totally different meaning. - When the stat information a cache entry records matches what is in the work tree, the entry is called clean or up-to-date. The opposite is dirty or not up-to-date. - An index file can be in merged or unmerged state. The former is when it does not have anything but stage 0 entries, the latter otherwise. I think the unmerged case should be mentioned in the cache entry thing, since it's really a per-entry state, exactly like dirty/clean. Then, explaining a unmerged index as being an index file with some entries being unmerged makes more sense. As it is, the above explains an index file as being unmerged by talking about stage 0 entries, which in turn haven't been explained at all. - A tree object can be recorded as a part of a commit object. The tree object is said to be associated with the commit object. In diffcore.txt, changeset is used in place of commit. We really should use commit throughout. ex-BK users sometimes lip into changeset (which in turn is probably because BK had these per-file commits too - deltas), but there's no point in the distinction in git. A commit is a commit. - The following objects are collectively called tree-ish: a tree object, a commit object, a tag object that resolves to either a commit or a tree object, and can be given to commands that expect to work on a tree object. We could call this category an ent. LOL. You are a total geek. - The files under $GIT_DIR/refs record object names, and are called refs. What is under refs/heads/ are called heads, refs/tags/ tags. Typically, they are either object names of commit objects or tag objects that resolve to commit objects, but a tag can point at any object. The tutorial never calls them refs, but instead references. It might be worth saying explicitly that a reference is nothing but the same thing as a object name aka sha1. And make it very clear that it can point to any object type, although commits tend to be the most common thng you want to reference. That then leads naturally into a very specific _subcase_ of refs, namely a head: - A head is always an object name of a commit, and marks the latest commit in one line of development. A line of development is often called a branch. We sometimes use the word branch head to stress the fact that we are talking
Re: [RFC] git homepage
On Friday 05 August 2005 04:27, Petr Baudis wrote: etc. And if you don't author any porcelain, send me updates anyway. :-) from the site gitk is a simple GTK GUI for browsing history of GIT repositories easily. ^^^ /from the site - Martin - --- --- index.html 2005-08-05 21:38:20.605324272 +0300 +++ index.html.new 2005-08-05 21:38:44.804645416 +0300 @@ -148,7 +148,7 @@ dt id=gitkgitk/dt dda href=http://ozlabs.org/~paulus/gitk/;gitk/a is a simple -GTK GUI for browsing history of GIT repositories easily./dd +TK GUI for browsing history of GIT repositories easily./dd dt id=qgitqgit/dt dda href=http://sourceforge.net/projects/qgit;qgit/a is a QT - 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: gitk hyperlinks (was Re: Display of merges in gitk)
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote:
For 2.6.13 we've been reverting some stuff lately, to make sure we get a
stable release. That's fine, and when I revert something I try to mention
the commit ID of the thing I revert in the message. Apparently others do
too, as indicated by a patch I just got from Petr Vandovec. So we've got
for example:
[snipped]
The following code worked for me on a toy commit. I'm not sure the regular
expression in linkcommits is right if the SHA1 is followed by a colon or a
comma,
as I noticed it was in your examples. If it doesn, then removing the [[::]]
and [[::]] will probably fix it.
Things that look like SHA1s are highlighted even if they don't actually exist.
There is probably a more right place to do the '$ctext tag bind Commit'
commands
but I didn't find it right away.
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1753,6 +1753,11 @@ proc selectline {l} {
$ctext conf -state disabled
set commentend [$ctext index end - 1c]
+linkcommits $ctext 0.0 $commentend
+$ctext tag configure Commit -underline yes -foreground blue
+$ctext tag bind Commit Enter { %W configure -cursor hand2 }
+$ctext tag bind Commit Leave { %W configure -cursor {} }
+$ctext tag bind Commit Button-1ButtonRelease-1 { linkclick %W %x %y }
$cflist delete 0 end
$cflist insert end Comments
if {$nparents($id) == 1} {
@@ -1762,6 +1767,30 @@ proc selectline {l} {
}
}
+proc linkclick {w x y} {
+set index [$w index @$x,$y]
+set tags [$w tag names $index]
+foreach c $tags {
+if {![string match {C_*} $c]} { continue; }
+global sha1string
+set sha1string [string range $c 2 end]
+gotocommit
+}
+}
+
+proc linkcommits {w start end} {
+while {1} {
+set pos [$w search -regexp {[[::]][0-9a-fA-F]{40}[[::]]} $start $end]
+if {$pos == {}} {break}
+
+set commit [$w get $pos $pos+40c]
+
+$w tag add Commit $pos $pos+40c
+$w tag add C_$commit $pos $pos+40c
+set start [$w index $pos+40c]
+}
+}
+
proc selnextline {dir} {
global selectedline
if {![info exists selectedline]} return
pgppDwXRz0T1l.pgp
Description: PGP signature
Re: Terminology
On Fri, 5 Aug 2005, Linus Torvalds wrote: On Fri, 5 Aug 2005, Johannes Schindelin wrote: - The files under $GIT_DIR/refs record object names, and are called refs. What is under refs/heads/ are called heads, refs/tags/ tags. Typically, they are either object names of commit objects or tag objects that resolve to commit objects, but a tag can point at any object. The tutorial never calls them refs, but instead references. It might be worth saying explicitly that a reference is nothing but the same thing as a object name aka sha1. Well, it's an object name stored in a file. This adds a layer of indirection and a meaningful name. So I'd vote for making the suggested definition official: fetch means fetching the data, and pull means fetch + merge. So what's the converse of fetch (to rename git-ssh-push to)? Maybe ship? -Daniel *This .sig left intentionally blank* - 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: Terminology
Hi, On Fri, 5 Aug 2005, [EMAIL PROTECTED] wrote: On Fri, 5 Aug 2005, Linus Torvalds wrote: On Fri, 5 Aug 2005, Johannes Schindelin wrote: - The files under $GIT_DIR/refs record object names, and are called refs. What is under refs/heads/ are called heads, refs/tags/ tags. Typically, they are either object names of commit objects or tag objects that resolve to commit objects, but a tag can point at any object. The tutorial never calls them refs, but instead references. It might be worth saying explicitly that a reference is nothing but the same thing as a object name aka sha1. Well, it's an object name stored in a file. This adds a layer of indirection and a meaningful name. Yes. So I'd vote for making the suggested definition official: fetch means fetching the data, and pull means fetch + merge. So what's the converse of fetch (to rename git-ssh-push to)? Maybe ship? I actually like push. You know, not everybody agrees that push is the opposite of pull... Ciao, Dscho - 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: Terminology
Hi, wow! What a long mail! But I probably deserved it, quoting that lengthy mail from Junio... On Fri, 5 Aug 2005, Linus Torvalds wrote: On Fri, 5 Aug 2005, Johannes Schindelin wrote: Tutorial says cache aka index. Though technically, a cache is the index file _plus_ the related objects in the object database. git-update-cache.txt even makes the difference between the index and the directory cache. I think we should globally rename it to index. Totally agree. The index is a central concept. But let's keep in mind -- and make future Documentation/ readers do the same -- that the index, without the referenced objects in the objects database, is only a skeleton. The directory cache and later cache naming came from when I started doing the work - before git was even git at all, and had no backing store what-so-ever, I started out writing cache.h and read-cache.c, and it was really first a trial at doing a totally SCM-neutral directory cache front-end. You don't even see that in the git revision history, because that was before git was self-hosting - the project was partly started to also work as possibly just a fast front-end to something that wasn't as fast (ie think something like a front-end to make monotone work better). So the directory cache and cache naming comes from that historical background: it was really started as a front-end cache, and in fact the .git directory was called .dircache initially. You can see some of that in the very earliest git releases: by then I had already done the backing store, and the thing was already called git, but the dircache naming still remains in places. For example, here's my backup target in the initial checkin: backup: clean cd .. ; tar czvf dircache.tar.gz dir-cache which shows that not only did I call the resulting tar file dircache, the directory I was developing stuff in was called dir-cache as well ;) The index obviously ended up doing a lot more, and especially with the different stages it became much more than just a directory cache thing: it's integral to how git does the fast part of a merge. So we should call it index and edit out the old cache and director cache naming entirely. I quoted this entirely, for a good reason: Linus, one day you really should write a Wikibook about all the small projects you started. I still remember the words I'm doing a (free) operating system (just a hobby, won't be big There's so much to be learnt about good engineering. And people do want to add there anecdotes to it. - the directory which corresponds to the top of the hierarchy described in the index file; I've seen words like working tree, working directory, work tree used. The tutorial initially says working tree, but then working directory. Usually, a directory does not include its subdirectories, though. git-apply-patch-script.txt, git-apply.txt, git-hash-object.txt, git-read-tree.txt use work tree. git-checkout-cache.txt, git-commit-tree.txt, git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain working directory. git-diff-files.txt talks about a working tree. I think we should use working tree throughout, since working directory is unix-speak for pwd and has a totally different meaning. I hoped so much. - An index file can be in merged or unmerged state. The former is when it does not have anything but stage 0 entries, the latter otherwise. I think the unmerged case should be mentioned in the cache entry thing, since it's really a per-entry state, exactly like dirty/clean. Then, explaining a unmerged index as being an index file with some entries being unmerged makes more sense. As it is, the above explains an index file as being unmerged by talking about stage 0 entries, which in turn haven't been explained at all. That's right. We probably should copy a bit from git-read-tree.txt, or at least reference it in the glossary. - A tree object can be recorded as a part of a commit object. The tree object is said to be associated with the commit object. In diffcore.txt, changeset is used in place of commit. We really should use commit throughout. ex-BK users sometimes lip into changeset (which in turn is probably because BK had these per-file commits too - deltas), but there's no point in the distinction in git. A commit is a commit. That is, if you don't do git-update-cache single-file (which is not possible with some porcelains). Apart from that: I think that it is quite important to make the distinction between a commit and a commit object. Newbies (in that case, people working with CVS are newbies to the concepts of git, too) tend understand better what you say, if you make that distinction very clearly, IMHO. - The following objects are collectively called tree-ish: a tree object, a commit object, a tag object that resolves to
Re: My Itchlist
On Fri, 5 Aug 2005, Junio C Hamano wrote: - Teach fetch-pack reference renaming. Well, the fetch side at least needs it less. Right now the renaming means that you can only really fetch _one_ head at a time, but that's at least a fairly common and important case, and you can do the rest from there. And doing only one means that git-fetch-pack can just return the result SHA1 of the head it was asked to fetch. In fact, even that could just be extended to returning multiple heads: just return each SHA1 in order. No renaming necessary, since it's then up to the user what to do with the results. In fact, many users don't even want to write the result to a ref _at_all_: they just use the raw name - no refs - to merge. So arguably it is _wrong_ to make git-fetch-pack write refs, because that just leads to the problem with temporary refs etc. Local variables are good. These are not 1.0 showstopper items but what I personally would love to see. - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable) Some people send patches in MIME quoted-printable. I could drop them on the floor and ask the sender to resend, but I've been being a nice guy, which currently involves manual intervention. This really is a nasty problem. People add their own commentary etc, and the fact is, the maintainer _needs_ to edit it. Otherwise you'll have people saying Hi there, I really like this thing, but I have this problem which this patch fixes etc, which is all very nice, but dammit, that's simply not changelog material. Also, I definitely myself end up editing patches occasionally: fixing things up. Again, this is simply a major pain if the patch comes in as an attachment. So there are tons of reasons to just try to teach people that attachments are painful. Much better to teach people not to use them than having people use them and the tools working with them. - teach git-apply reverse and possibly fuzz. I think this might help Porcelain; currently they have to interpret git extended diff headers themselves. Reverse would definitely be useful. fuzz is really pretty dangerous. I think that once a a patch doesn't apply, you really want to have helper tools like a graphical wiggle etc, and that really means that it's not git-apply, it's something totally different. And quite frankly, if you have a tool that can handle unified diffs already, then extending it for the git rename stuff should be pretty easy. It's not like we haven't wanted renaming patches for at least a _decade_ already, it's just that nobody ever did them. So I'm hoping that git can act as a impetus for people to just finally have a standard way of saying rename. EVERYBODY wants it. Anybody who ever sees a rename as a patch will always go damn, it would be nice to have renames. And dammit, we have them, so let's try to push out the concept. And if that means that we should use rename patches and let non-git users have some pain until they say ok, ok, it's a good idea, I'll do it. Uncle, uncle!, then maybe the world will be a better place. It's not like they can't see how git-apply does it already ;) Linus - 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] Making CFLAGS compilant with GNU Coding Standards
Hello! Quoting GNU Coding Standards (info standards): If there are C compiler options that _must_ be used for proper compilation of certain files, do not include them in `CFLAGS'. Users expect to be able to specify `CFLAGS' freely themselves. This patch renames COPTS to CFLAGS, because it's COPTS that was user overridable. Also, -Wall is moved there because it's optional. What was CFLAGS is now ALL_CFLAGS, which users should not override. Defines are added to DEFINES. Since ALL_CFLAGS is recursively expanded, it uses the final value of DEFINES. Implicit rules are made explicit since the implicit rules use CFLAGS rather than ALL_CFLAGS. I believe that serious projects should not rely on implicit rules anyway. Percent rules are used because they are used already and because they don't need the .SUFFIXES target. Signed-off-by: Pavel Roskin [EMAIL PROTECTED] diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -34,8 +34,8 @@ GIT_VERSION=0.99.3 -COPTS?=-g -O2 -CFLAGS+=$(COPTS) -Wall $(DEFINES) +CFLAGS ?= -g -O2 -Wall +ALL_CFLAGS = $(CFLAGS) $(DEFINES) prefix=$(HOME) bindir=$(prefix)/bin @@ -125,7 +125,7 @@ ifndef NO_OPENSSL LIB_OBJS += epoch.o OPENSSL_LIBSSL=-lssl else - CFLAGS += '-DNO_OPENSSL' + DEFINES += '-DNO_OPENSSL' MOZILLA_SHA1=1 OPENSSL_LIBSSL= endif @@ -146,8 +146,8 @@ endif endif endif -CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)' -CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT=$(etcgitdir)/templates' +DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)' +DEFINES += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT=$(etcgitdir)/templates' @@ -156,9 +156,15 @@ CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRO all: $(PROG) +%.o: %.c + $(CC) -c $(ALL_CFLAGS) $ + +%.o: %.S + $(CC) -c $(ALL_CFLAGS) $ + .PRECIOUS: %.o git-%: %.o $(LIB_FILE) - $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS) + $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS) git-http-pull: pull.o git-local-pull: pull.o @@ -185,13 +191,13 @@ test: all $(MAKE) -C t/ all test-date: test-date.c date.o - $(CC) $(CFLAGS) -o $@ test-date.c date.o + $(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o test-delta: test-delta.c diff-delta.o patch-delta.o - $(CC) $(CFLAGS) -o $@ $^ + $(CC) $(ALL_CFLAGS) -o $@ $^ check: - for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done + for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done -- Regards, Pavel Roskin - 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
