* Re: optimize gitdiff-do script
From: Paul Jackson @ 2005-04-18 15:23 UTC (permalink / raw)
To: pasky; +Cc: git
In-Reply-To: <20050416171009.0bedbab4.pj@sgi.com>
Pasky,
Looks like a couple of questions I asked over the weekend
got lost along the way.
1) How do you want me to fix the indentation on my patch
to optimize gitdiff-do script:
- forget my first patch and resend from scratch, or
- a second patch restoring indentation, on top of my first one.
2) Would you be interested in a patch that used a more robust tmp
file creation, along the lines of replacing
t=${TMPDIR:-/usr/tmp}/gitdiff.$$
trap 'set +f; rm -fr $t.?; trap 0; exit 0' 0 1 2 3 15
with:
tmp=${TMPDIR-/tmp}
tmp=$tmp/gitdiff-do.$RANDOM.$RANDOM.$RANDOM.$$
(umask 077 && mkdir $tmp) || {
echo "Could not create temporary directory! Exiting." 1>&2
exit 1
}
trap 'rm -fr $tmp; trap 0; exit 0' 0 1 2 3 15
t=$tmp/tmp
From the www.linuxsecurity.com link that Dave Jones provided, the
above $tmp directory is about as good as using mktemp, while
avoiding both dependency on mktemp options not everyone has.
3) If interested in (2), would you want it instead of my previous mktemp
removal patch, or on top of it?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Randy.Dunlap @ 2005-04-18 15:25 UTC (permalink / raw)
To: Greg KH; +Cc: torvalds, rmk, dwmw2, git, hpa
In-Reply-To: <20050418150456.GC12750@kroah.com>
On Mon, 18 Apr 2005 08:04:57 -0700 Greg KH wrote:
| On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
| >
| > Tools absolutely matter. And it will take time for us to build up that
| > kind of helper infrastructure. So being newbie might be part of it, but
| > it's the smaller part, I say. Rough interfaces is a big issue.
|
| Speaking of tools, you had a "dotest" program to apply patches in email
| form to a bk tree. And from what I can gather, you've changed that to
| handle git archives, right? Any pointers to where I can find this so I
| could try to build up some git trees for you to merge with? I think I
| can even make a tree with a merge issue if you want to test that out :)
it's at
http://www.kernel.org/pub/linux/kernel/people/torvalds/git-tools.git/
---
~Randy
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-18 15:23 UTC (permalink / raw)
To: Russell King; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20050418102332.A21081@flint.arm.linux.org.uk>
On Mon, 18 Apr 2005, Russell King wrote:
>
> Ok, I just tried pulling your tree into the tree you pulled from, and
> got this:
No, that can't work. The pesky tools are helpful, but they really don't do
merges worth cr*p right now, excuse my french.
The _real_ way to pull is to do the (horribly complex) thing I described
by the merge, but noticing that one of the commits you are merging is a
proper subset of the other one, and just updating the head instead of
actually doing a real merge (ie skipping the "read-tree -m" and
"write-tree" phases).
> This was with some random version of git-pasky-0.04. Unfortunately,
> this version doesn't have the sha1 ID appended, so I couldn't say
> definitively that it's the latest and greatest. It might be a day
> old.
I'm afraid that until Pasky's tools script this properly, a "pull" really
ends up being something like this (which _can_ be scripted, never fear):
NOTE NOTE NOTE! This is untested! I'm writing this within the email
editor, so do _not_ do this on a tree that you care about.
#!/bin/sh
#
# use "$1" or something in a real script, this
# just hard-codes it.
#
merge_repo=master.kernel.org:/pub/linux/kernel/people/torvalds/linux-2.6.git
echo "Getting object database"
rsync -avz --ignore-existing $merge_repo/ .git/
echo "Getting remote head"
rsync -avz $merge_repo/HEAD .git/MERGE_HEAD
head=$(cat .git/HEAD)
merge_head=$(cat .git/MERGE-HEAD)
common=$(merge-base $head $merge_head)
if [ -z "$common" ]; then
echo "Unable to find common commit between" $merge_head $head
exit 1
fi
# Get the trees associated with those commits
common_tree=tree=$(cat-file commit $common | sed 's/tree //;q')
head_tree=tree=$(cat-file commit $head | sed 's/tree //;q')
merge_tree=tree=$(cat-file commit $merge | sed 's/tree //;q')
if [ "$common" == "$merge_head" ]; then
echo "Already up-to-date. Yeeah!"
exit 0
fi
if [ "$common" == "$head" ]; then
echo "Updating from $head to $merge_head."
echo "Destroying all noncommitted data!"
echo "Kill me within 3 seconds.."
sleep 3
read-tree $merge_tree && checkout-cache -f -a
echo $merge_head > .git/HEAD
exit 0
fi
echo "Trying to merge $merge_head into $head"
read-tree -m $common_tree $head_tree $merge_tree
result_tree=$(write-tree) || exit 1
result_commit=$(echo "Merge $merge_repo" | commit-tree $result_tree -p $head -p $merge_head)
echo "Committed merge $result_commit"
echo $result_commit > .git/HEAD
read-tree $result_tree && checkout-cache -f -a
The above looks like it might work, but I also warn you: it's not only
untested, but it's pretty fragile in that if something breaks, you are
probably left with a mess. I _tried_ to do the right thing, but... So it
obviously will need testing, tweaking and just general tender loving care.
And if the merge isn't clean, it will exit early thanks to the
write-tree || exit 1
and now you have to resolve the merge yourself. There are tools to help
you do so automatically, but that's really a separate script.
You shouldn't hit the "merge" case at all right now, you should hit the
"Updating from $head to $merge_head" thing.
If Pesky wants to take the above script, test it, and see if it works,
that would be good. It's definitely a much better "pull" than trying to
apply the patches forward..
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Greg KH @ 2005-04-18 15:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Russell King, David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504171621330.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
>
> Tools absolutely matter. And it will take time for us to build up that
> kind of helper infrastructure. So being newbie might be part of it, but
> it's the smaller part, I say. Rough interfaces is a big issue.
Speaking of tools, you had a "dotest" program to apply patches in email
form to a bk tree. And from what I can gather, you've changed that to
handle git archives, right? Any pointers to where I can find this so I
could try to build up some git trees for you to merge with? I think I
can even make a tree with a merge issue if you want to test that out :)
thanks,
greg k-h
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-18 14:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Russell King, David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504171621330.7211@ppc970.osdl.org>
Dear diary, on Mon, Apr 18, 2005 at 01:24:24AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sun, 17 Apr 2005, Russell King wrote:
> >
> > I pulled it tonight into a pristine tree (which of course worked.)
>
> Goodie.
>
> > In doing so, I noticed that I'd messed up one of the commits - there's
> > a missing new file. Grr. I'll put that down to being a newbie git.
>
> Actually, you should put that down to horribly bad interface tools. With
> BK, we had these nice tools that pointed out that there were files that
> you might want to commit (ie "bk citool"), and made this very obvious.
>
> Tools absolutely matter. And it will take time for us to build up that
> kind of helper infrastructure. So being newbie might be part of it, but
> it's the smaller part, I say. Rough interfaces is a big issue.
I just committed some simple git status, which is equivalent to svn
status or cvs update (except it does no update). So it shows all the
files not tracked by git with a question mark in front of them.
This will need some ignore rules, though (currently it just ignores *.o
and the tags file). Now it turns out that it is rather unfortunate that
git ignores hidden files, since this would be a perfect object for that
- I think it is useful to have the ignore list tracked by git. I think I
will just name it git-ignores to be found in the working directory for
now.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: First git-pasky bug report? :) error: bad signature/verify header failed
From: Petr Baudis @ 2005-04-18 13:40 UTC (permalink / raw)
To: David Greaves; +Cc: git
In-Reply-To: <4263B4A3.4030000@dgreaves.com>
Dear diary, on Mon, Apr 18, 2005 at 03:22:43PM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Hi
Hi,
I should release early and often. :-)
> Tree change:
> c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a
> Tracked branch, applying changes...
> error: bad signature
> error: verify header failed
> read_cache: Invalid argument
> error: bad signature
> error: verify header failed
> error: bad signature
> error: verify header failed
this is a known problem, caused by the directory cache index format
change (to fix endianity issues). You can solve it by doing
read-tree $(tree-id)
update-cache --refresh
(if you are reading this and didn't to the problematic pull yet, do it
right after you get git-pasky-base, do your first pull and rebuild;
you won't get into problems that way).
To recover, do this now, and then do:
(i) if you have local commits:
git merge -b c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf \
5bf2f464d382b0bd746d06e264bc6951e7bfcd3a
(ii) if you don't have local commits:
git diff -r c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a \
| git apply
I'm thinking how to handle future directory cache changes. Doing
read-tree $(tree-id) && update-cache --refresh on the kernel tree is
fast (three seconds?) if you have it in cache already, but SLOOOOOW
(more than a minute) if you have cold cache; so I wouldn't do it
always.
I think I will do something like check-cache which will just return
exitcode based on whether the cache is ok or not, and do this time
in the git multiplexer.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* First git-pasky bug report? :) error: bad signature/verify header failed
From: David Greaves @ 2005-04-18 13:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Hi
I'm just starting to look at git (and cogito).
Earlier this morning I got and built
http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2
I then did a "git pull pasky" and a make.
All went well.
A couple of hours later I did another git pull pasky and had the problem
shown below.
I moved the directory to one side and reissued the commands and all was
well:
723 tar xvfj git-pasky-base.tar.bz2
724 cd git-pasky-0.4/
725 make
726 git pull pasky
727 make
728 git pull pasky
729 history | tail -10
This is just a heads up in case there's anything useful here.
It may just have been locking issues and me pulling whilst the repo was
being updated or something...
I'll hold the bad directory for a day or two in case anyone wants any
diagnostics running.
David
david@ash:/everything/devel/git/git-pasky-0.4$ git pull pasky
MOTD: Welcome to Petr Baudis' rsync archive.
MOTD:
MOTD: If you are pulling my git branch, please do not repeat that
MOTD: every five minutes or so - new stuff is likely not going to
MOTD: appear so fast, and my line is not that thick. Nothing wrong
MOTD: with pulling every half an hour or so, of course.
MOTD:
MOTD: Feel free to contact me at <pasky@ucw.cz>, shall you have
MOTD: any questions or suggestions.
Tree change:
c29b3b29c2861ab0ffb475c7a7c9cfc946106eaf:5bf2f464d382b0bd746d06e264bc6951e7bfcd3a
*100644->100644 blob
222bce21788308e1bf567304b474225b1681b03b->ad44415110ab63f1daa93e07dc496193d8006d81
Makefile
*100755->100755 blob
667f877ae836c418294ef085e91efcb48d30cabb->035a1f470003c8b0963d0eb5f0eb457155f415ad
git
*100755->100755 blob
fadd17e52845c5656ba344a9413b29b641c9ff5f->67e97fb71094693929f56d74bc13e572420d99d4
gitcommit.sh
*100755->100755 blob
7ea441e584d603463fb1b83991b88f63a3895cff->18478101980f630f0e9fd95365c6d9f46bf27bfd
gitmerge.sh
*100755->100755 blob
9bda6555a1dafc1db762bc46db60d2a9485dc523->8e016f7d3aeb0244c8a6524ddaa4b2cb1ff8015f
gitpull.sh
+100755 blob b6e318b31eb2ed6d2e137833a2064327331504b4 gitseek.sh
*100755->100755 blob
30654380c10edde32def8e5fa2e2c956fbff3d58->ce44c1d4ce3b949b8ac99f1b90927da4e698e3de
gittrack.sh
-100755 blob 2488078570c4a5709332d92d7a1b5b65036ff3a0 gitupdate.sh
Tracked branch, applying changes...
error: bad signature
error: verify header failed
read_cache: Invalid argument
error: bad signature
error: verify header failed
error: bad signature
error: verify header failed
At this point I moved the directory aside...
--
^ permalink raw reply
* Re: Yet another base64 patch
From: Kevin Smith @ 2005-04-18 12:59 UTC (permalink / raw)
Cc: git
In-Reply-To: <426341FC.7090600@dwheeler.com>
David A. Wheeler wrote:
> Does anyone know of any other issues in how git data is stored that
> might cause problems for some situations? Windows' case-insensitive/
> case-preserving model for NTFS and vfat32 seems to be enough
> (since the case is preserved) so that the format should work,
If git is retaining hex naming, and not moving to base64, then I don't
think what I am about to say is relevant. However, if base64 file naming
is still being considered, then vfat32 compatibility may be a concern
(I'm not sure about NTFS). Although it is case-preserving, it actually
considers both cases as being the same name. So AaA would overwrite aAa.
If I'm doing the math right, we would effectively be ignoring roughly
one out of 6 base64 bits. This would reduce the collision avoidance
capability of SHA-1 (on vfat32) from 160 bits to about 133 bits. Still
strong, and probably acceptable, but worth noting.
I'll take this opportunity to support David's position that it would be
fantastic if git could end up being valuable for a wide range of
projects, rather than just the kernel. I also fully understand that the
kernel is the primary target, but when there are opportunities to make
the data structures more generally useful without causing problems for
the kernel project, I hope they are taken.
Thanks,
Kevin
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-18 12:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: GIT Mailing Lists
In-Reply-To: <1113827713.5286.13.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1813 bytes --]
On Mon, 2005-04-18 at 22:35 +1000, David Woodhouse wrote:
> On Mon, 2005-04-18 at 12:36 +0200, Martin Schlemmer wrote:
> > realgecos[strchr(realgecos, ',') - realgecos] = '\0';
>
> Er, *strchr(realgecos, ',') = 0; surely? Even if the compiler is clever
> enough to optimise out the gratuitous addition and subtraction, that's
> no real excuse for it.
>
Err, right. Updated patch.
The gecos is delimited by ',' or ';', so we should only use whatever
before the first ',' or ';' for the full name, and not just strip those.
Signed-off-by: Martin Schlemmer <azarah@gentoo.org>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
[-- Attachment #1.2: git-gecos.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: David Woodhouse @ 2005-04-18 12:35 UTC (permalink / raw)
To: azarah; +Cc: GIT Mailing Lists
In-Reply-To: <1113820589.16288.5.camel@nosferatu.lan>
On Mon, 2005-04-18 at 12:36 +0200, Martin Schlemmer wrote:
> realgecos[strchr(realgecos, ',') - realgecos] = '\0';
Er, *strchr(realgecos, ',') = 0; surely? Even if the compiler is clever
enough to optimise out the gratuitous addition and subtraction, that's
no real excuse for it.
--
dwmw2
^ permalink raw reply
* Re: Darcs and git: plan of action
From: David Roundy @ 2005-04-18 12:20 UTC (permalink / raw)
To: darcs-devel; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7ivf6lm594.fsf@lanthane.pps.jussieu.fr>
Linus and gittish people,
I'm cc'ing you on this email, since Juliusz had some interesting ideas as
to how darcs could interact with git, which then gave me an idea concerning
which I'd like feedback from you. In particular, it would make life (that
is, life interacting back and forth with git) easier if we were to embed
darcs patches in their entirety in the git comment block. It's a bit of an
ugly idea, but would greatly simplify the two-way interaction between git
and darcs, since no information would be lost when a darcs patch was merged
into git. See below for the discussion.
As I say, it's a bit ugly, and before we explore the idea further, it would
be nice to know if this would cause Linus to vomit in disgust and/or refuse
patches from darcs users. Another slightly less noxious possibility would
be to store the darcs patch as a "hidden" file, if git were given the
concept of commit-specific files. So then we could include in the commit
log something like "Darcs-patch:
780c057447d4feef015a905aaf6c87db894ff58c". We could do this silently,
except that I wonder if fsck would delete these files, since they aren't
pointed to by any trees.
On Mon, Apr 18, 2005 at 12:02:15AM +0200, Juliusz Chroboczek wrote:
> David,
>
> I've read git over the week-end. I think I can see where it's coming
> from.
>
> Git is basically a (userspace) filesystem with support for efficiently
> finding identical objects. It's both simple and generic enough to be
> usable by us.
Right.
> You mentioned that you'd like to use git as a cache for Darcs; and I
> don't think I agree. Caches are tricky -- they need to be kept in
> synch -- and they might result in unexpected performance (you need to
> update both the native and the cached data structures on every
> modification).
It's true that we'd need to keep the cache in sync, which would mean making
sure it gets updated with every repository-modifying darcs command, but
we've already got a cache that has those properties, and it seems like
modifying the interface to deal with a more complex cache would be
relatively straightforward, and would likely have other advantages, such as
if we wanted to implement a per-file cache to speed up annotate (since the
speed of annotate seems to be a relatively common concern).
Basically, I'm imagining that we'd have to replace writePristine and
write_dirty_Pristine with the applyPristine that Ian implemented for
efficiency reasons. So we'd write to pristine by throwing patches at it,
and letting it do what it pleases with them. Then we'd read from Pristine
as usual--but we might want to add interfaces for reading slurpies of older
versions from the pristine cache. This would again be a helpful interface
anyways, since it might allow us, for example, to use checkpoints when
reading older versions.
> I'd rather remodularise Darcs so that the on-disk patch representation
> is decoupled from the in-memory representation, so that we can use
> various backends in the same way as we use the native repository
> format.
The problem I have with this is that "other" repository formats (e.g. git)
store "tree versions", not "changes", and I think it would be fragile to
try to store "changes" (in the darcs sense) in them.
> As you seem motivated by git (my motivation is slightly different -- I
> want to be able to pull from Arch and other widespread systems with
> dysfunctional user interfaces), I suggest that we start with that.
I see. You're thinking of using darcs as a client for other SCMs. That's
sort of how I'm thinking of darcs interacting with git, so we aren't so far
off in terms of goals. My hope would tend to be that people would coalesce
around git--since Linus will be using git. If everyone can interoperate
with git, we'd be able to interoperate with everyone, in a sense, anyways.
> I suggest we do the following:
>
> 1. remove the assumption that patch IDs have a fixed format. Patch
> IDs should be opaque blobs of binary data that Darcs only compares
> for equality.
I'm not really comfortable with this, although I can see that there is an
appeal to it, and that something like it may turn out to be necesary for
interacting with systems for which we can't create a simple mapping of
patch IDs.
> 2. get Darcs to pull from git. By restricting ourselves to a fairly
> simple command, this should be doable in finite time.
Okay, this is definitely a good goal. See below for thoughts on how this
should be accomplished.
> 3. allow a patch to have multiple IDs; if the IDs associated to two
> patches are not disjoint, then the patches are the same patch.
This I find a bit confusing. So a patch can have two IDs, presumably
something like a "darcs ID" and a "git ID"? I can see that this might
simplify some things, but am not sure how it would work. The IDs would
have to have a hierarchy, so that you wouldn't ever end up with the "same"
patch having disjoint IDs in two cases.
> 4. allow applying to git repos of non-merger patches.
Here's where I think I'd differ. I think when dealing with git (and
probably also with *any* other SCM (arch being a possible exception), we
need to consider the exchange medium to be not a patch, but a tag. Git
only knows about "versions" of the tree, which in darcs terminology is a
tag. It *does* know about the (possibly multiple) parents of a given
version, so we have a "context" for the patch--provided those two (or
one...) parents are treated as tags.
So in pulling from git, I'd treat each git change as a patch followed by a
tag. When pulling from git, unfortunately, the contents of that patch will
be determined by our diff algorithm, so if we want long-term stability we
might need to mummify a variant of the diff algorithm that we agree not to
change, and to always use when computing patches from a git archive. This
tagging (and I imagine the tags will look something like
"git:0c16636264037e8b5ccd38b28ecd191aebc67389") will mean that we can
create a single-patch darcs "patch bundle" for any given git commit. Which
is to say, that we'll be able to "see" a git repository as an odd-looking
darcs repository.
This means that getting a fresh darcs repository from git would potentially
involve a whole lot of merging...
Putting darcs patches *into* git is more complicated, since we'll want to
get them back again without modification. Normal "hunk" patches would be
no problem, provided we never change our diff algorithm (which has been
discussed recently, in the context of making hunks better align with blocks
of code). We could perhaps tell users not to use "replace" patches. But
avoiding "mv" patches would be downright silly. So we're somehow going to
have to either sneak this sort of metadata into the git repository, or
we're going to have to store just the darcs "patch ID" in the git
repository, and require that darcs users get the actual patch from
somewhere else. I had been imagining the latter, but now I'm wondering if
the former is a reasonable possibility.
Linus has said that he figures an SCM needs to be built on top of git, and
that SCM--rather than git itself--would be the one that would know about
things like file renames, probably by storing some sort of rename metadata.
I wonder if we could perhaps store the entire darcs patch in the git
commit? It seems a bit abusive, but would certainly be the easiest way to
interface losslessly with git. So when we pull from git, we'd look in the
commit log for the magic words indicating that this is really a darcs
patch. If so, we could handle it natively. If not, we'd know it was
actually a "gittish" entity, and requires that we diff a couple of trees to
find the actual patch to be used with darcs' patch theory.
The ugliness of this idea is that it involves storing redundant
information. And I think we'll have a bit of an excercise in commutation
and merging when we get the patches from a git repository, since in git
they'll be stored in tree form, but that's something we'll have to do even
to create a read-only darcs mirror of a git repository.
We could perhaps alleviate the pain by perhaps not including the actual
contents of new or deleted files in the patch, but instead retrieve those
from git directly. But that might be more trouble than it's worth, at
least for the first sketch.
> 5. think about mergers.
Since git stores a branched history rather than a linear history, I'm not
sure that we'll ever need to store mergers in git. Instead, we could just
commute until the mergers disappear (which might be a bit scary), and then
store *that* in git. On the other hand, if this is to inefficient, and if
we store actual darcs patches in git, then we wouldn't perhaps need to
worry about mergers as a special case.
> Whether we end up with a useful implementation of Darcs/git or not,
> this will result in a more modular Darcs, and hence one that will be
> easier to optimise.
>
> What do you think?
Err, I think I've answered that one... :)
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: [PATCH] Pretty-print date in 'git log'
From: David Woodhouse @ 2005-04-18 12:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sanjoy Mahajan, git
In-Reply-To: <20050418102744.GK1461@pasky.ji.cz>
On Mon, 2005-04-18 at 12:27 +0200, Petr Baudis wrote:
> Yes. As far as I'm concerned, I'd put such stuff to git log, and extend
> it usage so that it is possible to print individual log entries with it
> - just make it accept a _range_ of commits, and then do
>
> git log $commit $commit
That's fairly trivial. In the current (and misguided) version with
chronological output, rev-tree will do it all for you, in fact:
rev-tree $1 ^$2
In the older and more useful version, it was only slightly more complex:
base=$(gitXnormid.sh -c $1) || exit 1
+if [ -n "$2" ]; then
+ endpoint=$(gitXnormid.sh -c $2) || exit 1
+ if rev-tree $base $endpoint | grep -q $base:3; then
+ base=
+ else
+ rev-tree --edges $base $endpoint | sed 's/[a-z0-9]*:1//g' > $TMPCL
+ fi
+fi
changelog $base
rm $TMPCL $TMPCM
--
dwmw2
^ permalink raw reply
* Re: fix mktemp (remove mktemp ;)
From: Florian Weimer @ 2005-04-18 12:12 UTC (permalink / raw)
To: Herbert Xu; +Cc: Paul Jackson, pasky, git, mj
In-Reply-To: <E1DNMVX-00013d-00@gondolin.me.apana.org.au>
* Herbert Xu:
> Paul Jackson <pj@sgi.com> wrote:
>>
>> Even mktemp(1) can collide, in theory, since there is no practical way
>> in shell scripts to hold open and locked the file from the instant of it
>> is determined to be a unique name.
>
> mktemp(1) creates the file before exiting. Other instances of mktemp(1)
> cannot successfully create the same file (they all use O_EXCL).
> Therefore this race does not exist, even in theory :)
/tmp cleaners exist, but the risks are minimal for programs which
aren't SUID/SGID.
^ permalink raw reply
* A couple of questions
From: Imre Simon @ 2005-04-18 11:51 UTC (permalink / raw)
To: git
How will git handle a corrupted (git) file system?
For instance, what can be done if objects/xy/z{38} does not pass the
simple consistency test, i.e. if the file's sha1 hash is not xyz{38}?
This might be a serious problem because, in general, one cannot
reconstruct the contents of file objects/xy/z{38} from its name
xyz{38}.
Another problem might come up if the file does pass the simple
consistency test but the file's contents is not a valid git file,
i.e. something that
(*) successfully inflates to a stream of bytes that forms a sequence of
<ascii tag without space> + <space> + <ascii decimal size> +
<byte\0> + <binary object data>.
Are there enough internal redundancies in git to allow fixing at least
some corrupted file systems? Shouldn't there be some?
Another related observation is that git is not really based on a 160 bit
hashing scheme. Indeed, only files that satisfy the above condition
(*) are allowed and this most certainly reduces the valid range of the
hashing function. I do not think that this will be a problem, but it
doesn't hurt to point this out once.
Cheers,
Imre Simon
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-18 11:15 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050418102332.A21081@flint.arm.linux.org.uk>
Dear diary, on Mon, Apr 18, 2005 at 11:23:32AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> Ok, I just tried pulling your tree into the tree you pulled from, and
> got this:
>
> Tree change: e7905b2f22eb5d5308c9122b9c06c2d02473dd4f ee423ea56280512778a5961ee58a785a73acb7d1
> ...
> *100644->100644 blob 46f0a3caae02b4bb8f903d7ac86456aa0c37954b->ba4afd7956173b6f89eb6b0b9ad23b392d5c0aee arch/arm/kernel/process.c
> *100644->100644 blob 4a36fa7192e11df36f5e0928b064239dabe1e305->ec0bc8f315ab5d78a4220e176e7aee76d52d1c74 arch/arm/kernel/traps.c
> *100644->100644 blob 311d19ee00208faf02359f9e7c5394577a40f253->bf923a953703c6ca0c88eac3b2850cf07b838996 arch/arm/lib/changebit.S
> *100644->100644 blob c07afa31695654e6489ec59c3f837183b325e9da->41f89b3a393d5af939f04f63c5bf4991b2bf6599 arch/arm/lib/clearbit.S
> ...
> Tracked branch, applying changes...
> Merging e7905b2f22eb5d5308c9122b9c06c2d02473dd4f -> ee423ea56280512778a5961ee58a785a73acb7d1
> to df4449813c900973841d0fa5a9e9bc7186956e1e...
> COPYING: needs update
> CREDITS: needs update
> Documentation/00-INDEX: needs update
> Documentation/BK-usage/00-INDEX: needs update
> ...
> patching file arch/arm/kernel/process.c
> Reversed (or previously applied) patch detected! Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file arch/arm/kernel/process.c.rejpatching file arch/arm/kernel/traps.c
> Reversed (or previously applied) patch detected! Skipping patch.
> 3 out of 3 hunks ignored -- saving rejects to file arch/arm/kernel/traps.c.rej
> patching file arch/arm/lib/changebit.S
> Reversed (or previously applied) patch detected! Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/changebit.S.rej
> patching file arch/arm/lib/clearbit.S
> Reversed (or previously applied) patch detected! Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/clearbit.S.rej
>
> so obviously git pull isn't able to indentify what's already in the
> local repository.
For unknown reason, patch sucks at this, even if I pass it
-N or --forward
Ignore patches that seem to be reversed or already applied. See also -R.
:-(
git merge does not use the in-GIT merging capabilities yet.
Could you do
merge-base $(tree-id ee423ea56280512778a5961ee58a785a73acb7d1) \
$(tree-id df4449813c900973841d0fa5a9e9bc7186956e1e)
and check if it returns e7905b2f22eb5d5308c9122b9c06c2d02473dd4f, please?
I guess it won't. So you could try to wipe the -b "$orig_head" from
gitmerge.sh invocation in gitpull.sh.
> Interestingly, the files listed above as having rejects are excluded
> from the list of "needs update". And I don't know why git is staying
> that these files need updating, because they haven't changed since
> they were initially checked out.
Because it is checking out only the files which changed (pass -a to git
merge to check out everything; I will probably make git pull take a -m
argument which will take merge arguments ;). And then it does
update-cache --refresh which complains about missing files. :/
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Martin Schlemmer @ 2005-04-18 11:15 UTC (permalink / raw)
To: Russell King
Cc: David A. Wheeler, Linus Torvalds, Git Mailing List, Peter Anvin,
Andrew Morton
In-Reply-To: <20050417192000.C13233@flint.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
On Sun, 2005-04-17 at 19:20 +0100, Russell King wrote:
> On Sun, Apr 17, 2005 at 02:13:59PM -0400, David A. Wheeler wrote:
> > On Sun, 17 Apr 2005, Russell King wrote:
> > >>BTW, there appears to be "errors" in the history committed thus far.
> > >>I'm not sure where this came from though. Some of them could be
> > >>UTF8 vs ASCII issues, ....>
> > ...
> > >>One thing which definitely needs to be considered is - what character
> > >>encoding are the comments to be stored as?
> >
> > Linus Torvalds replied:
> > > To git, it's just a byte stream, and you can have binary comments if you
> > > want to. I personally would prefer to move towards UTF eventually, but I
> > > really don't think it matters a whole lot as long as 99.9% of everything
> > > we'd see there is still 7-bit ascii.
> >
> > I would _heartily_ recommend moving towards UTF-8 as the
> > internal charset for all comments. Alternatives are possible
> > (e.g., recording the charset in the header), but they're
> > incredibly messy. Even if you don't normally work in UTF-8,
> > it's pretty easy to set most editors up to read & write UTF-8.
> > Having the data stored as a constant charset eliminates
> > a raft of error-prone code.
>
> Except, I believe, MicroEMACS, which both Linus and myself use. As
> far as I know, there aren't any patches to make it UTF-8 compliant.
>
> The alternative is, I suppose, iconv. However, iconv in _my_ glibc
> seems buggy (segfaults) and my efforts for building glibc 2.3.2 for
> ARM have failed. Effectively that means iconv is inaccessible to
> me.
>
OT, and probably not much help, but glibc-2.3.5 is out ...
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Martin Schlemmer @ 2005-04-18 11:14 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, Petr Baudis, Git Mailing List
In-Reply-To: <20050418102332.A21081@flint.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]
On Mon, 2005-04-18 at 10:23 +0100, Russell King wrote:
> On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
> > On Sun, 17 Apr 2005, Russell King wrote:
> > > I pulled it tonight into a pristine tree (which of course worked.)
> >
> > Goodie.
>
> Note the "pristine". Now comes the real test...
>
> > > In doing so, I noticed that I'd messed up one of the commits - there's
> > > a missing new file. Grr. I'll put that down to being a newbie git.
> >
> > Actually, you should put that down to horribly bad interface tools. With
> > BK, we had these nice tools that pointed out that there were files that
> > you might want to commit (ie "bk citool"), and made this very obvious.
> >
> > Tools absolutely matter. And it will take time for us to build up that
> > kind of helper infrastructure. So being newbie might be part of it, but
> > it's the smaller part, I say. Rough interfaces is a big issue.
>
> Ok, I just tried pulling your tree into the tree you pulled from, and
> got this:
>
> Tree change: e7905b2f22eb5d5308c9122b9c06c2d02473dd4f ee423ea56280512778a5961ee58a785a73acb7d1
> ...
> *100644->100644 blob 46f0a3caae02b4bb8f903d7ac86456aa0c37954b->ba4afd7956173b6f89eb6b0b9ad23b392d5c0aee arch/arm/kernel/process.c
> *100644->100644 blob 4a36fa7192e11df36f5e0928b064239dabe1e305->ec0bc8f315ab5d78a4220e176e7aee76d52d1c74 arch/arm/kernel/traps.c
> *100644->100644 blob 311d19ee00208faf02359f9e7c5394577a40f253->bf923a953703c6ca0c88eac3b2850cf07b838996 arch/arm/lib/changebit.S
> *100644->100644 blob c07afa31695654e6489ec59c3f837183b325e9da->41f89b3a393d5af939f04f63c5bf4991b2bf6599 arch/arm/lib/clearbit.S
> ...
> Tracked branch, applying changes...
> Merging e7905b2f22eb5d5308c9122b9c06c2d02473dd4f -> ee423ea56280512778a5961ee58a785a73acb7d1
> to df4449813c900973841d0fa5a9e9bc7186956e1e...
> COPYING: needs update
> CREDITS: needs update
> Documentation/00-INDEX: needs update
> Documentation/BK-usage/00-INDEX: needs update
> ...
> patching file arch/arm/kernel/process.c
> Reversed (or previously applied) patch detected! Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file arch/arm/kernel/process.c.rejpatching file arch/arm/kernel/traps.c
> Reversed (or previously applied) patch detected! Skipping patch.
> 3 out of 3 hunks ignored -- saving rejects to file arch/arm/kernel/traps.c.rej
> patching file arch/arm/lib/changebit.S
> Reversed (or previously applied) patch detected! Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/changebit.S.rej
> patching file arch/arm/lib/clearbit.S
> Reversed (or previously applied) patch detected! Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/clearbit.S.rej
>
> so obviously git pull isn't able to indentify what's already in the
> local repository.
>
> Interestingly, the files listed above as having rejects are excluded
> from the list of "needs update". And I don't know why git is staying
> that these files need updating, because they haven't changed since
> they were initially checked out.
>
> This was with some random version of git-pasky-0.04. Unfortunately,
> this version doesn't have the sha1 ID appended, so I couldn't say
> definitively that it's the latest and greatest. It might be a day
> old.
>
gitmerge.sh does not yet have support for the new merge stuff as far as
I know, and if it does, then its a very recent version (ie, one that
have the sha1 ID appended).
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [pasky] recent changes to gitdiff.sh
From: Martin Schlemmer @ 2005-04-18 10:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050418104038.GM1461@pasky.ji.cz>
[-- Attachment #1.1: Type: text/plain, Size: 2344 bytes --]
On Mon, 2005-04-18 at 12:40 +0200, Petr Baudis wrote:
> Dear diary, on Mon, Apr 18, 2005 at 12:40:08PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Hi,
>
> Hello,
>
> > I see the recent changes to gitdiff.sh requires you to pass -r (git diff
> > -r local:$tracking) even if you separate the branches via ':'. Is this
> > intended (seems like it)?
>
> yes. This brings the usage style in sync with the rest of the world. :-)
>
> > If so, then gittrack.sh, gitpull.sh and gitmerge.sh needs to be
> > updated ...
>
> I hopes I updated all the places. If I missed anything, please say what.
>
Update calls to gitdiff.sh to include the '-r' switch.
Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
gitmerge.sh: 7ea441e584d603463fb1b83991b88f63a3895cff
--- 1/gitmerge.sh
+++ 2/gitmerge.sh 2005-04-18 12:55:34.000000000 +0200
@@ -67,7 +67,7 @@
fi
update-cache --refresh
-gitdiff.sh "$base":"$branch" | gitapply.sh
+gitdiff.sh -r "$base":"$branch" | gitapply.sh
cat >&2 <<__END__
Please inspect the merge in the ,,merge/ subdirectory. Commit from that
gitpull.sh: 9bda6555a1dafc1db762bc46db60d2a9485dc523
--- 1/gitpull.sh
+++ 2/gitpull.sh 2005-04-18 12:55:34.000000000 +0200
@@ -73,7 +73,7 @@
gitmerge.sh -b "$orig_head" "$new_head"
else
- gitdiff.sh "$orig_head":"$new_head" | gitapply.sh
+ gitdiff.sh -r "$orig_head":"$new_head" | gitapply.sh
read-tree $(tree-id $new_head)
echo $new_head >.git/HEAD
gittrack.sh: 30654380c10edde32def8e5fa2e2c956fbff3d58
--- 1/gittrack.sh
+++ 2/gittrack.sh 2005-04-18 12:55:34.000000000 +0200
@@ -50,7 +50,7 @@
echo $name >.git/tracking
read-tree $(tree-id "$name")
- gitdiff.sh local:"$name" | gitapply.sh
+ gitdiff.sh -r local:"$name" | gitapply.sh
update-cache --refresh
else
@@ -60,7 +60,7 @@
die "tracked \"$tracking\" branch missing!"
if [ -s ".git/HEAD.local" ]; then
- gitdiff.sh "$tracking":local | gitapply.sh
+ gitdiff.sh -r "$tracking":local | gitapply.sh
read-tree $(tree-id local)
update-cache --refresh
--
Martin Schlemmer
[-- Attachment #1.2: git-diff_sh-updates.patch --]
[-- Type: text/x-patch, Size: 1350 bytes --]
gitmerge.sh: 7ea441e584d603463fb1b83991b88f63a3895cff
--- 1/gitmerge.sh
+++ 2/gitmerge.sh 2005-04-18 12:55:34.000000000 +0200
@@ -67,7 +67,7 @@
fi
update-cache --refresh
-gitdiff.sh "$base":"$branch" | gitapply.sh
+gitdiff.sh -r "$base":"$branch" | gitapply.sh
cat >&2 <<__END__
Please inspect the merge in the ,,merge/ subdirectory. Commit from that
gitpull.sh: 9bda6555a1dafc1db762bc46db60d2a9485dc523
--- 1/gitpull.sh
+++ 2/gitpull.sh 2005-04-18 12:55:34.000000000 +0200
@@ -73,7 +73,7 @@
gitmerge.sh -b "$orig_head" "$new_head"
else
- gitdiff.sh "$orig_head":"$new_head" | gitapply.sh
+ gitdiff.sh -r "$orig_head":"$new_head" | gitapply.sh
read-tree $(tree-id $new_head)
echo $new_head >.git/HEAD
gittrack.sh: 30654380c10edde32def8e5fa2e2c956fbff3d58
--- 1/gittrack.sh
+++ 2/gittrack.sh 2005-04-18 12:55:34.000000000 +0200
@@ -50,7 +50,7 @@
echo $name >.git/tracking
read-tree $(tree-id "$name")
- gitdiff.sh local:"$name" | gitapply.sh
+ gitdiff.sh -r local:"$name" | gitapply.sh
update-cache --refresh
else
@@ -60,7 +60,7 @@
die "tracked \"$tracking\" branch missing!"
if [ -s ".git/HEAD.local" ]; then
- gitdiff.sh "$tracking":local | gitapply.sh
+ gitdiff.sh -r "$tracking":local | gitapply.sh
read-tree $(tree-id local)
update-cache --refresh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] fork optional branch point normazilation
From: Martin Schlemmer @ 2005-04-18 10:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brad Roberts, git
In-Reply-To: <Pine.LNX.4.58.0504171636590.7211@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Sun, 2005-04-17 at 16:39 -0700, Linus Torvalds wrote:
>
> On Sun, 17 Apr 2005, Brad Roberts wrote:
> >
> > braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash
> >
> > All gecos entries on all my debian boxes are of the form:
> >
> > fullname, office number, office extension, and home number
>
> Ahh, ok.
>
> I'll make the "cleanup" thing just remove strange characters from the end,
> that should fix this kind of thing for now.
>
> I'd just remove everything after the first strange number, but I can also
> see people using the "lastname, firstname" format, and I'd hate to just
> ignore firstname in that case.
>
If we get the info from /etc/passwd, then we should just use whatever
before the first [,;] (see patch I posted earlier). If not, then I
think AUTHOR_* should be sane).
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [pasky] recent changes to gitdiff.sh
From: Petr Baudis @ 2005-04-18 10:40 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists
In-Reply-To: <1113820808.16288.9.camel@nosferatu.lan>
Dear diary, on Mon, Apr 18, 2005 at 12:40:08PM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Hi,
Hello,
> I see the recent changes to gitdiff.sh requires you to pass -r (git diff
> -r local:$tracking) even if you separate the branches via ':'. Is this
> intended (seems like it)?
yes. This brings the usage style in sync with the rest of the world. :-)
> If so, then gittrack.sh, gitpull.sh and gitmerge.sh needs to be
> updated ...
I hopes I updated all the places. If I missed anything, please say what.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [pasky] recent changes to gitdiff.sh
From: Martin Schlemmer @ 2005-04-18 10:40 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
Hi,
I see the recent changes to gitdiff.sh requires you to pass -r (git diff
-r local:$tracking) even if you separate the branches via ':'. Is this
intended (seems like it)? If so, then gittrack.sh, gitpull.sh and
gitmerge.sh needs to be updated ...
(I did not want to add a patch as I am not sure which it is)
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-18 10:36 UTC (permalink / raw)
To: GIT Mailing Lists
[-- Attachment #1.1: Type: text/plain, Size: 1565 bytes --]
Hi,
The gecos is delimited by ',' or ';', so we should only use whatever
before the first ',' or ';' for the full name, and not just strip those.
Also, a '.' may be valid in the full name (Foo B. Zooman) or email
(foo.zooman@bar.com).
Signed-off-by: Martin Schlemmer <azarah@gentoo.org>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ realgecos[strchr(realgecos, ',') - realgecos] = '\0';
+ else if (strchr(realgecos, ';'))
+ realgecos[strchr(realgecos, ';') - realgecos] = '\0';
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
[-- Attachment #1.2: git-gecos.patch --]
[-- Type: text/x-patch, Size: 967 bytes --]
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ realgecos[strchr(realgecos, ',') - realgecos] = '\0';
+ else if (strchr(realgecos, ';'))
+ realgecos[strchr(realgecos, ';') - realgecos] = '\0';
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Pretty-print date in 'git log'
From: Petr Baudis @ 2005-04-18 10:27 UTC (permalink / raw)
To: David Woodhouse; +Cc: Sanjoy Mahajan, git
In-Reply-To: <1113808105.5286.1.camel@localhost.localdomain>
Dear diary, on Mon, Apr 18, 2005 at 09:08:24AM CEST, I got a letter
where David Woodhouse <dwmw2@infradead.org> told me that...
> On Mon, 2005-04-18 at 07:43 +0100, Sanjoy Mahajan wrote:
> > Is this short script good enough:
>
> It's not far off; thanks. We might as well just do it like that inside
> gitlog.sh. Could do with falling back to just printing the input if it
> can't parse it -- the git repo has old-style dates in it still.
Yes. As far as I'm concerned, I'd put such stuff to git log, and extend
it usage so that it is possible to print individual log entries with it
- just make it accept a _range_ of commits, and then do
git log $commit $commit
And maybe options for changelog-suitable output (RMK-like) etc.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Add help details to git help command.
From: Petr Baudis @ 2005-04-18 10:24 UTC (permalink / raw)
To: Steven Cole; +Cc: git
In-Reply-To: <200504172242.26326.elenstev@mesatop.com>
Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> told me that...
> There's a patch at the bottom of this, so please look at that first before
> my reading my whining immediately below.
>
> I'm having some troubles with git pull, so this is just an ordinary diff.
> Otherwise, I would have used the in-house diff command.
>
> <troubles>
> patch: **** Only garbage was found in the patch input.
> </troubles>
> <more troubles>
> Tracked branch, applying changes...
> error: bad signature
> error: verify header failed
> read_cache: Invalid argument
> error: bad signature
> error: verify header failed
> error: bad signature
> error: verify header failed
> </more troubles>
read-tree $(tree-id) && update-cache --refresh
The directory cache format changed, so it causes this. I'm hoping to
release 0.5 with good cache prepackaged Real Soon Now (tm). :-)
Note that then you will have to recover from the failed apply. If you
had no local commits, it is easy - put that two IDs git pull told
you to git diff and pipe it to git apply. If you had local commits, and
have already GIT version with merge-base, do just git merge pasky and
proceed with the merge. If you don't have merge-base, pass the first
ID from git track to git merge with the -b argument.
> This patch will provide the comment lines in the shell script associated
> with the command, cleaned up a bit for presentation.
>
> BUGS: This will also print any comments in the entire file, which may
> not be desired. If a command name and shell script filename
> do not follow the usual convention, this won't work, e.g. ci for commit.
Hey, those BUGS are the only slightly non-trivial thing on the whole
thing! I could do this patch myself... ;-) Also, you don't want to print
the first newline and the Copyright notices.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Catalin Marinas @ 2005-04-18 10:07 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050416131528.GB19908@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> i've converted the Linux kernel CVS tree into 'flat patchset' format,
> which gave a series of 28237 separate patches. (Each patch represents a
> changeset, in the order they were applied. I've used the cvsps
> utility.)
AFAIK, cvsps uses the date/time to create the changesets. There is a
problem with the BKCVS export since some files in the same commit can
have a different time (by an hour). I posted a mail some time ago
about this -
http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
I read that the old history won't be merged into the new repository
but, if you are interested, I have a script that can do this based on
the "(Logical change ...)" string in the file commit logs and it is
quite fast at generating the patches.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox