* Re: [PATCH] t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
From: Brian Gernhardt @ 2007-11-11 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Björn Steinbrink, aroben, dak, git
In-Reply-To: <Pine.LNX.4.64.0711111742010.4362@racer.site>
On Nov 11, 2007, at 12:44 PM, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Björn Steinbrink wrote:
>
>> The git wrapper executable always prepends the GIT_EXEC_PATH build
>> variable to the current PATH, so prepending "." to the PATH is not
>> enough to give precedence to the fake vi executable.
>>
>> The --exec-path option allows to prepend a directory to PATH even
>> before
>> GIT_EXEC_PATH (which is added anyway), so we can use that instead.
>
> Hmm. This will probably stop working when you do not have git
> installed,
> because you now tell git to search for git programs in ".", where
> they are
> not. Probably git-commit executes your installed write-tree, commit-
> tree
> and friends, instead of the compiled ones.
You are wrong there. From exec_cmd.c:setup_path() (lines 51-54):
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
add_path(&new_path, builtin_exec_path);
add_path(&new_path, cmd_path);
So the path with this patch will still include the build directory
before the install location.
~~ Brian
^ permalink raw reply
* Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 17:54 UTC (permalink / raw)
To: Git Mailing List
What am I doing wrong in this sequence?
In my local repo I have two remotes:
jonsmirl@terra:~/mpc5200b$ git remote
dreamhost
linus
I create branches off from these using:
git branch -b m29 linus/master
I update them with
stg rebase linus/master
My repo has a .git/packed-refs file
When I push this repo to a remote server my local branches get renamed.
jonsmirl@terra:~/mpc5200b$ git push dreamhost
To ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
* [new branch] m24 -> linus/m24
* [new branch] m25 -> linus/m25
* [new branch] m26 -> linus/m26
* [new branch] m28 -> linus/m28
* [new branch] m29 -> linus/m29
Counting objects: 619084, done.
...
So one the remote server I see this:
[daedalus]$ git remote
[daedalus]$ git branch
[daedalus]$ git branch -r
linus/m24
linus/m25
linus/m26
linus/m28
linus/m29
[daedalus]$
With the repo in this state at the remote server gitweb thinks the
repo is empty.
Why are these branches getting renamed?
git head is in use on both ends.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
From: Björn Steinbrink @ 2007-11-11 18:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: benji, aroben, dak, git
In-Reply-To: <Pine.LNX.4.64.0711111742010.4362@racer.site>
On 2007.11.11 17:44:14 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Björn Steinbrink wrote:
>
> > The git wrapper executable always prepends the GIT_EXEC_PATH build
> > variable to the current PATH, so prepending "." to the PATH is not
> > enough to give precedence to the fake vi executable.
> >
> > The --exec-path option allows to prepend a directory to PATH even before
> > GIT_EXEC_PATH (which is added anyway), so we can use that instead.
>
> Hmm. This will probably stop working when you do not have git installed,
> because you now tell git to search for git programs in ".", where they are
> not. Probably git-commit executes your installed write-tree, commit-tree
> and friends, instead of the compiled ones.
The . is prepended to PATH in _addition_ to the usual paths (as I wrote,
see setup_path() in exec_cmd.c). It does not replace anything AFAICT.
$ echo $PATH
/home/doener/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
$ GIT_EXEC_PATH=.. GIT_EDITOR="env;" ../git commit | grep ^PATH=
PATH=/home/doener/src/git:/home/doener/bin:/home/doener/src/git:/home/doener/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
$ GIT_EXEC_PATH=.. GIT_EDITOR="env;" ../git --exec-path=. commit | grep
^PATH=
PATH=/home/doener/src/git/t:/home/doener/src/git:/home/doener/bin:/home/doener/src/git:/home/doener/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
Looks good to me...
Björn
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 18:02 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9e4733910711110954m3ed3f9adtf19ca15dff61f0@mail.gmail.com>
Is the remote config not correct?
[remote "dreamhost"]
url = ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
fetch = +refs/heads/*:refs/remotes/dreamhost/*
push = +refs/heads/*:refs/remotes/linus/*
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Steffen Prohaska @ 2007-11-11 18:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711111002x2f8cabf7yce263faf7b33bde1@mail.gmail.com>
On Nov 11, 2007, at 7:02 PM, Jon Smirl wrote:
> Is the remote config not correct?
This is the configuration for remote "dreamhost". In your
previous mail you also mentioned a remote "linus". But
this seems to be unrelated to your question.
> [remote "dreamhost"]
> url = ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
> fetch = +refs/heads/*:refs/remotes/dreamhost/*
correct. This fetches the branches from the remote and stores
them locally as remote tracking branches "dreamhost/<branch>".
> push = +refs/heads/*:refs/remotes/linus/*
This "renames" your branches when you push. Your local branches
get pushed to "dreamhost" and are stored there as remote branches
"linus/<branch>". From your previous mail I assume you like to store
them as normal branches. You'd need to say
push = +refs/heads/*:refs/heads/*
But most likely you don't want to force here, that is drop '+'.
And you don't need to explicitly say that you want to store a branch
under the same name. So, probably you want
push = refs/heads/*
But maybe you could even drop the push line completely. Then, only
existing branches would be pushed and if you want to create a new
remote branch on "dreamhost" you'd need to explicitly tell git with
git push dreamhost <new-branch>
Does this help?
Steffen
^ permalink raw reply
* Re: [PATCH] t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
From: Johannes Schindelin @ 2007-11-11 18:31 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Bj?rn Steinbrink, aroben, git
In-Reply-To: <2AE2E502-7942-449E-B847-75876A5DAF37@silverinsanity.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 648 bytes --]
Hi Brian, hi Björn,
On Sun, 11 Nov 2007, Brian Gernhardt wrote:
> On Nov 11, 2007, at 12:44 PM, Johannes Schindelin wrote:
>
> > Probably git-commit executes your installed write-tree, commit-tree
> > and friends, instead of the compiled ones.
>
> You are wrong there. From exec_cmd.c:setup_path() (lines 51-54):
>
> add_path(&new_path, argv_exec_path);
> add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
> add_path(&new_path, builtin_exec_path);
> add_path(&new_path, cmd_path);
Ah, I forgot that --exec-path=<path> did not override GIT_EXEC_PATH.
Thanks for clarifying! Your patch is obviously good, then.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-svn: prevent dcommitting if the index is dirty.
From: Benoit Sigoure @ 2007-11-11 18:41 UTC (permalink / raw)
To: git; +Cc: normalperson, Benoit Sigoure
dcommit uses rebase `sync' the history with what has just been pushed to
SVN. Trying to dcommit with a dirty index is troublesome for rebase, so now
the user will get an error message if he attempts to dcommit with a dirty
index.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
git-svn.perl | 3 +++
t/t9106-git-svn-dcommit-clobber-series.sh | 6 ++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index dd93e32..a15df4f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -390,6 +390,9 @@ sub cmd_set_tree {
sub cmd_dcommit {
my $head = shift;
+ git_cmd_try { command_oneline(qw/diff-index --quiet HEAD/) }
+ 'Cannot dcommit with a dirty index. Commit your changes first'
+ . "or stash them with `git stash'.\n";
$head ||= 'HEAD';
my @refs;
my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
diff --git a/t/t9106-git-svn-dcommit-clobber-series.sh b/t/t9106-git-svn-dcommit-clobber-series.sh
index 7eff4cd..44fae3b 100755
--- a/t/t9106-git-svn-dcommit-clobber-series.sh
+++ b/t/t9106-git-svn-dcommit-clobber-series.sh
@@ -53,4 +53,10 @@ test_expect_success 'change file but in unrelated area' "
test x\"\`sed -n -e 61p < file\`\" = x6611
"
+test_expect_failure 'attempt to dcommit with a dirty index' "
+ echo foo >>file &&
+ git add file &&
+ git svn dcommit
+ "
+
test_done
--
1.5.3.5.654.gdd5ec
^ permalink raw reply related
* Re: [PATCH] for-each-ref: fix setup of option-parsing for --sort
From: Johannes Schindelin @ 2007-11-11 19:19 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Jakub Narebski, Jon Smirl, git
In-Reply-To: <1194713274-31200-1-git-send-email-hjemli@gmail.com>
Hi,
On Sat, 10 Nov 2007, Lars Hjemli wrote:
> The option value for --sort is already a pointer to a pointer to struct
> ref_sort, so just use it.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> On Nov 10, 2007 5:25 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Could you add a test for that too, please?
>
> Is this ok?
That's exactly what I had in mind.
Thank you,
Dscho
^ permalink raw reply
* Re: git-branch silently ignores --track on local branches
From: Johannes Schindelin @ 2007-11-11 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wayne Davison, git
In-Reply-To: <7vfxzelz5b.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 10 Nov 2007, Junio C Hamano wrote:
> Wayne Davison <wayne@opencoder.net> writes:
>
> > ... Is there
> > a problem with local branches being supported when explicitly
> > requested?
>
> Maybe this one?
>
> commit 6f084a56fcb3543d88d252bb49c1d2bbf2bd0cf3
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Tue Jul 10 18:50:44 2007 +0100
>
> branch --track: code cleanup and saner handling of local branches
>
> This patch cleans up some complicated code, and replaces it with a
> cleaner version, using code from remote.[ch], which got extended a
> little in the process. This also enables us to fix two cases:
>
> The earlier "fix" to setup tracking only when the original ref started
> with "refs/remotes" is wrong. You are absolutely allowed to use a
> separate layout for your tracking branches. The correct fix, of course,
> is to set up tracking information only when there is a matching
> remote.<nick>.fetch line containing a colon.
>
> Another corner case was not handled properly. If two remotes write to
> the original ref, just warn the user and do not set up tracking.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> As a local branch does not have to be "fetched", the restriction
> on "remote.<nick>.fetch" is sort of pointless.
IIRC it was you, Junio, who complained first that the local branches have
tracking set up.
> Also why remote.<nick>.fetch needs a colon, I begin to wonder. You can
> be keep fetching and merging from the same branch of the same remote
> without keeping a remote tracking branch for that, but the above
> "correct fix" forbids that.
The point here was to find out what to track when we do a "git branch
--track <name> <origname>". So we definitely only want to find those
remotes that fetch to a certain tracking branch.
Sure, you can set up branch.<x>.merge to a branch that is not tracked.
But git cannot find out which one it is in the command "branch".
> Dscho, what were we smoking when we made this change?
Dude, I, uh, I think I, uh, don't remember. Peace.
Ciao,
Dscho
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 19:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <A1B9CE91-15E0-4298-A606-68BB31541574@zib.de>
On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Nov 11, 2007, at 7:02 PM, Jon Smirl wrote:
>
> > Is the remote config not correct?
>
> This is the configuration for remote "dreamhost". In your
> previous mail you also mentioned a remote "linus". But
> this seems to be unrelated to your question.
>
>
> > [remote "dreamhost"]
> > url = ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
> > fetch = +refs/heads/*:refs/remotes/dreamhost/*
>
> correct. This fetches the branches from the remote and stores
> them locally as remote tracking branches "dreamhost/<branch>".
>
> > push = +refs/heads/*:refs/remotes/linus/*
>
> This "renames" your branches when you push. Your local branches
> get pushed to "dreamhost" and are stored there as remote branches
> "linus/<branch>". From your previous mail I assume you like to store
> them as normal branches. You'd need to say
I did this part incorrectly. I was trying to push my local definition
of the linus remote to the dreamhost repo so that when someone clones
dreamhost linus would be defined in their repo.
jonsmirl@terra:~/mpc5200b$ git remote show linus
* remote linus
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
How do I push the definition of the linus remote repo?
>
> push = +refs/heads/*:refs/heads/*
>
> But most likely you don't want to force here, that is drop '+'.
> And you don't need to explicitly say that you want to store a branch
> under the same name. So, probably you want
>
> push = refs/heads/*
>
> But maybe you could even drop the push line completely. Then, only
> existing branches would be pushed and if you want to create a new
> remote branch on "dreamhost" you'd need to explicitly tell git with
>
> git push dreamhost <new-branch>
>
> Does this help?
>
> Steffen
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/6] push: mention --verbose option in documentation
From: Junio C Hamano @ 2007-11-11 19:39 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <FAB11CE3-B834-45A9-9D29-A37C302A9E1D@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> The Author line was already wrong in Junio's pu branch, commit
> f31447f5f06200305393ca16e2eb9485e65dcccc, and I carried this
> over without noticing.
Yes, I know I pushed out a faulty one on 'pu' in the past. I am
suspecting that it probably was a misuse of "git commit --author"
after _not_ applying a WS mangled patch and instead of typing,
or something like that.
^ permalink raw reply
* Re: [PATCH 5/6] builtin-commit: resurrect behavior for multiple -m options
From: Pierre Habouzit @ 2007-11-11 19:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711111736310.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
On Sun, Nov 11, 2007 at 05:36:39PM +0000, Johannes Schindelin wrote:
>
> When more than one -m option is given, the message does not replace
> the previous, but is appended.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> builtin-commit.c | 26 ++++++++++++++++++++------
> 1 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 66d7e5e..069d180 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -30,13 +30,27 @@ static char *use_message_buffer;
> static const char commit_editmsg[] = "COMMIT_EDITMSG";
> static struct lock_file lock_file;
>
> -static char *logfile, *force_author, *message, *template_file;
> +static char *logfile, *force_author, *template_file;
> static char *edit_message, *use_message;
> static int all, edit_flag, also, interactive, only, amend, signoff;
> static int quiet, verbose, untracked_files, no_verify;
>
> static int no_edit, initial_commit, in_merge;
> const char *only_include_assumed;
> +struct strbuf message;
Unless I'm mistaken `static` keywords are missign for`message` and
`only_include_assumed`.
And you _have_ to initialize message with STRBUF_INIT (remember of the
slop).
> +static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> +{
> + struct strbuf *buf = opt->value;
> + if (unset)
> + strbuf_setlen(buf, 0);
> + else {
> + strbuf_addstr(buf, arg);
> + strbuf_addch(buf, '\n');
> + strbuf_addch(buf, '\n');
> + }
> + return 0;
> +}
I believe such a callback could live in parse-options.[hc]. The need
to aggregate all string arguments into a strbuf looks generic enough to
me. Why are you adding two '\n' btw ? Isn't one enough ?
Oh and last nitpicking, strbuf_addstr(buf, "\n\n"); is more efficient
than the two addchar (the strlen it generates is inlined).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: t7005 and vi in GIT_EXEC_PATH
From: Junio C Hamano @ 2007-11-11 19:43 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <FCFF59B3-D3F1-4BEB-B3C3-D07DD5D5D8EF@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> I'm sorry, I should have been more clear. I was referring to the
> GIT_EXEC_PATH build variable, not the environment variable. The git
> wrapper always adds the path determined during build to the front of
> PATH. When I was changing my build script, this got set to "/usr/
> local/bin" (I usually use /usr/local/stow/git, instead). Since I have
> a /usr/local/bin/vim, PATH for git-commit.sh during the test was:
>
> - my git build directory
> - /usr/local/bin (containing a symlink vi -> vim)
> - the t/trash directory, added by the test via `PATH=".:$PATH"`
> (containing the test vi script)
> - my normal path
Maybe that is what is broken. t/test-lib.sh makes the
environment variable point at the build directory, and that
should override the path that is compiled in, shouldn't it?
^ permalink raw reply
* [StGit PATCH 0/5] A few small fixes
From: Karl Hasselström @ 2007-11-11 19:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
These are available from
git://repo.or.cz/stgit/kha.git safe
The clean test and the assimilare/repair stuff are new, the rest have
been sitting in kha/safe for a while now.
David: I believe the repair patch should fix the situation you
encountered.
---
Note how the actual patch that renames assimilate to repair looks fine
-- I gave stg mail --diff-opts='-M -C -C'. But the diffstats
apparently don't get those flags, neither the aggregate one below nor
the one just for that patch. We ought to fix that ...
Karl Hasselström (5):
stg repair: Patchify non-patch commits between patches
Rename "stg assimilate" to "stg repair"
Let some commands work with detached HEAD
Cogito is deprecated, so don't point to it
Simple test for "stg clean"
Documentation/stg.txt | 4 -
README | 4 -
contrib/stgit-completion.bash | 2
stgit/commands/add.py | 2
stgit/commands/assimilate.py | 198 -----------------------------------------
stgit/commands/common.py | 2
stgit/commands/repair.py | 192 ++++++++++++++++++++++++++++++++++++++++
stgit/commands/resolved.py | 2
stgit/commands/status.py | 2
stgit/main.py | 4 -
t/t1301-assimilate.sh | 84 -----------------
t/t1301-repair.sh | 80 +++++++++++++++++
t/t1302-assimilate-interop.sh | 59 ------------
t/t1302-repair-interop.sh | 59 ++++++++++++
t/t2500-clean.sh | 27 ++++++
15 files changed, 368 insertions(+), 353 deletions(-)
delete mode 100644 stgit/commands/assimilate.py
create mode 100644 stgit/commands/repair.py
delete mode 100755 t/t1301-assimilate.sh
create mode 100755 t/t1301-repair.sh
delete mode 100755 t/t1302-assimilate-interop.sh
create mode 100755 t/t1302-repair-interop.sh
create mode 100755 t/t2500-clean.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 1/5] Simple test for "stg clean"
From: Karl Hasselström @ 2007-11-11 19:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t2500-clean.sh | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100755 t/t2500-clean.sh
diff --git a/t/t2500-clean.sh b/t/t2500-clean.sh
new file mode 100755
index 0000000..3364c18
--- /dev/null
+++ b/t/t2500-clean.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+test_description='Run "stg clean"'
+
+. ./test-lib.sh
+
+test_expect_success 'Initialize StGit stack' '
+ stg init &&
+ stg new e0 -m e0 &&
+ stg new p0 -m p0 &&
+ echo foo > foo.txt &&
+ git add foo.txt &&
+ stg refresh &&
+ stg new e1 -m e1 &&
+ stg new e2 -m e2 &&
+ stg pop
+'
+
+test_expect_success 'Clean empty patches' '
+ [ "$(echo $(stg applied))" = "e0 p0 e1" ] &&
+ [ "$(echo $(stg unapplied))" = "e2" ] &&
+ stg clean &&
+ [ "$(echo $(stg applied))" = "p0" ] &&
+ [ "$(echo $(stg unapplied))" = "" ]
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 2/5] Cogito is deprecated, so don't point to it
From: Karl Hasselström @ 2007-11-11 19:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
README | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 0e648f5..4f20154 100644
--- a/README
+++ b/README
@@ -6,9 +6,7 @@ other repositories using standard GIT functionality.
Note that StGIT is not an SCM interface on top of GIT and it expects a
previously initialised GIT repository (unless it is cloned using StGIT
-directly). For standard SCM operations, either use plain GIT commands
-or the Cogito tool but it is not recommended to mix them with the
-StGIT commands.
+directly). For standard SCM operations, use plain GIT commands.
For the latest version see http://www.procode.org/stgit/
For a tutorial see http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial
^ permalink raw reply related
* [StGit PATCH 4/5] Rename "stg assimilate" to "stg repair"
From: Karl Hasselström @ 2007-11-11 19:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
With the capabilities it's gained lately, this is a better name.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/stg.txt | 4 -
contrib/stgit-completion.bash | 2
stgit/commands/assimilate.py | 198 -----------------------------------------
stgit/commands/common.py | 2
stgit/commands/repair.py | 197 +++++++++++++++++++++++++++++++++++++++++
stgit/main.py | 4 -
t/t1301-assimilate.sh | 84 -----------------
t/t1301-repair.sh | 80 +++++++++++++++++
t/t1302-assimilate-interop.sh | 59 ------------
t/t1302-repair-interop.sh | 59 ++++++++++++
10 files changed, 342 insertions(+), 347 deletions(-)
delete mode 100644 stgit/commands/assimilate.py
create mode 100644 stgit/commands/repair.py
delete mode 100755 t/t1301-assimilate.sh
create mode 100755 t/t1301-repair.sh
delete mode 100755 t/t1302-assimilate-interop.sh
create mode 100755 t/t1302-repair-interop.sh
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index 4f9d18e..f6cd815 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -146,8 +146,8 @@ stglink:commit[]::
stgdesc:commit[]
stglink:uncommit[]::
stgdesc:uncommit[]
-stglink:assimilate[]::
- stgdesc:assimilate[]
+stglink:repair[]::
+ stgdesc:repair[]
Controlling what patches are applied
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
index b1d2730..b3b23d4 100644
--- a/contrib/stgit-completion.bash
+++ b/contrib/stgit-completion.bash
@@ -13,7 +13,6 @@
_stg_commands="
add
applied
- assimilate
branch
delete
diff
@@ -42,6 +41,7 @@ _stg_commands="
rebase
refresh
rename
+ repair
resolved
rm
series
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 2a80e8c..2672dcf 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -114,7 +114,7 @@ def check_head_top_equal(crt_series):
if not crt_series.head_top_equal():
raise CmdException(
"""HEAD and top are not the same. This can happen if you
- modify a branch with git. The "assimilate" command can
+ modify a branch with git. The "repair" command can
fix this situation.""")
def check_conflicts():
diff --git a/stgit/commands/assimilate.py b/stgit/commands/repair.py
similarity index 90%
rename from stgit/commands/assimilate.py
rename to stgit/commands/repair.py
index be992aa..f8fe624 100644
--- a/stgit/commands/assimilate.py
+++ b/stgit/commands/repair.py
@@ -29,28 +29,28 @@ from stgit import stack, git
help = 'StGit-ify any git commits made on top of your StGit stack'
usage = """%prog [options]
-"assimilate" will repair three kinds of inconsistencies in your StGit
+"repair" will repair three kinds of inconsistencies in your StGit
stack, all of them caused by using plain git commands on the branch:
1. If you have made regular git commits on top of your stack of
- StGit patches, "assimilate" converts them to StGit patches,
+ StGit patches, "repair" converts them to StGit patches,
preserving their contents.
2. Merge commits cannot become patches; if you have committed a
- merge on top of your stack, "assimilate" will simply mark all
+ merge on top of your stack, "repair" will simply mark all
patches below the merge unapplied, since they are no longer
reachable. If this is not what you want, use "git reset" to get
- rid of the merge and run "assimilate" again.
+ rid of the merge and run "repair" again.
3. The applied patches are supposed to be precisely those that are
reachable from the branch head. If you have used e.g. "git reset"
to move the head, some applied patches may no longer be
reachable, and some unapplied patches may have become reachable.
- "assimilate" will correct the appliedness of such patches.
+ "repair" will correct the appliedness of such patches.
Note that these are "inconsistencies", not "errors"; furthermore,
-"assimilate" will repair them reliably. As long as you are satisfied
-with the way "assimilate" handles them, you have no reason to avoid
+"repair" will repair them reliably. As long as you are satisfied
+with the way "repair" handles them, you have no reason to avoid
causing them in the first place if that is convenient for you."""
directory = DirectoryGotoToplevel()
@@ -99,11 +99,10 @@ def read_commit_dag(branch):
return commits, patches
def func(parser, options, args):
- """Assimilate a number of patches.
- """
+ """Repair inconsistencies in StGit metadata."""
def nothing_to_do():
- out.info('No commits to assimilate')
+ out.info('Nothing to repair')
orig_applied = crt_series.get_applied()
orig_unapplied = crt_series.get_unapplied()
@@ -118,7 +117,7 @@ def func(parser, options, args):
raise CmdException(
'This branch is protected. Modification is not permitted.')
- # Find commits to assimilate, and applied patches.
+ # Find commits that aren't patches, and applied patches.
commits, patches = read_commit_dag(crt_series.get_name())
c = commits[head]
patchify = []
@@ -149,7 +148,7 @@ def func(parser, options, args):
% (len(hidden), ['es', ''][len(hidden) == 1])),
'%s,' % merge.id, 'and will be considered unapplied.')
- # Assimilate any linear sequence of commits on top of a patch.
+ # Make patches of any linear sequence of commits on top of a patch.
names = set(p.patch for p in patches)
def name_taken(name):
return name in names
diff --git a/stgit/main.py b/stgit/main.py
index e8242c2..a03447f 100644
--- a/stgit/main.py
+++ b/stgit/main.py
@@ -60,7 +60,6 @@ class Commands(dict):
commands = Commands({
'add': 'add',
'applied': 'applied',
- 'assimilate': 'assimilate',
'branch': 'branch',
'delete': 'delete',
'diff': 'diff',
@@ -89,6 +88,7 @@ commands = Commands({
'rebase': 'rebase',
'refresh': 'refresh',
'rename': 'rename',
+ 'repair': 'repair',
'resolved': 'resolved',
'rm': 'rm',
'series': 'series',
@@ -109,7 +109,6 @@ repocommands = (
)
stackcommands = (
'applied',
- 'assimilate',
'branch',
'clean',
'commit',
@@ -122,6 +121,7 @@ stackcommands = (
'pull',
'push',
'rebase',
+ 'repair',
'series',
'sink',
'top',
diff --git a/t/t1301-assimilate.sh b/t/t1301-repair.sh
similarity index 70%
rename from t/t1301-assimilate.sh
rename to t/t1301-repair.sh
index 7f47c31..5d9bdbd 100755
--- a/t/t1301-assimilate.sh
+++ b/t/t1301-repair.sh
@@ -1,19 +1,19 @@
#!/bin/sh
# Copyright (c) 2006 Karl Hasselström
-test_description='Test the assimilate command.'
+test_description='Test the repair command.'
. ./test-lib.sh
test_expect_success \
- 'Assimilate in a non-initialized repository' \
- '! stg assimilate'
+ 'Repair in a non-initialized repository' \
+ '! stg repair'
test_expect_success \
'Initialize the StGIT repository' \
'stg init'
test_expect_success \
- 'Assimilate in a repository without patches' \
- 'stg assimilate'
+ 'Repair in a repository without patches' \
+ 'stg repair'
test_expect_success \
'Create a patch' \
@@ -25,8 +25,8 @@ test_expect_success \
'
test_expect_success \
- 'Assimilate when there is nothing to do' \
- 'stg assimilate'
+ 'Repair when there is nothing to do' \
+ 'stg repair'
test_expect_success \
'Create a GIT commit' \
@@ -36,11 +36,9 @@ test_expect_success \
git commit -a -m bar
'
-test_expect_success \
- 'Assimilate one GIT commit' \
- '
+test_expect_success 'Turn one GIT commit into a patch' '
[ $(stg applied | wc -l) -eq 1 ] &&
- stg assimilate &&
+ stg repair &&
[ $(stg applied | wc -l) -eq 2 ]
'
@@ -56,11 +54,9 @@ test_expect_success \
git commit -a -m three
'
-test_expect_success \
- 'Assimilate three GIT commits' \
- '
+test_expect_success 'Turn three GIT commits into patches' '
[ $(stg applied | wc -l) -eq 2 ] &&
- stg assimilate &&
+ stg repair &&
[ $(stg applied | wc -l) -eq 5 ]
'
@@ -75,9 +71,9 @@ test_expect_success \
git pull . br
'
-test_expect_success 'Assimilate in the presence of a merge commit' '
+test_expect_success 'Repair in the presence of a merge commit' '
[ $(stg applied | wc -l) -eq 5 ] &&
- stg assimilate &&
+ stg repair &&
[ $(stg applied | wc -l) -eq 0 ]
'
diff --git a/t/t1302-assimilate-interop.sh b/t/t1302-repair-interop.sh
similarity index 91%
rename from t/t1302-assimilate-interop.sh
rename to t/t1302-repair-interop.sh
index 31f8b78..82c5ed2 100755
--- a/t/t1302-assimilate-interop.sh
+++ b/t/t1302-repair-interop.sh
@@ -1,5 +1,5 @@
#!/bin/sh
-test_description='Test git/StGit interoperability with "stg assimilate"'
+test_description='Test git/StGit interoperability with "stg repair"'
. ./test-lib.sh
test_expect_success 'Create some git-only history' '
@@ -28,7 +28,7 @@ test_expect_success 'Create five patches' '
test_expect_success 'Pop two patches with git-reset' '
git reset --hard HEAD~2 &&
! stg refresh &&
- stg assimilate &&
+ stg repair &&
stg refresh &&
[ "$(echo $(stg applied))" = "p0 p1 p2" ] &&
[ "$(echo $(stg unapplied))" = "p3 p4" ]
@@ -43,7 +43,7 @@ test_expect_success 'Create a new patch' '
test_expect_success 'Go to an unapplied patch with with git-reset' '
git reset --hard $(stg id p3) &&
! stg refresh &&
- stg assimilate &&
+ stg repair &&
stg refresh &&
[ "$(echo $(stg applied))" = "p0 p1 p2 p3" ] &&
[ "$(echo $(stg unapplied))" = "q0 p4" ]
@@ -51,7 +51,7 @@ test_expect_success 'Go to an unapplied patch with with git-reset' '
test_expect_success 'Go back to below the stack base with git-reset' '
git reset --hard foo-tag &&
- stg assimilate &&
+ stg repair &&
[ "$(echo $(stg applied))" = "" ] &&
[ "$(echo $(stg unapplied))" = "p0 p1 p2 p3 q0 p4" ]
'
^ permalink raw reply related
* [StGit PATCH 5/5] stg repair: Patchify non-patch commits between patches
From: Karl Hasselström @ 2007-11-11 19:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
This teaches "stg repair" to find non-patch commits that sit between
patches, and turn them into patches. This situation can happen e.g.
like this:
stg new -m A && stg new -m B && stg new -m C
stg pop A B C
stg push B
echo foo > foo && git add foo && stg refresh
git reset --hard $(stg id C)
The old "stg repair" would at this point simply conclude that A and C
are applied, and B unapplied. However, B's old commit is still between
them even though it's not a patch, which will cause problems later --
StGit generally assumes that the applied patches are a consecutive
string of commits. The new "stg repair", on the other hand, will find
B's old commit, and create a new patch for it.
One downside of this change is that we can no longer conclude that all
is well just because head == top, so no-op runs of "stg repair" just
got more expensive.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/repair.py | 19 +++++++------------
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/stgit/commands/repair.py b/stgit/commands/repair.py
index f8fe624..4787f72 100644
--- a/stgit/commands/repair.py
+++ b/stgit/commands/repair.py
@@ -101,33 +101,28 @@ def read_commit_dag(branch):
def func(parser, options, args):
"""Repair inconsistencies in StGit metadata."""
- def nothing_to_do():
- out.info('Nothing to repair')
-
orig_applied = crt_series.get_applied()
orig_unapplied = crt_series.get_unapplied()
- # If head == top, we're done.
- head = git.get_commit(git.get_head()).get_id_hash()
- top = crt_series.get_current_patch()
- if top and head == top.get_top():
- return nothing_to_do()
-
if crt_series.get_protected():
raise CmdException(
'This branch is protected. Modification is not permitted.')
# Find commits that aren't patches, and applied patches.
+ head = git.get_commit(git.get_head()).get_id_hash()
commits, patches = read_commit_dag(crt_series.get_name())
c = commits[head]
- patchify = []
+ patchify = [] # commits to definitely patchify
+ maybe_patchify = [] # commits to patchify if we find a patch below them
applied = []
while len(c.parents) == 1:
parent, = c.parents
if c.patch:
applied.append(c)
- elif not applied:
- patchify.append(c)
+ patchify.extend(maybe_patchify)
+ maybe_patchify = []
+ else:
+ maybe_patchify.append(c)
c = parent
applied.reverse()
patchify.reverse()
^ permalink raw reply related
* [StGit PATCH 3/5] Let some commands work with detached HEAD
From: Karl Hasselström @ 2007-11-11 19:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
add, resolved, and status didn't use the crt_series that was
initialized for them. So don't initialize it, since that means (1)
less work and (2) they won't fail when HEAD is detached.
Note that this doesn't completely fix the problem with detached HEAD:
a number of other commands (e.g. branch) don't always need to refer to
a current series, but currently fails on a detached HEAD even in those
situations.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/add.py | 2 +-
stgit/commands/resolved.py | 2 +-
stgit/commands/status.py | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/add.py b/stgit/commands/add.py
index 264ab9f..ceea188 100644
--- a/stgit/commands/add.py
+++ b/stgit/commands/add.py
@@ -31,7 +31,7 @@ Add the files or directories passed as arguments to the
repository. When a directory name is given, all the files and
subdirectories are recursively added."""
-directory = DirectoryHasRepository()
+directory = DirectoryHasRepository(needs_current_series = False)
options = []
diff --git a/stgit/commands/resolved.py b/stgit/commands/resolved.py
index 236ffd7..011db91 100644
--- a/stgit/commands/resolved.py
+++ b/stgit/commands/resolved.py
@@ -34,7 +34,7 @@ Mark a merge conflict as resolved. The conflicts can be seen with the
'C'. This command also removes any <file>.{ancestor,current,patched}
files."""
-directory = DirectoryHasRepository()
+directory = DirectoryHasRepository(needs_current_series = False)
options = [make_option('-a', '--all',
help = 'mark all conflicts as solved',
action = 'store_true'),
diff --git a/stgit/commands/status.py b/stgit/commands/status.py
index 5763d09..20614b0 100644
--- a/stgit/commands/status.py
+++ b/stgit/commands/status.py
@@ -40,7 +40,7 @@ under revision control. The files are prefixed as follows:
A 'refresh' command clears the status of the modified, new and deleted
files."""
-directory = DirectoryHasRepository()
+directory = DirectoryHasRepository(needs_current_series = False)
options = [make_option('-m', '--modified',
help = 'show modified files only',
action = 'store_true'),
^ permalink raw reply related
* Re: Subject: [PATCH 1/3] Added basic color support to git add --interactive
From: Junio C Hamano @ 2007-11-11 19:56 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071110202319.1f89a755@paradox.zwell.net>
Dan Zwell <dzwell@zwell.net> writes:
> Added function "colored()" that prints text with a color that
> is passed in. Converted many calls to "print" to being calls to
> "print colored".
You said "Let me know if other things need correction." I think
most of the comments you recieved were about improvements not
correction, and I think I am going to say in this message will
also mostly fall into that category.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 8d5d200..3712d6a 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -382,6 +382,12 @@ color.diff.<slot>::
> whitespace). The values of these variables may be specified as
> in color.branch.<slot>.
>
> +color.interactive::
> + When true (or `always`), always use colors in `git add
> + --interactive`. When false (or `never`), never. When set to
> + `auto`, use colors only when the output is to the
> + terminal. Defaults to false.
> +
I think "auto" should disable colors even when the output is "-t
STDOUT" if $TERM eq "dumb" (see color.c::git_config_colorbool()).
> @@ -175,7 +207,7 @@ sub list_and_choose {
> if (!$opts->{LIST_FLAT}) {
> print " ";
> }
> - print "$opts->{HEADER}\n";
> + print colored $header_color, "$opts->{HEADER}\n";
I agree with Jeff's suggestion to stick to more C-ish style to
always use parentheses around function arguments.
^ permalink raw reply
* Re: [PATCH v3] Make GIT_INDEX_FILE apply to git-commit
From: Junio C Hamano @ 2007-11-11 19:59 UTC (permalink / raw)
To: Rémi Vanicat; +Cc: git
In-Reply-To: <87r6ixj7af.dlv@vanicat.homelinux.org>
Rémi Vanicat <vanicat@debian.org> writes:
> @@ -26,7 +26,7 @@ refuse_partial () {
> }
>
> TMP_INDEX=
> -THIS_INDEX="$GIT_DIR/index"
> +THIS_INDEX="${GIT_INDEX_FILE:-$GIT_DIR/index}"
> NEXT_INDEX="$GIT_DIR/next-index$$"
> rm -f "$NEXT_INDEX"
> save_index () {
This is just a "purist" question, but I wonder if we want to
differentiate the case where GIT_INDEX_FILE is set to empty and
GIT_INDEX_FILE is not set at all?
> diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
> index abbf54b..3e5abef 100755
> --- a/t/t7500-commit.sh
> +++ b/t/t7500-commit.sh
> @@ -93,4 +93,17 @@ test_expect_success 'commit message from file should override template' '
> commit_msg_is "standard input msg"
> '
>
> +test_expect_success 'using GIT_INDEX_FILE' '
> +
> + echo "some new content" >file &&
> + GIT_INDEX_FILE=.git/another_index git add file &&
> + GIT_INDEX_FILE=.git/another_index \
> + git commit -m "commit using another index" &&
Tests that git-commit does not choke on committing the addion a
new 'file'.
> + git reset HEAD &&
> + git diff HEAD -- file >current &&
> + touch empty-file &&
> + diff empty-file current
Clobbers the index that the above GIT_INDEX_FILE trick should
not have touched before making sure of that, which is bad, and
then makes sure that the new file actually has the right
contents.
So, what I would suggest is:
* Your "GIT_INDEX_FILE=... git-commit" test -- git-commit
should not fail;
+ Test that the path you modified in the above commit (in this
case, 'file') matches between index you used in the commit
and the resulting commit;
* Test that the path you modified in the above commit matches
between the HEAD, the alternate index and the work tree (your
latter test).
+ Test that the original index the above wanted to preserve was
not clobbered by git-commit;
+ Test git-commit runs sensibly even when it is given a
nonexistent file as GIT_INDEX_FILE.
Perhaps like this, instead of your patch to t/t7500:
test_expect_success 'using alternate GIT_INDEX_FILE (1)' '
cp .git/index saved-index &&
(
echo some new content >file &&
GIT_INDEX_FILE=.git/another_index &&
export GIT_INDEX_FILE &&
git add file &&
git commit -m "commit using another index" &&
git diff-index --exit-code HEAD &&
git diff-files --exit-code
) &&
cmp .git/index saved-index >/dev/null
'
test_expect_success 'using alternate GIT_INDEX_FILE (2)' '
cp .git/index saved-index &&
(
rm -f .git/no-such-index &&
GIT_INDEX_FILE=.git/no-such-index &&
export GIT_INDEX_FILE &&
git commit -m "commit using nonexistent index" &&
test -z "$(git ls-files)" &&
test -z "$(git ls-tree HEAD)"
) &&
cmp .git/index saved-index >/dev/null
'
^ permalink raw reply
* [PATCH] Use the best available exec path only
From: Björn Steinbrink @ 2007-11-11 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3avcefg9.fsf@gitster.siamese.dyndns.org>
On 2007.11.11 11:43:02 -0800, Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
> > I'm sorry, I should have been more clear. I was referring to the
> > GIT_EXEC_PATH build variable, not the environment variable. The git
> > wrapper always adds the path determined during build to the front of
> > PATH. When I was changing my build script, this got set to "/usr/
> > local/bin" (I usually use /usr/local/stow/git, instead). Since I have
> > a /usr/local/bin/vim, PATH for git-commit.sh during the test was:
> >
> > - my git build directory
> > - /usr/local/bin (containing a symlink vi -> vim)
> > - the t/trash directory, added by the test via `PATH=".:$PATH"`
> > (containing the test vi script)
> > - my normal path
>
> Maybe that is what is broken. t/test-lib.sh makes the
> environment variable point at the build directory, and that
> should override the path that is compiled in, shouldn't it?
Maybe you prefer this patch then? "make test" survived up to 9101/25,
but that fails with the current master anyway and I didn't bother to run
the remaining tests manually, so it seems to be fine. Might break some
weird setups that rely on being able to set multiple additional paths
though (not that I think that that is a good idea to begin with).
Björn
---
Instead of adding all possible exec paths to PATH, only add the best
one, following the same rules that --exec-path, without arguments, uses
to figure out which path to display.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
diff --git a/exec_cmd.c b/exec_cmd.c
index 2d0a758..9c376ad 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -48,9 +48,7 @@ void setup_path(const char *cmd_path)
strbuf_init(&new_path, 0);
- add_path(&new_path, argv_exec_path);
- add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
- add_path(&new_path, builtin_exec_path);
+ add_path(&new_path, git_exec_path());
add_path(&new_path, cmd_path);
if (old_path)
^ permalink raw reply related
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Junio C Hamano @ 2007-11-11 20:34 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320711102218h259199e3g2b4a4d3b73202cdb@mail.gmail.com>
"Yin Ping" <pkufranky@gmail.com> writes:
> I think it's this kind of case in most open-source project. However,
> in a company environment, superprojects may be not so super.
Let's not say "most open-source" nor "company", because I think
nobody said anything that substantiates that the commit density
characteristics I described is typical for most open-source, nor
what you said is typical for corporate development projects, in
this thread so far.
If "superprojects is not so super", why are you using submodule
to bind these, instead of using a single project that tracks
developments of such closely tied parts?
I am not saying that it is wrong to use submodule to track such
groups of source trees whose versions are very closely tied
together. At least not yet.
I am just trying to find out what benefit you are getting out of
the submodule support, after rejecting one of the most visible
and advertised benefit of submodule support, which is to enable
binding "related but not that closely tied together" projects.
^ permalink raw reply
* Re: [PATCH 5/6] builtin-commit: resurrect behavior for multiple -m options
From: Johannes Schindelin @ 2007-11-11 20:42 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, krh, gitster
In-Reply-To: <20071111194228.GC13200@artemis.corp>
Hi,
On Sun, 11 Nov 2007, Pierre Habouzit wrote:
> On Sun, Nov 11, 2007 at 05:36:39PM +0000, Johannes Schindelin wrote:
> >
> > When more than one -m option is given, the message does not replace
> > the previous, but is appended.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > builtin-commit.c | 26 ++++++++++++++++++++------
> > 1 files changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/builtin-commit.c b/builtin-commit.c
> > index 66d7e5e..069d180 100644
> > --- a/builtin-commit.c
> > +++ b/builtin-commit.c
> > @@ -30,13 +30,27 @@ static char *use_message_buffer;
> > static const char commit_editmsg[] = "COMMIT_EDITMSG";
> > static struct lock_file lock_file;
> >
> > -static char *logfile, *force_author, *message, *template_file;
> > +static char *logfile, *force_author, *template_file;
> > static char *edit_message, *use_message;
> > static int all, edit_flag, also, interactive, only, amend, signoff;
> > static int quiet, verbose, untracked_files, no_verify;
> >
> > static int no_edit, initial_commit, in_merge;
> > const char *only_include_assumed;
> > +struct strbuf message;
>
> Unless I'm mistaken `static` keywords are missign for`message` and
> `only_include_assumed`.
Oh yeah. Will fix.
> And you _have_ to initialize message with STRBUF_INIT (remember of the
> slop).
Not in this case, since I do not use message.buf as long as message.len ==
0. But I agree it would be cleaner to just use STRBUF_INIT.
> > +static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> > +{
> > + struct strbuf *buf = opt->value;
> > + if (unset)
> > + strbuf_setlen(buf, 0);
> > + else {
> > + strbuf_addstr(buf, arg);
> > + strbuf_addch(buf, '\n');
> > + strbuf_addch(buf, '\n');
> > + }
> > + return 0;
> > +}
>
> I believe such a callback could live in parse-options.[hc]. The need
> to aggregate all string arguments into a strbuf looks generic enough to
> me. Why are you adding two '\n' btw ? Isn't one enough ?
Well, this empty line is needed to stay backwards compatible. It was
added to pass the test that Junio added to 'next'. As such, this function
is not really generic enough, right?
> Oh and last nitpicking, strbuf_addstr(buf, "\n\n"); is more efficient
> than the two addchar (the strlen it generates is inlined).
Well, I meant to mention it in the cover letter. My preference is to do
away with the extra empty line. But this might break existing setups
depending on that behaviour.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Johannes Schindelin @ 2007-11-11 20:50 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <20071111203318.GA32671@atjola.homenet>
Hi,
On Sun, 11 Nov 2007, Bj?rn Steinbrink wrote:
> On 2007.11.11 11:43:02 -0800, Junio C Hamano wrote:
> > Brian Gernhardt <benji@silverinsanity.com> writes:
> >
> > > I'm sorry, I should have been more clear. I was referring to the
> > > GIT_EXEC_PATH build variable, not the environment variable. The git
> > > wrapper always adds the path determined during build to the front of
> > > PATH. When I was changing my build script, this got set to "/usr/
> > > local/bin" (I usually use /usr/local/stow/git, instead). Since I
> > > have a /usr/local/bin/vim, PATH for git-commit.sh during the test
> > > was:
> > >
> > > - my git build directory
> > > - /usr/local/bin (containing a symlink vi -> vim)
> > > - the t/trash directory, added by the test via `PATH=".:$PATH"`
> > > (containing the test vi script)
> > > - my normal path
> >
> > Maybe that is what is broken. t/test-lib.sh makes the environment
> > variable point at the build directory, and that should override the
> > path that is compiled in, shouldn't it?
>
> Maybe you prefer this patch then? "make test" survived up to 9101/25,
> but that fails with the current master anyway and I didn't bother to run
> the remaining tests manually, so it seems to be fine. Might break some
> weird setups that rely on being able to set multiple additional paths
> though (not that I think that that is a good idea to begin with).
>
> Bj?rn
> ---
> Instead of adding all possible exec paths to PATH, only add the best
> one, following the same rules that --exec-path, without arguments, uses
> to figure out which path to display.
>
> Signed-off-by: Bj?rn Steinbrink <B.Steinbrink@gmx.de>
> ---
For easy application by the maintainer, please make the commit message the
first part, then have a single "---", and then the quoted mail.
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 2d0a758..9c376ad 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -48,9 +48,7 @@ void setup_path(const char *cmd_path)
>
> strbuf_init(&new_path, 0);
>
> - add_path(&new_path, argv_exec_path);
> - add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
> - add_path(&new_path, builtin_exec_path);
> + add_path(&new_path, git_exec_path());
> add_path(&new_path, cmd_path);
I wonder why cmd_path is still there, then. (I'd have expected something
like
add_path(&new_path, cmd_path ? cmd_path : git_exec_path());
In related news, IMO cmd_path should be made absolute if it is not already
the case.
Ciao,
Dscho
^ 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