* [PATCH 3/3] Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
From: Christian Couder @ 2007-10-24 5:01 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-bisect.sh | 82 +++++++++++++++++++++-----------------------------------
1 files changed, 31 insertions(+), 51 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 61a2956..f8d0099 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -135,47 +135,33 @@ bisect_write() {
test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
-bisect_bad() {
+bisect_state() {
bisect_autostart
- case "$#" in
- 0)
- rev=$(git rev-parse --verify HEAD) ;;
- 1)
- rev=$(git rev-parse --verify "$1^{commit}") ;;
+ state=$1
+ case "$#,$state" in
+ 0,*)
+ die "Please call 'bisect_state' with at least one argument." ;;
+ 1,bad|1,good|1,skip)
+ rev=$(git rev-parse --verify HEAD) ||
+ die "Bad rev input: HEAD"
+ bisect_write "$state" "$rev" ;;
+ 2,bad)
+ rev=$(git rev-parse --verify "$2^{commit}") ||
+ die "Bad rev input: $2"
+ bisect_write "$state" "$rev" ;;
+ *,good|*,skip)
+ shift
+ revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@"
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") ||
+ die "Bad rev commit: $rev^{commit}"
+ bisect_write "$state" "$rev"
+ done ;;
*)
usage ;;
- esac || exit
- bisect_write 'bad' "$rev"
- bisect_auto_next
-}
-
-bisect_good() {
- bisect_autostart
- case "$#" in
- 0) revs=$(git rev-parse --verify HEAD) || exit ;;
- *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
- test '' != "$revs" || die "Bad rev input: $@" ;;
esac
- for rev in $revs
- do
- rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write 'good' "$rev"
- done
- bisect_auto_next
-}
-
-bisect_skip() {
- bisect_autostart
- case "$#" in
- 0) revs=$(git rev-parse --verify HEAD) || exit ;;
- *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
- test '' != "$revs" || die "Bad rev input: $@" ;;
- esac
- for rev in $revs
- do
- rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write 'skip' "$rev"
- done
bisect_auto_next
}
@@ -405,24 +391,22 @@ bisect_run () {
exit $res
fi
- # Use "bisect_good" or "bisect_bad"
- # depending on run success or failure.
+ # Find current state depending on run success or failure.
if [ $res -gt 0 ]; then
- next_bisect='bisect_bad'
+ state='bad'
else
- next_bisect='bisect_good'
+ state='good'
fi
- # We have to use a subshell because bisect_good or
- # bisect_bad functions can exit.
- ( $next_bisect > "$GIT_DIR/BISECT_RUN" )
+ # We have to use a subshell because "bisect_state" can exit.
+ ( bisect_state $state > "$GIT_DIR/BISECT_RUN" )
res=$?
cat "$GIT_DIR/BISECT_RUN"
if [ $res -ne 0 ]; then
echo >&2 "bisect run failed:"
- echo >&2 "$next_bisect exited with error code $res"
+ echo >&2 "'bisect_state $state' exited with error code $res"
exit $res
fi
@@ -444,12 +428,8 @@ case "$#" in
case "$cmd" in
start)
bisect_start "$@" ;;
- bad)
- bisect_bad "$@" ;;
- good)
- bisect_good "$@" ;;
- skip)
- bisect_skip "$@" ;;
+ bad|good|skip)
+ bisect_state "$cmd" "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
--
1.5.3.4.215.g187cf
^ permalink raw reply related
* Re: What's cooking in git/spearce.git (topics)
From: Theodore Tso @ 2007-10-24 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7vtzoh7j1l.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 23, 2007 at 12:00:38PM -0700, Junio C Hamano wrote:
>
> You can view 'next' as if it is sort of -mm. Following 'master'
> is like following Linus tree, whose development is without those
> numerous 'merge improvements again' merges into 'next'.
Actually -mm is much closer to 'pu', since it can and is rewound all
the time. Patches can disappear if they are causing problems, they
can be replaced and reworked, etc.
- Ted
^ permalink raw reply
* Re: intended use of "git --exec-path"?
From: Scott Parish @ 2007-10-24 5:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071024043819.GI14735@spearce.org>
On Wed, Oct 24, 2007 at 12:38:19AM -0400, Shawn O. Pearce wrote:
> Scott Parish <sRp@srparish.net> wrote:
> > "git --exec-path" presently prints out the highest priority path
> > to find executable in. That's a what; i'm curious why and when it
> > should be used. Basically i'm wondering if its still useful, and
> > what, if anything, it should be printing.
>
> git-gui uses it. git-gui runs git-* by prefixing it with the
> exec path. It also scans the first line of the file if we are on
> Windows and the "executable" doesn't end in ".exe" so it can figure
> out what process to run it through.
>
> So it really can't go away.
So it sounds like it might be more helpful for git to return its
PATH, so other programs can set their PATH or search for executables
accordingly.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: intended use of "git --exec-path"?
From: David Symonds @ 2007-10-24 5:54 UTC (permalink / raw)
To: Scott Parish; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071024054749.GT16291@srparish.net>
On 10/24/07, Scott Parish <sRp@srparish.net> wrote:
> On Wed, Oct 24, 2007 at 12:38:19AM -0400, Shawn O. Pearce wrote:
>
> > Scott Parish <sRp@srparish.net> wrote:
> > > "git --exec-path" presently prints out the highest priority path
> > > to find executable in. That's a what; i'm curious why and when it
> > > should be used. Basically i'm wondering if its still useful, and
> > > what, if anything, it should be printing.
> >
> > git-gui uses it. git-gui runs git-* by prefixing it with the
> > exec path. It also scans the first line of the file if we are on
> > Windows and the "executable" doesn't end in ".exe" so it can figure
> > out what process to run it through.
> >
> > So it really can't go away.
>
> So it sounds like it might be more helpful for git to return its
> PATH, so other programs can set their PATH or search for executables
> accordingly.
You don't necessarily want to be monkeying around with $PATH if you're
trying to use a particular git installation (say, a build of next)
instead of your "proper" install, which is in your $PATH; if you call
/some/random/path/git-whatever, it should use the git tools in
/some/random/path/, not in $PATH.
Dave.
^ permalink raw reply
* Re: [PATCH 7/9] git-hash-object: Add --stdin-paths option
From: Eric Wong @ 2007-10-24 6:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Adam Roben, git, Junio C Hamano
In-Reply-To: <20071023061022.GG14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Adam Roben <aroben@apple.com> wrote:
> > Shawn O. Pearce wrote:
> > >Adam Roben <aroben@apple.com> wrote:
> > >
> > >>This allows multiple paths to be specified on stdin.
> > >
> > >git-fast-import wasn't suited to the task?
> >
> > I actually considered using fast-import for the whole shebang, but
> > decided that I don't yet understand the workings and structure of
> > git-svn well enough to make such a big change.
> >
> > git-svn uses git-hash-object to both determine a file's hash and insert
> > it into the index in one go -- can fast-import do this? Or will it just
> > put it in the index and not give you the hash back? The latter was my
> > impression.
>
> It doesn't currently give you the hash back. You can sort of get
> to it by marking the blob then using the 'checkpoint' command to
> dump the marks to a file, which you can read in. Not good.
>
> It probably wouldn't be very difficult to give fast-import a way
> to dump marks back on stdout as they are assigned. So long as the
> frontend either locksteps with fast-import or is willing to monitor
> it with a select/poll type of arrangement and read from stdout as
> soon as its ready.
>
> Probably a 5 line code change to fast-import. Like this. Only Git
> won't recognize that object SHA-1 as its in a packfile that has
> no index. You'd need to 'checkpoint' to flush the object out, or
> just use all of fast-import for the processing. So yea, I guess
> I can see now how its not suited to this.
Shawn, thanks for clearing that up. I was previously considering
fast-import for git-svn, but never had time[1] to really look at it.
I guess Adam is on the right track with his patches.
[1] - Sorry to all on the list, but I've really been slacking on git-svn
work. I was going to get some stuff done this weekend but decided
to attempt to fight my nasty caffeine addiction instead :x
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 9/9] git-svn: Make fetch ~1.7x faster
From: Eric Wong @ 2007-10-24 6:34 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Junio C Hamano
In-Reply-To: <1193118397-4696-10-git-send-email-aroben@apple.com>
Adam Roben <aroben@apple.com> wrote:
> We were spending a lot of time forking/execing git-cat-file and
> git-hash-object. We now use command_bidi_pipe to keep one instance of each
> running and feed it input on stdin.
Nice job! I just got access to a very fast SVN repository for a project
I'm working on (not working on git-svn itself, unfortunately).
A few comments and small nitpicks below:
> Signed-off-by: Adam Roben <aroben@apple.com>
> ---
> git-svn.perl | 94 ++++++++++++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 72 insertions(+), 22 deletions(-)
> +package Git::Commands;
Can this be a separate file, or a part of Git.pm? I'm sure other
scripts can eventually use this and I've been meaning to split
git-svn.perl into separate files so it's easier to follow.
> +use vars qw/$_cat_blob_pid $_cat_blob_in $_cat_blob_out $_cat_blob_ctx $_cat_blob_separator
> + $_hash_object_pid $_hash_object_in $_hash_object_out $_hash_object_ctx/;
I have trouble following long lines, and most of the git code also wraps
at 80-columns. Dead-tree publishers got this concept right a long
time ago :)
> +use strict;
> +use warnings;
> +use File::Temp qw/tempfile/;
> +use Git qw/command_bidi_pipe command_close_bidi_pipe/;
> +
> +sub _open_cat_blob_if_needed {
> + return if defined($_cat_blob_pid);
> + $_cat_blob_separator = "--------------GITCATFILESEPARATOR-----------";
Brian brought this up already, but yes, having pre-defined separators
instead of explicitly-specified sizes makes it all too easy for a
malicious user to commit code that will break things for git-svn users.
> +sub hash_object {
> + my (undef, $fh) = @_;
> +
> + my ($tmp_fh, $tmp_filename) = tempfile(UNLINK => 1);
> + while (my $line = <$fh>) {
> + print $tmp_fh $line;
> + }
> + close($tmp_fh);
Related to the above. It's better to sysread()/syswrite() or
read()/print() in a loop with a predefined buffer size rather than to
use a readline() since you could be dealing with files with very long
lines or binaries with no newline characters in them at all.
> + _open_hash_object_if_needed();
> + print $_hash_object_out $tmp_filename . "\n";
Minor, but
print $_hash_object_out $tmp_filename, "\n";
avoids creating a new string.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 9/9] git-svn: Make fetch ~1.7x faster
From: Adam Roben @ 2007-10-24 6:48 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Junio C Hamano
In-Reply-To: <20071024063401.GB10916@soma>
Eric Wong wrote:
> Adam Roben <aroben@apple.com> wrote:
>
>> +package Git::Commands;
>>
>
> Can this be a separate file, or a part of Git.pm? I'm sure other
> scripts can eventually use this and I've been meaning to split
> git-svn.perl into separate files so it's easier to follow.
>
I had considered doing one of the above, but decided that splitting it
out could be done if/when it was deemed useful for another script. But
I'll split it out since you think it's a good idea.
>> +use vars qw/$_cat_blob_pid $_cat_blob_in $_cat_blob_out $_cat_blob_ctx $_cat_blob_separator
>> + $_hash_object_pid $_hash_object_in $_hash_object_out $_hash_object_ctx/;
>>
>
> I have trouble following long lines, and most of the git code also wraps
> at 80-columns. Dead-tree publishers got this concept right a long
> time ago :)
>
Will fix.
>> +use strict;
>> +use warnings;
>> +use File::Temp qw/tempfile/;
>> +use Git qw/command_bidi_pipe command_close_bidi_pipe/;
>> +
>> +sub _open_cat_blob_if_needed {
>> + return if defined($_cat_blob_pid);
>> + $_cat_blob_separator = "--------------GITCATFILESEPARATOR-----------";
>>
>
> Brian brought this up already, but yes, having pre-defined separators
> instead of explicitly-specified sizes makes it all too easy for a
> malicious user to commit code that will break things for git-svn users.
>
Yup, will fix this. :-)
>> +sub hash_object {
>> + my (undef, $fh) = @_;
>> +
>> + my ($tmp_fh, $tmp_filename) = tempfile(UNLINK => 1);
>> + while (my $line = <$fh>) {
>> + print $tmp_fh $line;
>> + }
>> + close($tmp_fh);
>>
>
> Related to the above. It's better to sysread()/syswrite() or
> read()/print() in a loop with a predefined buffer size rather than to
> use a readline() since you could be dealing with files with very long
> lines or binaries with no newline characters in them at all.
>
Hm, OK. I'll look for similar code in git-svn and follow that.
>> + _open_hash_object_if_needed();
>> + print $_hash_object_out $tmp_filename . "\n";
>>
>
> Minor, but
>
> print $_hash_object_out $tmp_filename, "\n";
>
> avoids creating a new string.
>
Good idea.
Thanks for the feedback! I'll send out some new patches sometime soon.
-Adam
^ permalink raw reply
* Re: intended use of "git --exec-path"?
From: Andreas Ericsson @ 2007-10-24 8:08 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071024043224.GR16291@srparish.net>
Scott Parish wrote:
> "git --exec-path" presently prints out the highest priority path
> to find executable in. That's a what; i'm curious why and when it
> should be used. Basically i'm wondering if its still useful, and
> what, if anything, it should be printing.
>
git supports having all its "helpers" in a separate path. Since
there were performance concerns with having scripts call the git
wrapper for every invocation of every git program, the --exec-path
option was added when the wrapper was rewritten in C.
Unless it's a very tight loop that runs non-builtin programs,
there's really no reason for scripts to use the git-whatever form
of commands, but the ability to do so should probably be retained
more or less forever. See 8e49d50388211a0f3e7286f6ee600bf7736f4814
for details.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Git public repository naming convention (was: Re: users.txt patch)
From: Benoit SIGOURE @ 2007-10-24 8:41 UTC (permalink / raw)
To: Jim Meyering; +Cc: bug-gnulib, git list
In-Reply-To: <87y7dtt0gk.fsf@rho.meyering.net>
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
[CC: Git-ML]
On Oct 24, 2007, at 9:51 AM, Jim Meyering wrote:
> Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>>> On Oct 24, 2007, at 12:28 AM, Paul Eggert wrote:
>>>> Index: gnulib.html
>>>> ===================================================================
>>>> RCS file: /web/gnulib/gnulib/gnulib.html,v
>>>> retrieving revision 1.13
>>>> retrieving revision 1.16
>>>> diff -p -u -r1.13 -r1.16
>>>> --- gnulib.html 22 Oct 2007 21:41:43 -0000 1.13
>>>> +++ gnulib.html 23 Oct 2007 22:22:18 -0000 1.16
>>>> @@ -57,14 +57,20 @@ You can also view the <a href="MODULES.h
>>>> anonymous <a href='http://git.or.cz/'>Git</a>, using the following
>>>> shell command:</p>
>>>>
>>>> -<pre><samp>git clone git://git.savannah.gnu.org/gnulib.git
>>>> +<pre><samp>git clone git://git.savannah.gnu.org/gnulib
>>>> </samp></pre>
>>
>> Is there any reason why this has changed? I learned (the hard way)
>> that for bare public repositories, it's better to stick to what turns
>> out to be more than a naming convention of `project.git'. I don't
>
> What are the consequences of not doing that?
You can't git-clone the remote repo because it tries to fetch the
wrong URL (if the url isn't of the form `foo.git' it will try to
fetch `foo/.git' which will fail).
>> know if these issues are only related to dumb protocols (HTTP*) or if
>> they also affect the Git protocol. I can't find the relevant thread
>
> Hmm... maybe it's http-specific?
> Things seem to work fine with the git protocol.
Yeah, that's what I wondered.
>> on the Git ML but the thing is that it seems that several tools rely
>> on the fact that a repository name of the form `foo.git' implies that
>> it's a bare repository (and thus it doesn't need to look for a
>> nested
>> .git directory).
>
> It has always worked -- on that server, at least.
> I use that form because I prefer the shorter URL:
>
> git clone git://git.sv.gnu.org/gnulib
>
> In general, if you control the server repo,
> you can simply add a symlink in project.git:
>
> .git -> ..
>
> I suppose that avoids any such problems, but I haven't
> done that on any of the savannah repositories.
Yeah well that's more of a workaround than anything else.
My guess: it works with the Git protocol, probably because git-http-
fetch works differently than whatever tool does the fetch for the
native Git protocol. OTOH, isn't it better to have a consistent
naming? If you look at the gitweb of gnulib [ http://
git.savannah.gnu.org/gitweb/?p=gnulib.git ], it says "URL git://
git.sv.gnu.org/gnulib.git". Oddly enough, whether you add the `.git'
or not doesn't seem to change anything.
The documentation (Documentation/urls.txt) only shows examples of the
form `git://host.xz/path/to/repo.git/'. So do Documentation/core-
tutorial.txt, Documentation/git-clone.txt and Documentation/
repository-layout.txt (among others).
Maybe the Git gurus will be able to shed some light on this issue.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Git public repository naming convention
From: Andreas Ericsson @ 2007-10-24 9:03 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Jim Meyering, bug-gnulib, git list
In-Reply-To: <FD3A6F4E-1570-4AF0-ADDC-5680B4E83C7D@lrde.epita.fr>
Benoit SIGOURE wrote:
> [CC: Git-ML]
>
> On Oct 24, 2007, at 9:51 AM, Jim Meyering wrote:
>> Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>>>> On Oct 24, 2007, at 12:28 AM, Paul Eggert wrote:
>>>>> Index: gnulib.html
>>>>> ===================================================================
>>>>> RCS file: /web/gnulib/gnulib/gnulib.html,v
>>>>> retrieving revision 1.13
>>>>> retrieving revision 1.16
>>>>> diff -p -u -r1.13 -r1.16
>>>>> --- gnulib.html 22 Oct 2007 21:41:43 -0000 1.13
>>>>> +++ gnulib.html 23 Oct 2007 22:22:18 -0000 1.16
>>>>> @@ -57,14 +57,20 @@ You can also view the <a href="MODULES.h
>>>>> anonymous <a href='http://git.or.cz/'>Git</a>, using the following
>>>>> shell command:</p>
>>>>>
>>>>> -<pre><samp>git clone git://git.savannah.gnu.org/gnulib.git
>>>>> +<pre><samp>git clone git://git.savannah.gnu.org/gnulib
>>>>> </samp></pre>
>>>
>>> Is there any reason why this has changed? I learned (the hard way)
>>> that for bare public repositories, it's better to stick to what turns
>>> out to be more than a naming convention of `project.git'. I don't
>>
>> What are the consequences of not doing that?
>
> You can't git-clone the remote repo because it tries to fetch the wrong
> URL (if the url isn't of the form `foo.git' it will try to fetch
> `foo/.git' which will fail).
>
>>> know if these issues are only related to dumb protocols (HTTP*) or if
>>> they also affect the Git protocol. I can't find the relevant thread
>>
>> Hmm... maybe it's http-specific?
>> Things seem to work fine with the git protocol.
>
> Yeah, that's what I wondered.
>
>>> on the Git ML but the thing is that it seems that several tools rely
>>> on the fact that a repository name of the form `foo.git' implies that
>>> it's a bare repository (and thus it doesn't need to look for a nested
>>> .git directory).
>>
>> It has always worked -- on that server, at least.
>> I use that form because I prefer the shorter URL:
>>
>> git clone git://git.sv.gnu.org/gnulib
>>
>> In general, if you control the server repo,
>> you can simply add a symlink in project.git:
>>
>> .git -> ..
>>
>> I suppose that avoids any such problems, but I haven't
>> done that on any of the savannah repositories.
>
> Yeah well that's more of a workaround than anything else.
>
> My guess: it works with the Git protocol, probably because
> git-http-fetch works differently than whatever tool does the fetch for
> the native Git protocol. OTOH, isn't it better to have a consistent
> naming? If you look at the gitweb of gnulib [
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git ], it says "URL
> git://git.sv.gnu.org/gnulib.git". Oddly enough, whether you add the
> `.git' or not doesn't seem to change anything.
>
> The documentation (Documentation/urls.txt) only shows examples of the
> form `git://host.xz/path/to/repo.git/'. So do
> Documentation/core-tutorial.txt, Documentation/git-clone.txt and
> Documentation/repository-layout.txt (among others).
>
> Maybe the Git gurus will be able to shed some light on this issue.
>
The dwimmery is handled on the server side and always happens unless
git-upload-pack gets the --strict flag. In git-daemon, this option is
called "--strict-paths".
git clone http://anything means the request doesn't end up in the hands
of git-upload-pack, so the DWIM code in path.c::enter_repo() is never
run.
Letting http-fetch re-implement the same dwimmery, using a trial/error
approach, but saving the correct URL in the remotes config, should
solve this problem, although it will be quite slow on high-latency
networks. Perhaps that doesn't matter, as it should only be an issue
for the original clone.
The suffixes to try are these:
const char *suffix[] = { ".git/.git", "/.git", ".git", "", NULL };
I believe gitweb mimics this behaviour.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-{diff,ls}-files from a subdirectory fails ...
From: Johannes Schindelin @ 2007-10-24 10:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20071024012038.GA31326@diana.vm.bytemark.co.uk>
Hi,
On Wed, 24 Oct 2007, Karl Hasselstr?m wrote:
> ... when GIT_DIR is specified.
>
> I have a repository at ~/stgit-lib. With cwd at the top of the tree,
> things work as expected when I set all those fancy envoronment
> variables:
>
> kha@yoghurt:~/stgit-lib> git-diff-files --name-only
> stgit/utillib.py
>
> kha@yoghurt:~/stgit-lib> GIT_DIR=/home/kha/stgit-lib/.git GIT_INDEX_FILE=/home/kha/stgit-lib/.git/index GIT_WORK_TREE=/home/kha/stgit-lib git-diff-files --name-only
> stgit/utillib.py
>
> However, it doen't seem to work from a subdirectory:
>
> kha@yoghurt:~/stgit-lib/stgit> git-diff-files --name-only
> stgit/utillib.py
>
> kha@yoghurt:~/stgit-lib/stgit> GIT_DIR=/home/kha/stgit-lib/.git GIT_INDEX_FILE=/home/kha/stgit-lib/.git/index GIT_WORK_TREE=/home/kha/stgit-lib git-diff-files --name-only | wc
> 170 170 3560
>From looking at it (very) briefly, it seems that you encountered the same
bug that was fixed in
dd5c8af176bb935a0b01a7dc2d5e022565c3aac3(Fix setup_git_directory_gently()
with relative GIT_DIR & GIT_WORK_TREE).
IOW if you run git version v1.5.3.4-14-gdd5c8af or newer, you should not
experience this.
Hth,
Dscho
^ permalink raw reply
* Re: UI and git-completion.sh
From: Johannes Schindelin @ 2007-10-24 10:20 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071023234617.45a4fc64@paolo-desktop>
Hi,
On Tue, 23 Oct 2007, Paolo Ciarrocchi wrote:
> Using the git-completation script it all boils down to 48 commands.
>
> paolo@paolo-desktop:~/git$ git
> add fetch rebase
> am filter-branch rebase--interactive
> annotate format-patch relink
> apply fsck remote
> archive gc repack
> bisect get-tar-commit-id request-pull
> blame grep reset
> branch gui resolve
> bundle imap-send revert
> checkout init rm
> checkout-index instaweb send-email
> cherry log shortlog
> cherry-pick lost-found show
> citool ls-files show-branch
> clean ls-remote show-ref
> clone ls-tree stash
> commit merge status
> config mergetool submodule
> convert-objects mv tag
> count-objects name-rev var
> describe pickaxe verify-pack
> diff pull whatchanged
> diff-stages push
diff-stages just struck my eye. It is no longer in git... But AFAICS it
is no longer in git-completion.bash either.
Besides, I think that the number of commands could be reduced further.
For example, I think that a regular user does not want to see
checkout-index, citool, convert-objects, filter-branch, get-tar-commit-id,
imap-send, instaweb, lost-found, ls-tree, name-rev, rebase--interactive,
relink, repack, request-pull, show-ref, var, verify-pack and whatchanged.
This list was not vs the quoted list, but my current list (pretty much tip
of Shawn's "next".
Note: I would like to complete the _options_ when one of these subcommands
was specified, but I just do not want to see them when entering
"git<SPACE><TAB>".
BTW Pierre's idea of generating many (if not all) of these completions on
the fly (maybe with "--help-completion"?) is intriguing.
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Karl Hasselström @ 2007-10-24 10:29 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Andreas Ericsson, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <8fe92b430710231906l35606fe2j2b7c28ed6f4dd1a3@mail.gmail.com>
On 2007-10-24 04:06:38 +0200, Jakub Narebski wrote:
> 5. git format-patch to generate patch series; use git-shortlog or
> grepping for patches subjects and git-diff --stat to generate
> introductory email. Unfortunately StGIT template for introductory
> email does have neither shortlog nor diffstat fields to atomatically
> fill.
It does now! (I don't think it's in any released version yet, though.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-{diff,ls}-files from a subdirectory fails ...
From: Karl Hasselström @ 2007-10-24 10:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710241104560.25221@racer.site>
On 2007-10-24 11:06:43 +0100, Johannes Schindelin wrote:
> On Wed, 24 Oct 2007, Karl Hasselström wrote:
>
> > However, it doen't seem to work from a subdirectory:
> >
> > kha@yoghurt:~/stgit-lib/stgit> git-diff-files --name-only
> > stgit/utillib.py
> >
> > kha@yoghurt:~/stgit-lib/stgit> GIT_DIR=/home/kha/stgit-lib/.git GIT_INDEX_FILE=/home/kha/stgit-lib/.git/index GIT_WORK_TREE=/home/kha/stgit-lib git-diff-files --name-only | wc
> > 170 170 3560
>
> From looking at it (very) briefly, it seems that you encountered the
> same bug that was fixed in
>
> dd5c8af176bb935a0b01a7dc2d5e022565c3aac3(Fix setup_git_directory_gently()
> with relative GIT_DIR & GIT_WORK_TREE).
>
> IOW if you run git version v1.5.3.4-14-gdd5c8af or newer, you should
> not experience this.
Thanks for the pointer; that looks like it might indeed fix this bug.
Will hopefully have time to verify later today.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-24 11:04 UTC (permalink / raw)
To: Karl Hasselström
Cc: Johannes Schindelin, Andreas Ericsson, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <20071024102950.GA3908@diana.vm.bytemark.co.uk>
On 10/24/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-24 04:06:38 +0200, Jakub Narebski wrote:
>
>> 5. git format-patch to generate patch series; use git-shortlog or
>> grepping for patches subjects and git-diff --stat to generate
>> introductory email. Unfortunately StGIT template for introductory
>> email does have neither shortlog nor diffstat fields to atomatically
>> fill.
>
> It does now! (I don't think it's in any released version yet, though.)
That is nice to hear.
By the way, there is SRPM for StGIT in
http://homepage.ntlworld.com/cmarinas/stgit/
(I need it because I have Python 2.4), but it is not listed on downloads page...
--
Jakub Narebski
^ permalink raw reply
* git-remote: Use of uninitialized value in string ne, line 248
From: martin f krafft @ 2007-10-24 11:08 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
I am useless at Perl, otherwise I'd fix this, but I don't know
what's going on, so best I can do is report it. This is against
current tip of master.
piper:~> git remote show origin
* remote origin
URL: ssh://git.madduck.net/~/git/etc/mailplate.git
Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tracked remote branches
master
piper:~> git branch
* master
--
martin | http://madduck.net/ | http://two.sentenc.es/
"... and so he killed Miguel in a rit of fealous jage."
-- inspector clouseau
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-{diff,ls}-files from a subdirectory fails ...
From: Karl Hasselström @ 2007-10-24 11:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20071024104055.GB3908@diana.vm.bytemark.co.uk>
On 2007-10-24 12:40:55 +0200, Karl Hasselström wrote:
> On 2007-10-24 11:06:43 +0100, Johannes Schindelin wrote:
>
> > IOW if you run git version v1.5.3.4-14-gdd5c8af or newer, you
> > should not experience this.
>
> Thanks for the pointer; that looks like it might indeed fix this
> bug. Will hopefully have time to verify later today.
It works! Very timely bugfix ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Karl Hasselström @ 2007-10-24 11:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Andreas Ericsson, Steffen Prohaska,
Federico Mena Quintero, git, Catalin Marinas
In-Reply-To: <8fe92b430710240404u202521d4g2275bc4886956807@mail.gmail.com>
On 2007-10-24 13:04:01 +0200, Jakub Narebski wrote:
> By the way, there is SRPM for StGIT in
> http://homepage.ntlworld.com/cmarinas/stgit/ (I need it because I
> have Python 2.4), but it is not listed on downloads page...
I'll leave the webpage question to Catalin, but I'm curious about the
Python version remark. What exactly is the problem?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: Junio C Hamano @ 2007-10-24 11:49 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071024110807.GA12501@piper.oerlikon.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> piper:~> git remote show origin
> * remote origin
> URL: ssh://git.madduck.net/~/git/etc/mailplate.git
> Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Perhaps....
git-remote.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index 9ca3e7e..4cee044 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -244,7 +244,8 @@ sub show_remote {
print "* remote $name\n";
print " URL: $info->{'URL'}\n";
for my $branchname (sort keys %$branch) {
- next if ($branch->{$branchname}{'REMOTE'} ne $name);
+ next if (!$branch->{$branchname}{'REMOTE'} ||
+ $branch->{$branchname}{'REMOTE'} ne $name);
my @merged = map {
s|^refs/heads/||;
$_;
^ permalink raw reply related
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: martin f krafft @ 2007-10-24 11:59 UTC (permalink / raw)
To: Junio C Hamano, git discussion list
In-Reply-To: <7vwstc68bk.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
also sprach Junio C Hamano <gitster@pobox.com> [2007.10.24.1349 +0200]:
> - next if ($branch->{$branchname}{'REMOTE'} ne $name);
> + next if (!$branch->{$branchname}{'REMOTE'} ||
> + $branch->{$branchname}{'REMOTE'} ne $name);
Confirmed: this fixes the issue. Thanks.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"convictions are more dangerous enemies of truth than lies."
- friedrich nietzsche
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-24 12:51 UTC (permalink / raw)
To: git
In-Reply-To: <20071022063222.GS14735@spearce.org>
Thanks to Shawn who was a terrific interim maintainer while I
was away, there are quite a few new topics in 'pu'. The ones in
'next' look safe enough to me, and may graduate to 'master' by
the end of the month. We'll see.
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* cc/skip (Mon Oct 22 07:49:39 2007 +0200) 9 commits
- Bisect: add a "bisect replay" test case.
- Bisect: add "bisect skip" to the documentation.
- Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
- Bisect: refactor some logging into "bisect_write".
- Bisect: refactor "bisect_write_*" functions.
- Bisect: implement "bisect skip" to mark untestable revisions.
- Bisect: fix some white spaces and empty lines breakages.
- rev-list documentation: add "--bisect-all".
- rev-list: implement --bisect-all
Still "just parked" as Shawn described, but three patches were
replaced and as a result the series has a single liner fix since
the last "What's cooking".
* ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit
+ gitweb: Provide title attributes for abbreviated author names.
* lt/rename (Mon Oct 22 10:29:16 2007 -0700) 2 commits
- Linear-time/space rename logic (exact renames only)
- Split out "exact content match" phase of rename detection
The tip commit has been replaced with a new one (actually,
squash of a few commits) since Shawn's announcement and now
t4001 passes.
* js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
- execv_git_cmd(): also try PATH if everything else fails.
I do not quite get why this is needed; need to go back to the
discussion myself. On the other hand, I found the alternative
approach suggested on the list very interesting (i.e. instead of
"also try", just letting exec*p use PATH, relying on the fact
that we do prepend-to-path anyway). What happened to it? Was
there a downside?
* ja/shorthelp (Sun Oct 21 01:41:41 2007 +0300) 1 commit
+ On error, do not list all commands, but point to --help option
Shawn says he likes this, and I tend to agree.
* db/fetch-pack (Sat Oct 20 16:03:49 2007 -0400) 60 commits
+ Define compat version of mkdtemp for systems lacking it
+ Avoid scary errors about tagged trees/blobs during git-fetch
+ fetch: if not fetching from default remote, ignore default merge
+ Support 'push --dry-run' for http transport
+ Support 'push --dry-run' for rsync transport
+ Fix 'push --all branch...' error handling
+ Fix compilation when NO_CURL is defined
+ Added a test for fetching remote tags when there is not tags.
+ Fix a crash in ls-remote when refspec expands into nothing
...
This has been cooking forever in git timescale. Judging from
the type of fixes going in, I can see people are using this in
production and the topic is not terribly broken.
* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 74 commits
+ Use the asyncronous function infrastructure to run the content
filter.
+ Avoid a dup2(2) in apply_filter() - start_command() can do it for
us.
+ t0021-conversion.sh: Test that the clean filter really cleans
content.
+ upload-pack: Run rev-list in an asynchronous function.
+ upload-pack: Move the revision walker into a separate function.
+ Use the asyncronous function infrastructure in builtin-fetch-
pack.c.
+ Add infrastructure to run a function asynchronously.
+ upload-pack: Use start_command() to run pack-objects in
create_pack_file().
+ Have start_command() create a pipe to read the stderr of the
child.
+ Use start_comand() in builtin-fetch-pack.c instead of explicit
fork/exec.
+ Use run_command() to spawn external diff programs instead of
fork/exec.
+ Use start_command() to run content filters instead of explicit
fork/exec.
+ Use start_command() in git_connect() instead of explicit
fork/exec.
+ Change git_connect() to return a struct child_process instead of a
pid_t.
Gave a cursory look at a few of the patches but they all looked
fine.
* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit
- Better support AFS hardlinking across object directories
I share Shawn's concern of breaking the "never replace existing
object" security. Will probably drop this patch in the current
shape.
* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits
- park
- git-fetch: mega-terse fetch output
Haven't caught up with the output format discussion. Hopefully
somebody will implement the list concensus and resend a
replacement patch, at which time I can drop these two before
looking at these two patches ;-).
* np/progress (Fri Oct 19 01:01:40 2007 -0400) 9 commits
+ Stop displaying "Pack pack-$ID created." during git-gc
+ Teach prune-packed to use the standard progress meter
+ Change 'Deltifying objects' to 'Compressing objects'
+ fix for more minor memory leaks
+ fix const issues with some functions
+ pack-objects.c: fix some global variable abuse and memory leaks
+ pack-objects: no delta possible with only one object in the list
+ cope with multiple line breaks within sideband progress messages
+ more compact progress display
"Compressing objects" caught my eye, but it all makes sense.
* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits
+ mergetool: avoid misleading message "Resetting to default..."
+ mergetool: add support for ECMerge
+ mergetool: use path to mergetool in config var
mergetool.<tool>.path
* jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
+ t5516: test update of local refs on push
+ send-pack: don't update tracking refs on error
* js/rebase (Wed Oct 17 10:31:35 2007 +0100) 1 commit
+ Fixing path quoting in git-rebase
I have a feeling that this should have forked off of 'maint'.
The change looks obvious and trivial, so perhaps after getting a
testcase (hint, hint) merge to 'master' and then cherry-pick to
'maint' as well.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
Obviously this was meant for git-stash, but I am not sure if
allowing to drop reflog entries in the middle is a good idea in
general. If we are going to change the UI and the end-user view
for stash _anyway_, we may be better off reimplementing stash as
separate, numbered and/or named refs (e.g. refs/stash/stash-$n).
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
As I already said earlier, I do not think unstashing always on
top of rebased state is the right thing to do anyway, we would
want to change the behaviour of the tip one, but the question is
how.
* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit
- Add color support to git-add--interactive
* jc/revert-merge (Tue Oct 23 13:33:26 2007 -0700) 1 commit
- revert/cherry-pick: work on merge commits as well
Allowing to revert/cherry-pick a merge commit. I got my first
exposure to the new option parser because I had to adjust to the
new "--mainline" option. The option is supposed to take positive
integer as a value but I left it as a generic OPT_INTEGER for
now and as a result you may get funny error messages if you give
nonsense input.
* ph/parseopt (Mon Oct 15 23:06:02 2007 +0200) 22 commits
- Make builtin-pack-refs.c use parse_options.
- Make builtin-name-rev.c use parse_options.
- Make builtin-count-objects.c use parse_options.
- Make builtin-fsck.c use parse_options.
- Update manpages to reflect new short and long option aliases
- Make builtin-for-each-ref.c use parse-opts.
- Make builtin-symbolic-ref.c use parse_options.
- Make builtin-update-ref.c use parse_options
- Make builtin-revert.c use parse_options.
- Make builtin-describe.c use parse_options
- Make builtin-branch.c use parse_options.
- Make builtin-mv.c use parse-options
- Make builtin-rm.c use parse_options.
- Port builtin-add.c to use the new option parser.
- parse-options: allow callbacks to take no arguments at all.
- parse-options: Allow abbreviated options when unambiguous
- Add shortcuts for very often used options.
- parse-options: make some arguments optional, add callbacks.
- Rework make_usage to print the usage message immediately
- Add tests for parse-options.c
- parse-options: be able to generate usages automatically
- Add a simple option parser.
* sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits
- push, send-pack: use same rules as git-rev-parse to resolve
refspecs
- add ref_cmp_full_short() comparing full ref name with a short name
- push, send-pack: support pushing HEAD to real ref name
- rev-parse: teach "git rev-parse --symbolic" to print the full ref
name
- add get_sha1_with_real_ref() returning full name of ref on demand
- push, send-pack: fix test if remote branch exists for colon-less
refspec
* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
+ Export rerere() and launch_editor().
+ Introduce entry point add_interactive and add_files_to_cache
+ Enable wt-status to run against non-standard index file.
+ Enable wt-status output to a given FILE pointer.
* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
- git-diff: complain about >=8 consecutive spaces in initial indent
* jc/nu (Mon Oct 1 19:35:12 2007 -0700) 2 commits
- PARK a bit more work
- (PARK) WIP
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
^ permalink raw reply
* Re: [PATCH 2/2] Quoting paths in tests
From: Jonathan del Strother @ 2007-10-24 13:07 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <4716F849.3090102@viscovery.net>
On 18 Oct 2007, at 07:08, Johannes Sixt wrote:
> Jonathan del Strother schrieb:
>> On 17 Oct 2007, at 12:32, Johannes Sixt wrote:
>>> Jonathan del Strother schrieb:
>>>> --- a/t/lib-git-svn.sh
>>>> +++ b/t/lib-git-svn.sh
>>>> @@ -25,7 +25,7 @@ perl -w -e "
>>>> use SVN::Core;
>>>> use SVN::Repos;
>>>> \$SVN::Core::VERSION gt '1.1.0' or exit(42);
>>>> -system(qw/svnadmin create --fs-type fsfs/, '$svnrepo') == 0 or
>>>> exit(41);
>>>> +system(qw/svnadmin create --fs-type fsfs/, \"$svnrepo\") == 0 or
>>>> exit(41);
>>>
>>> Here you have to work harder: The reason is that this is part of a
>>> perl expression (as opposed to an eval'd string), which does not
>>> have access to $svnrepo of the shell by which it is invoked. The
>>> original version failed if there were single-quotes in $svnrepo,
>>> the new version fails if it contains double-quotes.
>
> You can rewrite this expression as
> perl -w -e '$svnrepo = shift;
> ...
> $SVN::Core::Version gt "1.1.0" ...
> system(qw/svnadmin create --fs-type fsfs/, $svnrepo) == 0 ...
> ...
> ' >&3 2>&4 "$svnrepo"
>
> i.e. you pass the repository name as an argument to the scriptlet.
>
>>> May I recommend that you run the test suite in a directory named
>>> like this:
>>>
>>> $ mkdir \"\ \$GIT_DIR\ \'
>>> $ ls
>>> " $GIT_DIR '
>> Eww. I'm struggling a bit with paths this perverse, actually.
>> For instance, git_editor in git-sh-setup expects the editor path to
>> be pre-quoted. So in t3404, you need to produce escaped double
>> quotes & dollar signs, resulting in unpleasantness like this :
>> VISUAL="`pwd`/fake-editor.sh"
>> VISUAL=${VISUAL//\"/\\\"}
>> VISUAL=${VISUAL//$/\\\$}
>
> This is a bashism - that's a big no-no.
>
>> VISUAL=\"$VISUAL\"
>> export VISUAL
>> And I'm struggling to come up with neat ways of rewriting things
>> like, eg, this bit from t5500 -
>> test_expect_success "clone shallow" "git-clone --depth 2 \"file://
>> `pwd`/.\" shallow"
>> - to handle paths like that properly.
>
> These examples expand `pwd` too early. Can't you just put everything
> inside single-quotes? Although I'm not sure about VISUAL: Is it
> invoked with $PWD that is different from $PWD when VISUAL is
> defined? If so, then you can hardly delay `pwd`...
>
> I know I'm a bit anal with my criticism. I reviewed your patch
> because I think fixing for paths with whitespace is worthwhile.
> However, I also think any fix should go the full way and not only
> shift the problems into a different corner. Maybe a word from
> $maintainer would be in order ;)
In theory, I agree that the tests should properly handle perverse
paths, but it's beginning to stretch my shell scripting skills.
So now our esteemed leader is back in business, any thoughts on how
hard we want to work to quote things?
Also, from "What's cooking in git.git" :
> I have a feeling that this should have forked off of 'maint'.
> The change looks obvious and trivial, so perhaps after getting a
> testcase (hint, hint) merge to 'master' and then cherry-pick to
> 'maint' as well.
Noted
Jon del Strother
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Symonds @ 2007-10-24 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzly84qwf.fsf@gitster.siamese.dyndns.org>
On 10/24/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> * ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit
> + gitweb: Provide title attributes for abbreviated author names.
I was hoping you could include my other two related patches on top of
that one, since they clean it up somewhat.
Dave.
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Catalin Marinas @ 2007-10-24 13:15 UTC (permalink / raw)
To: Jakub Narebski
Cc: Karl Hasselström, Johannes Schindelin, Andreas Ericsson,
Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <8fe92b430710240404u202521d4g2275bc4886956807@mail.gmail.com>
On Wed, 2007-10-24 at 13:04 +0200, Jakub Narebski wrote:
> On 10/24/07, Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-10-24 04:06:38 +0200, Jakub Narebski wrote:
> >
> >> 5. git format-patch to generate patch series; use git-shortlog or
> >> grepping for patches subjects and git-diff --stat to generate
> >> introductory email. Unfortunately StGIT template for introductory
> >> email does have neither shortlog nor diffstat fields to atomatically
> >> fill.
> >
> > It does now! (I don't think it's in any released version yet, though.)
>
> That is nice to hear.
>
> By the way, there is SRPM for StGIT in
> http://homepage.ntlworld.com/cmarinas/stgit/
> (I need it because I have Python 2.4), but it is not listed on downloads page...
I never thought anyone would need it. I find the .tar.gz better.
BTW, what is the problem with Python 2.4? Was the RPM built for a
different version? The upcoming 0.14 release will be based on Python 2.5
but we keep the compatibility with 2.4 (we dropped 2.3).
--
Catalin
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Jing Xue @ 2007-10-24 13:44 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Jan Wielemaker, Petr Baudis, git
In-Reply-To: <256C87B5-3ADE-4A96-9530-A45B97601BAA@spinlock.ch>
On Tue, Oct 23, 2007 at 10:28:46PM +0200, Matthias Kestenholz wrote:
> Hi,
Hi,
> If someone tracks the main branch you are working on and fetches
> while you are travelling home, he has the WIP commit as a new tip
> in his tree.
> If he bases further work upon the WIP commit, he'll need to rebase
> or merge his changes onto your new tip once you have amended or
> replaced the commit. If you are working on the
> master branch, you should really avoid rewinding it. Rewinding topic
> branches is ok, but a temporary branch is still better to clearly tell
> potential fetch-ers that this is only Work in Progress, and not meant
> to be published in the current state.
Good point. Although I guess if some workflow lets you directly hack on a
public branch, it can have lots of other issues beyond just the WIP
being pulled accidentally, no?
Cheers.
--
Jing Xue
^ 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