* Re: [RFC] allow file list editing during cg-commit
From: Petr Baudis @ 2005-05-09 8:46 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Eugene Surovegin, git
In-Reply-To: <1115627229.8949.132.camel@pegasus>
Dear diary, on Mon, May 09, 2005 at 10:27:09AM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Eugene,
Hello,
> > I just started playing with cogito and failed to find _easy_ way to
> > select which files will be committed and which won't. cg-commit seems
> > to support specifying file list in command line, but this isn't very
> > convenient when the list is big.
>
> do you know any SCM native text interface that supports such a thing? In
> general this is done by high-level GUI based interfaces to the SCM or a
> special Emacs mode etc.
so what? I still think the idea is cool, why shouldn't support it if
noone else does?
The only thing to watch out for is that cg-commit -C produces no such
list at all; it should deal with that and tell the user he is not going
to be able to control what is going to be committed then.
Another thing is that at the moment you modify the file list, you should
set customfiles - otherwise you will commit even cg-adds and cg-rms of
files you didn't select. But do that really only when you change the
file list, since it is more expensive.
You should also place an appropriate hint near the CG: lines, saying
that removing some of them will limit the list of files to be committed.
--
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: [RFC] allow file list editing during cg-commit
From: Eugene Surovegin @ 2005-05-09 8:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1115627229.8949.132.camel@pegasus>
On Mon, May 09, 2005 at 10:27:09AM +0200, Marcel Holtmann wrote:
> Hi Eugene,
>
> > I just started playing with cogito and failed to find _easy_ way to
> > select which files will be committed and which won't. cg-commit seems
> > to support specifying file list in command line, but this isn't very
> > convenient when the list is big.
>
> do you know any SCM native text interface that supports such a thing? In
> general this is done by high-level GUI based interfaces to the SCM or a
> special Emacs mode etc.
Perforce works like that. This is where I "stole" this idea :)
I think cogito _is_ UI, a text one, of course.
--
Eugene
^ permalink raw reply
* Re: [RFC] allow file list editing during cg-commit
From: Marcel Holtmann @ 2005-05-09 8:27 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: git
In-Reply-To: <20050509041459.GA13475@gate.ebshome.net>
Hi Eugene,
> I just started playing with cogito and failed to find _easy_ way to
> select which files will be committed and which won't. cg-commit seems
> to support specifying file list in command line, but this isn't very
> convenient when the list is big.
do you know any SCM native text interface that supports such a thing? In
general this is done by high-level GUI based interfaces to the SCM or a
special Emacs mode etc.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Petr Baudis @ 2005-05-09 7:33 UTC (permalink / raw)
To: Edgar Toernig; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <20050509052814.617dceac.froese@gmx.de>
Dear diary, on Mon, May 09, 2005 at 05:28:14AM CEST, I got a letter
where Edgar Toernig <froese@gmx.de> told me that...
> Petr Baudis wrote:
> >
> > > + if ! [ $LOGMSG2 -nt $LOGMSG ]; then
> > > + rm $LOGMSG $LOGMSG2
> > > + die 'Commit message not modified, commit aborted'
> > > + fi
>
> Just in case you come to a conclusion some day, how about changing the
> if-test to
>
> if cmp -s $LOGMSG LOGMSG2; then
>
> ? :-) IMHO much better then comparing only the date.
>
> Ciao, ET.
Much, much worse. What if I really actually do not want to change
anything in the merge message or the series of -m's? Ok, :x didn't work
now since we cannot know. But now, :wq won't do either, and you actually
need to do some silly dummy change now.
I think we should really ask the user as CVS, as Marcel (or whoever)
suggested.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Petr Baudis @ 2005-05-09 7:24 UTC (permalink / raw)
To: Steven Cole; +Cc: Sean, Junio C Hamano, Marcel Holtmann, git
In-Reply-To: <200505082159.59595.elenstev@mesatop.com>
Dear diary, on Mon, May 09, 2005 at 05:59:59AM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> told me that...
> On Sunday 08 May 2005 09:40 pm, Sean wrote:
> > On Sun, May 8, 2005 11:25 pm, Steven Cole said:
> >
> > > I had intended it only as a quick check by an end-user before doing
> > > a commit that the values had been set as desired.
> >
> > Hey Steven,
> >
> > Rather than creating a separate command, perhaps the values could
> > automatically be added to the initial commit message in a few "CG:" lines?
I was already thinking about this and I think Sean's way makes more
sense. Also, I actually believe you should add this functionality to
commit-tree instead (commit-tree -n (dry-run), perhaps?) - so that the
user can actually check the default values commit-tree is going to use
too. *That* would be useful.
> A secondary reason for adding the cg-printenv capability was that a user would
> see this command in the cg-help list, and cg-help printenv would give:
No, I think this sucks. You should just list the variables in cg-commit
documentation if anything. That's where they matter anyway and where the
user could possibly look for them anyway.
I think the command is otherwise pretty useless, and the important thing
is, the command slots are precious (well, there are free cg-admin slots
but I think this one does not qualify there neither) - have too many
useless (or barely useful) commands and you end up as GNU Arch. So I'm
willing to add commands only when I'm convinced they will really help
the user.
--
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: Prototype git commit viewer
From: Petr Baudis @ 2005-05-09 7:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17022.49021.344841.79940@cargo.ozlabs.ibm.com>
Dear diary, on Mon, May 09, 2005 at 03:40:13AM CEST, I got a letter
where Paul Mackerras <paulus@samba.org> told me that...
> 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.
What are its advantages to git-viz?
--
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: [RFC] Cache optimizations
From: Junio C Hamano @ 2005-05-09 5:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0505090058240.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> Does anyone know of a reason not to refresh each entry in
DB> the cache as it's checked out?
I vaguely recall Linus saying something about wanting to keep
checkout-cache being a read-only consumer of the index file;
I've checked mailing list archive but I cannot not find a
reference to point you at, though.
^ permalink raw reply
* Re: Pointers to CVS 2 GIT imports and gateways
From: Martin Langhoff @ 2005-05-09 5:41 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <427EEB9E.9070701@zytor.com>
On 5/9/05, H. Peter Anvin <hpa@zytor.com> wrote:
> What would be the point? The reason for bkcvs was that bk wasn't
> available to everyone.
Ease of transition for other automated tasks, perhaps? I don't know
what bits and pieces of infrastructure hang from the old BK-CVS
changeset distribution infrastructure.
Some projects do count on CVS gateways even if they use smarter SCMs.
This is not just because of licensing issues -- sometimes portability
and preexisting tools trump SCM changes.
regards,
martin
^ permalink raw reply
* [RFC] Cache optimizations
From: Daniel Barkalow @ 2005-05-09 5:15 UTC (permalink / raw)
To: git
Does anyone know of a reason not to refresh each entry in the cache as
it's checked out? It seems to me like this would eliminate the need to
call update-cache --refresh after checkout-cache and it would update only
the entries for files which are actually changed in the working directory.
Is it just that the code to lock and write the cache is
(currently) inconvenient to add to different programs?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Pointers to CVS 2 GIT imports and gateways
From: H. Peter Anvin @ 2005-05-09 4:48 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90505081616335c2a61@mail.gmail.com>
Martin Langhoff wrote:
>
> A related question follows: is anyone running git -> cvs gateways, and how?
>
What would be the point? The reason for bkcvs was that bk wasn't
available to everyone.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.10
From: H. Peter Anvin @ 2005-05-09 4:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050508233431.GP9495@pasky.ji.cz>
Petr Baudis wrote:
>
> 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.
>
An autogenerated specfile so "rpmbuild -ta" works would still be very
much appreciated.
-hpa
^ permalink raw reply
* [RFC] allow file list editing during cg-commit
From: Eugene Surovegin @ 2005-05-09 4:14 UTC (permalink / raw)
To: git
Hi!
I just started playing with cogito and failed to find _easy_ way to
select which files will be committed and which won't. cg-commit seems
to support specifying file list in command line, but this isn't very
convenient when the list is big.
I tend to have many modified files in my repo, but commit them in
several different changeset.
I just made simple change to cg-commit which allows editing file
list while editing log message; for example, if I have 30 files ready
for commit, but want to commit only 29, I just remove this file
from "CG:" list.
Patch which demonstrates the idea follows. Please note, this is
just a quick hack, and I probably missed some cg-commit cases, when
such behavior is undesirable; also, I cheated a little to make
grepping easy :).
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Index: cg-commit
===================================================================
--- 3974261da777f55a7a11aff6e02f584bbfe2b475/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -116,7 +116,7 @@
for file in "${commitfiles[@]}"; do
# TODO: Prepend a letter describing whether it's addition,
# removal or update. Or call git status on those files.
- echo "CG: $file" >>$LOGMSG
+ echo "CG:F $file" >>$LOGMSG
[ "$msgs" ] && ! [ "$forceeditor" ] && echo $file
done
fi
@@ -131,6 +131,11 @@
rm $LOGMSG $LOGMSG2
die 'Commit message not modified, commit aborted'
fi
+ eval commitfiles=($(grep ^CG:F $LOGMSG2 | sed 's/^CG:F//'))
+ if [ ! "${commitfiles[*]}" ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Nothing to commit'
+ fi
else
cat >>$LOGMSG2
fi
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Steven Cole @ 2005-05-09 3:59 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Marcel Holtmann, Petr Baudis, git
In-Reply-To: <2970.10.10.10.24.1115610025.squirrel@linux1>
On Sunday 08 May 2005 09:40 pm, Sean wrote:
> On Sun, May 8, 2005 11:25 pm, Steven Cole said:
>
> > I had intended it only as a quick check by an end-user before doing
> > a commit that the values had been set as desired.
>
> Hey Steven,
>
> Rather than creating a separate command, perhaps the values could
> automatically be added to the initial commit message in a few "CG:" lines?
>
> Sean
A secondary reason for adding the cg-printenv capability was that a user would
see this command in the cg-help list, and cg-help printenv would give:
Print exported git environment variables
Copyright (c) Steven Cole 2005 <--- Petr, my early version of cg-help stripped (c) lines.
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.
-------------
Yes, I know that the environment variables are documented in Documentation/core-git.txt,
but having this usage right up front like this may help those who only RTFM as a last resort.
If others feel that the more obscure environment variables should be exposed here, feel
free to submit patches.
Here is a patch with Junio's improved version:
--------------------------------------------------------------------------------------
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: cg-log patches
From: Sean @ 2005-05-09 3:45 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <20050508234936.GA26624@diku.dk>
On Sun, May 8, 2005 7:49 pm, Jonas Fonseca said:
Hey Jonas,
>> 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.
You might want to rip it out and submit it, because it's not likely to see
the light of day otherwise.
> The reason I put it at the top was to make it more similar to GNU-style
> changelogs (if there is such a style).
Yeah, I felt a bit guilty sliding that shift in, really I had no rationale
other than it looked better _to me_.
> 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.
Your patch will work fine but I did test my version out against the kernel
repo and it didn't seem to be a problem.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Sean @ 2005-05-09 3:40 UTC (permalink / raw)
To: Steven Cole; +Cc: Junio C Hamano, Marcel Holtmann, Petr Baudis, git
In-Reply-To: <200505082125.28521.elenstev@mesatop.com>
On Sun, May 8, 2005 11:25 pm, Steven Cole said:
> I had intended it only as a quick check by an end-user before doing
> a commit that the values had been set as desired.
Hey Steven,
Rather than creating a separate command, perhaps the values could
automatically be added to the initial commit message in a few "CG:" lines?
Sean
^ permalink raw reply
* Re: [PATCH] Add cg-printenv command.
From: Steven Cole @ 2005-05-09 3:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marcel Holtmann, Petr Baudis, git
In-Reply-To: <7vpsw115v0.fsf@assigned-by-dhcp.cox.net>
On Sunday 08 May 2005 08:38 pm, Junio C Hamano wrote:
> 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?
I had intended it only as a quick check by an end-user before doing
a commit that the values had been set as desired.
>
> 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"
>
My simple testing didn't result in any meaningful whitespace loss,
but I only had a single blank character inside my test strings. Your
method is better.
[steven@spc cogito]$ echo "AUTHOR_NAME="$AUTHOR_NAME
AUTHOR_NAME=Homer Simpson
[steven@spc cogito]$ echo COMMIT_AUTHOR_NAME="$COMMIT_AUTHOR_NAME"
COMMIT_AUTHOR_NAME=Two Spaces Here
> If it is for eval consumption of course they have to be much
> more careful.
>
If Petr wants to add this command, he can either move the double quotes
or I can submit a modified patch.
Thanks,
Steven
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Edgar Toernig @ 2005-05-09 3:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marcel Holtmann, GIT Mailing List
In-Reply-To: <20050508210857.GL9495@pasky.ji.cz>
Petr Baudis wrote:
>
> > + if ! [ $LOGMSG2 -nt $LOGMSG ]; then
> > + rm $LOGMSG $LOGMSG2
> > + die 'Commit message not modified, commit aborted'
> > + fi
Just in case you come to a conclusion some day, how about changing the
if-test to
if cmp -s $LOGMSG LOGMSG2; then
? :-) IMHO much better then comparing only the date.
Ciao, ET.
^ permalink raw reply
* Re: Prototype git commit viewer
From: Junio C Hamano @ 2005-05-09 2:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17022.49021.344841.79940@cargo.ozlabs.ibm.com>
Good job --- I like it already. Especially the way it correctly
handles oddballs like 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
;-).
^ 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
* 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: 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
* [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
* [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 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] 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
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