* Re: [PATCH] cogito: Add cg-undo command
From: Petr Baudis @ 2005-05-08 20:59 UTC (permalink / raw)
To: Matt Porter; +Cc: git
In-Reply-To: <20050503224007.B637@cox.net>
Dear diary, on Wed, May 04, 2005 at 07:40:07AM CEST, I got a letter
where Matt Porter <mporter@kernel.crashing.org> told me that...
> Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Thanks. I took it, hacked upon it for a while and then committed
something similar but largely rewritten as cg-admin-uncommit. ;-)
--
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: Commit template
From: Petr Baudis @ 2005-05-08 20:40 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Sean, GIT Mailing List
In-Reply-To: <1115584617.8949.51.camel@pegasus>
Dear diary, on Sun, May 08, 2005 at 10:36:57PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
>
> > > > my argument is; not to mess up with the CG: lines created by cg-commit.
> > > > If you wanna insert a warning then you can of course add additional CG:
> > > > lines to the commit template.
> > >
> > > Well, i'd argue that anyone making their own commit should be responsible
> > > for making it look however they like. Maybe they want to only use only 60
> > > character wide lines and are tired of seeing the notice about CG: being
> > > ignored. Gives the power user a tad more flexibility. But I really
> > > don't care much either way.
> >
> > I'm with Sean on this one - implemented (with current cg-commit, and I
> > used .git/commit-template file instead), committed, pushed out.
>
> then please do a "touch .git/commit-template" and call cg-commit. Now
> you will see what I mean. It is too easy to screw up.
So don't touch .git/commit-template. It's not like it stops working, you
just don't get the top stuff. Which you probably wanted, why would you
touch .git/commit-template otherwise?
> Why not leave the list of modified files in the hand of the cg-commit
> and people that wanna extra text inside their commit-template add
> something like:
>
> CG: ---
> CG: This is my testing tree, don't commit
>
> This will look much prettier and gives people the same possibilities to
> change everything.
But you have extra stuff both before and after the list of modified
files.
> If you wanna make the modified files list into a full configurable
> template, then I think you must introduce place holders.
That's what I was thinking about, actually - @@MODIFIED@@ and such, and
it replaces _all_ the CG: stuff. Just decided that I have better things
to do now personally.
--
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: Make errors
From: John Kacur @ 2005-05-08 19:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0505081538110.30848-100000@iabervon.org>
On Sun, 2005-05-08 at 15:43, Daniel Barkalow wrote:
> On Sun, 8 May 2005, John Kacur wrote:
>
> > gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-http-pull
> > http-pull.c libgit.a -lz -lssl -lcurl
> > http-pull.c:10:23: curl/curl.h: No such file or directory
> > http-pull.c:11:23: curl/easy.h: No such file or directory
> > http-pull.c:13: error: parse error before '*' token
>
> You need to either install libcurl or remove "git-http-pull" from PROGS in
> the Makefile. libcurl provides the HTTP implementation used to download
> heads hosted on websites.
>
> -Daniel
> *This .sig left intentionally blank*
>
Thank you, indeed it compiled fine after installing the curl-devel rpm
^ permalink raw reply
* Re: Commit template
From: Marcel Holtmann @ 2005-05-08 20:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050508201723.GH9495@pasky.ji.cz>
Hi Petr,
> > > my argument is; not to mess up with the CG: lines created by cg-commit.
> > > If you wanna insert a warning then you can of course add additional CG:
> > > lines to the commit template.
> >
> > Well, i'd argue that anyone making their own commit should be responsible
> > for making it look however they like. Maybe they want to only use only 60
> > character wide lines and are tired of seeing the notice about CG: being
> > ignored. Gives the power user a tad more flexibility. But I really
> > don't care much either way.
>
> I'm with Sean on this one - implemented (with current cg-commit, and I
> used .git/commit-template file instead), committed, pushed out.
then please do a "touch .git/commit-template" and call cg-commit. Now
you will see what I mean. It is too easy to screw up.
Why not leave the list of modified files in the hand of the cg-commit
and people that wanna extra text inside their commit-template add
something like:
CG: ---
CG: This is my testing tree, don't commit
This will look much prettier and gives people the same possibilities to
change everything. If you wanna make the modified files list into a full
configurable template, then I think you must introduce place holders.
Also an option to suppress the list of modified files is possible.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Marcel Holtmann @ 2005-05-08 20:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050508200334.GG9495@pasky.ji.cz>
Hi Petr,
> > look at the attached patch. We should use "fmt -s" to keep newlines that
> > are inside the commit message and there is one unneeded empty CG: line.
>
> thanks, fixed and pushed out.
cool. Now I have everything I am used to from CVS, but ...
@@ -113,7 +113,9 @@
# TODO: Prepend a letter describing whether it's addition,
# removal or update. Or call git status on those files.
echo "CG: $file" >>$LOGMSG
- [ "$msgs" ] && echo $file
+ if [ "$msgs" ] && ! [ "$forceeditor" ]; then
+ echo $file
+ fi
done
fi
There is no need to print out the files if we start the editor anyway.
@@ -122,10 +124,10 @@
if tty -s; then
if ! [ "$msgs" ] || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
- fi
- if ! [ "$msgs" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
- rm $LOGMSG $LOGMSG2
- die 'Commit message not modified, commit aborted'
+ if ! [ $LOGMSG2 -nt $LOGMSG ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Commit message not modified, commit aborted'
+ fi
fi
else
If you provide a commit message via -m and then close the editor without
changing it, it will commit the message. I think that will not be the
intention of the user.
> > I also put back in the "mess", because if there is no commit message
> > provided via -m it gives us an initial empty line to start in. This is
> > the same that CVS does and it makes the life inside vi a lot more
> > easier.
>
> Well, I use 'O' to start editing. ;-) (Actually, I use the -m arguments
> extensively; the way it is now is how I always dreamt of it since I
> started using SCMs. Possibly in conjuction with -e to add some fancy
> stuff.)
>
> Your way might be cunning, fast, or even clever, but it was certainly
> not clear, therefore not maintainable well. I tried to implement it in a
> simpler and more clear way. Does it behave as you want now?
What should I say ;)
I will do a little bit more tests, but it looks very good. Besides the
stuff above.
> > > > If you want the extra newline(s) then it is a good idea to add something
> > > > that strips heading and trailing empty lines from the final commit
> > > > message, because otherwise it will be ugly if you don't enter extra text
> > > > for the merge.
> > >
> > > Isn't that what I initially suggested? :-)
> >
> > But this hasn't been done so far. And I don't know any shell tool for
> > this job, beside some crazy awk or sed stuff. However stripspace.c from
> > git-tools can do this job.
>
> #/bin/sh
>
> leading=1
> emptylines=0
> while read line; do
> if ! [ "$line" ]; then
> [ "$leading" ] && continue
> emptylines=$(($emptylines + 1))
> else
> leading=0
> while [ $emptylines -gt 0 ]; do
> echo ""
> emptylines=$(($emptylines - 1))
> done
> echo $line
> fi
> done
>
> or something? (Based on someone else's script since I was too lazy. ;-)
I am not that script expert anymore. I do most stuff in C now and I am
very happy with it. Maybe someone else comes up with a clever way to
handle the following case:
/*
* Remove empty lines from the beginning and end.
*
* Turn multiple consecutive empty lines into just one
* empty line.
*/
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 0/2] core-git documentation update
From: Junio C Hamano @ 2005-05-08 20:28 UTC (permalink / raw)
To: David Greaves; +Cc: Linus Torvalds, git
In-Reply-To: <427E4AE1.2040105@dgreaves.com>
David, thanks for taking time to update the document. I ended
up hand merging your two patches since I had a bit more
documentation updates in git-jc tree, so I'd like you to
proofread the result.
It is my understanding that if I have a correct patch result
from your patch 1 and patch 2, I can throw away this message:
Subject: [FILES] core-git documentation update
Am I correct?
I intend to keep not-so-controvercial stuff in git-jc tree, so
that when Linus returns he can pull from it instead of patching
from a pile of e-mails, potentially risking to leave good stuff
in his mailbox during that process.
The following diff is between:
- Linus tree with two patches from you
+ The result of my hand merge, which I intend to ask Linus
to pull when he returns.
Thanks.
---
# - 2: As Greaves
# + (working tree)
--- a/Documentation/core-git.txt
+++ b/Documentation/core-git.txt
@@ -473,7 +473,7 @@ git-diff-cache - Compares content and mo
SYNOPSIS
--------
-'git-diff-cache' [-p] [-r] [-z] [--cached] <tree-ish>
+'git-diff-cache' [-p] [-r] [-z] [-m] [--cached] <tree-ish>
DESCRIPTION
-----------
@@ -500,6 +500,12 @@ OPTIONS
--cached::
do not consider the on-disk file at all
+-m::
+ By default, files recorded in the index but not checked
+ out are reported as deleted. This flag makes
+ git-diff-cache say that all non-checked-out files are up
+ to date.
+
Output format
-------------
include::diff-format.txt[]
@@ -1515,7 +1521,7 @@ git-update-cache - Modifies the index or
SYNOPSIS
--------
'git-update-cache'
- [--add] [--remove] [--refresh]
+ [--add] [--remove] [--refresh] [--replace]
[--ignore-missing]
[--force-remove <file>]
[--cacheinfo <mode> <object> <file>]\*
@@ -1556,6 +1562,14 @@ OPTIONS
Remove the file from the index even when the working directory
still has such a file.
+--replace::
+ By default, when a file `path` exists in the index,
+ git-update-cache refuses an attempt to add `path/file`.
+ Similarly if a file `path/file` exists, a file `path`
+ cannot be added. With --replace flag, existing entries
+ that conflicts with the entry being added are
+ automatically removed with warning messages.
+
--::
Do not interpret any more arguments as options.
^ permalink raw reply
* Re: Commit template
From: Petr Baudis @ 2005-05-08 20:17 UTC (permalink / raw)
To: Sean; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <2159.10.10.10.24.1115582791.squirrel@linux1>
Dear diary, on Sun, May 08, 2005 at 10:06:31PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> told me that...
> On Sun, May 8, 2005 4:03 pm, Marcel Holtmann said:
>
> > my argument is; not to mess up with the CG: lines created by cg-commit.
> > If you wanna insert a warning then you can of course add additional CG:
> > lines to the commit template.
>
> Marcel,
>
> Well, i'd argue that anyone making their own commit should be responsible
> for making it look however they like. Maybe they want to only use only 60
> character wide lines and are tired of seeing the notice about CG: being
> ignored. Gives the power user a tad more flexibility. But I really
> don't care much either way.
I'm with Sean on this one - implemented (with current cg-commit, and I
used .git/commit-template file instead), committed, pushed out.
Sean, could you please sign off the patches you send to the mailing list
in the future?
Thanks,
--
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: Commit template
From: Sean @ 2005-05-08 20:06 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1115582601.8949.31.camel@pegasus>
On Sun, May 8, 2005 4:03 pm, Marcel Holtmann said:
> my argument is; not to mess up with the CG: lines created by cg-commit.
> If you wanna insert a warning then you can of course add additional CG:
> lines to the commit template.
Marcel,
Well, i'd argue that anyone making their own commit should be responsible
for making it look however they like. Maybe they want to only use only 60
character wide lines and are tired of seeing the notice about CG: being
ignored. Gives the power user a tad more flexibility. But I really
don't care much either way.
Sean
^ permalink raw reply
* Re: Commit template
From: Sean @ 2005-05-08 19:57 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1115580630.8949.27.camel@pegasus>
On Sun, May 8, 2005 3:30 pm, Marcel Holtmann said:
Hey Marcel,
> if you don't put any CG: lines in the commit template you screw up the
> look of the modified files list. So I propose to leave all the CG: lines
> additions as they are in cg-commit and only add the template in front of
> it.
Yes, but you're free to make it look however you like. Here's a sample:
CG: -[DO NOT COMMIT!]-------------------------------------------
CG:
CG: Hey! You don't want to commit here, use a cloned repository!
CG:
and another:
CG: -[USB CHANGES REPO!]----------------------------------------
CG:
CG: Commit only USB changes here!
CG:
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
CG:
CG:
The trailing CG: lines ensure that those added by cg-commit look okay.
It's not perfect, but it's a nice feature.
Sean
^ permalink raw reply
* Re: Commit template
From: Marcel Holtmann @ 2005-05-08 20:03 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <2095.10.10.10.24.1115582244.squirrel@linux1>
Hi Sean,
> > if you don't put any CG: lines in the commit template you screw up the
> > look of the modified files list. So I propose to leave all the CG: lines
> > additions as they are in cg-commit and only add the template in front of
> > it.
>
> Yes, but you're free to make it look however you like. Here's a sample:
>
> CG: -[DO NOT COMMIT!]-------------------------------------------
> CG:
> CG: Hey! You don't want to commit here, use a cloned repository!
> CG:
>
>
> and another:
>
> CG: -[USB CHANGES REPO!]----------------------------------------
> CG:
> CG: Commit only USB changes here!
> CG:
>
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> CG:
> CG:
>
> The trailing CG: lines ensure that those added by cg-commit look okay.
> It's not perfect, but it's a nice feature.
my argument is; not to mess up with the CG: lines created by cg-commit.
If you wanna insert a warning then you can of course add additional CG:
lines to the commit template.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Petr Baudis @ 2005-05-08 20:03 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: GIT Mailing List
In-Reply-To: <1115578658.8949.9.camel@pegasus>
Dear diary, on Sun, May 08, 2005 at 08:57:38PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
Hello,
> look at the attached patch. We should use "fmt -s" to keep newlines that
> are inside the commit message and there is one unneeded empty CG: line.
thanks, fixed and pushed out.
> I also put back in the "mess", because if there is no commit message
> provided via -m it gives us an initial empty line to start in. This is
> the same that CVS does and it makes the life inside vi a lot more
> easier.
Well, I use 'O' to start editing. ;-) (Actually, I use the -m arguments
extensively; the way it is now is how I always dreamt of it since I
started using SCMs. Possibly in conjuction with -e to add some fancy
stuff.)
Your way might be cunning, fast, or even clever, but it was certainly
not clear, therefore not maintainable well. I tried to implement it in a
simpler and more clear way. Does it behave as you want now?
> > > If you want the extra newline(s) then it is a good idea to add something
> > > that strips heading and trailing empty lines from the final commit
> > > message, because otherwise it will be ugly if you don't enter extra text
> > > for the merge.
> >
> > Isn't that what I initially suggested? :-)
>
> But this hasn't been done so far. And I don't know any shell tool for
> this job, beside some crazy awk or sed stuff. However stripspace.c from
> git-tools can do this job.
#/bin/sh
leading=1
emptylines=0
while read line; do
if ! [ "$line" ]; then
[ "$leading" ] && continue
emptylines=$(($emptylines + 1))
else
leading=0
while [ $emptylines -gt 0 ]; do
echo ""
emptylines=$(($emptylines - 1))
done
echo $line
fi
done
or something? (Based on someone else's script since I was too lazy. ;-)
--
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: cg-log patches
From: Sean @ 2005-05-08 19:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <20050508192536.GE9495@pasky.ji.cz>
On Sun, May 8, 2005 3:25 pm, Petr Baudis said:
>>
>> cg-log -c -f -u petr
>>
>> or
>>
>> cg-log -uxpasky
>>
>> Sean
>
> That sounds great. Could you please post a patch against the current
> Cogito's cg-log?
>
Hey Petr,
Sorry it relies on other patches in a series. If you're interested in
them they're available from:
http://git.homelinux.com/cogito
Actually, if you look you'll see I renamed the option -a and added help so
that it shows up on -h or --help.
Cheers,
Sean
^ permalink raw reply
* Re: Make errors
From: Petr Baudis @ 2005-05-08 19:46 UTC (permalink / raw)
To: John Kacur; +Cc: git
In-Reply-To: <1115580904.5536.28.camel@linux.site>
Dear diary, on Sun, May 08, 2005 at 09:35:04PM CEST, I got a letter
where John Kacur <jkacur@rogers.com> told me that...
> gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-convert-cache
> convert-c
> ache.c libgit.a -lz -lssl
> convert-cache.c: In function `write_subdirectory':
> convert-cache.c:102: warning: field precision is not type int (arg 4)
I'm not sure how serious this is in practice.
> gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-http-pull
> http-pull.c l
> ibgit.a -lz -lssl -lcurl
> http-pull.c:10:23: curl/curl.h: No such file or directory
> http-pull.c:11:23: curl/easy.h: No such file or directory
> http-pull.c:13: error: parse error before '*' token
You need curl in order to compile http-pull. It is not a core part of
git, so if you just remove it from the makefile, things should work as
long as you don't want to pull over http. (You can pull Linus' and my
trees over rsync, not sure about Junio - I *think* he is http-only.)
--
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: Make errors
From: Thomas Glanzmann @ 2005-05-08 19:43 UTC (permalink / raw)
To: git
In-Reply-To: <1115580904.5536.28.camel@linux.site>
Hello John,
> http-pull.c:10:23: curl/curl.h: No such file or directory
> http-pull.c:11:23: curl/easy.h: No such file or directory
> http-pull.c:13: error: parse error before '*' token
Install curl + curl development package. Your compiler complains that it
can't find the header files for libcurl.
Thomas
^ permalink raw reply
* Re: Make errors
From: Daniel Barkalow @ 2005-05-08 19:43 UTC (permalink / raw)
To: John Kacur; +Cc: git
In-Reply-To: <1115580904.5536.28.camel@linux.site>
On Sun, 8 May 2005, John Kacur wrote:
> gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-http-pull
> http-pull.c libgit.a -lz -lssl -lcurl
> http-pull.c:10:23: curl/curl.h: No such file or directory
> http-pull.c:11:23: curl/easy.h: No such file or directory
> http-pull.c:13: error: parse error before '*' token
You need to either install libcurl or remove "git-http-pull" from PROGS in
the Makefile. libcurl provides the HTTP implementation used to download
heads hosted on websites.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/2] core-git documentation update
From: Junio C Hamano @ 2005-05-08 19:38 UTC (permalink / raw)
To: David Greaves; +Cc: Linus Torvalds, git
In-Reply-To: <427E4AE1.2040105@dgreaves.com>
Quick question. Is this against the tip of Linus tree?
^ permalink raw reply
* Make errors
From: John Kacur @ 2005-05-08 19:35 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
Ok, I'm coming late to the git game, and having some build problems.
My machine is amd64 (athlon64), and I fetched both
git-0.7.tar.bz2
cogito-0.9.tar.bz2
They both fail to build in a similar fashion
For example, I did
bunzip2 -c git-0.7.tar.bz2 | tar xvf -
cd git-0.7
export PATH=$PWD:$PATH
make
and it fails here:
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-convert-cache
convert-c
ache.c libgit.a -lz -lssl
convert-cache.c: In function `write_subdirectory':
convert-cache.c:102: warning: field precision is not type int (arg 4)
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-http-pull
http-pull.c l
ibgit.a -lz -lssl -lcurl
http-pull.c:10:23: curl/curl.h: No such file or directory
http-pull.c:11:23: curl/easy.h: No such file or directory
http-pull.c:13: error: parse error before '*' token
Any hints?
Thanks in advance
The entire build output is attached:
[-- Attachment #2: out.txt --]
[-- Type: text/plain, Size: 4381 bytes --]
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o read-cache.o read-cache.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o sha1_file.o sha1_file.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o usage.o usage.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o object.o object.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o commit.o commit.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o tree.o tree.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o blob.o blob.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o tag.o tag.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o strbuf.o strbuf.c
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -c -o diff.o diff.c
ar rcs libgit.a read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o tag.o strbuf.o diff.o
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-update-cache update-cache.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-diff-files diff-files.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-init-db init-db.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-write-tree write-tree.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-read-tree read-tree.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-commit-tree commit-tree.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-cat-file cat-file.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-fsck-cache fsck-cache.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-checkout-cache checkout-cache.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-diff-tree diff-tree.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-rev-tree rev-tree.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-show-files show-files.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-check-files check-files.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-ls-tree ls-tree.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-merge-base merge-base.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-merge-cache merge-cache.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-unpack-file unpack-file.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-export export.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-diff-cache diff-cache.c libgit.a -lz -lssl
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-convert-cache convert-cache.c libgit.a -lz -lssl
convert-cache.c: In function `write_subdirectory':
convert-cache.c:102: warning: field precision is not type int (arg 4)
gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-http-pull http-pull.c libgit.a -lz -lssl -lcurl
http-pull.c:10:23: curl/curl.h: No such file or directory
http-pull.c:11:23: curl/easy.h: No such file or directory
http-pull.c:13: error: parse error before '*' token
http-pull.c:13: warning: type defaults to `int' in declaration of `curl'
http-pull.c:13: warning: data definition has no type or storage class
http-pull.c: In function `fetch':
http-pull.c:73: warning: implicit declaration of function `curl_easy_setopt'
http-pull.c:73: error: `CURLOPT_FILE' undeclared (first use in this function)
http-pull.c:73: error: (Each undeclared identifier is reported only once
http-pull.c:73: error: for each function it appears in.)
http-pull.c:74: error: `CURLOPT_WRITEFUNCTION' undeclared (first use in this function)
http-pull.c:86: error: `CURLOPT_URL' undeclared (first use in this function)
http-pull.c:90: warning: implicit declaration of function `curl_easy_perform'
http-pull.c: In function `main':
http-pull.c:191: warning: implicit declaration of function `curl_global_init'
http-pull.c:191: error: `CURL_GLOBAL_ALL' undeclared (first use in this function)
http-pull.c:193: warning: implicit declaration of function `curl_easy_init'
http-pull.c:193: warning: assignment makes pointer from integer without a cast
http-pull.c:202: warning: implicit declaration of function `curl_global_cleanup'
make: *** [git-http-pull] Error 1
^ permalink raw reply
* Re: cg-log patches
From: Petr Baudis @ 2005-05-08 19:18 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Sean, GIT Mailing List
In-Reply-To: <1115578807.8949.12.camel@pegasus>
Dear diary, on Sun, May 08, 2005 at 09:00:07PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Sean,
>
> > > why don't you use diffstat for it? I think that it is more handy then
> > > the list of modified files.
> >
> > Is a good idea, but would be a fair bit harder to generate unfortunately.
> > Right now the blobs themselves don't have to be opened and inspected, just
> > the commit trees. Actually, i'm not sure exactly how you'd even go about
> > generating a correct diffstat for commits that have multiple parents.
>
> I am not a really good git expert, but maybe another option for it would
> be fine.
>
> However there is another thing that I am missing. With Bitkeeper I was
> able to do something like "bk changes -umarcel" to list all changes done
> by the user "marcel". I like to have something similar with cg-log. Any
> ideas on how to do that?
What should it take in regard? Username portion of the email address?
The email address itself? The realname?
--
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: Commit template
From: Marcel Holtmann @ 2005-05-08 19:30 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <2003.10.10.10.24.1115580031.squirrel@linux1>
Hi Sean,
> >> This adds the ability to have a per repository commit template. Create
> >> a
> >> .git/commit.form file containg "CG: " and other lines and it will be
> >> used
> >> in place of the regular top 3 lines. This is kind of handy so that you
> >> can include your signed-off-by: with your email etc.
> >
> > I think it is a bad idea to take the CG: into it. Let them be created by
> > the cg-commit script, because it knows what to do.
> >
> > The question now is when we should provide that form. For me it only
> > makes sense if it is not a merge and if no commit message is provided
> > via command line.
>
> Yeah, it was just a quick hack. You're not forced to put any CG: lines in
> the commit template of course, but it will handle it if you do. Even
> with the patch, cg-commit will add addtional CG: lines containing a list
> of modified files etc..
if you don't put any CG: lines in the commit template you screw up the
look of the modified files list. So I propose to leave all the CG: lines
additions as they are in cg-commit and only add the template in front of
it.
Regards
Marcel
^ permalink raw reply
* Re: [FILES] core-git documentation update
From: Junio C Hamano @ 2005-05-08 19:30 UTC (permalink / raw)
To: David Greaves; +Cc: Petr Baudis, git
In-Reply-To: <427E4F6C.6090302@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
DG> it just makes across the board changes easier and at the minute the
DG> stuff I've been doing is systemic.
DG> I have no problems with breaking it up - hence the script...
Monolithic version is easier to work with when there is only one
or very few people working on it but when the document matures
enough to describe the current state of affairs accurately
enough, further changes would come almost solely from changing
the programs the document describes. At that point having
separate files describing each program is easier to work with,
and I think that point is now.
^ permalink raw reply
* Re: cg-log patches
From: Marcel Holtmann @ 2005-05-08 19:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050508191831.GD9495@pasky.ji.cz>
Hi Petr,
> > However there is another thing that I am missing. With Bitkeeper I was
> > able to do something like "bk changes -umarcel" to list all changes done
> > by the user "marcel". I like to have something similar with cg-log. Any
> > ideas on how to do that?
>
> What should it take in regard? Username portion of the email address?
> The email address itself? The realname?
good question. Bitkeeper was only able to handle the user part of the
address. Maybe we can make cg-log a little bit more intelligent. We also
have the author and the committer. My idea would be to use -A for the
author and -C for the committer and maybe -U to search in both. If the
value contains and "@" it should search in the email address part and
otherwise in the username portion. Some regular expression stuff like
"^marcel" (case insensitive) would also be great.
I have no idea how to realize it, but would be thankful for such an
option. It is one of the last pieces that I miss.
Regards
Marcel
^ permalink raw reply
* Re: cg-log patches
From: Sean @ 2005-05-08 19:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <20050508191831.GD9495@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 811 bytes --]
On Sun, May 8, 2005 3:18 pm, Petr Baudis said:
>> I am not a really good git expert, but maybe another option for it would
>> be fine.
>>
>> However there is another thing that I am missing. With Bitkeeper I was
>> able to do something like "bk changes -umarcel" to list all changes done
>> by the user "marcel". I like to have something similar with cg-log. Any
>> ideas on how to do that?
>
> What should it take in regard? Username portion of the email address?
> The email address itself? The realname?
>
Attached is a new version of cg-log that includes a -u option that takes a
single parameter. Whatever you put in that parameter will be searched in
the author line, so it can be part or all of an authors name and/or email
address.
So you could do:
cg-log -c -f -u petr
or
cg-log -uxpasky
Sean
[-- Attachment #2: cg-log --]
[-- Type: application/octet-stream, Size: 3187 bytes --]
#!/usr/bin/env bash
#
# Make a log of changes in a GIT branch.
# Copyright (c) Petr Baudis, 2005.
# Copyright (c) David Woodhouse, 2005.
# Copyright (c) Sean Estabrooks, 2005.
#
# Takes a -c option to add color to the output.
# Currently, the colors are:
#
# header Green
# author Cyan
# committer Magenta
# files Blue
# signoff Yellow
#
# Takes an -f option to list which files was changed.
#
# Takes an -r followed with id resolving to a commit to start from
# (HEAD by default), or id1:id2 representing an (id1;id2] range
# of commits to show.
#
# The rest of arguments are took as filenames; cg-log then displays
# only changes in those files.
. cg-Xlib
# Try to fix the annoying "Broken pipe" output. May not help, but apparently
# at least somewhere it does. Bash is broken.
trap exit SIGPIPE
colheader=
colauthor=
colcommitter=
colfiles=
colsignoff=
coldefault=
list_files=
log_start=
log_end=
user=
while getopts cfr:u: o
do
case $o in
c) # See terminfo(5), "Color Handling"
colheader="$(tput setaf 2)" # Green
colauthor="$(tput setaf 6)" # Cyan
colcommitter="$(tput setaf 5)" # Magenta
colfiles="$(tput setaf 4)" # Blue
colsignoff="$(tput setaf 3)" # Yellow
coldefault="$(tput op)" # Restore default
;;
f) list_files=1
;;
r) if [ -z $log_start ]; then
log_start="${OPTARG/:*}"
[ $OPTARG != $log_start ] && log_end="${OPTARG/*:}"
else log_end="$OPTARG"
fi
;;
u) user="$OPTARG"
;;
*) exit 1
;;
esac
done
shift $((OPTIND-1))
list_commit_files()
{
echo
if [ -z $2 ]; then
git-ls-tree $1 # List all files for initial commit
else
local tree1=$1; shift
for tree2; do
git-diff-tree -r $tree1 $tree2
done
fi | cut -f4 | sort -u | column | column -t | \
sed "s/^/$colfiles * /;s/$/$coldefault/"
}
id1="$(commit-id $log_start)" || exit 1
if [ "$log_end" ]; then
id2="$(commit-id $log_end)" || exit 1
git-rev-tree $id2 ^$id1 | sort -rn | cut -d' ' -f2
else
git-rev-list $id1
fi | \
while read commit
do
trap exit SIGPIPE
trees=
if [ $# -ne 0 ]; then
parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
[ "$parent" ] && [ "$(git-diff-tree -r $commit $parent "$@")" ] || continue
fi
if [ ! -z "$user" ]; then
git-cat-file commit $commit | grep '^author ' | grep -qi "$user" || continue
fi
echo $colheader""commit ${commit%:*} $coldefault;
git-cat-file commit $commit | \
while read key rest; do
trap exit SIGPIPE
case "$key" in
"author"|"committer")
if [ "$key" = "author" ]; then
color="$colauthor"
else
color="$colcommitter"
fi
date=(${rest#*> })
pdate="$(showdate $date)"
if [ "$pdate" ]; then
echo -n $color$key $rest | sed "s/>.*/> $pdate/"
echo $coldefault
else
echo $color$key $rest $coldefault
fi
;;
"tree"|"parent")
trees="$trees $rest"
echo $colheader$key $rest $coldefault
;;
"")
echo; sed -re "
s/^(from|cc|signed.off.by|acked.by): .*/$colsignoff&$coldefault/I
s/^/ /"
[ -n "$list_files" ] && list_commit_files $trees
;;
*)
echo $colheader$key $rest $coldefault
;;
esac
done
echo
done | ${PAGER:-less} ${PAGER_FLAGS:--R}
^ permalink raw reply
* Re: Commit template
From: Sean @ 2005-05-08 19:20 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1115579764.8949.15.camel@pegasus>
On Sun, May 8, 2005 3:16 pm, Marcel Holtmann said:
> Hi Sean,
>
>> This adds the ability to have a per repository commit template. Create
>> a
>> .git/commit.form file containg "CG: " and other lines and it will be
>> used
>> in place of the regular top 3 lines. This is kind of handy so that you
>> can include your signed-off-by: with your email etc.
>
> I think it is a bad idea to take the CG: into it. Let them be created by
> the cg-commit script, because it knows what to do.
>
> The question now is when we should provide that form. For me it only
> makes sense if it is not a merge and if no commit message is provided
> via command line.
Marcel,
Yeah, it was just a quick hack. You're not forced to put any CG: lines in
the commit template of course, but it will handle it if you do. Even
with the patch, cg-commit will add addtional CG: lines containing a list
of modified files etc..
Sean
^ permalink raw reply
* Re: cg-log patches
From: Petr Baudis @ 2005-05-08 19:25 UTC (permalink / raw)
To: Sean; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <2014.10.10.10.24.1115580230.squirrel@linux1>
Dear diary, on Sun, May 08, 2005 at 09:23:50PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> told me that...
> On Sun, May 8, 2005 3:18 pm, Petr Baudis said:
>
> >> I am not a really good git expert, but maybe another option for it would
> >> be fine.
> >>
> >> However there is another thing that I am missing. With Bitkeeper I was
> >> able to do something like "bk changes -umarcel" to list all changes done
> >> by the user "marcel". I like to have something similar with cg-log. Any
> >> ideas on how to do that?
> >
> > What should it take in regard? Username portion of the email address?
> > The email address itself? The realname?
> >
>
> Attached is a new version of cg-log that includes a -u option that takes a
> single parameter. Whatever you put in that parameter will be searched in
> the author line, so it can be part or all of an authors name and/or email
> address.
>
> So you could do:
>
> cg-log -c -f -u petr
>
> or
>
> cg-log -uxpasky
>
> Sean
That sounds great. Could you please post a patch against the current
Cogito's cg-log?
Thanks,
--
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: Commit template
From: Marcel Holtmann @ 2005-05-08 19:16 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1965.10.10.10.24.1115579256.squirrel@linux1>
Hi Sean,
> This adds the ability to have a per repository commit template. Create a
> .git/commit.form file containg "CG: " and other lines and it will be used
> in place of the regular top 3 lines. This is kind of handy so that you
> can include your signed-off-by: with your email etc.
I think it is a bad idea to take the CG: into it. Let them be created by
the cg-commit script, because it knows what to do.
The question now is when we should provide that form. For me it only
makes sense if it is not a merge and if no commit message is provided
via command line.
Regards
Marcel
^ 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