* Re: Pointers to CVS 2 GIT imports and gateways
From: H. Peter Anvin @ 2005-05-09 13:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f905050822413ece89b9@mail.gmail.com>
Martin Langhoff wrote:
>
> 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.
>
None. That was all owned by Bitmover.
-hpa
^ permalink raw reply
* Re: cg-log patches
From: Sean @ 2005-05-09 13:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jonas Fonseca, GIT Mailing List
In-Reply-To: <20050509121435.GB18382@pasky.ji.cz>
On Mon, May 9, 2005 8:14 am, Petr Baudis said:
> But that makes no sense, since each merge will have enormous amount of
> files listed, making no sense. E.g. each merge of Cogito with Linus will
> have all the Cogito files listed, since they aren't in the Linus branch
> - but that's wrong, since the merge _to_ the Cogito branch concerns no
> Cogito files.
>
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
But, there are commits (even in your tree) that aren't produced by Cogito.
And the current logic gets them wrong.
Look at commit: 211232bae64bcc60bbf5d1b5e5b2344c22ed767e in your tree.
The current logic will miss the fact that one of the other parents
altered, git-apply-patch-script. Seems better to over report, than under
report changes, although I agree that some way must be found to handle the
merge case.
Sean
^ permalink raw reply
* Re: cg-log patches
From: Jonas Fonseca @ 2005-05-09 12:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050509121435.GB18382@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> wrote Mon, May 09, 2005:
> Dear diary, on Mon, May 09, 2005 at 01:39:07PM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> told me that...
> > Fix cg-log -f option so that a complete list of files is
> > displayed when a commit has more than one parent.
> >
> > Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> But that makes no sense, since each merge will have enormous amount of
> files listed, making no sense. E.g. each merge of Cogito with Linus will
> have all the Cogito files listed, since they aren't in the Linus branch
> - but that's wrong, since the merge _to_ the Cogito branch concerns no
> Cogito files.
>
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
>
> parent A
> parent B
Ok, forget the patch then. I was not sure how to handle the multiple parents.
> > Index: cg-log
> > ===================================================================
> > --- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
> > +++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log (mode:100755)
> > @@ -67,8 +67,16 @@
> > done
> > fi | sort -u | \
> > while read modes type sha1s file; do
> > - echo -n "$sep$file"
# Always put a trailing comma
> > + 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:"
> > }
>
> Could we have a trailing comma at the previous line?
It should already do that ..
committer Petr Baudis <xpasky@machine.sinus.cz> Sun, 08 May 2005 23:54:08 +0200
* cg-Xlib, cg-update, cg-seek, cg-pull, cg-tag-ls, cg-branch-ls, cg-merge,
cg-commit, cg-tag, cg-init, cg-branch-add, cg-admin-lsobj, cg-status,
cg-cancel, cg-admin-uncommit:
--
Jonas Fonseca
^ permalink raw reply
* Re: cg-log patches
From: Petr Baudis @ 2005-05-09 12:14 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050509113907.GA22830@diku.dk>
Dear diary, on Mon, May 09, 2005 at 01:39:07PM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Fix cg-log -f option so that a complete list of files is
> displayed when a commit has more than one parent.
>
> Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
But that makes no sense, since each merge will have enormous amount of
files listed, making no sense. E.g. each merge of Cogito with Linus will
have all the Cogito files listed, since they aren't in the Linus branch
- but that's wrong, since the merge _to_ the Cogito branch concerns no
Cogito files.
In git, the parents list is unordered. But this is different in Cogito,
where the first parent _is_ special. If you are merging _from_ branch B
_to_ branch A, the order of parents will be always
parent A
parent B
In practice, it does not make too much difference, but this is one of
the cases where it makes difference. So I think the current behaviour is
right.
BTW, this also implies that merges
A --
\
B ---+--
and
A ---+--
/
B --
are considered as different ones by Cogito; in git itself, you might
model that as
A --.
>---
B --'
which is not possible in Cogito. I could imagine doing it by e.g.
passing cg-clone multiple arguments, but I'd have to first see a
compelling real-world usage for this first.
> Index: cg-log
> ===================================================================
> --- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
> +++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log (mode:100755)
> @@ -67,8 +67,16 @@
> done
> fi | sort -u | \
> 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:"
> }
Could we have a trailing comma at the previous line?
--
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-09 11:39 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <4302.10.10.10.24.1115610350.squirrel@linux1>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Sean <seanlkml@sympatico.ca> wrote Sun, May 08, 2005:
> On Sun, May 8, 2005 7:49 pm, Jonas Fonseca said:
> Hey Jonas,
Hi Sean,
> >> 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.
I ripped it out and made a patch only with the fix.
Pasky, I also updated the line-wrapping patch if you want it.
> > 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 don't feel strong about it. I guess I have just gotten used to it that
way.
--
Jonas Fonseca
[-- Attachment #2: fix-cg-log.patch --]
[-- Type: text/plain, Size: 2218 bytes --]
Fix cg-log -f option so that a complete list of files is
displayed when a commit has more than one parent.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 06a6b40f8e52eff0e34706c7024b54df50abb6b9
tree 95bc73fd188347aa294991d1c5c7cffd60422098
parent 4ed293bc0a5ffca9683e139cad499b69a4c4d569
author jonas <fonseca@diku.dk> Mon, 09 May 2005 13:23:20 +0200
committer jonas <fonseca@diku.dk> Mon, 09 May 2005 13:23:20 +0200
cg-log | 34 +++++++++++++++-------------------
1 files changed, 15 insertions(+), 19 deletions(-)
Index: cg-log
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-log (mode:100755)
+++ 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
@@ -53,17 +53,20 @@
list_commit_files()
{
- tree1="$1"
- tree2="$2"
+ tree="$1"
sep=" * $colfiles"
- # List all files for for the initial commit
- if [ -z $tree2 ]; then
- list_cmd="git-ls-tree $tree1"
- else
- list_cmd="git-diff-tree -r $tree1 $tree2"
- fi
echo
- $list_cmd | while read modes type sha1s file; do
+ if [ -z $2 ]; then
+ # List all files for the initial commit
+ git-ls-tree $tree
+ else
+ shift
+ # List changes from each parent
+ for parent; do
+ git-diff-tree -r $tree $parent
+ done
+ fi | sort -u | \
+ while read modes type sha1s file; do
echo -n "$sep$file"
sep=", "
done
@@ -102,8 +105,7 @@
$revls | $revsort | while read time commit parents; do
trap exit SIGPIPE
- tree1=
- tree2=
+ trees=
[ "$revfmt" = "git-rev-list" ] && commit="$time"
if [ $# -ne 0 ]; then
parent=$(git-cat-file commit $commit | sed -n '2s/parent //p;2Q')
@@ -131,17 +133,11 @@
fi
;;
"tree"|"parent")
- if [ -z $tree1 ]; then
- tree1=$rest
- elif [ -z $tree2 ]; then
- tree2=$rest
- fi
+ trees="$trees $rest"
echo $colheader$key $rest $coldefault
;;
"")
- if [ -n "$list_files" ]; then
- list_commit_files "$tree1" "$tree2"
- fi
+ [ -n "$list_files" ] && list_commit_files $trees
echo; sed -re '
/ *Signed-off-by:.*/Is//'$colsignoff'&'$coldefault'/
/ *Acked-by:.*/Is//'$colsignoff'&'$coldefault'/
[-- Attachment #3: wrap-file-listing-lines.patch --]
[-- Type: text/plain, Size: 1030 bytes --]
Wrap file listing lines near the 80th column.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 9d86f44f7d1eee525ed4c45731ad07b95f62dbb6
tree ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8
parent 06a6b40f8e52eff0e34706c7024b54df50abb6b9
author jonas <fonseca@diku.dk> Mon, 09 May 2005 13:27:20 +0200
committer jonas <fonseca@diku.dk> Mon, 09 May 2005 13:27:20 +0200
cg-log | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletion(-)
Index: cg-log
===================================================================
--- 95bc73fd188347aa294991d1c5c7cffd60422098/cg-log (mode:100755)
+++ ddf82a0140bdc1440eb93bcbe01e14e90e44a3e8/cg-log (mode:100755)
@@ -67,8 +67,16 @@
done
fi | sort -u | \
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:"
}
^ permalink raw reply
* Re: Prototype git commit viewer
From: Benjamin Herrenschmidt @ 2005-05-09 9:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paul Mackerras, git
In-Reply-To: <20050509071341.GA3599@pasky.ji.cz>
>
> What are its advantages to git-viz?
I haven't looked at git-viz in details, but from the screen-shot, I can
say I prefer paulus one :)
But heh, since when should we limit ourselves to a single tool to do a
given job ? :)
^ permalink raw reply
* 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
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