* Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 21:28 UTC (permalink / raw)
To: Junio C Hamano, git
The current code drops extra blank lines between the first line of a
commit message (the summary line) and the remainder. That is:
This is the summary
This is another bit
This is a third bit
turns into:
Subject: This is the summary
Other-Headers:
This is another bit
This is a third bit
This is an issue if you want to generate an email whose body starts with a
blank line, and I assume (although I haven't tried), that rebase would
lose a blank line out of commits formatted like that. We don't seem to
have any tests that require that line to get suppressed, and we also don't
suppress any other blank lines. Is there some reason to do it?
I'd guess that the "first" handling in pp_remainder() was intended to skip
the blank line between the summary line and the body, but that line has
already been consumed by other code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] fix index-pack with packs >4GB containing deltas on 32-bit machines
From: Junio C Hamano @ 2007-11-11 21:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711102319470.21255@xanadu.home>
Looks obviously correct. Thanks.
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 21:20 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <B5C127C0-04B8-4469-B6DD-C8B5335BBA88@zib.de>
On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
> > 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?
>
> You can't. Remotes are local to a repository. They cannot be
> "pushed" nor will they be "cloned" or "fetched".
Dreamhost is way slow compared to kernel.org, so it is better to clone
from kernel.org first and then pull from dreamhost. What is the right
sequence of commands so that a new user will end up with a kernel they
can use 'git pull' on to get updates from dreamhost? I'll add these to
the repo description page.
I'm trying this locally and I can't figure out the right sequence of
git command to redirect origin from kernel.org to dreamhost.
Doing this was bad, it messed up my heads.
jonsmirl@terra:~/foo/digispeaker$ git remote rm origin
error: unable to resolve reference refs/remotes/origin/master: No such
file or directory
update-ref -d refs/remotes/origin/master
6e800af233e0bdf108efb7bd23c11ea6fa34cdeb: command returned error: 1
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Björn Steinbrink @ 2007-11-11 21:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711112047170.4362@racer.site>
On 2007.11.11 20:50:40 +0000, Johannes Schindelin wrote:
> 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.
OK.
> > 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());
Wouldn't that break setups where only the "git" wrapper is in $PATH?
cmd_path is just the path to the called executable (argv[0]). As I read
the code, it seems that cmd_path is just a worst case fallback, when the
"real" exec path is messed up somehow. I figured that I'd better keep
it, instead of just dropping it without knowing its intended purpose.
But if you're going to change anything about it, I'd guess that the only
option is to drop it, or change its relative position in PATH.
> In related news, IMO cmd_path should be made absolute if it is not already
> the case.
add_path() already takes care of that.
Björn
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Junio C Hamano @ 2007-11-11 21:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711111103240.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sat, 10 Nov 2007, Ask Bj?rn Hansen wrote:
>
>> For new users the superfluous programs are a burden making it harder to
>> learn how everything works.
>
> This should be a non-issue. We really should start deprecating
> "git-<command>" in favour of "git <command>" for real.
>
> New users should not even be told that this is correct usage.
>
> My reason? We have plumbing, and we will always have plumbing, as
> commands. A regular git user does not _want_ to see that. Without said
> deprecation she _will_, however.
If you can write "git-commit" and "git commit" interchangeably
while you cannot say "git-cat-file" and are forced to say "git
cat-file", I suspect that would lead to a great confusion and
unhappy users.
I wonder if making the distinction between plumbing and
porcelain in the git(7) page even more cleaner would help.
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Jakub Narebski @ 2007-11-11 21:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711112047170.4362@racer.site>
Johannes Schindelin wrote:
> On Sun, 11 Nov 2007, Björn Steinbrink wrote:
>>
>> ---
>> 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.
There are two conventions, for slightly different cases:
1. Commit message, then diffstat / single "---", then comments,
then patch
2. Email (for example long discussion), then separator BUT NOT "---";
use for example "-- >8 --" (cut here scissors), then commit message,
then diffstat and patch, beginning with "---".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Steffen Prohaska @ 2007-11-11 20:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711111136s20616468sd70b4bb19e7f3d0c@mail.gmail.com>
On Nov 11, 2007, at 8:36 PM, Jon Smirl wrote:
> 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?
You can't. Remotes are local to a repository. They cannot be
"pushed" nor will they be "cloned" or "fetched".
Steffen
^ 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
* 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] 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
* [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 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
* 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
* [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
* [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 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 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 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 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
* 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
* 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: [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: 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: 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: [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
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