* Re: [PATCH] Really *do* nothing in while loop
From: Daniel Barkalow @ 2005-05-08 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Tokarev, jdow, James Purser, Thomas Glanzmann, GIT
In-Reply-To: <7vy8ap4e8l.fsf@assigned-by-dhcp.cox.net>
On Sun, 8 May 2005, Junio C Hamano wrote:
> >>>>> "MT" == Michael Tokarev <mjt@tls.msk.ru> writes:
>
> MT> As I already said, deflate() in this case does only ONE iteration.
> MT> stream.avail_in is NOT changed in the loop (except of the deflate()
> MT> itself, where it will be set to 0 - provided out buffer have enouth
> MT> room)....
>
> Just a stupid question, but what happens when we do not have
> enough room in the buffer?
We must have enough room; we sized the buffer with deflateBound to fit the
worst case.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Marcel Holtmann @ 2005-05-08 21:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050508210857.GL9495@pasky.ji.cz>
Hi Petr,
> > @@ -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.
>
> Now, this is a pretty difficult question. The only other place in the
> Cogito toolkit which uses cg-commit -e is now cg-init when doing the
> initial commit - and you definitively want to commit even if the message
> was not modified in that case. Also, what if you want to just review
> how the -m stuff flows like before committing?
>
> OTOH, we might want to stay consistent in behaviour and always abandon
> action when the file was not modified (except for the initial commit).
> Perhaps some -E for that? Other thoughts?
I think using -E to commit even when you don't modify the commit message
is a good idea. The alternative way is to ask the user like CVS does.
> > /*
> > * Remove empty lines from the beginning and end.
> > *
> > * Turn multiple consecutive empty lines into just one
> > * empty line.
> > */
>
> Bah, that's even easier when you want to squeeze the empty lines inside
> of the commit message. I don't, though.
You can do that with "cat -s", I know. But then you still have to look
at the first and the last line and delete it if they are empty.
I think it is a good idea to squeeze empty lines, because multi empty
lines are not useful for commit messages anyway. What do you think?
Regards
Marcel
^ permalink raw reply
* Re: Broken adding of cache entries
From: Petr Baudis @ 2005-05-08 21:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, git
In-Reply-To: <7v3bsx5sxx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, May 08, 2005 at 11:06:02PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> Dear diary, on Sun, May 08, 2005 at 07:22:31AM CEST, I got a letter
> PB> where Junio C Hamano <junkio@cox.net> told me that...
>
> >> Ok, I have two updates pushed out at git-jc archive at
> >> http://members.cox.net/junkio/git-jc.git/
>
> PB> I wanted to merge with you, but I'd like to make some (mostly minor)
> PB> nitpicks first.
>
> I've addressed the points you raised and pushed them out.
> Thanks again for the review.
Great, thanks.
Still, I'd like to know why the checking in write-tree is necessary.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [BUG] in asciidoc was Re: [FILES] core-git documentation update
From: David Greaves @ 2005-05-08 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vpsw15xdf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"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.
>
>
I was waiting for comments on this set in case there were comments like:
every document should have 'x' or change all 'y' to 'z'
I fully intend to split it out...
I will send patches next time.
One thing I failed to mention.
There's a minor bug in asciidoc for which I've submitted a patch to the
author. IIRC the bug causes problems with the -man option and is
cosmetically wrong with the html.
>From the asciidoc docs:
The first manpage section is mandatory and must be called /NAME/ and
contain a single paragraph (usually a single line) consisting of a list
of one or more comma separated command name(s) separated from the
command purpose by a dash character. **The dash must have at least one
white space character on either side.**
However this is not enforced (or indeed possible) at the moment - the
NAME section seems to split on the first hyphen.
This patch fixes that for me.
--- /usr/bin/asciidoc.orig 2005-05-08 17:03:42.666249974 +0100
+++ /usr/bin/asciidoc 2005-05-08 16:56:00.518923960 +0100
@@ -1067,7 +1067,7 @@
error('malformed NAME section body')
lines = reader.read_until(r'^$')
s = string.join(lines)
- mo = re.match(r'^(?P<manname>.*?)-(?P<manpurpose>.*)$',s)
+ mo =
re.match(r'^(?P<manname>.*?)\s+-\s+(?P<manpurpose>.*)$',s)
if not mo:
error('malformed NAME section body')
attrs['manname'] = string.strip(mo.group('manname'))
^ permalink raw reply
* Re: [PATCH 0/2] core-git documentation update
From: David Greaves @ 2005-05-08 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5s15up8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Junio C Hamano wrote:
>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.
>
>
This merged fine.
Purely for editorial consistency I added "" around the command - see patch
The intention now was for me to go through Linus' HEAD and verify the
docs actually documented the HEAD.
Then I think comparing the HEAD to jit-jc and preparing patches for that?
>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?
>
>
yes - that was just to assist people in reading the docs without having
to apply patches etc etc.
>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.
>
>
I had hoped you'd pick this up in that manner - thanks
David
PS Removed Linus from cc
Add quotes for editorial consistency
Signed-off-by: David Greaves <david@dgreaves.com>
---
[-- Attachment #2: core-git_editorial.patch --]
[-- Type: text/x-patch, Size: 614 bytes --]
Documentation/core-git.txt: needs update
Index: Documentation/core-git.txt
===================================================================
--- 08cd7ce14ca4da7db37dce88e416e67b01f3452a/Documentation/core-git.txt (mode:100644 sha1:e046119fcdd948dec81b11376ec9198e76a109af)
+++ uncommitted/Documentation/core-git.txt (mode:100644)
@@ -503,7 +503,7 @@
-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
+ "git-diff-cache" say that all non-checked-out files are up
to date.
Output format
^ permalink raw reply
* Re: [PATCH] Really *do* nothing in while loop
From: Junio C Hamano @ 2005-05-08 21:35 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Michael Tokarev, jdow, James Purser, Thomas Glanzmann, GIT
In-Reply-To: <Pine.LNX.4.21.0505081713070.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> On Sun, 8 May 2005, Junio C Hamano wrote:
>>
MT> As I already said, deflate() in this case does only ONE iteration.
MT> stream.avail_in is NOT changed in the loop (except of the deflate()
MT> itself, where it will be set to 0 - provided out buffer have enouth
MT> room)....
>>
>> Just a stupid question, but what happens when we do not have
>> enough room in the buffer?
DB> We must have enough room; we sized the buffer with deflateBound to fit the
DB> worst case.
Thanks for the explanation. Then do we still need to express it
as a while loop?
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Marcel Holtmann @ 2005-05-08 21:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050508200334.GG9495@pasky.ji.cz>
Hi Petr,
> #/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. ;-)
@@ -134,7 +134,7 @@
else
cat >>$LOGMSG2
fi
-grep -v ^CG: $LOGMSG2 >$LOGMSG
+grep -v ^CG: $LOGMSG2 | sed '/./,${/./b;:a;$d;N;/\n$/ba;b;};d' >$LOGMSG
rm $LOGMSG2
If you don't wanna squeeze then you can do it with a one-line in sed.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Sean @ 2005-05-08 21:46 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1115584015.8949.43.camel@pegasus>
On Sun, May 8, 2005 4:26 pm, Marcel Holtmann said:
> /*
> * Remove empty lines from the beginning and end.
> *
> * Turn multiple consecutive empty lines into just one
> * empty line.
> */
sed ' 1{:a;s/^[ \t]*$//;T;N;s/\n//;ta}
/^[ \t]*$/{:b;$d;N;s/\n[ \t]*$//;tb}' filename
There's probably shorter... but it's mothers day.. time to go!
Cheers,
Sean
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 22:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <20050508212202.GM9495@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Still, I'd like to know why the checking in write-tree is necessary.
The following is just a rephrase of what I wrote in my previous
message <7vll6q70mg.fsf@assigned-by-dhcp.cox.net>.
------------ test.sh ------------
#!/bin/sh
test="++testdir"
rm -fr $test
mkdir $test
cd $test || exit
show () {
echo "# ls ($1)"
ls -F
echo "# git-ls-files --stage ($1)"
git-ls-files --stage
case "$2" in
'') ;;
?*)
echo "# git-ls-tree -r ($1)"
git-ls-tree -r $2
;;
esac
}
echo "# Original"
git-init-db
date >not-so-interesting
git-update-cache --add not-so-interesting
original=$(echo Original | git-commit-tree $(git-write-tree))
show Original $original
rm -rf path not-so-interesting
echo "# Branch A"
git-read-tree $original
git-checkout-cache -f -a
date >path
git-update-cache --add path
branchA=$(echo Branch A Changes |
git-commit-tree $(git-write-tree) -p $original)
show 'Branch A' $branchA
rm -rf path not-so-interesting
echo "# Branch B"
git-read-tree $original
git-checkout-cache -f -a
mkdir path
date >path/file
git-update-cache --add path/file
branchB=$(echo Branch B Changes |
git-commit-tree $(git-write-tree) -p $original)
show 'Branch B' $branchB
rm -rf path not-so-interesting
echo "# Attempt merge O A B"
mb=$(git-merge-base $branchA $branchB)
echo "Original $original"
echo "Branch-A $branchA"
echo "Branch-B $branchB"
echo "MergeBase $mb"
git-read-tree -m $mb $branchA $branchB
show "Merge"
------------ test.out ------------
# Original
defaulting to local storage area
Committing initial tree 682c2247823f37e4cf64f240009c9ba932b04fe0
# ls (Original)
not-so-interesting
# git-ls-files --stage (Original)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
# git-ls-tree -r (Original)
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 not-so-interesting
# Branch A
# ls (Branch A)
not-so-interesting
path
# git-ls-files --stage (Branch A)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 path
# git-ls-tree -r (Branch A)
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 not-so-interesting
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 path
# Branch B
# ls (Branch B)
not-so-interesting
path/
# git-ls-files --stage (Branch B)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 path/file
# git-ls-tree -r (Branch B)
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 not-so-interesting
040000 tree f4e939c9b65aff9a59118f3f3f299ef30744adfa path
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 path/file
# Attempt merge O A B
Original 40c1d8a0e79df9e681667e0074664266b6bd9935
Branch-A 88b3e7e4ce0ba55c60fe4de6523968ecabb1cc78
Branch-B 0faa7f6b7f68ce2951fe3f26f937766ee53dc11c
MergeBase 40c1d8a0e79df9e681667e0074664266b6bd9935
# ls (Merge)
# git-ls-files --stage (Merge)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 2 path
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 3 path/file
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 22:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <7v7ji94b1d.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Still, I'd like to know why the checking in write-tree is necessary.
Ok, having thought about it a bit more, I think we can yank it
out. I'd rather keep ourselves cautious, though; there may be
some other ways we haven't thought of to create such nonsense,
and it would not hurt to be cautious before writing a tree out.
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 22:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <7v3bsx4aum.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
JCH> Ok, having thought about it a bit more, I think we can yank it
JCH> out. I'd rather keep ourselves cautious, though; there may be
JCH> some other ways we haven't thought of to create such nonsense,
JCH> and it would not hurt to be cautious before writing a tree out.
Here is a revert you can apply after merging with the tip of my
tree if you wanted to. As you pointed out correctly, three-way
read-tree would not produce the situation as I feared, and the
attempt to postprocess the result by git-merge-one-file-script
git-merge-cache calls would be caught with the changes we made
to git-update-cache, so there is no need for the extra check by
write-tree in that workflow example. Sorry for being ultra
dense.
The only reason why I am holding off from pushing this out is
because I still cannot convince myself that we eradicated _all_
the possibile paths to create such nonsense in the index, and I
feel safer to keep the check this patch is reverting, at least
for now.
---
Author: Junio C Hamano <junkio@cox.net>
Date: Sun May 8 15:34:17 2005 -0700
Revert the extra-careful check in write-tree.c
I am not particularly fond of reverting this, but with the
git-update-cache changes it is unlikely that we will have file
vs directory conflicts in the index anymore, so there may be no
point in being extra careful when writing the tree out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
--- a/write-tree.c
+++ b/write-tree.c
@@ -84,7 +84,7 @@ static int write_tree(struct cache_entry
int main(int argc, char **argv)
{
- int i, funny;
+ int i, unmerged;
int entries = read_cache();
unsigned char sha1[20];
@@ -92,45 +92,18 @@ int main(int argc, char **argv)
die("write-tree: no cache contents to write");
/* Verify that the tree is merged */
- funny = 0;
+ unmerged = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = active_cache[i];
if (ntohs(ce->ce_flags) & ~CE_NAMEMASK) {
- if (10 < ++funny) {
+ if (++unmerged > 10) {
fprintf(stderr, "...\n");
break;
}
fprintf(stderr, "%s: unmerged (%s)\n", ce->name, sha1_to_hex(ce->sha1));
}
}
- if (funny)
- die("write-tree: not able to write tree");
-
- /* Also verify that the cache does not have path and path/file
- * at the same time. At this point we know the cache has only
- * stage 0 entries.
- */
- funny = 0;
- for (i = 0; i < entries - 1; i++) {
- /* path/file always comes after path because of the way
- * the cache is sorted. Also path can appear only once,
- * which means conflicting one would immediately follow.
- */
- const char *this_name = active_cache[i]->name;
- const char *next_name = active_cache[i+1]->name;
- int this_len = strlen(this_name);
- if (this_len < strlen(next_name) &&
- strncmp(this_name, next_name, this_len) == 0 &&
- next_name[this_len] == '/') {
- if (10 < ++funny) {
- fprintf(stderr, "...\n");
- break;
- }
- fprintf(stderr, "You have both %s and %s\n",
- this_name, next_name);
- }
- }
- if (funny)
+ if (unmerged)
die("write-tree: not able to write tree");
/* Ok, write it out */
^ permalink raw reply
* Pointers to CVS 2 GIT imports and gateways
From: Martin Langhoff @ 2005-05-08 23:16 UTC (permalink / raw)
To: git
I am looking into importing a cvs repo HEAD history into git using
cvsps. I read throught the thread where Ingo discussed his import of
the kernel sources, but I couldn't find any pointers to what kind of
shell magic or other associated scripts were used, and google hasn't
helped much either.
How do I feed the patchsets into GIT preserving commit msgs and other metadata?
A related question follows: is anyone running git -> cvs gateways, and how?
pointers to TFM will be much appreciated ;)
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add exclude file support to cg-status
From: Junio C Hamano @ 2005-05-08 23:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: Matt Porter, git
In-Reply-To: <20050508015016.GL9495@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> ... since I *don't* think you want to share this. The very
PB> fact it is in the .git/ directory implies here that these
PB> are your local exclude patterns which are likely
PB> temporary...
Is it really the case? I recall that Linux kernel started
shipping with the standard dontdiff file for everybody's use
some time ago, after enough people wanted it included in the
upstream release. Maybe you would want to read from both?
PB> The fact that we have no support for version-tracked exclude file can't
PB> stop me! ;-)
What darcs folks do is that they have a per-tree configuration
(kept in ./_darcs, which is similar to our ./.git) that says
which file is the exclude list, and by setting configuration
item to point at a file which _is_ version controlled they can
share the exclude file.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.10
From: Petr Baudis @ 2005-05-08 23:34 UTC (permalink / raw)
To: git
Hello,
I'm happy to announce new release of Cogito, my SCM-like layer upon
the Linus' GIT tree history storage engine, aiming for user-friendliness.
Get it at
http://www.kernel.org/pub/software/scm/cogito
or cg-update if you already have any decently fresh version.
The highlights are cg-logging of individual files, cg-export
foo.tar.gz, fixed cg-init of fresh trees (it makes an initial commit
now), cg-commit message processing enhancements (in cooperation mainly
with Marcel Holtmann), cg-restore, cg-admin-uncommit, and cg-X* stuff in
a library directory. And also merge with Linus, which brings some stuff
chronologically pre-cogito-0.9, but I forgot to pull before release.
Usage changes:
* cg-update without parameters now does not recover lost files;
that functionality was moved to cg-restore which can do that
with individual files only too.
* cg-update and cg-pull w/o arguments default to "origin" again.
Everyone rejoices.
* cg-init SOURCE_LOC is now deprecated, cg-init should not be
called directly for the cloning stuff anymore. Use it only for
creating new repositories now.
* cg-clone can take a -s argument now which makes it to clone to
the current directory instead of a subdirectory.
I think the usage is very stabilized by now, and is actually quite
unlikely to change anymore - you can safely start to get used to it. The
only change still queued is removing cg-init SOURCE_LOC functionality
altogether; I'm delaying that yet mainly because of the
http://www.kernel.org/git/ text. ;-)
I think we are overall stabilizing very nicely, and might actually
be nearing cogito-1.0 (but let that not stop you doing anything yet...
perhaps except rewriting the whole thing in Befunge).
Please note that my patch queue is basically empty now. The only
things I have marked for consideration yet are:
4778 N Apr 22 Morten Welinder ( 7.0K) [PATCH] Constify
5607 N T Apr 28 Philip Pokorny ( 2.5K) PATCH[*/4]: Allow tree-id to return the ID of a tree object
So if you have a patch you think I should have in my tree too, please
resend it. Do not forget to put the patch inline to the mail body or as
a text/plain attachment, and to sign it off.
Have fun,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH 0/2] core-git documentation update
From: Junio C Hamano @ 2005-05-08 23:35 UTC (permalink / raw)
To: David Greaves; +Cc: git
In-Reply-To: <427E83EA.2000104@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
DG> The intention now was for me to go through Linus' HEAD and verify the
DG> docs actually documented the HEAD.
DG> Then I think comparing the HEAD to jit-jc and preparing patches for that?
That one is up to you, but if your patches are against git-jc,
it would make _my_ life simpler and hopefully would make merge
easier for Linus when he returns.
After he returns, it would probably not make much sense sending
patch against git-jc, unless all of the following conditions
hold true: (1) what is already merged to git-jc conflicts with
what you are modifying, (2) all changes in git-jc are trivially
correct and veriy likely to hit Linus tree without being
rejected, and (3) Linus is too busy and lags behind git-jc.
^ permalink raw reply
* Re: [PATCH] Add exclude file support to cg-status
From: Petr Baudis @ 2005-05-08 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt Porter, git
In-Reply-To: <7vfywx2t77.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, May 09, 2005 at 01:28:44AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> ... since I *don't* think you want to share this. The very
> PB> fact it is in the .git/ directory implies here that these
> PB> are your local exclude patterns which are likely
> PB> temporary...
>
> Is it really the case? I recall that Linux kernel started
> shipping with the standard dontdiff file for everybody's use
> some time ago, after enough people wanted it included in the
> upstream release. Maybe you would want to read from both?
Of course. You should combine them both, the .git/ one having the
ultimate precedence (if we support the CVS-like ! stuff too).
That is, in CVS the version-controlled files are per-directory, which
can be very nice too; things are getting harder now, though, since we
should have some per-project ignore file too.
> PB> The fact that we have no support for version-tracked exclude file can't
> PB> stop me! ;-)
>
> What darcs folks do is that they have a per-tree configuration
> (kept in ./_darcs, which is similar to our ./.git) that says
> which file is the exclude list, and by setting configuration
> item to point at a file which _is_ version controlled they can
> share the exclude file.
That is certainly a good idea (at least for kernel, where you probably
just want to give it dontdiff), but we need a sensible default.
--
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: Jonas Fonseca @ 2005-05-08 23:49 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1742.10.10.10.24.1115573750.squirrel@linux1>
Sean <seanlkml@sympatico.ca> wrote Sun, May 08, 2005:
> commit 33762f33ee87377c0cfcea51382bad04d7c9ba8d
>
> Fix cg-log -f option so that a complete list of files is
> displayed when a commit has more than one parent.
This sounds great.
> Move the list of files so they're displayed after the
> commit message
The reason I put it at the top was to make it more similar to GNU-style
changelogs (if there is such a style).
> List the files in columns, instead of one big line of comma-
> separated files.
I think that will make `-f' less usable because of the extra scrolling.
Assuming use of wc will not create more dependency nightmares and the
extra overhead is acceptable here is a patch that will wrap file listing
lines near the 80th column.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--- d4119364a7fbf5a4b8f00f061e4f5d58fa4abd0e/cg-log (mode:100755)
+++ uncommitted/cg-log (mode:100755)
@@ -64,8 +64,16 @@
fi
echo
$list_cmd | while read modes type sha1s file; do
- echo -n "$sep$file"
+ echo -n "$sep"
sep=", "
+ if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
+ line="$line$sep$file"
+ echo -n "$file"
+ else
+ line="$file"
+ echo "$coldefault"
+ echo -n " $colfiles$file"
+ fi
done
echo "$coldefault:"
}
--
Jonas Fonseca
^ permalink raw reply
* [PATCH Cogito] Use cg-commit -E to invoke editor and always commit
From: Marcel Holtmann @ 2005-05-09 0:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
Hi Petr,
the attached patch introduces the -E parameter to cg-commit and then
uses it in cg-init. If you use -E instead of -e the editor is invoked
and it will do the commit even it the default commit messages has not
been changed.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1618 bytes --]
cg-commit: needs update
cg-init: needs update
Index: cg-commit
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -13,6 +13,8 @@
# appended to a single commit message, each as separate paragraph.
# -e forces the editor to be brought up even when -m parameters were
# passed to cg-commit.
+# -E forces the editor to be brought up and it will do the commit
+# even if the default commit message is not changed.
. ${COGITO_LIB}cg-Xlib
@@ -21,6 +23,7 @@
forceeditor=
ignorecache=
+commitalways=
msgs=()
while [ "$1" ]; do
case "$1" in
@@ -32,6 +35,11 @@
forceeditor=1
shift
;;
+ -E)
+ forceeditor=1
+ commitalways=1
+ shift
+ ;;
-m*)
msgs=("${msgs[@]}" "${1#-m}")
shift
@@ -126,10 +134,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 ! [ "$commitalways" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Commit message not modified, commit aborted'
+ fi
fi
else
cat >>$LOGMSG2
Index: cg-init
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-init (mode:100755)
+++ uncommitted/cg-init (mode:100755)
@@ -32,6 +32,6 @@
else
git-read-tree # Seed the dircache
find * | xargs cg-add
- cg-commit -C -m"Initial commit" -e
+ cg-commit -C -m"Initial commit" -E
fi
exit 0
^ permalink raw reply
* [PATCH Cogito] Remove heading and trailing empty lines from commit messages
From: Marcel Holtmann @ 2005-05-09 0:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
Hi Petr,
the attached patch removes heading and trailing empty lines from the
commit message before doing the commit.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 389 bytes --]
cg-commit: needs update
Index: cg-commit
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -134,7 +134,7 @@
else
cat >>$LOGMSG2
fi
-grep -v ^CG: $LOGMSG2 >$LOGMSG
+grep -v ^CG: $LOGMSG2 | sed '/./,${/./b;:a;$d;N;/\n$/ba;b;};d' >$LOGMSG
rm $LOGMSG2
^ permalink raw reply
* [PATCH Cogito] Add -u option to cg-log to show only commits from a specific user
From: Marcel Holtmann @ 2005-05-09 0:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
Hi Petr,
the attached patch introduces the -u option for cg-log. Now you can give
a username or a part of a username and only commits with a matching
author or committer will be displayed.
This patch also changes the option parsing, because otherwise we are
stuck to a specific order.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2105 bytes --]
cg-log: needs update
Index: cg-log
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-log (mode:100755)
+++ uncommitted/cg-log (mode:100755)
@@ -15,6 +15,9 @@
#
# Takes an -f option to list which files was changed.
#
+# Takes -u"username" to list only commits where author or
+# committer contains username.
+#
# 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.
@@ -27,29 +30,39 @@
# at least somewhere it does. Bash is broken.
trap exit SIGPIPE
-if [ "$1" = "-c" ]; then
- shift
- # 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
-else
- colheader=
- colauthor=
- colcommitter=
- colfiles=
- colsignoff=
- coldefault=
-fi
-
+colheader=
+colauthor=
+colcommitter=
+colfiles=
+colsignoff=
+coldefault=
list_files=
-if [ "$1" = "-f" ]; then
- shift
- list_files=1
-fi
+user=
+while [ "$1" ]; do
+ case "$1" 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
+ shift
+ ;;
+ -f)
+ list_files=1
+ shift
+ ;;
+ -u*)
+ user="${1#-u}"
+ shift
+ ;;
+ *)
+ break
+ ;;
+ esac
+done
list_commit_files()
{
@@ -109,6 +122,9 @@
parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
[ "$parent" ] && [ "$(git-diff-tree -r $commit $parent "$@")" ] || continue
fi
+ if [ "$user" ]; then
+ git-cat-file commit $commit | grep -e '^author ' -e '^committer ' | grep -qi "$user" || continue
+ fi
echo $colheader""commit ${commit%:*} $coldefault;
git-cat-file commit $commit | \
while read key rest; do
^ permalink raw reply
* [PATCH Cogito] Strip .git suffix from destination directory
From: Marcel Holtmann @ 2005-05-09 1:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
Hi Petr,
the attached patch brings back the feature where a .git suffix got
stripped from the directory name when cloning another tree.
It also fixes a $samedir vs. $same_dir spelling mistake.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 592 bytes --]
cg-clone: needs update
Index: cg-clone
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-clone (mode:100755)
+++ uncommitted/cg-clone (mode:100755)
@@ -28,10 +28,10 @@
destdir=$2
if [ "$destdir" ]; then
- [ ! "$samedir" ] || die "specifying both -s and DESTDIR makes no sense"
+ [ ! "$same_dir" ] || die "specifying both -s and DESTDIR makes no sense"
dir=$destdir
else
- dir=${location%/.git}; dir=${dir##*/}
+ dir=${location%/.git}; dir=${dir##*/}; dir=${dir%.git}
fi
if ! echo "$location" | grep -q ":" ; then
^ permalink raw reply
* [PATCH] Add cg-printenv command.
From: Steven Cole @ 2005-05-09 1:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
The cg-printenv command will print exported git environment variables.
Signed-off-by: Steven Cole <elenstev@mesatop.com>
Index: Makefile
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/Makefile (mode:100644)
+++ uncommitted/Makefile (mode:100644)
@@ -48,7 +48,8 @@
SCRIPT= commit-id tree-id parent-id cg-add cg-admin-lsobj cg-admin-uncommit \
cg-branch-add cg-branch-ls cg-cancel cg-clone cg-commit cg-diff \
cg-export cg-help cg-init cg-log cg-ls cg-merge cg-mkpatch cg-patch \
- cg-pull cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls cg-update
+ cg-printenv cg-pull cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls \
+ cg-update
LIB_SCRIPT=cg-Xlib cg-Xdiffdo cg-Xmergefile
Index: cg-help
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/cg-help (mode:100755)
+++ uncommitted/cg-help (mode:100755)
@@ -35,6 +35,7 @@
cg-merge [-c] [-b BASE_ID] FROM_ID
cg-mkpatch [-s] [-r FROM_ID[:TO_ID]]
cg-patch < patch on stdin
+ cg-printenv
cg-pull [BNAME]
cg-restore [FILE]...
cg-rm FILE...
Index: cg-printenv
===================================================================
--- /dev/null (tree:3974261da777f55a7a11aff6e02f584bbfe2b475)
+++ uncommitted/cg-printenv (mode:100755)
@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+#
+# Print exported git environment variables
+# Copyright (c) Steven Cole 2005
+#
+#These git environment variables are used in case
+#values other than that returned by getpwuid(getuid())
+#are desired when performing a commit.
+#
+#AUTHOR_NAME Author's name
+#AUTHOR_EMAIL Author's e-mail address
+#AUTHOR_DATE Date, perhaps from a patch e-mail
+#COMMIT_AUTHOR_NAME Committer's name
+#COMMIT_AUTHOR_EMAIL Committer's e-mail address
+#
+# Takes no parameters.
+echo "AUTHOR_NAME="$AUTHOR_NAME
+echo "AUTHOR_EMAIL="$AUTHOR_EMAIL
+echo "AUTHOR_DATE="$AUTHOR_DATE
+echo "COMMIT_AUTHOR_NAME="$COMMIT_AUTHOR_NAME
+echo "COMMIT_AUTHOR_EMAIL="$COMMIT_AUTHOR_EMAIL
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Marcel Holtmann @ 2005-05-09 1:19 UTC (permalink / raw)
To: Steven Cole; +Cc: Petr Baudis, git
In-Reply-To: <200505081911.10371.elenstev@mesatop.com>
Hi Steven,
> The cg-printenv command will print exported git environment variables.
I like that idea. It is much more handy then using env and grep for the
variable names.
Regards
Marcel
^ permalink raw reply
* Prototype git commit viewer
From: Paul Mackerras @ 2005-05-09 1:40 UTC (permalink / raw)
To: git
Over the weekend I hacked up a prototype viewer for git commits in
Tk. It's called gitk and is at:
http://ozlabs.org/~paulus/gitk
(that's the actual script itself :).
It displays a window with two panes; the upper one shows a summary of
all the commits with a graph on the left showing the relationship of
the commits (each dot represents a commit, with lines joining parents
and children). The list is displayed with the most recent commit at
the top, and parents below their children.
If you click on a commit, the bottom pane shows more details of the
commit including the commit comments.
I plan to add a pane to show the list of files changed by the commit,
and provide a way to pop up a dirdiff-style diff viewer window to view
the actual diffs. I also plan to add a way to view the diffs between
arbitrary points in the graph using girdiff. There is quite a lot of
UI tweaking to be done too. However, it's already quite useful in its
current state.
Paul.
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Junio C Hamano @ 2005-05-09 2:38 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Steven Cole, Petr Baudis, git
In-Reply-To: <1115601540.8949.104.camel@pegasus>
MH> Hi Steven,
>> The cg-printenv command will print exported git environment variables.
SC> +echo "AUTHOR_NAME="$AUTHOR_NAME
SC> +echo "AUTHOR_EMAIL="$AUTHOR_EMAIL
SC> +echo "AUTHOR_DATE="$AUTHOR_DATE
SC> +echo "COMMIT_AUTHOR_NAME="$COMMIT_AUTHOR_NAME
SC> +echo "COMMIT_AUTHOR_EMAIL="$COMMIT_AUTHOR_EMAIL
MH> I like that idea. It is much more handy then using env and grep for the
MH> variable names.
I wonder what this command is used for? In a script to be
"eval"ed? Or just interactively by the end-user?
Even if it is just for human consumption, I think the echo
commands I quoted above have double quotes backwards. Wouldn't
it make more sense to quote the variables so shell expansion
would not lose whitespaces inside of variable values, like this?
echo AUTHOR_NAME="$AUTHOR_NAME"
echo AUTHOR_EMAIL="$AUTHOR_EMAIL"
echo AUTHOR_DATE="$AUTHOR_DATE"
echo COMMIT_AUTHOR_NAME="$COMMIT_AUTHOR_NAME"
echo COMMIT_AUTHOR_EMAIL="$COMMIT_AUTHOR_EMAIL"
If it is for eval consumption of course they have to be much
more careful.
^ 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