* Re: Tracking files across tree reorganizations
From: Martin Langhoff @ 2005-12-15 5:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Linus Torvalds, Git Mailing List
In-Reply-To: <20051215014453.GN22159@pasky.or.cz>
On 12/15/05, Petr Baudis <pasky@suse.cz> wrote:
> in the next few days, consequently making it trivial to add the
> on-the-fly automatic renames detection to per-file cg-log.
Does it matter? Who makes a big file reorg and doesn't put "big tree
reorganization" in the commit message, and can we shoot him?
cheers,
martin
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: Martin Langhoff @ 2005-12-15 5:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43A08B8F.1000901@zytor.com>
On 12/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
> Did anything ever happen with that?
Perhaps I'm slow today, but git-merge -s recursive was supposed to do
it transparently (automagically). At least it was merged into git with
that excuse ;-)
Does it not work for you or am I missing something?
martin
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Junio C Hamano @ 2005-12-15 5:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vlkynrurh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Not really. I take this back. What you want to do I did not
> understand well enough.
>
> HEAD is kinda special. A hack I can think of is to do ls-remote
> first and do the guess clone-pack does for full clone case, and
> then give a specific branch name to clone. That might work.
... and another way would be to do this; I'll put this (with
fixes if there is some needed) in "master" tonight.
Also I might want to give --keep option to fetch-pack as well;
clone-pack has some static functions that we can extract out to
a common file to link to both.
-- >8 --
Subject: [PATCH] clone-pack: make it usable for partial branch cloning.
clone-pack had some logic to accept subset of remote refs from
the command line and clone from there. However, it was never
used in practice and its problems were not found out so far.
This commit changes the command to output the object names of
refs to the standard output instead of making a clone of the
remote repository when explicit <head> parameters are given; the
output format is the same as fetch-pack.
The traditional behaviour of cloning the whole repository by
giving no explicit <head> parameters stays the same.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-clone-pack.txt | 6 +++++-
clone-pack.c | 13 +++++++++++--
2 files changed, 16 insertions(+), 3 deletions(-)
31ec6abf887ec95642cbe82fe61076e975494ab0
diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt
index cfc7b62..39906fc 100644
--- a/Documentation/git-clone-pack.txt
+++ b/Documentation/git-clone-pack.txt
@@ -43,7 +43,11 @@ OPTIONS
The heads to update. This is relative to $GIT_DIR
(e.g. "HEAD", "refs/heads/master"). When unspecified,
all heads are updated to match the remote repository.
-
++
+Usually all the refs from existing repository are stored
+under the same name in the new repository. Giving explicit
+<head> arguments instead writes the object names and refs to
+the standard output, just like get-fetch-pack does.
Author
------
diff --git a/clone-pack.c b/clone-pack.c
index a99a95c..b5ce5d3 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -259,8 +259,17 @@ static int clone_pack(int fd[2], int nr_
status = clone_without_unpack(fd);
- if (!status)
- write_refs(refs);
+ if (!status) {
+ if (nr_match == 0)
+ write_refs(refs);
+ else
+ while (refs) {
+ printf("%s %s\n",
+ sha1_to_hex(refs->old_sha1),
+ refs->name);
+ refs = refs->next;
+ }
+ }
return status;
}
--
0.99.9n
^ permalink raw reply related
* Re: qgit reports errors in the git repository
From: Pavel Roskin @ 2005-12-15 5:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Marco Costalba
In-Reply-To: <Pine.LNX.4.64.0512121700010.15597@g5.osdl.org>
On Mon, 2005-12-12 at 17:06 -0800, Linus Torvalds wrote:
>
> Basically, qgit should do either:
>
> - check the type of the object by hand first (using "git-cat-file -t" and
> then follow any tags it finds by hand)
I'm a complete Qt newbie, but this patch seems to work for me.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
index e08d466..1f6e9ad 100644
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -111,6 +111,10 @@ bool Git::getRefs() {
if (itNext != rLst.constEnd() && (*itNext).right(3) == "^{}") {
signedTag = true;
+ if (!run("git-cat-file -t " + refSha, &runOutput))
+ continue; // invalid SHA1
+ if (runOutput != "tag\n")
+ continue; // not a tag
if (run("git-cat-file tag " + refSha, &runOutput)) {
QString msg(runOutput.section("\n\n", 1));
if (!msg.isEmpty())
--
Regards,
Pavel Roskin
^ permalink raw reply related
* git-svnimport usage with different SVN repo layouts
From: Martin Langhoff @ 2005-12-15 4:47 UTC (permalink / raw)
To: Git Mailing List, Matthias Urlichs
git-svnimport doesn't seem to like the repos I point it to -- there is
something I must be missing when crafting the import invocation.
I am not a subversion user -- so I'm surely missing a lot of subtlety
WRT to the 'each tag is a directory, each branch is a directory'
philosophy. In any case, the repos I'm trying to use seem simple
(though may be broken).
(And, btw, what are the -T and -t parameters? The documentation and
the usage message contradict each other.)
Example:
# this gives me a small repo with 40 commits
svn co svn://elgg.net/devel
# but I could not get any of this to go
git-svnimport svn://elgg.net/devel
# I seem to be having /some/ luck with
git-svnimport -T devel -t releases svn://elgg.net/devel
... at least history shows through. But I am not seeing any files.
Gah. Also tried, without success
git-svnimport -T devel -t releases -b branches svn://elgg.net/devel
and -b branch too.
Another nut I haven't been able to crack has been
http://svn.berlios.de/svnroot/repos/serendipity/
puzzled,
martin
^ permalink raw reply
* [ANNOUNCE] GIT 0.99.9n aka 1.0rc6
From: Junio C Hamano @ 2005-12-15 2:36 UTC (permalink / raw)
To: git, linux-kernel
GIT 0.99.9n aka 1.0rc6 is available at the usual places.
RPM
http://kernel.org:/pub/software/scm/git/RPMS/
Debian
http://kernel.org:/pub/software/scm/git/debian/
I hate to do this, but I ended up merging some more that changes user
experience. Two notable non-fixes are:
- big usage string cleanups (Fredrik).
- git-am enhancements that made a lot of sense for non mbox
users (HPA).
So git is still in perpetual state of 1.0rc X-<.
No more big changes from now on will be merged to the "master"
branch, except fixes and documentation enhancements.
Well, patches are always welcome, but non-fixes will have to
stay in the proposed updates branch until Wednesday 2005-12-21,
which is the date I am aiming the final 1.0 for.
Right now, I have two somewhat debatable patch in the proposed
updates branch:
- when merging a branch that renames A->B and another branch
that renames A->C, merge-recursive leaves B and C in stage 2
and stage 3, instead of registering them at stage 0 as the
current "master" branch does.
- diff gets --abbrev option to shorten the blob object names in
diff-raw and commit object names in diff-tree headers.
These will *not* be in 1.0 final, unless somebody really wants
them and jumps up-and-down.
I personally feel the "renaming merge" desirable if it works
correctly, but (1) it is a rare case anyway, (2) I have not
tested it extensively, and (3) having hacked it myself, I do not
think I will be able to spot bugs that involve cases I have not
thought about. So maybe a good test script and an Ack or two
could push me into moving it forward but otherwise it is slated
post 1.0.
The "diff --abbrev" addition is lower impact and I find it
somewhat cute and especially useful while working on an
80-column terminal, but I'd like to make it find unambiguous
prefix, which it does not do currently, before pushing it out.
I am also holding off another one that changes things to use
textual symref for .git/HEAD everywhere, but I think it is well
known that that change is eventually coming sometime after 1.0.
-- >8 -- shortlog -- >8 --
Amos Waterland:
git rebase loses author name/email if given bad email address
Fredrik Kuivinen:
Usage message clean-up, take #2
Trivial usage string clean-up
git-verify-tag: Usage string clean-up, emit usage string at incorrect invocation
git-revert: Usage string clean-up
git-am: Usage string clean-up
git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
git-cherry: Usage string clean-up, use the 'usage' function
git-fetch: Usage string clean-up, emit usage string at unrecognized option
git-lost-found: Usage string clean-up, emit usage string at incorrect invocation
git-prune: Usage string clean-up, use the 'usage' function
git-rebase: Usage string clean-up, emit usage string at incorrect invocation
git-repack: Usage string clean-up, emit usage at incorrect invocation
H. Peter Anvin:
git-am support for naked email messages (take 2)
Junio C Hamano:
diffcore-break.c: check diff_delta() return value.
Add deltifier test.
diff-delta.c: allow delta with empty blob.
Everyday: some examples.
Revert "diff-delta.c: allow delta with empty blob."
Revert "Add deltifier test."
diffcore-break: do not break too small filepair.
Everyday: a bit more example.
Documentation: more examples.
Documentation: fix missing links to git(7)
Documentation: diff examples.
Documentation: not learning core git commands.
git-clone: tell the user a bit more about clone-pack failure.
allow merging any committish
checkout-index: fix checking out specific path.
Everyday: a bit more examples.
t3200: branch --help does not die anymore.
applypatch: no need to do non-portable [[ ... ]]
Documentation: topic branches
rebase: do not get confused in fast-forward situation.
Do not let errors pass by unnoticed when running `make check'.
mailinfo and git-am: allow "John Doe <johndoe>"
Lukas Sandström:
Bugfixes for git-rebase
Martin Atukunda:
define MAXPATHLEN for hosts that don't support it
Petr Baudis:
Make git-send-pack exit with error when some refs couldn't be pushed out
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-15 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsnzrv43.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 15, 2005 at 02:45:32AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Except that I cannot do the guessing git-clone-pack does (without
> > fetching all the branches)
>
> Exactly my point. If you are not getting all the branches, you
> are not cloning but doing something else.
Ah, play with the words. Sure I'm cloning - however I'm not cloning
a repository but a branch. In Cogito world, that's the only thing that
makes sense to clone, in GIT world it's more complicated (you don't
always clone the whole repository there either, since git-clone-pack
lets you narrow down the refs).
> Extending git-fetch-pack would be the right approach if that is
> what you are trying to do.
I'll then try to extend git-fetch-pack instead. I'll send some fix for
git-clone-pack anyway, though. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Junio C Hamano @ 2005-12-15 1:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsnzrv43.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Except that I cannot do the guessing git-clone-pack does (without
>> fetching all the branches)
>
> Exactly my point. If you are not getting all the branches, you
> are not cloning but doing something else.
Not really. I take this back. What you want to do I did not
understand well enough.
HEAD is kinda special. A hack I can think of is to do ls-remote
first and do the guess clone-pack does for full clone case, and
then give a specific branch name to clone. That might work.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Junio C Hamano @ 2005-12-15 1:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051215013201.GD10680@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Except that I cannot do the guessing git-clone-pack does (without
> fetching all the branches)
Exactly my point. If you are not getting all the branches, you
are not cloning but doing something else.
Extending git-fetch-pack would be the right approach if that is
what you are trying to do.
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: Petr Baudis @ 2005-12-15 1:44 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <43A0AE6B.3040309@zytor.com>
Dear diary, on Thu, Dec 15, 2005 at 12:44:43AM CET, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed
> out several time, losing) -- we already detect renames without relying
> on commit-time metadata. If it's too expensive to generate the metadata
> on every merge, it can be cached.
Just for the record, I'm not convinced at all (there's probably no
point in elaborating the reasons again). I give up, though - I don't
know how to store the explicit rename information "invisibly" so that
Linus would be willing to merge commits containing it, and that would
make the whole thing pretty much pointless at least for the kernel.
I plan to revive some old patches changing large portions of cg-log
in the next few days, consequently making it trivial to add the
on-the-fly automatic renames detection to per-file cg-log.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-15 1:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyovtaub.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 15, 2005 at 02:20:28AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@ucw.cz> writes:
>
> > (i) git-clone-pack url HEAD doesn't work
>
> "clone-pack url branchname" might work, but the thing is, nobody
> uses clone-pack with explicit heads arguments so if HEAD does
> not work I am not surprised at all.
..snip..
> I think extending git-fetch-pack to optionally keep things
> packed would be somewhat painful but the right approach. Less
> painful and readily doable would be to run clone-pack as is, and
> reorganize the result of "copy of the remote" yourself. That
> would be a straightforward thing to do if you are using it for
> the initial cloning.
Except that I cannot do the guessing git-clone-pack does (without
fetching all the branches) - so I guess I'll make a patch tomorrow which
fixes git-clone-pack ... HEAD (probably by checking in write_one_ref()
whether it is looking at a symlink and following it first if that's the
case) and then in Cogito do
git-symbolic-ref HEAD refs/heads/origin
before git-clone-pack (and repoint HEAD back after it's over). That
should do exactly what I need it to, I think.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: new file leaked onto release branch
From: Johannes Schindelin @ 2005-12-15 1:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ja7ures.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 14 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So, it could have been
> >
> > git pull . 5165
> >
> > which mistakes 5165 for a short SHA1?
>
> I do not think git-pull would work on arbitrary SHA1
> expressions, so you should be safe.
D'oh. I wanted to write it short, but I guess that made it only more
confusing. In reality, Len used "git merge", and that works quite well
with short SHA1s.
However, I just verified (as you did also), that they do not take
precedence over branch names (the relevant piece of code is in get_sha1_1:
get_short_sha1() is called only if get_sha1_basic() fails).
> Interestingly...
>
> $ git rev-parse 5165
> error: short SHA1 5165 is ambiguous.
> 5165
>
> that short SHA1 is ambiguous.
I don't want to be a PITA, but it could be ambiguous only since short time
ago.
> But a branch name immediately under .git/refs/heads takes precedence:
>
> $ git branch 5165 master
> $ git rev-parse 5165 master
> acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
> acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
There is an interesting side effect: If 5165 as a short SHA1 would be
unique, and there is a tag *and* a branch named 5165, git-rev-parse would
expand the short SHA1...
However, it still does not solve the original riddle.
Ciao,
Dscho
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Junio C Hamano @ 2005-12-15 1:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051215004440.GM22159@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> (i) git-clone-pack url HEAD doesn't work
"clone-pack url branchname" might work, but the thing is, nobody
uses clone-pack with explicit heads arguments so if HEAD does
not work I am not surprised at all.
> (ii) git-clone-pack has hardcoded assumptions about refs/heads/master
I've read that part of the code twice in the past, but my
recollection is it tries hard to "guess" where HEAD points at
(because the remote side does not tell us, other than which
commit object HEAD points at). When more than two branch heads
point at the same commit as HEAD records, it gives preference to
"master" branch while guessing, but otherwise there is nothing
special about the "master" branch.
The problem is, clone-pack is about cloning and not fetching. I
am not claiming it is the right design decision --- after all,
it was the oldest of the git native protocol driver suite ---
but just stating where it stands with all the history behind its
(and git-fetch-pack's) evolution.
I think extending git-fetch-pack to optionally keep things
packed would be somewhat painful but the right approach. Less
painful and readily doable would be to run clone-pack as is, and
reorganize the result of "copy of the remote" yourself. That
would be a straightforward thing to do if you are using it for
the initial cloning.
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: H. Peter Anvin @ 2005-12-15 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5jzurfi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed
>>out several time, losing) -- we already detect renames without relying
>>on commit-time metadata. If it's too expensive to generate the metadata
>>on every merge, it can be cached.
>
>
> I agree; I was wondering why you brought it up again.
>
Just because of Petr's comment about adding stuff to commit messages.
-hpa
^ permalink raw reply
* How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-15 0:44 UTC (permalink / raw)
To: junkio; +Cc: git
Hello,
I'd like to make cg-clone use git-clone-pack instead of git-fetch-pack
so that it gets actually usable on large repositories, but I'm hitting
problems:
(i) git-clone-pack url HEAD doesn't work
If .git/HEAD already exists, it will panick because of the
write_one_ref()'s O_CREAT|O_EXCL. If .git/HEAD doesn't exist,
git-clone-pack refuses to do anything since it doesn't run
with valid GIT repository.
(ii) git-clone-pack has hardcoded assumptions about refs/heads/master
The problem is, git-clone-pack doesn't seem to care about what
ref does HEAD point to at the remote side, it just starts to
panic and do weird things if it isn't master, which seems
"really really wrong". Also, because git-clone-pack ... HEAD
doesn't work, I think I have no way to clone the actual HEAD
ref of the remote repository.
Overally, I think what I really need is git-fetch-pack (with it
outputting the ref info which I can write on my own, DTRT'ing from
the Cogito POV), just with the option not to unpack the pack.
I'd be very happy if fixing this would be possible before 1.0 so that
I can fix Cogito's fetching over git and ssh ASAP - git-clone-pack's
architecture seems to be way too much hardcoded to carry over head names
to the cloned repository (which is fine for the GIT porcelainish, but
not for Cogito philosophy).
PS: Sorry if this mail is a bit incoherent - I'm already falling
asleep over the keyboard, but I don't want to see GIT 1.0 fly by during
the night. ;-) BTW, Junio, do you have any timeline (more precise than
"in the coming week(s)") for the release, or are you just waiting for
"n days without big problem" or something like that?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-15 0:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512150034120.8992@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So, it could have been
>
> git pull . 5165
>
> which mistakes 5165 for a short SHA1?
I do not think git-pull would work on arbitrary SHA1
expressions, so you should be safe.
Interestingly...
$ git rev-parse 5165
error: short SHA1 5165 is ambiguous.
5165
that short SHA1 is ambiguous. But a branch name immediately
under .git/refs/heads takes precedence:
$ git branch 5165 master
$ git rev-parse 5165 master
acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
And this makes it safer and unambiguous:
$ git branch -d 5165
Deleted branch 5165.
$ git branch bug/5165 master
$ git rev-parse bug/5165
acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
We might want to detect collisions between SHA1 prefix and
branch names, but I am not sure if it is worth it in practice.
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: Junio C Hamano @ 2005-12-15 0:36 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43A0AE6B.3040309@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed
> out several time, losing) -- we already detect renames without relying
> on commit-time metadata. If it's too expensive to generate the metadata
> on every merge, it can be cached.
I agree; I was wondering why you brought it up again.
^ permalink raw reply
* Re: git rebase loses author name/email if given bad email address
From: Junio C Hamano @ 2005-12-15 0:33 UTC (permalink / raw)
To: Amos Waterland; +Cc: git, mostrows
In-Reply-To: <20051214224818.GA5362@kvasir.watson.ibm.com>
Amos Waterland <apw@us.ibm.com> writes:
> If GIT_AUTHOR_EMAIL is of a certain form, `git rebase master' will blow
> away the author name and email when fast-forward merging commits.
True.
> +export GIT_AUTHOR_EMAIL=bogus_email_address
Do not do that, then ;-).
The rebasing involves extracting the patch as an e-mail form and
feeding it to the normal e-mail patch acceptance mechanism, and
mailinfo.c::handle_from() rejects "A U Thor <bogus_address>"
hence you lose the authorship information.
Having said that, maybe e-mail acceptance machinery should
reject such patch.
-- >8 --
Subject: [PATCH] mailinfo and git-am: allow "John Doe <johndoe>"
An isolated developer could have a local-only e-mail, which will
be stripped out by mailinfo because it lacks '@'. Define a
fallback parser to accomodate that.
At the same time, reject authorless patch in git-am.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-am.sh | 7 +++++++
mailinfo.c | 32 +++++++++++++++++++++++++++++++-
2 files changed, 38 insertions(+), 1 deletions(-)
e0e3ba208d235ab5623a86204fbd20b449520764
diff --git a/git-am.sh b/git-am.sh
index 343bee9..1a114bc 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -249,6 +249,13 @@ do
GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' "$dotest/info")"
GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$dotest/info")"
GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
+
+ if test -z "$GIT_AUTHOR_EMAIL"
+ then
+ echo "Patch does not have a valid e-mail address."
+ stop_here $this
+ fi
+
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
diff --git a/mailinfo.c b/mailinfo.c
index d4b4163..9f95f37 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -40,13 +40,43 @@ static char *sanity_check(char *name, ch
return name;
}
+static int bogus_from(char *line)
+{
+ /* John Doe <johndoe> */
+ char *bra, *ket, *dst, *cp;
+
+ /* This is fallback, so do not bother if we already have an
+ * e-mail address.
+ */
+ if (*email)
+ return 0;
+
+ bra = strchr(line, '<');
+ if (!bra)
+ return 0;
+ ket = strchr(bra, '>');
+ if (!ket)
+ return 0;
+
+ for (dst = email, cp = bra+1; cp < ket; )
+ *dst++ = *cp++;
+ *dst = 0;
+ for (cp = line; isspace(*cp); cp++)
+ ;
+ for (bra--; isspace(*bra); bra--)
+ *bra = 0;
+ cp = sanity_check(cp, email);
+ strcpy(name, cp);
+ return 1;
+}
+
static int handle_from(char *line)
{
char *at = strchr(line, '@');
char *dst;
if (!at)
- return 0;
+ return bogus_from(line);
/*
* If we already have one email, don't take any confusing lines
--
0.99.9m
^ permalink raw reply related
* Re: Tracking files across tree reorganizations
From: H. Peter Anvin @ 2005-12-14 23:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051214234504.GL22159@pasky.or.cz>
Petr Baudis wrote:
>>>
>>>(b) If there are no notes for the given commit, we do the rename
>>>autodetection already implemented in GIT. If it yields something,
>>>we follow it.
>>
>>I don't see anything in Linus' posts that says (b) is unacceptable.
>
> If we do it at the walk time, not commit time - I didn't emphasize
> that in my previous mail while I should have.
Exactly. This is the right thing to do, because it means that just
because you made the checkin with version foo, you're forever limited to
the capabilities of version foo.
-hpa
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: Petr Baudis @ 2005-12-14 23:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43A0A6E1.9070903@zytor.com>
Dear diary, on Thu, Dec 15, 2005 at 12:12:33AM CET, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> Petr Baudis wrote:
> >Hah, here we go again. :-)
> >
> >Dear diary, on Wed, Dec 14, 2005 at 10:15:59PM CET, I got a letter
> >where "H. Peter Anvin" <hpa@zytor.com> said that...
> >
> >>Did anything ever happen with that?
> >
> >Linus is against it.
> >
>
> I don't think so. Linus is against the user having to explicitly record
> the moves, but we can detect the moves at the point of reorganization.
Linus' <Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org>:
- you're doing the work at the wrong point for _another_ reason. You're
freezing your (crappy) algorithm at tree creation time, and basically
making it pointless to ever create something better later, because
even if hardware and software improves, you've codified that "we have
to have crappy information".
I tend to agree with this now - although I disagree about his
performance point in the mail; but we can cache the autodetection
results out of commit objects to improve the performance, if it's
worth it (and I suspect it actually isn't, if you don't care about
the "A renamed to B and new A introduced, both in the same commit"
case).
Note that the intent of the explicit rename recording is to really
record file reorganizations, not code refactoring. When you just
reorganize your tree, Linus' "meaningless special case" becomes very
meaningful, because at such point all the code inside the file travels.
But if you just move big chunks of code around and rename files based on
prevailing code origin or something (that's a weird thing to do but I've
seen people do it), then that's probably where the file as a whole
shouldn't be marked renamed.
To encourage this practice, I might check the similarities of the
renamed files at the time of recording them, and print a big fat warning
to the user if it's less than say 90% or so. But I think that the huge
majority of cases where people want to rename is when they reorganize
their trees and move files as a whole, and that's why it's so useful
to support explicit renames recording.
> >Cogito will do it anyway ;-), when someone sends me a nice patch or when
> >I get to it (probably not very soon). I imagine it like this:
> >
> >(a) User can explicitly note file moves / renames. We follow those notes.
> >Probably the most viable for recording the notes is appending them at
> >the tail of the commit message.
> >
> >(b) If there are no notes for the given commit, we do the rename
> >autodetection already implemented in GIT. If it yields something,
> >we follow it.
>
> I don't see anything in Linus' posts that says (b) is unacceptable.
If we do it at the walk time, not commit time - I didn't emphasize
that in my previous mail while I should have.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: H. Peter Anvin @ 2005-12-14 23:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512141538440.3292@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 14 Dec 2005, Petr Baudis wrote:
>
>>Linus is against it.
>>
>>Cogito will do it anyway ;-), when someone sends me a nice patch or when
>>I get to it (probably not very soon). I imagine it like this:
>
> I warn people that if cogito starts polluting the commit messages too
> much, I'll stop pulling from such trees.
>
I agree, putting that into the commit messages sounds like a pretty bad
thing. If anything it should go in the commit header, possibly in the
form of an object reference (with the object carrying the actual data.)
HOWEVER, I maintain that this is unnecessary (and, as Linus has pointed
out several time, losing) -- we already detect renames without relying
on commit-time metadata. If it's too expensive to generate the metadata
on every merge, it can be cached.
-hpa
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: Linus Torvalds @ 2005-12-14 23:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20051214223656.GJ22159@pasky.or.cz>
On Wed, 14 Dec 2005, Petr Baudis wrote:
>
> Linus is against it.
>
> Cogito will do it anyway ;-), when someone sends me a nice patch or when
> I get to it (probably not very soon). I imagine it like this:
I warn people that if cogito starts polluting the commit messages too
much, I'll stop pulling from such trees.
Linus
^ permalink raw reply
* Re: [PATCH] Do not ignore errors during make check
From: Linus Torvalds @ 2005-12-14 23:38 UTC (permalink / raw)
To: Amos Waterland; +Cc: junkio, git
In-Reply-To: <20051214210932.GA2642@kvasir.watson.ibm.com>
On Wed, 14 Dec 2005, Amos Waterland wrote:
>
> check:
> - for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
> + for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || break; done
Actually, you might be better off with just
sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) *.c
these days. It will cause some interesting warnings (it actually
cross-checks things, and is unhappy about multiple "main()" declarations
with different types ;), but especially with eventual libification it
might even be a good idea to try to avoid global functions with the same
names in different programs ("main", of course, is special, sparse is
just too stupid to know).
Linus
^ permalink raw reply
* [PATCH] Bugfixes for git-rebase
From: Lukas Sandström @ 2005-12-14 23:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Lukas Sandström
Fix bugs in git-rebase wrt rebasing another branch than
the current HEAD, rebasing with a dirty working dir,
and rebasing a proper decendant of the target branch.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
Without this patch git rebase complains about
"fatal: cannot read mbox" when doing a fast-forward.
git-rebase.sh | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
2c0e6289d37461abbadb878b9ca8d2bfe2ca1a1b
diff --git a/git-rebase.sh b/git-rebase.sh
index 638ff0d..1e9ddde 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -18,31 +18,30 @@ you still have something valuable there.
exit 1
fi
-# The other head is given. Make sure it is valid.
-other=$(git-rev-parse --verify "$1^0") || exit
-
-# Make sure we have HEAD that is valid.
-head=$(git-rev-parse --verify "HEAD^0") || exit
-
# The tree must be really really clean.
git-update-index --refresh || exit
diff=$(git-diff-index --cached --name-status -r HEAD)
-case "$different" in
+case "$diff" in
?*) echo "$diff"
exit 1
;;
esac
+# The other head is given. Make sure it is valid.
+other=$(git-rev-parse --verify "$1^0") || exit
+
+# Make sure the branch to rebase is valid.
+head=$(git-rev-parse --verify "${2:-HEAD^0}") || exit
+
# If the branch to rebase is given, first switch to it.
case "$#" in
2)
git-checkout "$2" || exit
esac
-# If the HEAD is a proper descendant of $other, we do not even need
-# to rebase. Make sure we do not do needless rebase. In such a
-# case, merge-base should be the same as "$other".
mb=$(git-merge-base "$other" "$head")
+
+#Check if we're already rebased.
if test "$mb" = "$other"
then
echo >&2 "Current branch `git-symbolic-ref HEAD` is up to date."
@@ -51,5 +50,15 @@ fi
# Rewind the head to "$other"
git-reset --hard "$other"
+
+# If the previous HEAD was a proper descendant of $other, we do not even
+# need to rebase. Make sure we do not do needless rebase. In such a
+# case, merge-base should be the same as "$head".
+if test "$mb" = "$head"
+then
+ echo >&2 "Fast-forwarded $head to $other."
+ exit 0
+fi
+
git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
git am --binary -3 -k
--
0.99.9.GIT
^ permalink raw reply related
* RE: new file leaked onto release branch
From: Johannes Schindelin @ 2005-12-14 23:34 UTC (permalink / raw)
To: Brown, Len; +Cc: Junio C Hamano, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056B8748@hdsmsx401.amr.corp.intel.com>
Hi,
On Wed, 14 Dec 2005, Brown, Len wrote:
> >BTW, are 5165, 3410, 5452, 5571... topic branch names?
>
> yes, the are bugzilla ids
So, it could have been
git pull . 5165
which mistakes 5165 for a short SHA1?
Hth,
Dscho
^ 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