* Re: [zooko@zooko.com: [Revctrl] colliding md5 hashes of human-meaningfuldocuments]
From: Daniel Barkalow @ 2005-06-14 2:23 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, petr
On Mon, 13 Jun 2005, David Lang wrote:
> Daniel, I thought that git changed to hash the uncompressed data so that
> you don't spend the time compressing all the data just to find out what's
> already known.
That's right; never mind.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Adding Correct Useage Notification and -h Help flag
From: James Purser @ 2005-06-14 2:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzptbrsg.fsf@assigned-by-dhcp.cox.net>
Thanks for the tips, I shall submit a new patch along these lines when I
get home from work tonight.
On Tue, 2005-06-14 at 12:23, Junio C Hamano wrote:
> >>Added a couple of lines to the git wrapper. Includes Correct
> >>Useage and available scripts
>
> I like the general direction of making "git" wrapper novice
> friendly, but have some suggestions to the implementation.
>
> (0) Do not mention that only certain subset is accessible.
> Just saying "Available commands are:" would be enough, and
> would not leave the end user wondering what he is missing.
>
> (1) Instead of explicitly checking for -h, you may want to
> structure it like this:
>
> #!/bin/sh
>
> cmd="git-$1-script";
> shift;
> exec $cmd "$@";
> echo "Usage: git <subcommand> [<param>...]"
> echo 'Available commands are:"
> git bar
> git foo
> ...
> '
> exit 1
>
> Alternatively, you could say:
>
> #!/bin/sh
>
> case "$1" in
> -h)
> echo "Usage: git <subcommand> [<param>...]"
> echo 'Available commands are:
> git bar
> git foo
> ...
> '
> exit 0 ;;
> esac
>
> cmd="git-$1-script";
> shift;
> exec $cmd "$@";
> git -h
> exit 1
>
> (2) Maintaining the list of commands by hand in git script
> itself have an advantage that you _could_ describe the
> options and parameters they take, but you are not doing
> that in your patch (hint, hint).
>
> If all you give is the list of subcommand names, have
> git.in as a source file, and create the "list of available
> commands" from the Makefile, like this:
>
> === Makefile ===
> ...
> git : git.in
> /bin/sh ls -1 git-*-script | \
> sed -e 's/git-\(.*\)-script/git \1/' >.git-cmd-list
> sed -e '/@@LIST_OF_COMMANDS@@/{s/.*//;r .git-cmd-list;}' <$@.in >$@
> rm -f .git-cmd-list
>
> === git.in ===
> #!/bin/sh
>
> cmd="git-$1-script";
> shift;
> exec $cmd "$@";
> echo "Usage: git <subcommand> [<param>...]"
> echo 'Available commands are:
> @@LIST_OF_COMMANDS@@
> '
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
James Purser
Winnet Developer
+61 2 4223 4131
http://www.winnet.com.au
^ permalink raw reply
* Re: [PATCH] Adding Correct Useage Notification and -h Help flag
From: James Purser @ 2005-06-14 5:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzptbrsg.fsf@assigned-by-dhcp.cox.net>
One thing I would like to double check.
When running git commit I am told to run git-update-cache against the
files I want to commit. Would it be easier to have the git-commit-script
run this itself? Take out that second step and all that.
--
James Purser
Winnet Developer
+61 2 4223 4131
http://www.winnet.com.au
^ permalink raw reply
* Re: [PATCH] Adding Correct Useage Notification and -h Help flag
From: Junio C Hamano @ 2005-06-14 5:52 UTC (permalink / raw)
To: purserj; +Cc: git
In-Reply-To: <1118726714.8712.22.camel@localhost.localdomain>
>>>>> "JP" == James Purser <purserj@winnsw.com.au> writes:
JP> When running git commit I am told to run git-update-cache
JP> against the files I want to commit. Would it be easier to
JP> have the git-commit-script run this itself? Take out that
JP> second step and all that.
That's a question better asked Linus, not me. My preference
would be (1) to ask the user if he wants us to automatically run
git-update-cache to all of those files, giving him an option to
decline and sort things out himself; or (2) leave things as they
are.
The core GIT treats the index file and the working directory
contents two logically separate entities, and we always require
the user to consciously tell us what to put in and remove from
the index file. The core GIT is all about committed tree
objects and the index file, and the working directory is merely
a temporary area the user can use to build the state the user
wishes to have in the index file. From this point of view,
running git-update-cache ourselves without asking the user is a
definite no-no.
^ permalink raw reply
* [PATCH] ssh-push: Don't add '/' to pathname
From: Sven Verdoolaege @ 2005-06-14 10:37 UTC (permalink / raw)
To: git, Daniel Barkalow, Linus Torvalds
ssh-push: Don't add '/' to pathname
Paths in the host:path notation are usually interpreted
relative to the login directory rather than relative to
the root directory.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
---
commit 508f3a7ad9d940529ad6736763108fe5c7729171
tree 7332f4cd8f29f0548821f1d0501b2e9a45ae502a
parent 200b82de27633d2c85a4358e1be5ae7fab1b077f
author Sven Verdoolaege <skimo@liacs.nl> Tue, 14 Jun 2005 12:34:49 +0200
committer Sven Verdoolaege <skimo@liacs.nl> Tue, 14 Jun 2005 12:34:49 +0200
rsh.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/rsh.c b/rsh.c
--- a/rsh.c
+++ b/rsh.c
@@ -31,14 +31,15 @@ int setup_connection(int *fd_in, int *fd
} else {
host = url;
path = strchr(host, ':');
+ if (path)
+ *(path++) = '\0';
}
if (!path) {
return error("Bad URL: %s", url);
}
- *(path++) = '\0';
- /* ssh <host> 'cd /<path>; stdio-pull <arg...> <commit-id>' */
+ /* ssh <host> 'cd <path>; stdio-pull <arg...> <commit-id>' */
snprintf(command, COMMAND_SIZE,
- "%s='/%s' %s",
+ "%s='%s' %s",
GIT_DIR_ENVIRONMENT, path, remote_prog);
posn = command + strlen(command);
for (i = 0; i < rmt_argc; i++) {
^ permalink raw reply
* [PATCH 1/1] Add support for an optional .nextmsg file to git-commit-script
From: Jon Seymour @ 2005-06-14 11:42 UTC (permalink / raw)
To: git; +Cc: jon.seymour
This change allows a commit message to be prepared prior to git-commit-script being
invoked. During git commit the user is then given an opportunity to edit the
existing message, if any, and must confirm the commit by deleting a sentinel
line from the top of the edit buffer.
If the user does not delete the sentinel line, the commit is aborted and the
text of the message is saved for future editing.
The purpose of this change is to enable undo/redo tools to repopulate a commit
message from a previous commit that has been undone and then allow the user to
make small edits to the previous commit message prior recommitting the change.
If the .nextmsg file does not exist, git-commit-script behaves as before.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-commit-script | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -1,5 +1,12 @@
#!/bin/sh
+SENTINEL="*** delete this line to confirm the commit ***"
: ${GIT_DIR=.git}
+:> .editmsg
+
+if [ -f .nextmsg ]
+then
+ cat .nextmsg >>.editmsg
+fi
PARENTS="HEAD"
if [ -f $GIT_DIR/MERGE_HEAD ]; then
echo "#"
@@ -9,17 +16,31 @@ if [ -f $GIT_DIR/MERGE_HEAD ]; then
echo "# and try again"
echo "#"
PARENTS="HEAD -p MERGE_HEAD"
-fi > .editmsg
+fi >> .editmsg
git-status-script >> .editmsg
if [ "$?" != "0" ]
then
cat .editmsg
exit 1
fi
+if [ -f .nextmsg ]
+then
+ echo "$SENTINEL" >>.editmsg
+fi
${VISUAL:-${EDITOR:-vi}} .editmsg
-grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
+if [ -f .nextmsg ]
+then
+ egrep -v "(^#|\\$SENTINEL)" < .editmsg > .nextmsg
+ if grep "\\$SENTINEL" < .editmsg >/dev/null
+ then
+ :> .editmsg
+ echo "commit aborted - to confirm, delete the sentinel line in the message"
+ fi
+fi
+egrep -v "^#|$SENTINEL" < .editmsg | git-stripspace > .cmitmsg
[ -s .cmitmsg ] || exit 1
tree=$(git-write-tree) || exit 1
commit=$(cat .cmitmsg | git-commit-tree $tree -p $PARENTS) || exit 1
echo $commit > $GIT_DIR/HEAD
rm -f -- $GIT_DIR/MERGE_HEAD
+[ -f .nextmsg ] && rm .nextmsg
------------
^ permalink raw reply
* Re: [PATCH] Unset TZ in t5000
From: Mark Allen @ 2005-06-14 13:17 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <42ADAC4D.7050408@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
--- Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:> Mark Allen schrieb:
> The expression
>
> length($5)<7 ? $5":00" : $5
>
> (where $5 is a time value) is there to cope with tars that format the
> time like hh:mm instead of the expected hh:mm:ss.
I put (escaped) parenthesis around the length function and now it works as expected.
Here's a new patch. Please ack if you approve.
Thanks,
--Mark
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
[-- Attachment #2: 560000162-t5000-portability.patch.txt --]
[-- Type: text/plain, Size: 528 bytes --]
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -50,8 +50,9 @@ test_expect_success \
test_expect_success \
'validate file modification time' \
- 'tar tvf b.tar a/a |
- awk \{print\ \$4,\ length\(\$5\)\<7\ ?\ \$5\":00\"\ :\ \$5\} >b.mtime &&
+ 'TZ= tar tvf b.tar a/a |
+ awk \{print\ \$4,\ \(length\(\$5\)\<7\)\ ?\ \$5\":00\"\ :\ \$5\} \
+ >b.mtime &&
echo "2005-05-27 22:00:00" >expected.mtime &&
diff expected.mtime b.mtime'
^ permalink raw reply
* Semantics for one step undo/redo
From: Jon Seymour @ 2005-06-14 13:50 UTC (permalink / raw)
To: Git Mailing List
Hi.
I've implemented some undo/redo scripts which I am testing in my own
workspace before I unleash them on an wider audience. However, I
thought it would be useful to discuss the semantics of my approach on
the list.
The approach focuses on one-step undo, redo. What I mean by this is
that a given undo or redo operation can undo or redo exactly one
commit. Of course, it is possible to compose arbitrary sequences of
undo and redos with the expected results. I regard multi-commit
undos/redos to be a special case of the one-step undo/redo and so can
be neglected for the purposes of discussion.
UNDO Semantics:
When the working tree and cache are synced with a commit, C, then
undo has the effect of returning the workspace to the state
immediately prior to the commit C.
UNDO Pre-conditions:
- the working tree matches the cache (git-update-cache --refresh
exits with zero)
- the cache matches the tree specified by HEAD or UNDONE_HEAD
UNDO Post-conditions
- UNDONE_HEAD is set to the value of HEAD
- HEAD is replaced by its left-most parent
- HEAD's commit message is written to .nextmsg
- the workspace tree and cache is unchanged
- an entry containing the UNDONE_HEAD head and its parents are
written to the end git/redo-log
A tweak to the undo implementation would be to allow the user to
specify which merge branch to undo down.
REDO Semantics
- redo will replay a previous commit but any or all of the tree,
the parents, the message may be replaced by edited values.
REDO Pre-conditions:
- at least one entry exists in the .git/redo-log
- the cache matches the working tree
- .nextmsg contains the commit message
- HEAD contains the commit id of the current predecessor (which
may differ from the logged value)
REDO Post-conditions:
- the working tree is committed with .nextmsg as its message, the
first parent replaced by HEAD and the remaining parents read from .the
tail of .git/redo-log
- .nextmsg is cleared
- the last line of .git/redo-log is removed
With the scripts I have written, I can fix a commit message, 4
messages old with:
undo
undo
undo
undo
vi .nextmsg
while redo
do
echo done
done
I think my approach differs a little from Junio's (but I haven't
analysed his deeply) in that the redolog is actually just the slightly
edited output of git-rev-list --merge-order --parents head base [ the
edits removes from the list the parallel branches that aren't actually
involved in the undo ]
Comments?
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Semantics for one step undo/redo
From: Jon Seymour @ 2005-06-14 13:54 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205061406507af5a66@mail.gmail.com>
Sorry, I omitted an important aspect of REDO Post-conditions - corrected below
> REDO Semantics
> - redo will replay a previous commit but any or all of the tree,
> the parents, the message may be replaced by edited values.
>
> REDO Pre-conditions:
> - at least one entry exists in the .git/redo-log
> - the cache matches the working tree
> - .nextmsg contains the commit message
> - HEAD contains the commit id of the current predecessor (which
> may differ from the logged value)
>
> REDO Post-conditions:
> - the working tree is committed with .nextmsg as its message, the
> first parent replaced by HEAD and the remaining parents read from .the
> tail of .git/redo-log
> - .nextmsg is cleared
> - the last line of .git/redo-log is removed
additional post-conditions:
- the diff between the old head and its old parent (as read from
the log) is applied to the workspace and cache.
- if the re-applied diff fails, the workspace and cache are
returned back to the state immediately following the previous commit
and the user has the chance to manually reapply the diffs before
updating the index into a state that allows further redos
jon.
^ permalink raw reply
* Re: [PATCH 1/1] Add support for an optional .nextmsg file to git-commit-script
From: Junio C Hamano @ 2005-06-14 14:44 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <20050614114243.12267.qmail@blackcubes.dyndns.org>
>>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> writes:
JS> This change allows a commit message to be prepared prior to git-commit-script being
JS> invoked. During git commit the user is then given an opportunity to edit the
JS> existing message, if any, and must confirm the commit by deleting a sentinel
JS> line from the top of the edit buffer.
JS> #!/bin/sh
JS> +SENTINEL="*** delete this line to confirm the commit ***"
JS> ..
JS> +egrep -v "^#|$SENTINEL" < .editmsg | git-stripspace > .cmitmsg
A handful comments.
(1) Although it happens to work in this case, I do not like
scripts that use grep without quoting metacharacters in a
string. You have two egreps that phrases the above slightly
differently. Make up your mind ;-) and pick one.
(2) What happens if I later want to make a commit with this commit
log?
[PATCH] Reword the sentinel line.
Instead of saying "*** delete this line to confirm the commit ***",
just say "# If you want to abort the commit, make this file empty.".
(3) The original implementation knows that the commit is to be
aborted when resulting .cmitmsg is empty. You may want to
tell the user in the comment in the commit template about
it, instead of using the sentinel line.
(4) Instead of teaching git-commit-script about the .nextmsg
file, it may be cleaner to split it into two parts:
- one that prepares the .cmitmsg file for editing;
- the other that invokes the editor on prepared a .cmitmsg
file, checks if the message file is edited and asks for
confirmation to abort if the file is unchanged, and does the
actual commit.
The new git-commit-script would prepare its .cmitmsg the way it
does now and only call the latter half. Your re-commit script
can do the first half differently from what git-commit-script
does, and call the same latter half.
P.S. I see you are using "git format-patch"; I'd suggest you
hand edit " 1/1" out of [PATCH 1/1] subject line for a patch
like this that is not part of a series. I did not special case
1/1 to do it myself because I often have a handful independent
patches and end up removing 1/7 2/7 ... etc. anyway.
^ permalink raw reply
* [PATCH] Warning fix in diff.c
From: Yoichi Yuasa @ 2005-06-14 14:57 UTC (permalink / raw)
To: git; +Cc: yuasa
This patch had fixed the following warning.
Please apply.
cc -g -O2 -Wall '-DSHA1_HEADER="mozilla-sha1/sha1.h"' -c -o diff.o diff.c
diff.c: In function `parse_num':
diff.c:606: warning: value computed is not used
Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -603,7 +603,7 @@ static int parse_num(const char **cp_p)
scale *= 10;
num = num * 10 + ch - '0';
}
- *cp++;
+ cp++;
}
*cp_p = cp;
^ permalink raw reply
* Re: Semantics for one step undo/redo
From: Junio C Hamano @ 2005-06-14 15:01 UTC (permalink / raw)
To: jon; +Cc: git
In-Reply-To: <2cfc403205061406507af5a66@mail.gmail.com>
>>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> writes:
JS> I think my approach differs a little from Junio's (but I haven't
JS> analysed his deeply) in that the redolog is actually just the slightly
JS> edited output of git-rev-list --merge-order --parents head base [ the
JS> edits removes from the list the parallel branches that aren't actually
JS> involved in the undo ]
JS> Comments?
I've only took a brief glance at your description and found it
quite sensible. I did not find anything majorly wrong.
If you are talking about jit-rewind (I think the message I told
you about it was not sent to the list, so the list audience may
not know about it, by the way), there is not much to analyze.
It populates the snapshot pool with the commits in the specified
commit chain, and after that it is totally up to the user what
to do with them, hence there is no redo semantics attached to
it. JIT way of doing things is generally more dangerous in that
it gives you so much more flexibility that it lets you freely
shoot yourself in the foot ;-). When the core Plumbing side
stabilizes I may revisit updating JIT to make certain parts of
it not so sharp-edged, but I have been busy futzing with the
Plumbing side lately, and having found not much need to change
JIT, haven't done much about updating my own Porcelain.
^ permalink raw reply
* Re: [PATCH] Unset TZ in t5000
From: Rene Scharfe @ 2005-06-14 15:17 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20050614131727.23011.qmail@web41211.mail.yahoo.com>
Mark Allen schrieb:
> --- Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:> Mark Allen schrieb:
> > The expression
>
>> length($5)<7 ? $5":00" : $5
>>
>>(where $5 is a time value) is there to cope with tars that format the
>>time like hh:mm instead of the expected hh:mm:ss.
>
>
> I put (escaped) parenthesis around the length function and now it works as expected.
> Here's a new patch. Please ack if you approve.
>
> Thanks,
>
> --Mark
>
> Signed-off-by: Mark Allen <mrallen1@yahoo.com>
>
>
> ------------------------------------------------------------------------
>
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -50,8 +50,9 @@ test_expect_success \
>
> test_expect_success \
> 'validate file modification time' \
> - 'tar tvf b.tar a/a |
> - awk \{print\ \$4,\ length\(\$5\)\<7\ ?\ \$5\":00\"\ :\ \$5\} >b.mtime &&
> + 'TZ= tar tvf b.tar a/a |
> + awk \{print\ \$4,\ \(length\(\$5\)\<7\)\ ?\ \$5\":00\"\ :\ \$5\} \
> + >b.mtime &&
> echo "2005-05-27 22:00:00" >expected.mtime &&
> diff expected.mtime b.mtime'
>
Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
^ permalink raw reply
* hgweb and gitweb: Commit times displayed incorrectly
From: Radoslaw Szkodzinski @ 2005-06-14 15:44 UTC (permalink / raw)
To: mercurial, git
Who is wrong there, especially with hours count?
Here it's 17:43 +0200
hgweb:
*16 hours ago: * *[PATCH] Typo in fbdev sysfs support, virtual_size *
changeset 30069: e888fb306d22e08c14c3aedac3ea32f8a918c0c0
<http://www.kernel.org/hg/?cmd=changeset;node=e888fb306d22e08c14c3aedac3ea32f8a918c0c0>
parent: 67be48281441be602419b1ceb0bd419b3be4b84b
<http://www.kernel.org/hg/?cmd=changeset;node=67be48281441be602419b1ceb0bd419b3be4b84b>
author: Jon Smirl <jonsmirl@gmail.com <mailto:jonsmirl@gmail.com>>
date: Mon Jun 13 22:52:36 2005
files
<http://www.kernel.org/hg/?cmd=manifest;manifest=c775357b0cce7d4f6835a5e1755a7c00c8a6516c;path=/>:
drivers/video/fbsysfs.c
<http://www.kernel.org/hg/?cmd=filediff;node=e888fb306d22e08c14c3aedac3ea32f8a918c0c0;file=drivers/video/fbsysfs.c>
gitweb:
/11 hours ago/ /Jon Smirl/ *[PATCH] Typo in fbdev sysfs support,
virtual_size*
<http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e2c16499515aa044676a14b97a1b8a35f879152a>
author Jon Smirl <jonsmirl@gmail.com <mailto:jonsmirl@gmail.com>>
Mon, 13 Jun 2005 22:52:36 +0000 (15:52 -0700)
committer Linus Torvalds <torvalds@ppc970.osdl.org
<mailto:torvalds@ppc970.osdl.org>>
Tue, 14 Jun 2005 03:58:58 +0000 (20:58 -0700)
commit e2c16499515aa044676a14b97a1b8a35f879152a
My clone:
commit e2c16499515aa044676a14b97a1b8a35f879152a
tree 87addb997369837e8cdad63c212876d161691ad2
parent 6df3cecbb95345981718b38d357c50bc3425420a
author Jon Smirl <jonsmirl@gmail.com> Mon, 13 Jun 2005 15:52:36 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> Mon, 13 Jun 2005
20:58:58 -0700
[PATCH] Typo in fbdev sysfs support, virtual_size
^ permalink raw reply
* Re: hgweb and gitweb: Commit times displayed incorrectly
From: Thomas Arendsen Hein @ 2005-06-14 16:25 UTC (permalink / raw)
To: mercurial, git
In-Reply-To: <42AEFB66.80902@gorzow.mm.pl>
* Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> [20050614 17:45]:
> Who is wrong there, especially with hours count?
> Here it's 17:43 +0200
>
> hgweb:
> *16 hours ago: *
http://www.kernel.org/hg/?cmd=changelog;rev=30069
> gitweb:
> /11 hours ago/
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=log;h=e2c16499515aa044676a14b97a1b8a35f879152a
> My clone:
> author Jon Smirl <jonsmirl@gmail.com> Mon, 13 Jun 2005 15:52:36 -0700
> committer Linus Torvalds <torvalds@ppc970.osdl.org> Mon, 13 Jun 2005 20:58:58 -0700
Both are correct.
hgweb uses the timestamp of the "author" line, gitweb uses the
timestamp of the "commiter" line. Mercurial (hg) doesn't distinguish
author and commiter, therefore it uses the earlier time.
Regards,
Thomas Arendsen Hein
--
Email: thomas@intevation.de
http://intevation.de/~thomas/
^ permalink raw reply
* Re: [PATCH] Unset TZ in t5000
From: Mark Allen @ 2005-06-14 17:09 UTC (permalink / raw)
To: Rene Scharfe, torvalds; +Cc: git
In-Reply-To: <42AEF512.5040107@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
Linus,
Please apply this patch to make t5000 more portable.
Thanks,
--Mark
---
Unset TZ to force GMT in test #4 and add a set of parens around
the length function in the awk script.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
[-- Attachment #2: 560000162-t5000-portability.patch.txt --]
[-- Type: text/plain, Size: 528 bytes --]
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -50,8 +50,9 @@ test_expect_success \
test_expect_success \
'validate file modification time' \
- 'tar tvf b.tar a/a |
- awk \{print\ \$4,\ length\(\$5\)\<7\ ?\ \$5\":00\"\ :\ \$5\} >b.mtime &&
+ 'TZ= tar tvf b.tar a/a |
+ awk \{print\ \$4,\ \(length\(\$5\)\<7\)\ ?\ \$5\":00\"\ :\ \$5\} \
+ >b.mtime &&
echo "2005-05-27 22:00:00" >expected.mtime &&
diff expected.mtime b.mtime'
^ permalink raw reply
* Re: hgweb and gitweb: Commit times displayed incorrectly
From: Matt Mackall @ 2005-06-14 17:38 UTC (permalink / raw)
To: mercurial, git
In-Reply-To: <20050614162541.GA27165@intevation.de>
On Tue, Jun 14, 2005 at 06:25:41PM +0200, Thomas Arendsen Hein wrote:
> * Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> [20050614 17:45]:
> > Who is wrong there, especially with hours count?
> > Here it's 17:43 +0200
> >
> > hgweb:
> > *16 hours ago: *
>
> http://www.kernel.org/hg/?cmd=changelog;rev=30069
>
> > gitweb:
> > /11 hours ago/
>
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=log;h=e2c16499515aa044676a14b97a1b8a35f879152a
>
> > My clone:
> > author Jon Smirl <jonsmirl@gmail.com> Mon, 13 Jun 2005 15:52:36 -0700
> > committer Linus Torvalds <torvalds@ppc970.osdl.org> Mon, 13 Jun 2005 20:58:58 -0700
>
> Both are correct.
>
> hgweb uses the timestamp of the "author" line, gitweb uses the
> timestamp of the "commiter" line. Mercurial (hg) doesn't distinguish
> author and commiter, therefore it uses the earlier time.
I may change this. One of the goals here is to have enough information
to generate git-compatible exports. Possibly through an extended
version of hgweb (hgitweb?).
So I'm eventually going to preserve both fields. The question is how.
Do we want separate author and committer fields in Mercurial?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] Adding Correct Useage Notification and -h Help flag
From: James Purser @ 2005-06-14 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzptbrsg.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]
Heres the revised patch along the lines you recommended yesterday. I am
still working on some of the command descriptions.
On the git-update-cache question, I think having a flag [-u] or
something like that in git commit would allow the user to decide to run
git-update-cache on only the files specified in the git commit command.
Signed-off-by: James Purser <purserj@k-sit.com>
On Tue, 2005-06-14 at 12:23, Junio C Hamano wrote:
> >>Added a couple of lines to the git wrapper. Includes Correct
> >>Useage and available scripts
>
> I like the general direction of making "git" wrapper novice
> friendly, but have some suggestions to the implementation.
>
> (0) Do not mention that only certain subset is accessible.
> Just saying "Available commands are:" would be enough, and
> would not leave the end user wondering what he is missing.
>
> (1) Instead of explicitly checking for -h, you may want to
> structure it like this:
>
> #!/bin/sh
>
> cmd="git-$1-script";
> shift;
> exec $cmd "$@";
> echo "Usage: git <subcommand> [<param>...]"
> echo 'Available commands are:"
> git bar
> git foo
> ...
> '
> exit 1
>
> Alternatively, you could say:
>
> #!/bin/sh
>
> case "$1" in
> -h)
> echo "Usage: git <subcommand> [<param>...]"
> echo 'Available commands are:
> git bar
> git foo
> ...
> '
> exit 0 ;;
> esac
>
> cmd="git-$1-script";
> shift;
> exec $cmd "$@";
> git -h
> exit 1
>
> (2) Maintaining the list of commands by hand in git script
> itself have an advantage that you _could_ describe the
> options and parameters they take, but you are not doing
> that in your patch (hint, hint).
>
> If all you give is the list of subcommand names, have
> git.in as a source file, and create the "list of available
> commands" from the Makefile, like this:
>
> === Makefile ===
> ...
> git : git.in
> /bin/sh ls -1 git-*-script | \
> sed -e 's/git-\(.*\)-script/git \1/' >.git-cmd-list
> sed -e '/@@LIST_OF_COMMANDS@@/{s/.*//;r .git-cmd-list;}' <$@.in >$@
> rm -f .git-cmd-list
>
> === git.in ===
> #!/bin/sh
>
> cmd="git-$1-script";
> shift;
> exec $cmd "$@";
> echo "Usage: git <subcommand> [<param>...]"
> echo 'Available commands are:
> @@LIST_OF_COMMANDS@@
> '
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: git_patch --]
[-- Type: text/plain, Size: 1835 bytes --]
Make the git wrapper a little bit more newbie friendly, when called on its own or with the -h flag will return a list of the commands available
---
commit 2ad499f75f0982953e43904085bd1b48dd821c4d
tree f137c4f3f5ee027b8b4d25a0434929e12eb7c51c
parent de4971b50076b5ef901c2ae0bbee9dd2c14f06ea
parent de4971b50076b5ef901c2ae0bbee9dd2c14f06ea
author James Purser <purserj@k-sit.com> Wed, 15 Jun 2005 07:43:20
committer James Purser <purserj@k-sit.com> Wed, 15 Jun 2005 07:43:20
git | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/git b/git
--- a/git
+++ b/git
@@ -1,4 +1,56 @@
#!/bin/sh
-cmd="git-$1-script"
-shift
-exec $cmd "$@"
+
+case "$1" in
+-h|"")
+ echo "Useage: git <subcommand> [<param 1>, <param 2> ...]"
+ echo "Available commands are:
+
+git apply-patch <patch file>
+
+ Applies patch file to local files
+
+git commit <file 1> <file 2> ...
+
+ Commits local changes to the cache. Before running this script you will need to run git-update-cache on the files you wish to commit.
+
+ Will accept wildcards ie git commit git-*-scripts
+
+git cvsimport [-v] [-z fuzz] <cvsroot> <module>
+
+ CVS to Git import tool. Relies on the cvsps package at least 2.1
+
+ -v Verbose output
+ -z
+ <cvsroot> Path to CVS Repository
+ <module> Module you want to import into git
+
+git deltafy:
+
+git diff [<File 1>, <File 2>, ...]
+
+ Diffs between the git cache and specified files. If no files are specified then creates a Diff between contents of the cache and all current files.
+
+git fetch:
+
+git log:
+
+git merge-one-file:
+
+git prune:
+
+git pull:
+
+git status:
+
+git tag:
+"
+ exit 0 ;;
+esac
+
+cmd="git-$1-script";
+shift;
+exec $cmd "$@";
+git -h
+exit 1
+
+
^ permalink raw reply
* [COGITO PATCH] Optimized print_help()
From: Pavel Roskin @ 2005-06-14 23:26 UTC (permalink / raw)
To: git
Hello!
print_help() in cg-Xlib should not be calling "which" 3 times. It's an
external command. The patch caches the result in a local variable.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -130,10 +130,11 @@ update_index () {
print_help () {
- which "cg-$1" >/dev/null 2>&1 || exit 1
- sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' < $(which cg-$1)
+ local toolpath=$(which cg-$1 2>/dev/null)
+ [ -z "$toolpath" ] && exit 1
+ sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' < $toolpath
echo
- cat $(which cg-$1) | sed -n '3,/^$/s/^# *//p'
+ cat $toolpath | sed -n '3,/^$/s/^# *//p'
exit
}
--
Regards,
Pavel Roskin
^ permalink raw reply
* [COGITO PATCH] Fixing "cg-help typo" again
From: Pavel Roskin @ 2005-06-14 23:32 UTC (permalink / raw)
To: git
Hello!
"cg-help typo" is broken again (same symptom - no output) because the
print_help() output is piped through colorize(), which never fails.
I don't know any way to get return status of the first command in a
pipeline, so I changed to code to put print_help() output in a variable,
check status and then pipe the variable contents through colorize().
GNU bash can hold indefinitely much data in variables, and we need a few
kilobytes at most.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-help b/cg-help
--- a/cg-help
+++ b/cg-help
@@ -59,7 +59,8 @@ colorize() {
if [ "$ARGS" ]; then
cmd=$(echo "${ARGS[0]}" | sed 's/^cg-//')
- ( print_help $cmd | colorize ) && exit
+ helpdata="$(print_help $cmd)"
+ [ "$?" = 0 ] && { echo "$helpdata" | colorize; exit 0; }
echo "cg-help: no help available for command \"${ARGS[0]}\""
echo "Call cg-help without any arguments for the list of available commands"
exit 1
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [COGITO PATCH] Fixing "cg-help typo" again
From: Jonas Fonseca @ 2005-06-14 23:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1118791967.3890.11.camel@dv>
Pavel Roskin <proski@gnu.org> wrote Tue, Jun 14, 2005:
> Hello!
Hi,
> "cg-help typo" is broken again (same symptom - no output) because the
> print_help() output is piped through colorize(), which never fails.
Sorry, I broke it in the cg-help colorization patch, and has already
sent a patch to pasky, off-list I am afraid ...
>
> I don't know any way to get return status of the first command in a
> pipeline, so I changed to code to put print_help() output in a variable,
> check status and then pipe the variable contents through colorize().
Use the PIPESTATUS aray as in the patch I sent:
@@ -59,7 +59,8 @@ colorize() {
if [ "$ARGS" ]; then
cmd=$(echo "${ARGS[0]}" | sed 's/^cg-//')
- ( print_help $cmd | colorize ) && exit
+ print_help $cmd | colorize
+ [ "${PIPESTATUS[0]}" -eq 0 ] && exit
echo "cg-help: no help available for command \"${ARGS[0]}\""
echo "Call cg-help without any arguments for the list of available commands"
exit 1
--
Jonas Fonseca
^ permalink raw reply
* Re: [COGITO PATCH] Optimized print_help()
From: Jonas Fonseca @ 2005-06-15 0:00 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1118791576.3890.4.camel@dv>
Pavel Roskin <proski@gnu.org> wrote Tue, Jun 14, 2005:
> Hello!
>
> print_help() in cg-Xlib should not be calling "which" 3 times. It's an
> external command. The patch caches the result in a local variable.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> diff --git a/cg-Xlib b/cg-Xlib
> --- a/cg-Xlib
> +++ b/cg-Xlib
> @@ -130,10 +130,11 @@ update_index () {
>
>
> print_help () {
> - which "cg-$1" >/dev/null 2>&1 || exit 1
> - sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' < $(which cg-$1)
> + local toolpath=$(which cg-$1 2>/dev/null)
> + [ -z "$toolpath" ] && exit 1
> + sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' < $toolpath
Shouldn't $toolpath be quoted here to make it safer? Although it seems
the make install don't handle irregular toolpaths at the moment.
> echo
> - cat $(which cg-$1) | sed -n '3,/^$/s/^# *//p'
> + cat $toolpath | sed -n '3,/^$/s/^# *//p'
What about also removing UUOC from this line ...
sed -n '3,/^$/s/^# *//p' < "$toolpath"
> exit
> }
--
Jonas Fonseca
^ permalink raw reply
* Re: [COGITO PATCH] Fixing "cg-help typo" again
From: Pavel Roskin @ 2005-06-15 0:17 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20050614234333.GA17152@diku.dk>
Hi, Jonas!
On Wed, 2005-06-15 at 01:43 +0200, Jonas Fonseca wrote:
> Pavel Roskin <proski@gnu.org> wrote Tue, Jun 14, 2005:
> > I don't know any way to get return status of the first command in a
> > pipeline, so I changed to code to put print_help() output in a variable,
> > check status and then pipe the variable contents through colorize().
>
> Use the PIPESTATUS aray as in the patch I sent:
OK, your patch is better.
Acked-by: Pavel Roskin <proski@gnu.org>
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [COGITO PATCH] Optimized print_help()
From: Pavel Roskin @ 2005-06-15 0:33 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20050615000001.GB17152@diku.dk>
On Wed, 2005-06-15 at 02:00 +0200, Jonas Fonseca wrote:
> Shouldn't $toolpath be quoted here to make it safer? Although it seems
> the make install don't handle irregular toolpaths at the moment.
Sure.
> > + cat $toolpath | sed -n '3,/^$/s/^# *//p'
>
> What about also removing UUOC from this line ...
UUOC? I had too look it up :-)
It's not just "useless use of cat", but also useless use of redirection
in both cases. I guess sed can exit after it finishes processing the
range (I don't know if it actually does), so feeding it the whole file
is not need.
OK, here's an improved patch.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -130,10 +130,11 @@ update_index () {
print_help () {
- which "cg-$1" >/dev/null 2>&1 || exit 1
- sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' < $(which cg-$1)
+ local toolpath=$(which cg-$1 2>/dev/null)
+ [ -z "$toolpath" ] && exit 1
+ sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' "$toolpath"
echo
- cat $(which cg-$1) | sed -n '3,/^$/s/^# *//p'
+ sed -n '3,/^$/s/^# *//p' "$toolpath"
exit
}
P.S. Maybe we could use "type" rather than "which" because the former is
a shell built-in. Or maybe we should hardcode the prefix on install.
Anyway, it's out of scope of this patch.
P.P.S. I hope that $toolpath doesn't start with "-". I could add "--"
to the sed command line, but I'm not sure if BSD sed would like it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* cg-restore - restoring modified files
From: Pavel Roskin @ 2005-06-15 1:45 UTC (permalink / raw)
To: git
Hello!
I believe the documented behavior of cg-restore is inconsistent.
"Restore given files to their original state. Without any parameters, it
recovers any files removed locally whose removal was not recorded by
`cg-rm`."
I interpret it that cg-restore without arguments restores removed files
but not modified ones.
"If passed a set of file names, it restores those files to their state
as of the last commit (including bringing files removed with cg-rm back
to life; FIXME: does not do that part yet)."
I interpret it that cg-restore with arguments restores both removed and
modified files.
Maybe we need an option whether to restore modified files? Or maybe
they should always be restored (I think it would more consistent)? Then
the help text should be more clear about modified files.
The actual behavior is that modified files are never restored. We need
"-f" option for git-checkout-cache to overwrite existing files, and it's
not used whether the filenames are specified or not. I wanted to send a
patch, but after reading help I'm not sure what exactly cg-restore is
supposed to do.
--
Regards,
Pavel Roskin
^ 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