Re: [ANNOUNCE] Cogito 0.12.1
* Petr Baudis ([EMAIL PROTECTED]) wrote:
here is Cogito 0.12.1, another desperate attempt to keep pace with
'@' or Linus, the named Human Master Coder. (Linus, the Human Master
Coder, mumbles arcane do { formulae } while (0)! Some kind of force
seems to attack your mind. Everything suddenly looks so different...
You are confused.) Visit the greater spellbook vault at
http://www.kernel.org/pub/software/scm/cogito
The SRPM and RPMS are uploaded to:
http://www.kernel.org/pub/software/scm/cogito/RPMS
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: How to get a directory filled with v2.6.11?
Hi, Marc Singer wrote:
v2.6.11, 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
You can create your own parent-less commit for that tree.
(It's what I did...)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
It was the most earnest ambition I ever hadNot that I ever
really wanted to be a preacher, but because it never occurred to
me that a preacher could be damned. It looked like a safe job.
[Mark Twain, a Biography]
-
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] tagger id
[EMAIL PROTECTED] (Eric W. Biederman) writes:
This patch adds a command git-id for use on
the command line to see what git will set your id too,
and for use in scripts (git-tag-script) so they can get your git id.
The common code for computing the git-id is moved to ident.c
Fix parse_date to not mind being passed a constant date
to parse.
The code to compute the identifier has been restructured
to at least make a reasonable stab at error handling. The
original version had so many unchecked return values it was
just scary to think about.
Well except for a small bug, but serious bug...
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -184,8 +126,8 @@ int main(int argc, char **argv)
add_buffer(buffer, size, parent %s\n,
sha1_to_hex(parent_sha1[i]));
/* Person/date information */
- add_buffer(buffer, size, author %s %s %s\n, gecos, email, date);
- add_buffer(buffer, size, committer %s %s %s\n\n, commitgecos,
commitemail, realdate);
+ add_buffer(buffer, size, author %s %s %s\n, author);
+ add_buffer(buffer, size, committer %s %s %s\n\n, committer);
This should be:
+ add_buffer(buffer, size, author %s\n, author);
+ add_buffer(buffer, size, committer %s\n\n, committer);
/* And add the comment */
while (fgets(comment, sizeof(comment), stdin) != NULL)
diff --git a/id.c b/id.c
new file mode 100644
--- /dev/null
+++ b/id.c
@@ -0,0 +1,36 @@
+#include cache.h
+#include stdio.h
+#include errno.h
+#include string.h
+
+static char *id_usage = git-id [--author | --committer];
+
+int main(int argc, char **argv)
+{
+ char buf[1000];
+ int (*ident)(char *buf, size_t bufsize);
+ int i;
+
+ ident = git_committer_ident;
Should this default to git_author_ident or git_committer_ident?
I'm not really certain how we expect to use the different flavors.
Eric
-
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: Why is there no git-update-cache --modified (aka I give up)
Dear diary, on Tue, Jul 12, 2005 at 07:52:18AM CEST, I got a letter where Marc Singer [EMAIL PROTECTED] told me that... # 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. It is. :-) It's only that they have cool scripts to do it, e.g. cg-commit. (You have to enumerate the files explicitly for git-commit-script as well, IIRC.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - 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] remove Obsoletes from cogito.spec.in
Dear diary, on Tue, Jul 12, 2005 at 02:33:45AM CEST, I got a letter where Chris Wright [EMAIL PROTECTED] told me that... This is leftover from early naming, and is no longer relevant. Signed-off-by: Chris Wright [EMAIL PROTECTED] Thanks, applied. BTW, Josh Boyer of Fedora suggested having the Provides: git line in cogito.spec.in as long as it comes with git bundled (which will be so until git stabilizes, doesn't break backwards compatibility once in a while, and gets into some regular and reasonably frequent release cycle). What do you think? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - 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
Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... 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. Could we please have the branch name written to .git/head-name in case we switch the branch? The reason is that .git/HEAD may not be always a symlink. Specifically, I do this - there's a command cg-seek, which will seek your working tree to a given commit, while staying on the branch (committing and some other operations are blocked). In that case, I remove .git/HEAD and replace it with ID of the commit I'm seeked at, and when I'm unseeking back to the top, I replace it with the symlink again. With some heuristics, I could create .git/head-name at the time of seek and hope, but I think it'd be cleaner to just always set it (except when we are on the master branch), if you agree. Note that even though Cogito won't let you create/change a local branch yet, it will understand .git/head-name and hopefully behave properly (although it's totally untested, of course). -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - 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: Why is there no git-update-cache --modified (aka I give up)
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. I'd like to know how others do it, since this was the first thing I automated when I started using GIT. Having clear distinction between cache (aka index file) and work tree files and making user concious decision of when to and when not to register/update index is what is quite different in GIT from CVS, SVN and friends [*1*], and while I appreciate its flexibility, it often ends up to be simply more typing (and to certain degree more thinking which is not a bad thing) to the user [*2*]. This snippet is essentially what I do to match the cache with the current work tree [*3*]: case $(git-ls-files --unmerged | sed -e 1q) in ?*) echo 2 You have unmerged files and cannot commit. exit 1 ;; esac git-update-cache --refresh /dev/null git-diff-files | sed -e 's/.*//' | xargs -r git-update-cache --add --remove -- [Footnote] *1* I vaguely recall reading somewhere that GIT is not the first SCM to have these three (not two) levels. Usual two-level SCM needs to only move between your hackery and what's in the repo, and words like committing and checking in are used interchangeably, while the other three level SCM (I do not remember which one I read about) gives distinct meaning to these two words. Can anybody tell me which SCM I am talking about? *2* The commit flow in GIT is three level thing. You have HEAD version (a commit with an associated tree already in the object database that you have checked out and started with), you have cache, and you have files in your work tree. Checking out is to match cache and work tree to HEAD; update-cache is to match cache to work tree; and committing is to create a new commit that matches the cache and make it your HEAD. Roughly speaking, diff-* brothers are about comparing these three stages: - diff-files compares cache and work tree - diff-cache compares commit and cache, or commit and work tree - diff-tree compares two commits *3* I do not officially do Porcelain ;-), but the script I use is slightly different from the one quoted above. It uses git-diff-files -z and a helper program to handle filenames with TAB in them. - 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 3/6] git-gnu-progs-Makefile: git Makefile update
Hi, Linus Torvalds wrote:
I also don't see why, if OS-X already _does_ include the GNU tools, they
couldn't be under /opt/fsf/bin or something like that, and then you could
just do
PATH=/opt/fsf/bin:$PATH
We could prepend /usr/lib/git to $PATH, and symlink them with their real
names there.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Go directly to jail. Do not pass Go, do not collect $200.
-
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
I do want to see various Porcelains to agree on how to store state information in $GIT_DIR for doing common operations, when they are conceptually compatible. The way they handle branches may fall into that category. With the barebone GIT Porcelain, seek like operation may simply be done by creating another branch or tag and jumping to it, so there may not be the concept of seek, in which case they may not be compatible after all. Having said that, I do like the concept of keeping track of which development line are we on, and what's most recent in it. The way I read your description of cg-seek, you currently have that information is either in .git/head-name and .git/refs/heads/head-name pair (when .git/head-name exists), or .git/HEAD. If you block certain operations while you have seeked to non-top anyway, wouldn't it be cleaner to have .git/seeked-to that records the commit ID you are at, which at the same time indicates that you are in a special situation, and not touching HEAD at all? Then .git/HEAD will always have that line of development information. Well, that was half tongue-in-cheek suggestion; I have a feeling that you may feel it is a bit too late to change this kind of thing easily. But if we are going to agree on using .git/head-name, I'd rather see it exist all times, so that cat $GIT_DIR/head-name would always tell us which branch we are working in. - 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: Stacked GIT 0.4
Catalin Marinas wrote: Stacked GIT 0.4 release is available from http://procode.org/stgit/ Very nice. Here's my wishlist. Hopefully I'll be able to dig in and help out. import: the complement to export template files for the series output of export, to put it into a format that sendpatchset understands. Bryan - 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] cg-commit chokes when given a very large list of files
cg-commit currently chokes when passed a very large list of files. Fix it.
This patch depends on your filenames not containing line feeds. No big deal,
lots of other parts of cogito break on filenames containing line feeds.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-commit |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -288,10 +288,12 @@ precommit_update () {
[ $op = N ] || [ $op = D ] || [ $op = M ] || op=M
eval [EMAIL PROTECTED]\$fname\
done
+ IFS=$'\n'
# XXX: Do we even need to do the --add and --remove update-caches?
- [ $queueN ] { git-update-cache --add ${infoonly} -- [EMAIL
PROTECTED] || return 1; }
- [ $queueD ] { git-update-cache --force-remove -- [EMAIL
PROTECTED] || return 1; }
- [ $queueM ] { git-update-cache ${infoonly} -- [EMAIL PROTECTED]
|| return 1; }
+ [ $queueN ] { ( echo ${queueN[*]} | tr \\n \\0 | xargs -0
git-update-cache --add ${infoonly} -- ) || return 1; }
+ [ $queueD ] { ( echo ${queueD[*]} | tr \\n \\0 | xargs -0
git-update-cache --force-remove -- ) || return 1; }
+ [ $queueM ] { ( echo ${queueM[*]} | tr \\n \\0 | xargs -0
git-update-cache ${infoonly} -- ) || return 1; }
+ IFS=$' \n\t'
return 0
}
-
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: Stacked GIT 0.4
Bryan Larsen [EMAIL PROTECTED] wrote: import: the complement to export It is written in the TODO file but didn't have time to do it. I'm working on moving all the commands from main.py into separate files under stgit/commands/ for a clearer view. This should be ready in the next day or two and, after that, I will work on other commands. template files for the series output of export, to put it into a format that sendpatchset understands. I thought about integrating sendpatchset into stgit but it is much simpler to just generate a control file (especially if you want to review what you're going to send). Is the subject line always the first line of the patch description? -- Catalin - 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: Stacked GIT 0.4
Catalin Marinas wrote: Bryan Larsen [EMAIL PROTECTED] wrote: template files for the series output of export, to put it into a format that sendpatchset understands. I thought about integrating sendpatchset into stgit but it is much simpler to just generate a control file (especially if you want to review what you're going to send). Is the subject line always the first line of the patch description? I haven't been using the Linux way for long, so I'm probably the wrong guy to answer, but for my current set of patches, the name of the patch would be the right thing to put in the Subject line. But my current set of patches is really small, so if you implemented the first line convention, I'd be happy to switch to it. Bryan - 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 2/2] Demo support for packs via HTTP
Daniel Barkalow wrote: If I understand the curl documentation, you should be able to set options on the curl object when it has just been created, if those options aren't going to change between requests. Note that I make requests from multiple places, but I use the same curl object for all of them. I didn't realize that it was the same object. Great! -- Darrin - 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] tagger id
Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: Should this default to git_author_ident or git_committer_ident? I'm not really certain how we expect to use the different flavors. The only in-tree user after your patch is applied is the tagger stuff, so in that sense committer_ident may make more sense. There is also the commit path, and that comes from C. I'm not quite certain how we should be using the environmental variables. Having said that, for something like this that would not be used constantly and interatively by the users, my preference is not to have any default at all, and always require --author or --committer. You have to type a bit more when doing the script, but that needs to be done only once. You will be sure which one you are asking from the command two weeks after you wrote the script so it is not a big loss. Make sense. Although I'm not quite certain we actually need the information twice. Possibly we just have GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL, and then have commit-write take a flag to override the author bit. That would certainly make it less confusing when setting up environmental variables for git. And that would also give us a better name. I am not seriously suggesting the below as an alternative, but have you thought about doing an inverse function of your computation for the case when the user has all the environment variables, and have script eval its output, like this [*1*]: $ git-id GIT_AUTHOR_NAME='Junio C Hamano' GIT_AUTHOR_EMAIL='[EMAIL PROTECTED]' GIT_COMMITTER_NAME='Junio C Hamano' GIT_COMMITTER_EMAIL='[EMAIL PROTECTED]' $ eval `git-id` $ tagger=$GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL Having names and emails available separately may turn out to be easier to use in other situation. Just a thought. Part of the request was to put all of this information together in a common place. And note that it is actually: tagger=$GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL $GIT_COMMITTER_DATE Where the date is a human unreadable string of the number of seconds since the epoch (aka 1 Jan 1970 UTC). By the way, I do not particularly like the name git-id. There could be IDs for different kinds (not just people) we would want later (file IDs, for example). Naming what you are computing _the_ id feels a bit too generic. I do not have a better alternative to suggest, though. Agreed. Something like git-author or git-author-stamp is probably better. *1* This makes its output syntax a bit too specific to the shell and unfriendly to Porcelain written in other languages. The only non-shell Porcelains I am aware of are done in Perl (I do not remember hearing its name) and Python (StGIT), both of which have reasonable regexp support to grok something like this, so it would not be a big issue. And in git-commit-script this is actually parsed by sed which makes it so the shell can parse the information as well so I think we are fine in that sense. Eric - 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] tagger id
Dear diary, on Tue, Jul 12, 2005 at 05:04:23PM CEST, I got a letter where Eric W. Biederman [EMAIL PROTECTED] told me that... By the way, I do not particularly like the name git-id. There could be IDs for different kinds (not just people) we would want later (file IDs, for example). Naming what you are computing _the_ id feels a bit too generic. I do not have a better alternative to suggest, though. Agreed. Something like git-author or git-author-stamp is probably better. Since that infriges the author/committer distinction, I would prefer git-person-id. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - 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: 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: Trial git RPM's..
Chris Wright [EMAIL PROTECTED] writes: * Linus Torvalds ([EMAIL PROTECTED]) wrote: And it does not pass my torture test of building rpm's on debian, but that is not a huge problem. Ok, why is debian problematic? Is there some missing dependency or something? I really haven't ever done an rpm, and the git rpm target was all done by Chris Wright, so I don't have any clue at all. Again, patches welcome. Heh debian rpm build...I missed that bit in Eric's message. Eric, care to give details? Ok paged back in my state. The practical problem is that rpmbuild try to lookup the build dependencies which simply aren't present on debian. Patch will be along shortly once I get the glitches fixed. One last issue with building packages. Some distros are still shipping GNU interactive tools so git as a package name for the rpm is problematic. At the very least it is extremely confusing that git-0.99 is a more recent package that git-4.3.20. Eric - 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
Darcs-git wiki page
http://www.darcs.net/DarcsWiki/DarcsGit You're welcome to leave any questions you might have -- I'll try to answer. Juliusz - 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
Hi, Junio C Hamano wrote:
Having said that, I do like the concept of keeping track of
which development line are we on, and what's most recent in
it. The way I read your description of cg-seek, you currently
have that information is either in .git/head-name and
.git/refs/heads/head-name pair (when .git/head-name exists),
or .git/HEAD.
Personally, I'd rather have as few invariants as possible, so that various
Porcelains can agree on semantics.
What I would expect from a sane .git tree is that
* .git/HEAD contains the commit that is currently checked out.
* If HEAD is not a symlink, then switching to a branch HEAD is not a part
of should emit a warning.
(fsck to find the dangling commits is not an answer ;-)
Ideas like
* remember the branch to un-seek back to
or
* treat HEAD as read-only when there's a seek active
seem to be optional / Porcelain-specific.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
We'll strategically withdraw to previously prepared position.
Who prepared them?
we'll prepare them when we get there.
-- Terry Pratchett (Reaper Man)
-
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 Tue, 12 Jul 2005, Petr Baudis wrote: Could we please have the branch name written to .git/head-name in case we switch the branch? I wouldn't mind per se, but on the other hand I really _hate_ having parallel information that can get out of sync. If you have two places holding the same information, they had better match. And this is something that sounds like it could very easily start to not match, and then we're screwed. So I'd _much_ rather see instead: - .git/head-name is a cogito-specific thing that is only active while cogito is _seeking_. So then cg-unseek ends up being pretty much equivalent to [ -e .git/head-name ] || die You weren't seeking git checkout $(cat .git/head-name) rm .git/head-name This way head-name is really never even supposed to be in sync with .git/HEAD, and there are no synchronization issues. - in order for a git checkout to not get confused and possibly throwing a cogito temporary head away (and so that git-fsck-cache is happy during a seek), would it be possible to make seek use a real temporary branch instead? Ie, cg-seek would be something like [ -e .git/head-name ] die You are already seeking readlink .git/HEAD .git/head-name echo $seekpoint .git/refs/heads/cg-seek-point git checkout -f cg-seek-point or similar? Then cg-seek and cg-unseek would continue to work, but the core git layer would never be confused because they're really using normal branches? 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: Trial git RPM's..
On Tue, 12 Jul 2005, Eric W. Biederman wrote: One last issue with building packages. Some distros are still shipping GNU interactive tools so git as a package name for the rpm is problematic. At the very least it is extremely confusing that git-0.99 is a more recent package that git-4.3.20. Ahh. Dang, I should have remembered this. We should call the rpm git-core-0.99, not just git-0.99. Chris, I assume this is just changing the name in the spec-file from git to git-core? 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: Trial git RPM's..
Linus Torvalds [EMAIL PROTECTED] writes: Ahh. Dang, I should have remembered this. We should call the rpm git-core-0.99, not just git-0.99. Chris, I assume this is just changing the name in the spec-file from git to git-core? The name of the tarball needs to be updated as well. Eric - 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] Design for http-pull on repo with packs
Junio C Hamano wrote: Dan Holmsand [EMAIL PROTECTED] writes: Repacking all of that to a single pack file gives, somewhat surprisingly, a pack size of 62M (+ 1.3M index). In other words, the cost of getting all those branches, and all of the new stuff from Linus, turns out to be *negative* (probably due to some strange deltification coincidence). We do _not_ want to optimize for initial slurps into empty repositories. Quite the opposite. We want to optimize for allowing quick updates of reasonably up-to-date developer repos. If initial slurps are _also_ efficient then that is an added bonus; that is something the baseline big pack (60M Linus pack) would give us already. So repacking everything into a single pack nightly is _not_ what we want to do, even though that would give the maximum compression ;-). I know you understand this, but just stating the second of the above paragraphs would give casual readers a wrong impression. I agree, to a point: I think the bonus is quite nice to have... As it is, it's actually faster on my machine to clone a fresh tree of Linus' than it is to git clone a local tree (without doing the hardlinking cheating, that is). And it's kind of nice to have the option to start completely fresh. Anyway, my point is this: to make pulling efficient, we should ideally have (1) as few object files to pull as possible, especially when using http, and (2) have as few packs as possible, to gain some compression for those who pull more seldom. Point 1 is obviously the most important one. To make this happen, relatively frequent repacking and re-repacking (even if only on parts of the repository) would be necessary. Or at least nice to have... Which was why I wanted the dumb fetch thingies to at least do some relatively smart un/repacking to avoid duplication. And, ideally, that they would avoid downloading entire packs that we just want the beginning of. That would lessen the cost of repacking, which I happen to think is a good thing. Also, it's kind of strange when the ssh/local fetching *always* unpacks everything, and rsync/http *never* does this... You are correct. For somebody like Jeff, having the Linus baseline pack with one pack of all of his head (incremental that excludes what is already in the Linus baseline pack) would help pullers. That would work, of course. It, however, means that Linus becomes the official repository maintainer in a way that doesn't feel very distributed. Perhaps then Linus' packs should be marked official in some way? The big problem, however, comes when Jeff (or anyone else) decides to repack. Then, if you fetch both his repo and Linus', you might end up with several really big pack files, that mostly overlap. That could easily mean storing most objects many times, if you don't do some smart selective un/repacking when fetching. Indeed. Overlapping packs is a possibility, but my gut feeling is that it would not be too bad, if things are arranged so that packs are expanded-and-then-repacked _very_ rarely if ever. Instead, at least for your public repository, if you only repack incrementally I think you would be OK. To be exact, you're ok (in the meaning of avoiding duplicates) as long as you always rsync in the official packs, and coordinate with others you're merging with, before you do any repacking of your own. Sure, this works. It just feels a bit un-distributed for my personal taste... /dan - 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: Trial git RPM's..
On Tue, 12 Jul 2005, Eric W. Biederman wrote: The name of the tarball needs to be updated as well. Yes, I noticed. I ended up renaming the spec-file too. Pushed out, 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: Trial git RPM's..
* Linus Torvalds ([EMAIL PROTECTED]) wrote: On Tue, 12 Jul 2005, Eric W. Biederman wrote: The name of the tarball needs to be updated as well. Yes, I noticed. I ended up renaming the spec-file too. Pushed out, Yup, looks good. -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: [PATCH] remove Obsoletes from cogito.spec.in
* Petr Baudis ([EMAIL PROTECTED]) wrote:
where Chris Wright [EMAIL PROTECTED] told me that...
This is leftover from early naming, and is no longer relevant.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Thanks, applied. BTW, Josh Boyer of Fedora suggested having the
Provides: git
line in cogito.spec.in as long as it comes with git bundled (which will
be so until git stabilizes, doesn't break backwards compatibility once
in a while, and gets into some regular and reasonably frequent release
cycle). What do you think?
Hmm, in an ideal world all of those stipulations are right around the
corner. Also, if the split is done, then cogito can depend on a specific
version of git-core, to help isolate against those upstream changes.
The main thing then is getting any local changes you have pushed to
Linus' git tree (if there are still any).
Adding Provides is probably only useful if there's some other package
that's relying on git being there (i.e. gitweb perhaps). I guess we
can add that, and remove it when there's proper dependencies in order.
May as well do git-core as is now done in git.
thanks,
-chris
--
Mark cogito rpm package as providing git-core, since it currently does.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
diff --git a/cogito.spec.in b/cogito.spec.in
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -10,6 +10,7 @@ Source: http://kernel.org/pub/software/
BuildRequires: zlib-devel, openssl-devel, curl-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Prereq:sh-utils, diffutils, rsync, rcs, mktemp = 1.5
+Provides: git-core
%description
GIT comes in two layers. The bottom layer is merely an extremely fast
-
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
Compilation troubles
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. [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 /usr/local/ssl/include/openssl/x509_vfy.h /usr/local/ssl/include/openssl/x509v3.h /usr/local/ssl/include/openssl/conf.h /usr/local/ssl/include/openssl/conf_api.h /usr/local/ssl/include/openssl/txt_db.h /usr/local/ssl/include/openssl/pkcs7.h /usr/local/ssl/include/openssl/pkcs12.h
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
Re: [PATCH] tagger id
Eric, I ended up coding the ident stuff a bit differently, and I didn't do done the tag/git-id part yet. Can you check out my latest commit (pushed out, but it will probably take a few minutes to mirror out), and do the final tag stuff based on that? 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] git: fix trivial warning from show_rename_copy()
apply.c: In function `show_rename_copy':
apply.c:1147: warning: field precision is not type int (arg 3)
Signed-off-by: Tony Luck [EMAIL PROTECTED]
---
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -1143,7 +1143,7 @@ static void show_rename_copy(struct patc
*/
if (old != p-old_name)
printf( %s %.*s{%s = %s} (%d%%)\n, renamecopy,
- old - p-old_name, p-old_name,
+ (int)(old - p-old_name), p-old_name,
old, new, p-score);
else
printf( %s %s = %s (%d%%)\n, renamecopy,
-
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
[RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
Sometimes (often actually) I do:
cp -Rl tree1 tree2# new tree with implied CoW semantics
cd tree2
cg-update # or similar
the latter well frob .git/HEAD or similar by doing echo foo bar
which obviously breaks the intended CoW semantics.
How would people feel about something like the patch below be? (RFC
purposes only, please eyeball this before blidnly applying anything.
I may have missed spots or goofed, you never know).
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -21,6 +21,12 @@ usage() {
die usage: $USAGE
}
+echo_to_file() {
+TMPFILE=`mktemp $2.tmp-XXX`
+echo $1 $TMPFILE
+mv $TMPFILE $2
+}
+
pager () {
local line
# Invoke pager only if there's any actual output
@@ -101,7 +107,7 @@ tree_timewarp () {
fi
git-read-tree -m $branch || die $branch: bad commit
- [ $no_head_update ] || echo $branch $_git/HEAD
+ [ $no_head_update ] || echo_to_file $branch $_git/HEAD
# Kill gone files
git-diff-tree -z -r $base $branch | xargs -0 bash -c '
diff --git a/cg-branch-add b/cg-branch-add
--- a/cg-branch-add
+++ b/cg-branch-add
@@ -50,4 +50,4 @@ mkdir -p $_git/branches
[ -s $_git/branches/$name ] die branch already exists
[ -s $_git/refs/heads/$name ] echo warning: I already have head of this
branch 2
-echo $location $_git/branches/$name
+echo_to_file $location $_git/branches/$name
diff --git a/cg-branch-chg b/cg-branch-chg
--- a/cg-branch-chg
+++ b/cg-branch-chg
@@ -14,4 +14,4 @@ location=$2
([ $name ] [ $location ]) || usage
[ -s $_git/branches/$name ] || die branch does not exist
-echo $location $_git/branches/$name
+echo_to_file $location $_git/branches/$name
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -331,7 +331,7 @@ fi
if [ $newhead ]; then
echo Committed as $newhead.
- echo $newhead $_git/HEAD
+ echo_to_file $newhead $_git/HEAD
[ $merging ] rm $_git/merging $_git/merging-sym $_git/merge-base
# Trigger the postcommit hook
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -44,7 +44,7 @@ mkdir $_git/branches
touch $_git/refs/heads/master
if [ $uri ]; then
- echo $uri $_git/branches/origin
+ echo_to_file $uri $_git/branches/origin
cg-pull origin || die pull failed
cp $_git/refs/heads/origin $_git/refs/heads/master
diff --git a/cg-seek b/cg-seek
--- a/cg-seek
+++ b/cg-seek
@@ -44,8 +44,8 @@ fi
if [ $seek_mode = away ]; then
rm $_git/HEAD
- echo $dstcommit $_git/HEAD
- [ -s $_git/blocked ] || echo seeked from $_git_head $_git/blocked
+ echo_to_file $dstcommit $_git/HEAD
+ [ -s $_git/blocked ] || echo_to_file seeked from $_git_head
$_git/blocked
else
rm $_git/HEAD
ln -s refs/heads/$_git_head $_git/HEAD
diff --git a/cg-tag b/cg-tag
--- a/cg-tag
+++ b/cg-tag
@@ -79,5 +79,5 @@ SIGEND
rm -rf $tagdir
else
- echo $id $_git/refs/tags/$name
+ echo_to_file $id $_git/refs/tags/$name
fi
diff --git a/git-branch-script b/git-branch-script
--- a/git-branch-script
+++ b/git-branch-script
@@ -8,4 +8,4 @@ rev=$(git-rev-parse --verify --default H
[ -z $branchname ] die git branch: I want a branch name
[ -e $GIT_DIR/refs/heads/$branchname ] die $branchname already exists
-echo $rev $GIT_DIR/refs/heads/$branchname
+echo_to_file $rev $GIT_DIR/refs/heads/$branchname
diff --git a/git-checkout-script b/git-checkout-script
--- a/git-checkout-script
+++ b/git-checkout-script
@@ -67,7 +67,7 @@ fi
#
if [ $? -eq 0 ]; then
if [ $newbranch ]; then
- echo $new $GIT_DIR/refs/heads/$newbranch
+ echo_to_file $new $GIT_DIR/refs/heads/$newbranch
branch=$newbranch
fi
[ $branch ] ln -sf refs/heads/$branch $GIT_DIR/HEAD
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -97,7 +97,7 @@ grep -v '^#' .editmsg | git-stripspace
[ -s .cmitmsg ]
tree=$(git-write-tree)
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS)
- echo $commit $GIT_DIR/HEAD
+ echo_to_file $commit $GIT_DIR/HEAD
rm -f -- $GIT_DIR/MERGE_HEAD
ret=$?
rm -f .cmitmsg .editmsg
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -30,4 +30,4 @@ rsync://*)
;;
esac || exit 1
git-rev-parse --verify $head /dev/null || exit 1
-echo $head $GIT_DIR/$destination
+echo_to_file $head $GIT_DIR/$destination
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -21,7 +21,7 @@ case $# in
esac
git-read-tree -m -u $junio $linus
-echo $linus $GIT_DIR/HEAD || exit
+echo_to_file $linus $GIT_DIR/HEAD || exit
tmp=.rebase-tmp$$
fail=$tmp-fail
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -24,8 +24,8 @@ if [ -z
RE: Compilation troubles
On Tue, 12 Jul 2005, Jerry Seutter wrote: The README file for cogito/git mentions that there is an ssl library included in the source which you can use if you don't have openssl. It doesn't give any directions on how to use it, however. You could try looking into using that. Use make MOZILLA_SHA1=1 to use the included mozilla-based SHA1 library. (Or just do export MOZILLA_SHA1=1 in your .bashrc so that you always do this). There's also a PPC_SHA1 which works the same way, and which enables the optimized ppc assembly language version. It used to make a big difference for me, but it seems modern openssl libraries already have something fairly optimized (on my YDL machine the openssl version was really slow). 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: Why is there no git-update-cache --modified (aka I give up)
Matthias Urlichs smurf at smurf.noris.de writes: Hi, Marc Singer wrote: # git-update-cache `git-diff-cache | cut -f2` g-d-c should have an option to print file names only. All that cutting and argument-backtick-ing gets pretty nasty when there are a lot of files, or if they contain special characters. I concur. I'll add --name-only flag to diff brothers soonish. Sorry I am at work and have turned the incoming connection to my home network before I left for work today -- this is the same [EMAIL PROTECTED] who is guilty for all your diff problems ;-). - 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] git-cvsimport-script: parse multidigit revisions
git-cvsimport-script: parse multidigit revisions.
Previously, git-cvsimport-script would fail
on revisions with more than one digit.
Signed-off-by: Sven Verdoolaege [EMAIL PROTECTED]
---
commit 7b5f7bcc470528beb4a0b6ef1c93ce634aaa0158
tree db66d0759f97016bd123e2351aa0e77585e3177b
parent e30e814dbfef7a6e89418863e5d7291a2d53b18f
author Sven Verdoolaege [EMAIL PROTECTED] Tue, 12 Jul 2005 22:36:57 +0200
committer Sven Verdoolaege [EMAIL PROTECTED] Tue, 12 Jul 2005 22:36:57 +0200
git-cvsimport-script |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -675,7 +675,7 @@ while(CVS) {
$state = 9;
} elsif($state == 8) {
$logmsg .= $_\n;
- } elsif($state == 9 and
/^\s+(\S+):(INITIAL|\d(?:\.\d+)+)-(\d(?:\.\d+)+)\s*$/) {
+ } elsif($state == 9 and
/^\s+(\S+):(INITIAL|\d+(?:\.\d+)+)-(\d+(?:\.\d+)+)\s*$/) {
# VERSION:1.96-1.96.2.1
my $init = ($2 eq INITIAL);
my $fn = $1;
-
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 PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
Chris Wedgwood cw at f00f.org writes: if [ $newhead ]; then echo Committed as $newhead. - echo $newhead $_git/HEAD + echo_to_file $newhead $_git/HEAD [ $merging ] rm $_git/merging $_git/merging-sym $_git/merge-base Good intentions, but wouldn't the above clobber symlinked HEAD? Not a fundamental flaw, though. You need to see if it is a symlink, readlink it (repeatedly until you get a regular file or dangling symlink target that does not exist --- immediately after git-init-db has such a HEAD) and run your echo_to_file on the link target. - 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, 11 Jul 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: 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? How about treating master a temporary thing --- whatever I happen to be working on right now? That conflicts with my usage, where I have a single repository for all of my working directories, with .git/refs and .git/objects being symlinks to it, but .git/HEAD being different for each branch. The stuff in objects/ and refs/ really shouldn't depend on what you're currently doing for this reason. My way of thinking of master is that it's a real branch, which is for all of the situations where you aren't using a specially-designated branch. For many people, they only do stuff that's not designated specially; Jeff only does stuff that is designated specially. But if you do both, you'll want master to be left alone while you work on the side branch. -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: [PATCH] tagger id
Linus Torvalds [EMAIL PROTECTED] writes: Eric, I ended up coding the ident stuff a bit differently, and I didn't do done the tag/git-id part yet. Can you check out my latest commit (pushed out, but it will probably take a few minutes to mirror out), and do the final tag stuff based on that? For the most part it looks sane. I'm not really thrilled that setup_ident() calls die, and when complaining about the user name we should probably complain that their sysadmin hated then if it is over a 1000 characters not their parents :) I'm also not at all thrilled with global variables. Globals aren't the source of all evil but they have a lot better claim than goto. At least real_email and friends are file local. If you like it and the code works git is you project and I won't complain again. Since we are still looking at this there is one change in the user interface I would like to make to simplify things for the end user. The only time when GIT_COMMITTER != GIT_AUTHOR is in git_commit_script when we you are making a new commit based on an old commit. Can we add a command line option to git-commit-write, --author that will allow the author field to be overridden. Allowing us to get down to a single set of GIT variables for specifying who the user is? That also simplifies the tagging case and answers the question which environment variables tags should look at, to see who the user is. Eric - 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] tagger id
Eric W. Biederman ebiederm at xmission.com writes: Since we are still looking at this there is one change in the user interface I would like to make to simplify things for the end user. The only time when GIT_COMMITTER != GIT_AUTHOR is in git_commit_script when we you are making a new commit based on an old commit... I am afraid I do not follow you. For a project lead person like Linus, who takes an e-mail submission of patches, GIT_AUTHOR is almost always different from the committer, and typically set up by the program that reads the e-mail to snarf the From: and Date: lines via environment variables, when the incoming patches are being processed. He is saying I am the COMMITTER, and this commit I am making is written by this AUTHOR. AUTHOR can be set to somebody other than yourself and that is a typical mode of operation for a project lead person. On the other hand, we made COMMITTER overridable only because (1) the computed value from the system are often not quite right on many systems with weird GECOS field or domain/e-mail setup, and (2) when converting from a foreign SCM, we wanted to keep the committer information (and dates), if available. Only in (2), which is quite a special case, COMMITTER names somebody different from yourself. What this means is that if you are asking the question who the user is, the answer _should_ always come from COMMITTER. That also simplifies the tagging case and answers the question which environment variables tags should look at, to see who the user is. The intent of tags (especially the signed kind) is to express trust: This commit is called v2.6.12 and *I* vouch for it. COMMITTER is the only sensible thing to use there, because (as you said) what you care is who I am, not for whom I am doing this. - 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 PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
On Tue, Jul 12, 2005 at 09:37:00PM +, Junio C Hamano wrote: if [ $newhead ]; then echo Committed as $newhead. - echo $newhead $_git/HEAD + echo_to_file $newhead $_git/HEAD [ $merging ] rm $_git/merging $_git/merging-sym $_git/merge-base Good intentions, but wouldn't the above clobber symlinked HEAD? Yeah, but I would argue that is the right thing to do. Symlink'd trees don't really make sense to me (they seem fragile and somewhat pointless) but perhaps I'm missing something? Not a fundamental flaw, though. You need to see if it is a symlink, readlink it (repeatedly until you get a regular file or dangling symlink target that does not exist --- immediately after git-init-db has such a HEAD) and run your echo_to_file on the link target. I don't see how that's helpful. The idea of echo_to_file is to make the metadata self-contained to the subtree --- so we don't want to have external links (possibly) pointing outside of it. - 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
