* Re: Which packages/versions are needed to build documentation
From: Simon Richter @ 2005-11-09 17:24 UTC (permalink / raw)
To: Alan Chandler, git
In-Reply-To: <200511091655.51093.alan@chandlerfamily.org.uk>
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
Hi,
> On my debian sarge system it fails almost immediately
Just take the asciidoc package from unstable, last time I looked it had
no dependencies that were unfulfillable from sarge.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: Real-life kernel debugging scenario
From: wa1ter @ 2005-11-09 17:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511071721200.3247@g5.osdl.org>
On Mon, 7 Nov 2005, Linus Torvalds wrote:
[...]
> The way to use "git bisect" couldn't be easier.
I see that Junio just added your entire response to Documentation/howto/
isolate-bugs-with-bisect.txt where even I could manage to find it :o)
> Also, figure out the most recent known-good commit (usually the _previous_
> kernel you ran: and if you've only done a single "pull" in between, it
> will be ORIG_HEAD).
The built-in variable ORIG_HEAD isn't explained anywhere AFAICT, or at
least it wasn't until today. Are there other such magic variables which
might be useful for us to know about?
^ permalink raw reply
* Re: Real-life kernel debugging scenario
From: Jon Loeliger @ 2005-11-09 18:17 UTC (permalink / raw)
To: wa1ter; +Cc: Git List
In-Reply-To: <Pine.LNX.4.64.0511090901370.6744@x2.ybpnyarg>
On Wed, 2005-11-09 at 11:40, wa1ter@myrealbox.com wrote:
>
> On Mon, 7 Nov 2005, Linus Torvalds wrote:
>
> [...]
> > The way to use "git bisect" couldn't be easier.
>
> I see that Junio just added your entire response to
> Documentation/howto/
> isolate-bugs-with-bisect.txt where even I could manage to find it :o)
Why, thank you. :-)
> The built-in variable ORIG_HEAD isn't explained anywhere AFAICT, or at
> least it wasn't until today. Are there other such magic variables
> which
> might be useful for us to know about?
Hey Junio,
I'm going to call "I told you so!" on this one! :-)
Ref:
Message-ID: <E1EXTw5-00063o-Gt@jdl.com>
From: Jon Loeliger <jdl@freescale.com>
Subject: Now What?
Date: Wed, 2 Nov 2005 18:30:37 -0700
Where in I mumbled:
I feel that an explanation of all of the behind-the-scripts-
in-.git communication files is needed. In particular these:
FETCH_HEAD
MERGE_HEAD
LAST_MERGE
MERGE_MSG
These need to be mentioned and explained because they
frequently form exactly the critical missing link or
starting point after a failed fetch or merge.
You know.
jdl
^ permalink raw reply
* Re: Which packages/versions are needed to build documentation
From: Junio C Hamano @ 2005-11-09 18:22 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511091655.51093.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> I have just downloaded git-core-0.99f
>
> On my debian unstable system I can build the documentation just fine
>
> On my debian sarge system it fails almost immediately
The debs on kernel.org were done in a chrooted sarge environment
(vanilla + security) with one exception: asciidoc 7.
I tried to make the documentation usable with asciidoc 6 as
well, but it turns out that not having xhtml11 is the least of
the problems with version 6 (see my message the other day).
^ permalink raw reply
* Re: Real-life kernel debugging scenario
From: Linus Torvalds @ 2005-11-09 18:36 UTC (permalink / raw)
To: wa1ter; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511090901370.6744@x2.ybpnyarg>
On Wed, 9 Nov 2005, wa1ter@myrealbox.com wrote:
>
> The built-in variable ORIG_HEAD isn't explained anywhere AFAICT, or at
> least it wasn't until today. Are there other such magic variables which
> might be useful for us to know about?
No, ORIG_HEAD is pretty much it.
There's a few special files that a non-committed merge leaves around
(either because you asked it to not be committed, or because it had
clashes and requires manual fixing), but they are not normally useful to
any regular people. You can poke around in the ".git" directory after such
a merge if you want (MERGE_HEAD, MERGE_MSG).
ORIG_HEAD is _very_ useful, though, and I use it all the time. Any time
you've pulled something from somebody else, and you wonder what you
pulled, just go
gitk ORIG_HEAD..
and you'll see exactly what new stuff you got in your branch. I often do
that command line several times a day as I merge stuff. Otherwise the new
stuff tends to be hidden in the noise.
(There's also FETCH_HEAD, which is the head of the last fetch, so if you
aren't interested in any potential merge, you could instead use the range
ORIG_HEAD..FETCH_HEAD, but quite frankly, I doubt anybody really cares
except for the internal git fetching/pulling logic).
Linus
^ permalink raw reply
* Re: Which packages/versions are needed to build documentation
From: Alan Chandler @ 2005-11-09 18:49 UTC (permalink / raw)
To: git
In-Reply-To: <437230C1.3090700@debian.org>
On Wednesday 09 Nov 2005 17:24, Simon Richter wrote:
> Hi,
>
> > On my debian sarge system it fails almost immediately
>
> Just take the asciidoc package from unstable, last time I looked it had
> no dependencies that were unfulfillable from sarge.
>
> Simon
Thanks - working now - although I needed to also install xmlto
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-09 20:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511090800330.3247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> That "extra" check only helps once. If we ever hit the "extra--", it's
> gone.
I think you are right here, but while digging into this I found
an interesting case.
The current show-branch code does the same as merge-base in the
pathological example depicted in merge-base.c, but they seem to
do different things to this picture (commit grows from bottom to
top, time flows alphabetically; find base between G and H).
H
/ \
G A \
|\ / \
| B \
| \ \
\ C F
\ \ /
\ D /
\ | /
\| /
E
"git-merge-base --all" says the merge bases are B and E, while
"show-branch --merge-base" mentions only B. In this case the
latter is probably the better answer. Actually git-merge-base
without --all only mentions E. This is because we give up when
we find the list elements are all uninteresting. And this is
very expensive to fix (I recall mentioning "horizon effect" last
time we worked on this --- around August 12th).
G gets bit 1 and H gets bit 2. Here is what happens in each
iteration:
List A B C D E F G H Result
G1 H2 - - - - - - 1 2
H2 E1 B1 - 1 - - 1 - 1 2
F2 E1 B1 A2 2 1 - - 1 2 1 2
E3 B1 A2 2 1 - - 3 2 1 2 E3
B1 A2 2 1 - - 3 2 1 2 E3
C1 A2 2 1 1 - 3 2 1 2 E3
D1 A2 2 1 1 1 3 2 1 2 E3
A2 2 1 1 1 3 2 1 2 E3
B3 2 3 1 1 3 2 1 2 E3 B3
C7 2 3 7 1 3 2 1 2 E3 B3
We popped B with flag 3, and started contaminating the well by
reinjecting its parent C with flag 7. That is all good, but
"while (interesting(list))" check stops us from going further.
Ideally the following two steps would have found out that E is
also uninteresting.
D7 2 3 7 7 3 2 1 2
E7 2 3 7 7 7 2 1 2
But that is expensive -- we would not know when to stop.
A reproduction recipe is attached here, primarily so I do not
have to worry about losing it from /var/tmp/.
-- >8 -- cut here -- >8 --
#!/bin/sh
rm -fr .git && git-init-db
T=$(git-write-tree)
M=1130000000
Z=+0000
export GIT_COMMITTER_EMAIL=git@comm.iter.xz
export GIT_COMMITTER_NAME='C O Mmiter'
export GIT_AUTHOR_NAME='A U Thor'
export GIT_AUTHOR_EMAIL=git@au.thor.xz
doit() {
OFFSET=$1; shift
NAME=$1; shift
PARENTS=
for P
do
PARENTS="${PARENTS}-p $P "
done
GIT_COMMITTER_DATE="$(($M + $OFFSET)) $Z"
GIT_AUTHOR_DATE=$GIT_COMMITTER_DATE
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
commit=$(echo $NAME | git-commit-tree $T $PARENTS)
echo $commit >.git/refs/tags/$NAME
echo $commit
}
checkit() {
echo MB
git-merge-base --all "$@" | xargs git-name-rev
echo SB
git-show-branch --merge-base "$@" | xargs git-name-rev
git-show-branch --sha1-name --more=99 "$@"
}
E=$(doit 5 E)
D=$(doit 4 D $E)
F=$(doit 6 F $E)
C=$(doit 3 C $D)
B=$(doit 2 B $C)
A=$(doit 1 A $B)
G=$(doit 7 G $B $E)
H=$(doit 8 H $A $F)
checkit $G $H
exit
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-09 20:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EZqAA-0002B0-Un@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> Normally you can just do "make" followed by "make install", and that
> will install the git programs in your own ~/bin/ directory. If you want
> to do a global install, you can do
>
> make prefix=/usr install
>
> I ran "make" as myself, and then later
> I ran "make prefix=/usr install" as root.
Would this be explicit enough?
-- >8 -- cut here -- >8 --
diff --git a/INSTALL b/INSTALL
index bbb13f3..b2cdb31 100644
--- a/INSTALL
+++ b/INSTALL
@@ -7,8 +7,10 @@ to do a global install, you can do
make prefix=/usr install
-(or prefix=/usr/local, of course). Some day somebody may send me a RPM
-spec file or something, and you can do "make rpm" or whatever.
+(or prefix=/usr/local, of course). Just like any program suite
+that uses $prefix, the built results have some paths encoded,
+which are derived from $prefix, so "make all; make prefix=/usr
+install" would not work.
Issues of note:
^ permalink raw reply related
* Problem with template location
From: Alan Chandler @ 2005-11-09 20:45 UTC (permalink / raw)
To: git
I am trying to set up a public repository on my server to which I can push
stuff
I have just downloaded the git-core-0.99f-tar.bz2 file and untarred it as me
(alan) on account on the server. My home directory is at /home/alan
Went in as me into the git-core-0.99f directory and did a make
Then became ROOT and did
make prefix=/usr/local install
(I also built the documentation but I don't think that is relevent)
Separately AS ROOT I have gone into the directory where I am going to build my
repositories (/var/lib/git) and tried to build the repository as per the
tutorial.
roo:/var/lib/git# mkdir famtree.git
roo:/var/lib/git# GIT_DIR=famtree.git git-init-db
warning: templates not found /home/alan/share/git-core/templates/
roo:/var/lib/git#
git-init-db seems to have got the wrong place for the templates - ie the
account where I originally built the code.
(NOTE: the templates have actually been installed
in /usr/local/share/git-core/templates)
I had to do a make clean, but following that I did
make prefix=/usr/local
for the first part, and then re-installed (also with the prefix) and it
solves the problem
I don't know whether this is something that can be fixed at install time, or
whether the README should be changed to make it clear that you need the
prefix on the first stage of the process as well as the second.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Problem with template location
From: Jon Loeliger @ 2005-11-09 21:06 UTC (permalink / raw)
To: Alan Chandler; +Cc: Git List
In-Reply-To: <200511092045.55300.alan@chandlerfamily.org.uk>
On Wed, 2005-11-09 at 14:45, Alan Chandler wrote:
>
> Went in as me into the git-core-0.99f directory and did a make
>
> Then became ROOT and did
>
> make prefix=/usr/local install
I don't know. There is something so... so... synchronatic
about this all... :-)
jdl
^ permalink raw reply
* Re: Regarding: git-lost+found
From: Junio C Hamano @ 2005-11-09 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511081811080.18406@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I think this is a valuable addition to the "Now what?" part of git.
> However, I'd like to see the results stored into .git/refs/lost+found/
> rather than .git/lost+found/, so that it is possible to inspect them
> easily with gitk or git-show-branch.
I've thought about it, but on the other hand, having them under
refs/ hierarchy means fsck-objects would think they are relevant
and prune would never be able to remove them anymore.
The scenario that git-lost+found would be useful is after you
did 'git branch -D', 'git tag -d', or 'git tag -f' and removed
something you did not mean to by accident. You would find what
you want with git-lost+found and perhaps with help from gitk,
and then reconnect them. At that point, it is very likely that
you would forget to clean the remainder afterwards. Later, you
probably forget you have ever run git-lost+found, and would
start wondering why git-prune would not remove any leftover
anymore.
Maybe we could use .git/lost+found/{commit,other}/?{40} and hang
committish under one directory and the rest in another? Then we
could do this:
$ gitk $(cd .git/lost+found/commit && echo ??*)
After you find what you want, you would do 'git tag' or 'git
branch' to reconnect them, but we can reasonably expect that is
to happen soon after you ran lost+found and before the next time
you run prune, because that was why you ran git-lost+found in
the first place.
Prune will remove the objects reachable only from lost+found, so
the above gitk command line would fail if run after you did
git-lost+found and then git-prune in this order, but that is an
unlikely sequence.
So, based on the above reasoning, how about this one?
-- >8 -- cut here -- >8 --
[PATCH] lost+found: make it a bit more useful with gitk
This separates the committish from others when resurrecting
dangling objects to .git/lost+found/ hierarchy. After running
git-lost+found command, you could:
$ gitk $(cd .git/lost+found/commit && echo ??*)
to see how these branches came about from known old tags.
---
diff --git a/git-lost+found.sh b/git-lost+found.sh
index bc1e988..b6b2616 100755
--- a/git-lost+found.sh
+++ b/git-lost+found.sh
@@ -3,18 +3,21 @@
. git-sh-setup || die "Not a git archive."
laf="$GIT_DIR/lost+found"
-mkdir -p "$laf" || exit
+rm -fr "$laf" && mkdir -p "$laf/commit" "$laf/other" || exit
git fsck-objects |
while read dangling type sha1
do
case "$dangling" in
dangling)
- echo "$sha1" >"$laf/$sha1"
- case "$type" in
- commit | tag)
- git-show-branch "$sha1" ;;
- esac
+ if git-rev-parse --verify "$sha1^0" >/dev/null 2>/dev/null
+ then
+ dir="$laf/commit"
+ git-show-branch "$sha1"
+ else
+ dir="$laf/other"
+ fi
+ echo "$sha1" >"$dir/$sha1"
;;
esac
done
^ permalink raw reply related
* Re: Problem with template location
From: Junio C Hamano @ 2005-11-09 21:29 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511092045.55300.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> I don't know whether this is something that can be fixed at install time, or
> whether the README should be changed to make it clear that you need the
> prefix on the first stage of the process as well as the second.
Thanks Alan and Jon. This seems to be hitting some people so
here is what I plan to push out.
-- >8 -- cut here -- >8 --
Subject: Update INSTALL
Explicitly mention how to install by hand in build-as-user and
install-as-root steps.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
INSTALL | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
applies-to: 132cf7a143b9ed08e69399da6caa0c627d26f181
c44922a7817398d63bb2b46dc599bd05c710e746
diff --git a/INSTALL b/INSTALL
index bbb13f3..06b11e1 100644
--- a/INSTALL
+++ b/INSTALL
@@ -5,10 +5,13 @@ Normally you can just do "make" followed
will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
- make prefix=/usr install
+ $ make prefix=/usr ;# as yourself
+ # make prefix=/usr install ;# as root
-(or prefix=/usr/local, of course). Some day somebody may send me a RPM
-spec file or something, and you can do "make rpm" or whatever.
+(or prefix=/usr/local, of course). Just like any program suite
+that uses $prefix, the built results have some paths encoded,
+which are derived from $prefix, so "make all; make prefix=/usr
+install" would not work.
Issues of note:
---
0.99.9.GIT
^ permalink raw reply related
* Problems with binary patches (pull) and spaces in filenames (gitk)
From: Peter Eriksen @ 2005-11-09 21:37 UTC (permalink / raw)
To: git
Hello,
I've got a nice project, where I am tracking both binary files and
filenames with spaces. So, I've noticed two small cosmetic bugs:
1) When pulling an updated binary files, I guess it still tries to
print this update summary by making and processing patches, and so
gives this error:
Updating from ab1c4033ba98c043e13da3446e7f244ac7f79942 to
c164231f6b59fd80171e95f31d762a80d884c708.
Fast forward
fatal: patch with only garbage at line 3249
2) When there are spaces in filenames, gitk only shows the first part of
the name in the filelist at the buttom right.
Regards,
Peter
^ permalink raw reply
* succesfull use of git-shell
From: Alan Chandler @ 2005-11-09 21:52 UTC (permalink / raw)
To: git
I just wanted to give a heads-up on a successful set up and push to a
repository where the account accessing the repository runs git-shell.
It turned out to be extremely simple to do - but the documentation that I
could find is so terse in places that I wasn't sure it was going to work
until I tried it. Two main issues.
1) the man page for git-push describes <repository> as
remote.machine:/path/to/repo.git/
the tutorial isn't much help either as it says
git push <public-host>:/path/to/my-git.git master
whereas I knew I wanted to access an account that was different from mine
2) the directory paths are always specified as absolute in the documentation,
but (particularly if you are going to set up a public repository which
several people may be pushing to) its helpful not to know exactly which path
on the server the repository exists.
In my setup I did the following simple things
1) created an account called git with a home directory at /var/lib/git and a
shell of /usr/local/bin/git-shell (you can see where my git is installed) on
my server (called roo.home)
2) created a an empty repository at /var/lib/git/famtree.git
a) Logged in as root into the machine that was the server
b) Became a git user with
su -s /bin/bash git
(You can't do a normal su git because the default shell immediately throws you
straight out again)
c) mkdir famtree.git; GIT_DIR=famtree.git git-init-db
d) chmod +x famtree.git/hooks/post-update
(planning to allow http anonymous access)
3) back on my development machine - pushed the master branch of my current
repository out to the new one just created with
git-push git@roo.home:famtree.git
It is this last simple command line that I _really_ like. If I wanted to set
up some form of centralised development with multiple access to the
repository, I only have to append the public keys of those people into the
authorized_keys file on that account on the server and I am done.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Comments on recursive merge..
From: Linus Torvalds @ 2005-11-09 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virv1efzv.fsf@assigned-by-dhcp.cox.net>
On Wed, 9 Nov 2005, Junio C Hamano wrote:
>
> The current show-branch code does the same as merge-base in the
> pathological example depicted in merge-base.c, but they seem to
> do different things to this picture (commit grows from bottom to
> top, time flows alphabetically; find base between G and H).
>
> H
> / \
> G A \
> |\ / \
> | B \
> | \ \
> \ C F
> \ \ /
> \ D /
> \ | /
> \| /
> E
>
> "git-merge-base --all" says the merge bases are B and E, while
> "show-branch --merge-base" mentions only B. In this case the
> latter is probably the better answer.
I don't agree.
Sure, B _may_ be the right answer for a particular merge strategt, but
there's no way of knowing. Maybe all the big changes came in through F,
and H is the merge that sorted that out, and E actually ends up being the
better base.
So I think from a correctness standpoint, the only thing that matters is
"git-merge-base --all", and anything that doesn't know to return both E
and B looks potentially buggy.
> Actually git-merge-base without --all only mentions E.
Well, we should really consider anything that doesn't take them all into
account to be a bug waiting to happen (or rather, a merge waiting for a
disaster), but E is the right one, since it's the more recent one).
Now, this case obviously depends on history being almost maximally insane
(ie pretty much _all_ the dates are wrong). So in practice we probably
don't care.
So maybe "git-show-branch --merge-base" ends up acceptable as a faster way
to do the quick "let's see if we can find _some_ merge-base to do the
in-index merge with", but personally I'd much rather always do a
"git-merge-base --all", and only do the fast index merge if we only have
one potential parent.
That way there would never any question about what the "quick merge" does.
Linus
^ permalink raw reply
* Re: succesfull use of git-shell
From: Alan Chandler @ 2005-11-09 22:00 UTC (permalink / raw)
To: git
In-Reply-To: <200511092152.07195.alan@chandlerfamily.org.uk>
On Wednesday 09 Nov 2005 21:52, Alan Chandler wrote:
> git-push git@roo.home:famtree.git
Whoops: missed off master of the end of that line (although do you need it?)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Problem with template location
From: Peter Eriksen @ 2005-11-09 21:49 UTC (permalink / raw)
To: git
In-Reply-To: <200511092045.55300.alan@chandlerfamily.org.uk>
On Wed, Nov 09, 2005 at 08:45:55PM +0000, Alan Chandler wrote:
> I am trying to set up a public repository on my server to which I can push
> stuff
>
> I have just downloaded the git-core-0.99f-tar.bz2 file and untarred it as me
> (alan) on account on the server. My home directory is at /home/alan
>
> Went in as me into the git-core-0.99f directory and did a make
>
> Then became ROOT and did
>
> make prefix=/usr/local install
Hey, I fell over this today also. To me it's really quite unintuitive.
Regards,
Peter
^ permalink raw reply
* Re: Problems with binary patches (pull) and spaces in filenames (gitk)
From: Junio C Hamano @ 2005-11-09 22:09 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20051109213730.GA23052@ebar091.ebar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> 1) When pulling an updated binary files, I guess it still tries to
> print this update summary by making and processing patches, and so
> gives this error:
>
> Updating from ab1c4033ba98c043e13da3446e7f244ac7f79942 to
> c164231f6b59fd80171e95f31d762a80d884c708.
> Fast forward
> fatal: patch with only garbage at line 3249
Hmm. Perhaps a suboption to git-apply --stat to tell it not to
barf is helpful? In the meantime, could you pull with -n flag?
> 2) When there are spaces in filenames, gitk only shows the first part of
> the name in the filelist at the buttom right.
Another minor gitk gripe I have is that it does not look at
subdirectories of refs/{heads,tags}/ so I do not get labels to
my topic branch heads.
^ permalink raw reply
* Re: Problems with binary patches (pull) and spaces in filenames (gitk)
From: Linus Torvalds @ 2005-11-09 22:10 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20051109213730.GA23052@ebar091.ebar.dtu.dk>
On Wed, 9 Nov 2005, Peter Eriksen wrote:
>
> 1) When pulling an updated binary files, I guess it still tries to
> print this update summary by making and processing patches, and so
> gives this error:
>
> Updating from ab1c4033ba98c043e13da3446e7f244ac7f79942 to
> c164231f6b59fd80171e95f31d762a80d884c708.
> Fast forward
> fatal: patch with only garbage at line 3249
Yes, this is "git-apply --stat" being unhappy about an empty patch.
Maybe we should only be unhappy when actually trying to apply (or check)
the patch.
So a patch like the appended may or may not be the right solution.
> 2) When there are spaces in filenames, gitk only shows the first part of
> the name in the filelist at the buttom right.
Can't help you there, that's more tcl/tk than I know. Paul?
Linus
---
diff --git a/apply.c b/apply.c
index 3e53b34..da1416a 100644
--- a/apply.c
+++ b/apply.c
@@ -890,7 +890,7 @@ static int parse_chunk(char *buffer, uns
patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
- if (!patchsize && !metadata_changes(patch))
+ if ((check ||apply) && !patchsize && !metadata_changes(patch))
die("patch with only garbage at line %d", linenr);
return offset + hdrsize + patchsize;
^ permalink raw reply related
* Re: latest stg/git commandline completions code
From: Petr Baudis @ 2005-11-09 22:23 UTC (permalink / raw)
To: Ben Clifford; +Cc: Blaisorblade, git
In-Reply-To: <A44A02AA-BDA8-4623-825E-288F1107A5ED@hawaga.org.uk>
Dear diary, on Tue, Nov 08, 2005 at 11:16:28AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> told me that...
> I've added some stuff to this to do a few cogito, gitk and (one) git
> completions, split into different files. I thought I might as well
> toss what I have out for anyone interested to play with.
>
> I tried to put it in a new git repo online, but I'm having
> difficulties - the poor link I'm on makes it not so much fun to
> experiment. So I've tarred up my local repo warts and all and put it at:
>
> http://www.hawaga.org.uk/ben/tech/gitcompletion-
> a108bdc110dad770ec5c092759a8bc511790d21f.tar
Nice, I would like to add cg completion to Cogito's contrib/ - could you
please add some header to it with (c) information and stuff? (And make
it available somewhere just as a plain file.)
Besides, it would be probably best to just autogenerate the
auto-completion code - the usage information in Cogito is supposed to be
100% consistent and correct, so it should be a reliable source for that.
--
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
* [PATCH] CVSps fixed, git-cvsimport still buggy (WAS: [OT] ancestor branch in cvsps is wrong for branch-of-branch)
From: Chris Shoemaker @ 2005-11-09 22:26 UTC (permalink / raw)
To: git; +Cc: cvsps, David Mansfield, Martin Langhoff
In-Reply-To: <20051101035148.GA11807@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]
[This is now on-topic.]
I tried the git-cvsimport script and found that in the
resulting git tree, on a branch-off-a-branch, files were missing from
the branch if they had been added to the branch's immediate parent. I
really wanted this to work better, so I looked into it and learned
that CVSps was incorrectly reporting that the "ancestor" branch was
HEAD for a branch-off-a-branch.
Since CVSps wasn't reporting the correct branch relationships, I
couldn't blame git-cvsimport. Trying to improve CVSps to get better
parent-detection proved much harder than I expected. I had to use a
completely different algorithm that loops over all files instead of
just the files in the patchsets that are on the child branch.
Now that I've done that, [David, please see attached patch] CVSps does
report more accurate branch parents. But, testing git-cvsimport with
the corrected CVSps output shows that it *still* doesn't produce the
right tree. In fact, it's WORSE! In the simple test script, not only
is file 'b' not on the 'dev' branch, but the 'stable' branch and the
file 'b' is completely MISSING form the git tree!
I could cut git-cvsimport some slack for failing to infer that file
'b' is also on the 'dev' branch, since I learned how hard that is when
I taught CVSps to make that inference. But completely missing a
branch and all files added to it is not good.
I'd *really* like to be told I'm off the deep end here, so if anyone
can set me straight please do.
If you want to reproduce this bug, use the test-script from my
original post (actually, I'll attach it again - it's been a while).
But you must first apply the attached patch to CVSps; or you can
instead use the '-P cvsps.out' option [which is quite handy BTW] to
git-cvsimport after you correct the one "Ancestor:" line from "HEAD"
to "stable" which is the only effect the new algorithm has on this
simple test case. Note: the script demonstrates that 'b' is missing
from 'dev'. To notice that 'stable' and 'b' are missing altogether
you have to say 'git-branch'.
If this stuff makes your head hurt like it does mine, you may want to
refer to the notes that I had to take in order to work through
this a half-hour at a time: http://www.codesifter.com/cvsps-notes.txt
-chris
[-- Attachment #2: ancestor.diff --]
[-- Type: text/plain, Size: 13200 bytes --]
cvsps.c | 242 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
cvsps_types.h | 2
2 files changed, 240 insertions(+), 4 deletions(-)
Index: cvsps-2.1/cvsps.c
===================================================================
--- cvsps-2.1.orig/cvsps.c
+++ cvsps-2.1/cvsps.c
@@ -81,9 +81,12 @@ static int ignore_cache;
static int do_write_cache;
static int statistics;
static const char * test_log_file;
+/* branch_heads actually store branch "roots": [char *] to [PatchSet *]
+ * It's only used by the track_branch_ancestry option. */
static struct hash_table * branch_heads;
static struct list_head all_patch_sets;
static struct list_head collisions;
+static struct list_head all_branches;
/* settable via options */
static int timestamp_fuzz_factor = 300;
@@ -143,8 +146,10 @@ static void set_psm_initial(PatchSetMemb
static int check_rev_funk(PatchSet *, CvsFileRevision *);
static CvsFileRevision * rev_follow_branch(CvsFileRevision *, const char *);
static int before_tag(CvsFileRevision * rev, const char * tag);
-static void determine_branch_ancestor(PatchSet * ps, PatchSet * head_ps);
+static void determine_branch_ancestor(const PatchSet * ps, PatchSet * head_ps);
static void handle_collisions();
+static void find_branch_parent(PatchSet *ps);
+static int is_ancestor_rev(const char *rev1, const char *rev2);
int main(int argc, char *argv[])
{
@@ -181,6 +186,7 @@ int main(int argc, char *argv[])
branch_heads = create_hash_table(1023);
INIT_LIST_HEAD(&all_patch_sets);
INIT_LIST_HEAD(&collisions);
+ INIT_LIST_HEAD(&all_branches);
/* this parses some of the CVS/ files, and initializes
* the repository_path and other variables
@@ -1259,6 +1265,29 @@ static int get_branch(char * buff, const
return get_branch_ext(buff, rev, NULL);
}
+/* Doesn't have to handle magic branches because parse_sym already did. */
+static int is_ancestor_rev(const char *rev1, const char *rev2)
+{
+ char b1[REV_STR_MAX], b2[REV_STR_MAX];
+ int len1 = strlen(rev1);
+ int len2 = strlen(rev2);
+ int leaf1, leaf2;
+
+ if (len1 > len2)
+ return 0;
+
+ if (strncmp(rev1, rev2, len1) == 0 || strcmp(rev1, "INITIAL") == 0)
+ return 1;
+
+ if (!get_branch_ext(b1, rev1, &leaf1) || !get_branch_ext(b2, rev2, &leaf2))
+ return 0;
+
+ if (strcmp(b1, b2) == 0 && leaf2 >= leaf1)
+ return 1;
+
+ return 0;
+}
+
/*
* the goal if this function is to determine what revision to assign to
* the psm->pre_rev field. usually, the log file is strictly
@@ -1499,11 +1528,15 @@ static void assign_patchset_id(PatchSet
PatchSet * head_ps = (PatchSet*)get_hash_object(branch_heads, ps->branch);
if (!head_ps)
{
+ Tag *tag;
head_ps = ps;
put_hash_object(branch_heads, ps->branch, head_ps);
+ find_branch_parent(ps);
+ tag = (Tag*)malloc(sizeof(*tag));
+ tag->tag = ps->branch;
+ /* This is our own private tag list, so we use global_link.*/
+ list_add(&tag->global_link, &all_branches);
}
-
- determine_branch_ancestor(ps, head_ps);
}
}
else
@@ -2394,6 +2427,8 @@ void patch_set_add_member(PatchSet * ps,
static void set_psm_initial(PatchSetMember * psm)
{
+ char *p;
+
psm->pre_rev = NULL;
if (psm->post_rev->dead)
{
@@ -2405,6 +2440,27 @@ static void set_psm_initial(PatchSetMemb
debug(DEBUG_APPMSG1, "WARNING: branch_add already set!");
psm->ps->branch_add = 1;
}
+
+ /* Maybe this is the best place to record which branch a file was
+ initially added on. It seems the most accurate way is
+ also painful - read the commit message. */
+ if (psm->file->initial_branch)
+ debug(DEBUG_APPMSG1, "WARNING: initial_branch already set!");
+
+ psm->file->initial_ps = psm->ps;
+
+ p = strstr(psm->ps->descr, " was initially added on branch ");
+ if (p) {
+ char * end;
+ p += strlen(" was initially added on branch ");
+ end = strchr(p, '.');
+ if (end) {
+ *end = 0;
+ psm->file->initial_branch = get_string(p);
+ return;
+ }
+ }
+ psm->file->initial_branch = psm->ps->branch;
}
/*
@@ -2532,7 +2588,13 @@ static void check_norc(int argc, char *
}
}
-static void determine_branch_ancestor(PatchSet * ps, PatchSet * head_ps)
+/* When we track ancestor branches, we run determine_branch_ancestor()
+ * for every ps not on HEAD. But, we only record the ancestor in
+ * head_ps. head_ps is the first (i.e. "root") ps on the same branch as
+ * ps (which may be the same as ps). In other words, we record the
+ * ancestor branch in the first patch that "branched-off".
+ */
+static void determine_branch_ancestor(const PatchSet * ps, PatchSet * head_ps)
{
struct list_head * next;
CvsFileRevision * rev;
@@ -2599,6 +2661,178 @@ static void determine_branch_ancestor(Pa
}
}
+/* only needs to be called once for each new branch we start */
+static void find_branch_parent(PatchSet *ps)
+{
+ const char* child = ps->branch;
+ char* parent;
+ struct list_head *next;
+ struct hash_entry * he_file;
+ Tag *tag;
+
+ /* We use the 'rev' struct member unconventionally: as a flag to mark
+ which branches have not yet been eliminated from consideration. */
+
+ /* Mark every branch for consideration. */
+ for (next = all_branches.next; next != &all_branches; next = next->next)
+ {
+ tag = list_entry(next, Tag, global_link);
+ tag->rev = (CvsFileRevision *) 1; /* cast just to silence compiler */
+ }
+
+ reset_hash_iterator(file_hash);
+ while ((he_file = next_hash_entry(file_hash)))
+ {
+ CvsFile *file = (CvsFile*)he_file->he_obj;
+
+ if (!file->initial_branch) {
+ debug(DEBUG_APPERROR, "invalid initial_branch for file %s, probably from old cache, run with -x.", file->filename);
+ exit(1);
+ }
+
+ /* If the file was introduced later than the branch point, we
+ don't consider it. NOTE: this won't catch the case where a
+ file is added to branch A, then later branch C branches off
+ of branch B, then branch A is merged into branch C. In
+ that case, the initial date for the file is earlier than
+ the root-branch patchset, so the absence of the file from
+ branch B *DOES* eliminate B from being the parent of C. */
+ if (file->initial_ps->date > ps->date)
+ continue;
+
+ /* If the file was added on this branch, we can't use it to
+ eliminate other potential parents just because they don't
+ have this file. */
+ if (strcmp(file->initial_branch, child) == 0)
+ continue;
+
+ /* If we haven't yet seen the branch that file was initially
+ added to, then *that* branch may be a child of *this*
+ child. In that case, we shouldn't expect that this file is
+ necessarily also on the parent branch - for the same reason
+ we ignore files added on the child branch immediately. */
+ if (strcmp(file->initial_branch, "HEAD") != 0 &&
+ NULL == get_hash_object(branch_heads, file->initial_branch))
+ continue;
+
+ /* Pick a branch to consider */
+ for (next = all_branches.next; next != &all_branches; next = next->next)
+ {
+ char *child_rev, *parent_rev;
+ tag = list_entry(next, Tag, global_link);
+ if (!tag->rev)
+ continue; /* skip branches already eliminated */
+
+ parent = tag->tag;
+ child_rev = get_hash_object(file->branches_sym, child);
+ parent_rev = get_hash_object(file->branches_sym, parent);
+ if (child_rev) {
+ if (parent_rev) {
+ if (!is_ancestor_rev(parent_rev, child_rev)) {
+ tag->rev = NULL;
+ debug(DEBUG_STATUS,
+ "%s not parent of %s: %s REV %s vs. %s",
+ parent, child, file->filename, parent_rev,
+ child_rev);
+ }
+ } else {
+ /* If this file is on the child branch but not on
+ the parent branch, then it's not the true
+ parent. WARNING: as commented above, this may
+ falsely eliminate a parent if a file added to
+ some other branch before this child's branch
+ point is later merged onto the child. That
+ file may not be on the true parent, but we
+ eliminate that parent anyway. Bah!
+ Corner-cases?! How often do people merge with
+ children branches? Anyway, this is too
+ effective at eliminating incorrect parents to
+ ignore. */
+ tag->rev = NULL;
+ debug(DEBUG_STATUS, "%s not parent of %s: parent missing %s",
+ parent, child, file->filename);
+ }
+ } else {
+ /* What about the file on the parent but not the child?
+ The file could have been added to the parent later than
+ the branch point. But we catch that above. More
+ importantly, it could have been added to some other
+ branch time-wise earlier than the branch point, and
+ then merged onto this parent after the branch point.
+ That's too hard to detect. Also, there's the evil of
+ partial-tree tagging. The most common way this arises
+ is that a child branches off just a portion (usually a
+ sub-directory) of the tree. In that case, lots of
+ files are on the parent but not on the child. So we'll
+ be lenient and let this potential parent live another
+ day. */
+#if 0
+ /* TODO?: maybe an optional "strict" mode could enable
+ this, if the user is willing to assume there haven't
+ been any partial-tree taggings. */
+ if (parent_rev) {
+ tag->rev = NULL;
+ debug(DEBUG_STATUS, "%s not parent of %s: child missing %s",
+ parent, child, file->filename);
+ }
+#endif
+
+ }
+ } /* end of loop over potential parents */
+ }
+
+ /* Any remaining branches are possible parents. But, if any of
+ these branches are parents of other possible parents, we'll
+ say they're "grandparents" and not consider them for
+ parenthood. */
+ for (next = all_branches.next; next != &all_branches; next = next->next)
+ {
+ struct list_head *j;
+ tag = list_entry(next, Tag, global_link);
+ if (!tag->rev) continue;
+ for (j = all_branches.next; j != &all_branches; j = j->next)
+ {
+ Tag *tag2 = list_entry(j, Tag, global_link);
+ PatchSet *root_ps;
+ if (!tag2->rev) continue;
+ if (j == next) continue;
+ root_ps = (PatchSet*)get_hash_object(branch_heads, tag2->tag);
+ if (root_ps && strcmp(root_ps->ancestor_branch, tag->tag) == 0) {
+ tag->rev = NULL;
+ debug(DEBUG_STATUS, "eliminate %s: it's GRANDparent of %s via %s",
+ tag->tag, child, tag2->tag);
+ break;
+ }
+ }
+ }
+
+ parent = NULL;
+ debug(DEBUG_STATUS, "Remaining parents for %s:", child);
+ for (next = all_branches.next; next != &all_branches; next = next->next)
+ {
+ tag = list_entry(next, Tag, global_link);
+ if (tag->rev) {
+ debug(DEBUG_STATUS, " %s", tag->tag);
+ if (parent)
+ debug(DEBUG_STATUS, "Alternative ambiguous parent of %s: %s",
+ child, tag->tag);
+ else
+ parent = tag->tag;
+ }
+ }
+
+ if (parent) {
+ debug(DEBUG_STATUS, "Assigning %s as parent of %s", parent, child);
+ ps->ancestor_branch = parent;
+ } else {
+ debug(DEBUG_STATUS, "HEAD parent of %s by default", child);
+ ps->ancestor_branch = "HEAD";
+ /* Strictly speaking, we didn't actually verify that HEAD
+ is a possible parent, but what else can we do if there
+ are no other branches left? */
+ }
+}
+
static void handle_collisions()
{
struct list_head *next;
Index: cvsps-2.1/cvsps_types.h
===================================================================
--- cvsps-2.1.orig/cvsps_types.h
+++ cvsps-2.1/cvsps_types.h
@@ -71,6 +71,8 @@ struct _CvsFile
* with the branch attribute NULL. Later we need to resolve these.
*/
int have_branches;
+ char *initial_branch;
+ PatchSet *initial_ps;
};
struct _PatchSetMember
[-- Attachment #3: test5 --]
[-- Type: text/plain, Size: 1203 bytes --]
#!/bin/sh
dirname=`date +"%Y%m%d%H%M%S"`
mkdir $dirname && cd $dirname
# create the repository
mkdir cvsroot && cd cvsroot
export CVSROOT=`pwd`
cd ..
cvs init
# import an empty project
mkdir project && cd project
cvs import -m "Create initial repo" project yoyo start
cd ..
rmdir project
# checkout the project
cvs co project && cd project
# create a new file on HEAD
echo 1 >a
cvs add a
cvs ci -m "added file a to HEAD" a
# create and switch to "stable" branch
cvs tag -b stable
cvs update -r stable
# add a new file to stable branch
echo 2 > b
cvs add b
cvs ci -m "added file b to 'stable' branch" b
# create and switch to "dev" branch from "stable"
cvs tag -b dev
cvs update -r dev
# modify file 'a' on "dev" branch
echo "change" >> a
cvs ci -m "changed file a on dev branch" a
# see what CVS thinks the "dev" branch looks like
cd ..
rm -rf project
cvs checkout -r dev project
ls project && echo "Note how b is PRESENT"
# check output of cvsps
cd project
cvs log > ../cvslog
cd ..
cvsps -A -x --test-log cvslog project > cvsps.out
# check behavior of git-cvsimport
git-cvsimport -i -d $CVSROOT -C project.git project
cd project.git
git-checkout -f dev
ls && echo "Note how b is ABSENT!"
^ permalink raw reply
* HTTP redirection with git-clone/git-fetch ?
From: Josef Weidendorfer @ 2005-11-09 22:31 UTC (permalink / raw)
To: git
Hi,
git-clone fails silently with a HTTP URL where the server
responds with a redirection (ie. header line "Location:...").
I tried to add "-L" to the curl command line in git-clone.sh,
but this is only half of a fix. Afterwards I get:
defaulting to local storage area
error: Couldn't get http://repo/project.git/refs/heads/origin for heads/origin
Failed writing body
error: Could not interpret heads/origin as something to pull
This seems because git-fetch should understand redirections, too.
I am not familiar to the curl API. So perhaps another one can try to
fix this?
Josef
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-11-09 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virwqwd3z.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Sep 24, 2005 at 08:10:40PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> > default post-update hook could change to
> >
> > [ -e "$_git/git-dummy-support" ] && exec git-update-server-info
> >
> > and be enabled by default?
>
> That is a thought. While I think doing update-server-info
> everywhere whenever you update ref is going a bit overboard, I
> agree there should be an easy way for the end user to keep
> repositories that are public accessible all times. But running
> server-info upon every commit does not make much sense to me --
> something is seriously broken if we need to do that.
Point taken, you are right.
BTW, Cogito has for a while the command 'cg-admin-setuprepo' which is
designed to be used to create those public accessible repositories where
you typically only push to. Recently, I've also changed it so that it
just enables the default post-update hook; is it safe to assume that the
default template post-update hook shipped with GIT will be
good-to-be-autoenabled on public repositories and will always contain
the git-update-server-info invocation (unless it becomes irrelevant in
the future) ?
--
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: Problems with binary patches (pull) and spaces in filenames (gitk)
From: Junio C Hamano @ 2005-11-09 22:36 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <7vfyq5bhi2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Hmm. Perhaps a suboption to git-apply --stat to tell it not to
> barf is helpful? In the meantime, could you pull with -n flag?
Would this help?
-- >8 -- cut here -- >8 --
[PATCH] git-apply: do not barf on binary diff when not applying.
Instead, just mark the patch as binary, and keep going when
doing --stat and --summary.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/apply.c b/apply.c
index 3e53b34..6d756f7 100644
--- a/apply.c
+++ b/apply.c
@@ -53,7 +53,7 @@ struct fragment {
struct patch {
char *new_name, *old_name, *def_name;
unsigned int old_mode, new_mode;
- int is_rename, is_copy, is_new, is_delete;
+ int is_rename, is_copy, is_new, is_delete, is_binary;
int lines_added, lines_deleted;
int score;
struct fragment *fragments;
@@ -890,8 +890,18 @@ static int parse_chunk(char *buffer, uns
patchsize = parse_single_patch(buffer + offset + hdrsize, size - offset - hdrsize, patch);
- if (!patchsize && !metadata_changes(patch))
- die("patch with only garbage at line %d", linenr);
+ if (!patchsize && !metadata_changes(patch)) {
+ static const char binhdr[] = "Binary files ";
+
+ if (sizeof(binhdr) - 1 < size - offset - hdrsize &&
+ !memcmp(binhdr, buffer + hdrsize, sizeof(binhdr)-1))
+ patch->is_binary = 1;
+
+ if (patch->is_binary && !apply)
+ ;
+ else
+ die("patch with only garbage at line %d", linenr);
+ }
return offset + hdrsize + patchsize;
}
@@ -949,9 +959,12 @@ static void show_stats(struct patch *pat
add = (add * max + max_change / 2) / max_change;
del = total - add;
}
- printf(" %s%-*s |%5d %.*s%.*s\n", prefix,
- len, name, patch->lines_added + patch->lines_deleted,
- add, pluses, del, minuses);
+ if (patch->is_binary)
+ printf(" %s%-*s | Bin\n", prefix, len, name);
+ else
+ printf(" %s%-*s |%5d %.*s%.*s\n", prefix,
+ len, name, patch->lines_added + patch->lines_deleted,
+ add, pluses, del, minuses);
if (qname)
free(qname);
}
^ permalink raw reply related
* Re: [cogito] cg-merge does not remove files removed upstream on fast-forward
From: Petr Baudis @ 2005-11-09 22:54 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200511090108.51776.blaisorblade@yahoo.it>
Dear diary, on Wed, Nov 09, 2005 at 01:08:33AM CET, I got a letter
where Blaisorblade <blaisorblade@yahoo.it> said that...
> Once again, (not the first time) when doing "cg-merge origin" (or cg-update I
> guess, too) I find a tons of files which were removed upstream and cogito
> didn't remove. It was a fast-forward merge on Linus' tree:
>
> $ cg merge origin
> Fast-forwarding d83c671fb7023f69a9582e622d01525054f23b66 ->
> a52e8381c430896d3bd6065a34fda99cb5c74c82
> on top of d83c671fb7023f69a9582e622d01525054f23b66...
Strange. I've just added a test against this, and it seems to work fine
for me. Hmm.
Could you please test any post-1936f62c0756d8051bd3a8ee4214e058f168d395
Cogito version?
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
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