* [PATCH] bash: remove fetch, push, pull dashed form leftovers
From: SZEDER Gábor @ 2008-10-03 19:34 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Rob Sanheim, Shawn O. Pearce
In-Reply-To: <1223051705-30347-1-git-send-email-trast@student.ethz.ch>
We don't provide complation for git-commands in dashed form anymore,
so there is no need to keep those cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
On Fri, Oct 03, 2008 at 06:35:05PM +0200, Thomas Rast wrote:
> Actually it's not enough, you need to teach fetch, pull and push to
> recognise the new alias too, as in this patch. I do wonder if there's
> a better approach to those functions however, so that the "obvious"
> fix suggested by Shawn would work.
Maybe something like this?
contrib/completion/git-completion.bash | 36 ++++++++------------------------
1 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 95c81f9..5a4e8c8 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -784,14 +784,9 @@ _git_fetch ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- case "${COMP_WORDS[0]},$COMP_CWORD" in
- git-fetch*,1)
+ if [ "$COMP_CWORD" = 2 ]; then
__gitcomp "$(__git_remotes)"
- ;;
- git,2)
- __gitcomp "$(__git_remotes)"
- ;;
- *)
+ else
case "$cur" in
*:*)
local pfx=""
@@ -810,8 +805,7 @@ _git_fetch ()
__gitcomp "$(__git_refs2 "$remote")"
;;
esac
- ;;
- esac
+ fi
}
_git_format_patch ()
@@ -1051,36 +1045,25 @@ _git_pull ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- case "${COMP_WORDS[0]},$COMP_CWORD" in
- git-pull*,1)
- __gitcomp "$(__git_remotes)"
- ;;
- git,2)
+ if [ "$COMP_CWORD" = 2 ]; then
__gitcomp "$(__git_remotes)"
- ;;
- *)
+ else
local remote
case "${COMP_WORDS[0]}" in
git-pull) remote="${COMP_WORDS[1]}" ;;
git) remote="${COMP_WORDS[2]}" ;;
esac
__gitcomp "$(__git_refs "$remote")"
- ;;
- esac
+ fi
}
_git_push ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- case "${COMP_WORDS[0]},$COMP_CWORD" in
- git-push*,1)
- __gitcomp "$(__git_remotes)"
- ;;
- git,2)
+ if [ "$COMP_CWORD" = 2 ]; then
__gitcomp "$(__git_remotes)"
- ;;
- *)
+ else
case "$cur" in
*:*)
local remote
@@ -1104,8 +1087,7 @@ _git_push ()
__gitcomp "$(__git_refs)"
;;
esac
- ;;
- esac
+ fi
}
_git_rebase ()
--
1.6.0.2.474.ga74ad.dirty
^ permalink raw reply related
* Re: [PATCH] Fix argument handling for fetch-pack call when stdout is connected and -q/--quiet is supplied.
From: Daniel Barkalow @ 2008-10-03 19:50 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git, davej
In-Reply-To: <4ac8254d0810031234x26ebc96cy7cf5dcae2ef516e0@mail.gmail.com>
On Fri, 3 Oct 2008, Tuncer Ayaz wrote:
> Following is a patch to complete the changes discussed
> here http://marc.info/?l=git&m=121529226023180&w=2.
>
> I hope it makes sense and doesn't break something else.
>
> With this simple one-liner patch applied I no longer see
> the following remote messages as no-progress is correctly
> sent to the remote site:
> remote: Counting objects: 84102, done.
> remote: Compressing objects: 100% (24720/24720), done.
> remote: Total 84102 (delta 60949), reused 80810 (delta 57900)
>
> Regards,
>
> Tuncer Ayaz
>
> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
> ---
> transport.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/transport.c b/transport.c
> index 71433d9..1f24011 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -644,7 +644,7 @@ static int fetch_refs_via_pack(struct transport *transport,
> args.include_tag = data->followtags;
> args.verbose = (transport->verbose > 0);
> args.quiet = args.no_progress = (transport->verbose < 0);
> - args.no_progress = !isatty(1);
> + args.no_progress = args.quiet || !isatty(1);
If you're doing that, remove the "args.no_progress =" from the previous
line, which was there to have that effect (but not so clearly). Aside from
that, it looks good to me.
> args.depth = data->depth;
>
> for (i = 0; i < nr_heads; i++)
> --
> 1.6.0.2
>
^ permalink raw reply
* Forcing progerss output for clone
From: Constantine Plotnikov @ 2008-10-03 20:01 UTC (permalink / raw)
To: git
Hello!
Is there a way to force a progress output on stderr for git clone
preferably using options or environment variables?
The clone command in the git 1.6.0.2 does not print a progress
information to stderr if stdout and stderr are redirected (even if no
"-q" option is specified).
Such information would have been useful for displaying progress
information when cloning from IDE. IDE run git with streams
redirected, and this progress information could have been displayed to
user to indicate current status of operation.
Best Regards,
Constantine
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: David Bryson @ 2008-10-03 20:06 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48E5AD8A.4070301@op5.se>
On Fri, Oct 03, 2008 at 07:28:42AM +0200 or thereabouts, Andreas Ericsson wrote:
> David Bryson wrote:
>> Signed-off-by: David Bryson <david@statichacks.org>
>> I tried to keep with the naming/coding conventions that I found in
>> remote.c. Feedback welcome.
>> ---
>> remote.c | 19 ++++++++++---------
>> 1 files changed, 10 insertions(+), 9 deletions(-)
>> diff --git a/remote.c b/remote.c
>> index 3f3c789..893a739 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -305,6 +305,7 @@ static int handle_config(const char *key, const char
>> *value, void *cb)
>> {
>> const char *name;
>> const char *subkey;
>> + const char *v;
>
>
> Not very mnemonic. I'm sure you can think up a better name, even if it's
> a long one. Git is notoriously sparse when it comes to comments. We rely
> instead on self-explanatory code.
>
Oh I agree entirely, it is quite vague, however like I mentioned I tried
to keep to the conventios in the file. This strategy(v) is used in several
other places in remote.c, if this is Bad Code, then I have no problem
changing it.
Thoughts from anybody else ?
^ permalink raw reply
* Re: [PATCH] bash: remove fetch, push, pull dashed form leftovers
From: Thomas Rast @ 2008-10-03 20:13 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Rob Sanheim, Shawn O. Pearce
In-Reply-To: <20081003193449.GA24821@neumann>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
SZEDER Gábor wrote:
> We don't provide complation for git-commands in dashed form anymore,
> so there is no need to keep those cases.
[...]
> On Fri, Oct 03, 2008 at 06:35:05PM +0200, Thomas Rast wrote:
> > I do wonder if there's a better approach to those functions
> > however, so that the "obvious" fix suggested by Shawn would work.
>
> Maybe something like this?
That's indeed much simpler and better. FWIW,
Tested-by: Thomas Rast <trast@student.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix argument handling for fetch-pack call when stdout is connected and -q/--quiet is supplied.
From: Tuncer Ayaz @ 2008-10-03 20:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, davej
In-Reply-To: <alpine.LNX.1.00.0810031548260.19665@iabervon.org>
On Fri, Oct 3, 2008 at 9:50 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Fri, 3 Oct 2008, Tuncer Ayaz wrote:
<snip>
>> diff --git a/transport.c b/transport.c
>> index 71433d9..1f24011 100644
>> --- a/transport.c
>> +++ b/transport.c
>> @@ -644,7 +644,7 @@ static int fetch_refs_via_pack(struct transport *transport,
>> args.include_tag = data->followtags;
>> args.verbose = (transport->verbose > 0);
>> args.quiet = args.no_progress = (transport->verbose < 0);
>> - args.no_progress = !isatty(1);
>> + args.no_progress = args.quiet || !isatty(1);
>
> If you're doing that, remove the "args.no_progress =" from the previous
> line, which was there to have that effect (but not so clearly). Aside from
> that, it looks good to me.
>
<snip>
Thanks Daniel, that makes a lot of sense.
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
transport.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/transport.c b/transport.c
index 71433d9..35cac44 100644
--- a/transport.c
+++ b/transport.c
@@ -643,8 +643,8 @@ static int fetch_refs_via_pack(struct transport *transport,
args.use_thin_pack = data->thin;
args.include_tag = data->followtags;
args.verbose = (transport->verbose > 0);
- args.quiet = args.no_progress = (transport->verbose < 0);
- args.no_progress = !isatty(1);
+ args.quiet = (transport->verbose < 0);
+ args.no_progress = args.quiet || !isatty(1);
args.depth = data->depth;
for (i = 0; i < nr_heads; i++)
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] Fix argument handling for fetch-pack call when stdout is connected and -q/--quiet is supplied.
From: Constantine Plotnikov @ 2008-10-03 20:33 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: Daniel Barkalow, git, davej
In-Reply-To: <4ac8254d0810031318j3e0f326ewc4bf250c51681670@mail.gmail.com>
I think such patch would be too harsh for IDE plugin developers. When
git is run from IDE, the isatty(1) will be true. But progress
information will be still useful, to display an operation progress to
user. Please provide a way to force output of progress (for example
using environment).
Regards,
Constantine
On Sat, Oct 4, 2008 at 12:18 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Fri, Oct 3, 2008 at 9:50 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> On Fri, 3 Oct 2008, Tuncer Ayaz wrote:
>
> <snip>
>
>>> diff --git a/transport.c b/transport.c
>>> index 71433d9..1f24011 100644
>>> --- a/transport.c
>>> +++ b/transport.c
>>> @@ -644,7 +644,7 @@ static int fetch_refs_via_pack(struct transport *transport,
>>> args.include_tag = data->followtags;
>>> args.verbose = (transport->verbose > 0);
>>> args.quiet = args.no_progress = (transport->verbose < 0);
>>> - args.no_progress = !isatty(1);
>>> + args.no_progress = args.quiet || !isatty(1);
>>
>> If you're doing that, remove the "args.no_progress =" from the previous
>> line, which was there to have that effect (but not so clearly). Aside from
>> that, it looks good to me.
>>
>
> <snip>
>
> Thanks Daniel, that makes a lot of sense.
>
> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
> ---
> transport.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/transport.c b/transport.c
> index 71433d9..35cac44 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -643,8 +643,8 @@ static int fetch_refs_via_pack(struct transport *transport,
> args.use_thin_pack = data->thin;
> args.include_tag = data->followtags;
> args.verbose = (transport->verbose > 0);
> - args.quiet = args.no_progress = (transport->verbose < 0);
> - args.no_progress = !isatty(1);
> + args.quiet = (transport->verbose < 0);
> + args.no_progress = args.quiet || !isatty(1);
> args.depth = data->depth;
>
> for (i = 0; i < nr_heads; i++)
> --
> 1.6.0.2
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Fix argument handling for fetch-pack call when stdout is connected and -q/--quiet is supplied.
From: Daniel Barkalow @ 2008-10-03 20:39 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Tuncer Ayaz, git, davej
In-Reply-To: <85647ef50810031333m254036bav81d6dd4a58fb56da@mail.gmail.com>
On Sat, 4 Oct 2008, Constantine Plotnikov wrote:
> I think such patch would be too harsh for IDE plugin developers. When
> git is run from IDE, the isatty(1) will be true. But progress
> information will be still useful, to display an operation progress to
> user. Please provide a way to force output of progress (for example
> using environment).
Probably progress.h ought to have something for whether progress bars make
sense, that uses isatty(1) with an environment variable override.
Conceptually, transport.c should be figuring out whether the verbosity of
the operation suggests progress bars, and should pass off to something
else the determination of whether we can actually output progress bars in
particular.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Fix argument handling for fetch-pack call when stdout is connected and -q/--quiet is supplied.
From: Tuncer Ayaz @ 2008-10-03 20:44 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Daniel Barkalow, git
In-Reply-To: <85647ef50810031333m254036bav81d6dd4a58fb56da@mail.gmail.com>
On Fri, Oct 3, 2008 at 10:33 PM, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> I think such patch would be too harsh for IDE plugin developers. When
> git is run from IDE, the isatty(1) will be true. But progress
> information will be still useful, to display an operation progress to
> user. Please provide a way to force output of progress (for example
> using environment).
Hi Constantine,
this only fixes what was wrong: If you call "git clone -q" args.no_progress
was meant to be 1 but wasn't due to a small error.
If isatty(1) returns 1 then args.no_progress=0, so you will get progress
logging in that case - assuming you haven't supplied -q.
To get progress logging call without -q _and_ have isatty(1)==1.
> Regards,
> Constantine
>
>
> On Sat, Oct 4, 2008 at 12:18 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> On Fri, Oct 3, 2008 at 9:50 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>>> On Fri, 3 Oct 2008, Tuncer Ayaz wrote:
>>
>> <snip>
>>
>>>> diff --git a/transport.c b/transport.c
>>>> index 71433d9..1f24011 100644
>>>> --- a/transport.c
>>>> +++ b/transport.c
>>>> @@ -644,7 +644,7 @@ static int fetch_refs_via_pack(struct transport *transport,
>>>> args.include_tag = data->followtags;
>>>> args.verbose = (transport->verbose > 0);
>>>> args.quiet = args.no_progress = (transport->verbose < 0);
>>>> - args.no_progress = !isatty(1);
>>>> + args.no_progress = args.quiet || !isatty(1);
>>>
>>> If you're doing that, remove the "args.no_progress =" from the previous
>>> line, which was there to have that effect (but not so clearly). Aside from
>>> that, it looks good to me.
>>>
>>
>> <snip>
>>
>> Thanks Daniel, that makes a lot of sense.
>>
>> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
>> ---
>> transport.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/transport.c b/transport.c
>> index 71433d9..35cac44 100644
>> --- a/transport.c
>> +++ b/transport.c
>> @@ -643,8 +643,8 @@ static int fetch_refs_via_pack(struct transport *transport,
>> args.use_thin_pack = data->thin;
>> args.include_tag = data->followtags;
>> args.verbose = (transport->verbose > 0);
>> - args.quiet = args.no_progress = (transport->verbose < 0);
>> - args.no_progress = !isatty(1);
>> + args.quiet = (transport->verbose < 0);
>> + args.no_progress = args.quiet || !isatty(1);
>> args.depth = data->depth;
>>
>> for (i = 0; i < nr_heads; i++)
>> --
>> 1.6.0.2
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Broken index file - any hope?
From: Jonas Schneider @ 2008-10-03 21:51 UTC (permalink / raw)
To: git
Hey guys,
I come from the Ruby on Rails world, where Git is now spreading like ...
duh, something fast.
Today I sadly lost my complete .git directory, only the working copy was
left behind.
I reconstructed the directory, but the index file seems to be corrupt,
every command just tells me about a bad signature.
I hope the rest of the repository is intanct. If it is, is there any
chance to restore/rebuild that index file from the rest?
I don't have an idea of the internals of git, but I know the objects are
stored in different files, and maybe on top of that
I could rebuild the index file.
Any hope?
Thanks,
--Jonas Schneider
^ permalink raw reply
* Re: Broken index file - any hope?
From: Shawn O. Pearce @ 2008-10-03 21:53 UTC (permalink / raw)
To: Jonas Schneider; +Cc: git
In-Reply-To: <48E693E9.708@gmx.de>
Jonas Schneider <JonasSchneider@gmx.de> wrote:
> I come from the Ruby on Rails world, where Git is now spreading like ...
> duh, something fast.
> Today I sadly lost my complete .git directory, only the working copy was
> left behind.
> I reconstructed the directory, but the index file seems to be corrupt,
> every command just tells me about a bad signature.
> I hope the rest of the repository is intanct. If it is, is there any
> chance to restore/rebuild that index file from the rest?
> I don't have an idea of the internals of git, but I know the objects are
> stored in different files, and maybe on top of that
> I could rebuild the index file.
Give this a shot:
git read-tree --reset HEAD
git status
at worst you lose staged changes. At best you recover the index
file.
--
Shawn.
^ permalink raw reply
* Re: Broken index file - any hope?
From: Jonas Schneider @ 2008-10-03 22:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081003215319.GX21310@spearce.org>
Shawn O. Pearce schrieb:
> git read-tree --reset HEAD
Sadly, this doesnt help. I still get the same error.
But, if I remove the corrupt index file, I get this:
fatal: just how do you expect me to merge 0 trees?
Does not look like a good sign :/
Are all my branches (branch==tree?) gone? (okay, werent that much)
Thanks anyway :)
-- Jonas
^ permalink raw reply
* Re: Broken index file - any hope?
From: Shawn O. Pearce @ 2008-10-03 22:07 UTC (permalink / raw)
To: Jonas Schneider; +Cc: git
In-Reply-To: <48E696CB.6040405@gmx.de>
Jonas Schneider <JonasSchneider@gmx.de> wrote:
> Shawn O. Pearce schrieb:
>> git read-tree --reset HEAD
> Sadly, this doesnt help. I still get the same error.
> But, if I remove the corrupt index file, I get this:
>
> fatal: just how do you expect me to merge 0 trees?
Yea, so that sounds like "git log" doesn't work because HEAD isn't
pointing at a valid branch.
> Does not look like a good sign :/
> Are all my branches (branch==tree?) gone? (okay, werent that much)
Yes, a branch contains a series of trees. The current tree of a
branch is the tree of the most recent commit on that branch.
They may be gone.
--
Shawn.
^ permalink raw reply
* Re: Broken index file - any hope?
From: Jeff Whiteside @ 2008-10-03 22:09 UTC (permalink / raw)
To: Jonas Schneider; +Cc: Shawn O. Pearce, git
In-Reply-To: <48E696CB.6040405@gmx.de>
I don't know if you're new to git, but I used git for about a year
before I knew what the index really was.
Remember, the index file only stores changes you made to the
checkedout code AFTER the last commit, so all your commits are safely
in the tree objects still.
The index is only a place to store changes you made with "git add",
not "git commit".
I'm not sure how you refresh the index file but i would back
everything up and try a "git reset --hard" or something.
On Fri, Oct 3, 2008 at 3:03 PM, Jonas Schneider <JonasSchneider@gmx.de> wrote:
> Shawn O. Pearce schrieb:
>>
>> git read-tree --reset HEAD
>
> Sadly, this doesnt help. I still get the same error.
> But, if I remove the corrupt index file, I get this:
>
> fatal: just how do you expect me to merge 0 trees?
>
> Does not look like a good sign :/
> Are all my branches (branch==tree?) gone? (okay, werent that much)
>
> Thanks anyway :)
> -- Jonas
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv4] gitweb: generate project/action/hash URLs
From: Jakub Narebski @ 2008-10-04 1:15 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1222906234-8182-4-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
> When generating path info URLs, reduce the number of CGI parameters by
> embedding action and hash_parent:filename or hash in the path.
I think this is good.
>---
> + # Finally, we put either hash_base:file_name or hash
> + if (defined $params{'hash_base'}) {
> + $href .= "/".esc_url($params{'hash_base'});
> + if (defined $params{'file_name'}) {
> + $href .= ":".esc_url($params{'file_name'});
> + delete $params{'file_name'};
> + }
> + delete $params{'hash'};
> + delete $params{'hash_base'};
> + } elsif (defined $params{'hash'}) {
> + $href .= "/".esc_url($params{'hash'});
> + delete $params{'hash'};
> + }
> }
That I'm not sure about, both the layout of conditional (shouldn't
we check $file_name first), and the fact that we remove parameter
which is not passed, and can be even not recoverable (for example
both 'hash' and 'hash_base' set, 'hash' != 'hash_base', and
'file_name' not set). So the code above probably has some strange
corner cases, but I guess it wouldn't be triggered by links generated
by gitweb.
But I guess that is "good enough", especially that 'tree' and 'history'
action links can have 'file_name' unset if they refer to top tree, and
they still need 'hash_base'.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse parent..current syntax from pathinfo
From: Jakub Narebski @ 2008-10-04 1:31 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1222906234-8182-6-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
> This makes it possible to use an URL such as
> $project/somebranch..otherbranch:/filename to get a diff between
> different version of a file. Paths like
> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
> as well.
>
In short, it allows to have link to '*diff' views using path_info URL,
or in general to pass $hash_[parent_]base and $file_parent using
path_info.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 26 ++++++++++++++++++++++++--
> 1 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 3e5b2b7..89e360f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -534,7 +534,9 @@ if ($path_info && !defined $action) {
>
> # we can now parse ref and pathnames in PATH_INFO
> if ($path_info) {
> - my ($refname, $pathname) = split(/:/, $path_info, 2);
> + $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
> + my ($parentrefname, $parentpathname, $refname, $pathname) = (
> + $2, $4, $5, $7);
Style: I would use (but that is perhaps matter of taste)
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($2, $4, $5, $7);
Also it would be I think simpler to use instead non-catching grouping,
i.e. (?: xxx ) extended pattern (see perlre(1)), and use
($1, $2, $3, $4), or even simpler 'list = (string =~ regexp)' form.
I also think that the situation is more complicated than that, if we
want to be more correct.
The following path_info layouts with '..' make sense:
hpb:fp..hb:f
hpb..hb:f == hpb:f..hb:f
hp..h
And the layout below can be though to make sense, but it is just
plain weird.
hpb:fp..f == hpb:fp..HEAD:f
> if (defined $pathname) {
> # we got "project.git/action/branch:filename" or "project.git/action/branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
> @@ -543,7 +545,11 @@ if ($path_info) {
> $input_params{'action'} ||= "tree";
> $pathname =~ s,/$,,;
> } else {
> - $input_params{'action'} ||= "blob_plain";
> + if ($parentrefname) {
> + $input_params{'action'} ||= "blobdiff_plain";
> + } else {
> + $input_params{'action'} ||= "blob_plain";
> + }
Good catch.
> }
> $input_params{'hash_base'} ||= $refname;
> $input_params{'file_name'} ||= $pathname;
> @@ -553,6 +559,22 @@ if ($path_info) {
> $input_params{'hash'} ||= $refname;
> $input_params{'hash_base'} ||= $refname;
> }
> + # the parent part might be missing the pathname, in which case we use the $file_name, if present
> + if (defined $parentrefname) {
> + $input_params{'hash_parent_base'} ||= $parentrefname;
> + if ($parentpathname) {
> + $parentpathname =~ s,^/+,,;
> + $parentpathname =~ s,/$,,;
> + $input_params{'file_parent'} ||= $parentpathname;
> + } else {
> + $input_params{'file_parent'} ||= $input_params{'file_name'};
> + }
> + if (defined $input_params{'file_parent'}) {
> + $input_params{'hash_parent'} ||= git_get_hash_by_path($input_params{'hash_parent_base'}, $input_params{'file_parent'});
This line is bit long, and I think it should be wrapped..
> + } else {
> + $input_params{'hash_parent'} ||= $parentrefname;
> + }
> + }
> }
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git commit: Repaint the output format bikeshed (again)
From: Jeff King @ 2008-10-04 2:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <20081003140951.GU21310@spearce.org>
On Fri, Oct 03, 2008 at 07:09:52AM -0700, Shawn O. Pearce wrote:
> I think the hard part now is to get the user docs updated to reflect
> the new format. We need to get that done before this can merge
> over to master.
Grepping only turned up the two instances that Andreas had changed for
his patch, so I think that is probably it. Here's the patch.
-- >8 --
tutorial: update output of git commit
Commit c85db254 changed the format of the message produced
by "git commit" when creating a commit. This patch updates
the example session in the tutorial to the new format.
It also adds in the missing diffstat summary lines, which
should have been added long ago.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/gittutorial-2.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 8484e7a..bab0f34 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -32,11 +32,13 @@ Initialized empty Git repository in .git/
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
-Created root-commit 54196cc (initial commit) on master
+[master (root-commit)] created 54196cc: "initial commit"
+ 1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
-Created c4d59f3 (add emphasis) on master
+[master] created c4d59f3: "add emphasis"
+ 1 files changed, 1 insertions(+), 1 deletions(-)
------------------------------------------------
What are the 7 digits of hex that git responded to the commit with?
--
1.6.0.2.636.gaa7b
^ permalink raw reply related
* Re: Broken index file - any hope?
From: Linus Torvalds @ 2008-10-04 3:08 UTC (permalink / raw)
To: Jonas Schneider; +Cc: Shawn O. Pearce, git
In-Reply-To: <48E696CB.6040405@gmx.de>
On Sat, 4 Oct 2008, Jonas Schneider wrote:
> Shawn O. Pearce schrieb:
> > git read-tree --reset HEAD
> Sadly, this doesnt help. I still get the same error.
> But, if I remove the corrupt index file, I get this:
>
> fatal: just how do you expect me to merge 0 trees?
Sounds like you didn't recreate the whole .git directory - not only was
your index file corrupt, but apparently your .git/HEAD file is too.
The index is just a cache (apart from when you stage things into it
and/or do merges), and the git read-tree should have recreated it for you.
The fact that it doesn't work implies that HEAD is corrupt or missing too.
Does "git branch" work for you? And what does .git/HEAD contain (normally
it would just contain a single line saying "ref: refs/heads/master", but
it obviously depends on which branch you were on, and it could just be a
detached head that just points directly to a SHA1).
Linus
^ permalink raw reply
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Jeff King @ 2008-10-04 4:17 UTC (permalink / raw)
To: Imre Deak; +Cc: Linus Torvalds, git
In-Reply-To: <500f3d130810021127j570bb540p901f6a73f58a6cb1@mail.gmail.com>
On Thu, Oct 02, 2008 at 09:27:36PM +0300, Imre Deak wrote:
> $ git apply patch
> fatal: git diff header lacks filename information (line 4)
> $ cat patch
> diff --git a/dev/null b/a
> new file mode 100644
> index 0000000000000000000000000000000000000000..1f2a4f5ef3df7f7456d91c961da36fc58904f2f1
> GIT binary patch
Hmm. The problem is that "git apply" doesn't accept that "a/dev/null"
and "b/a" are the same, so it rejects them as a name. I guess on a text
patch, we would just pull that information from the "---" and "+++"
lines, so we don't care that it's not on the diff commandline.
However, a _non_ --no-index patch doesn't produce the same output. It
will actually produce the line:
diff --git a/a b/a
even if it is a creation patch. So I'm not sure which piece of code is
at fault. Either:
1. git apply is right to reject, and "git diff --no-index" should be
putting the actual filename on the commandline of a binary patch
instead of /dev/null, even if it is a creation patch.
or
2. git apply should accept this construct. Perhaps we should relax the
"both names must be the same" rule if one of the names is /dev/null
(and we would take the other)?
Linus, the "both names must be the same" code in git_header_name blames
to you (5041aa70). Thoughts on number 2?
-Peff
^ permalink raw reply
* Re: [QGit] [PATCH] Modify Highlight Color at File Context View.
From: Marco Costalba @ 2008-10-04 6:19 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <e5bfff550809302347r59621e09sdea5c679ef3794c8@mail.gmail.com>
On Wed, Oct 1, 2008 at 8:47 AM, Marco Costalba <mcostalba@gmail.com> wrote:
> On Mon, Sep 29, 2008 at 3:27 AM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
>> Marco:
>>
>> I don't get my patch by git-pull.
>> There are not my patch at
>> http://git.kernel.org/?p=qgit/qgit4.git;a=summary.
>>
>> best regards
>> Frank Li
>> ________________________________
>
> I have pushed to my local repo, I will be able to push to public repo
> only this week end.
>
Ok. Now is pushed to public repo.
Frank, are you sure it works? for me it does not seem to make any difference.
Marco
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse parent..current syntax from pathinfo
From: Giuseppe Bilotta @ 2008-10-04 7:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <200810040331.27605.jnareb@gmail.com>
On Sat, Oct 4, 2008 at 3:31 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
>
>> This makes it possible to use an URL such as
>> $project/somebranch..otherbranch:/filename to get a diff between
>> different version of a file. Paths like
>> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
>> as well.
>>
>
> In short, it allows to have link to '*diff' views using path_info URL,
> or in general to pass $hash_[parent_]base and $file_parent using
> path_info.
Yes, that's probably a better form for the commit message.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> gitweb/gitweb.perl | 26 ++++++++++++++++++++++++--
>> 1 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 3e5b2b7..89e360f 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -534,7 +534,9 @@ if ($path_info && !defined $action) {
>>
>> # we can now parse ref and pathnames in PATH_INFO
>> if ($path_info) {
>> - my ($refname, $pathname) = split(/:/, $path_info, 2);
>> + $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
>> + my ($parentrefname, $parentpathname, $refname, $pathname) = (
>> + $2, $4, $5, $7);
>
> Style: I would use (but that is perhaps matter of taste)
>
> + my ($parentrefname, $parentpathname, $refname, $pathname) =
> + ($2, $4, $5, $7);
Right, I'm not sure why I put the ( on the previous line.
> Also it would be I think simpler to use instead non-catching grouping,
> i.e. (?: xxx ) extended pattern (see perlre(1)), and use
> ($1, $2, $3, $4), or even simpler 'list = (string =~ regexp)' form.
Good idea, I'll rework it in that sense.
> I also think that the situation is more complicated than that, if we
> want to be more correct.
>
> The following path_info layouts with '..' make sense:
>
> hpb:fp..hb:f
> hpb..hb:f == hpb:f..hb:f
> hp..h
And these are matched by the above regexp
> And the layout below can be though to make sense, but it is just
> plain weird.
>
> hpb:fp..f == hpb:fp..HEAD:f
I'm afraid I'm not going to support that, although it's probably easy
to support hpb:fp..:f (i.e. accept a missing refname but on condition
of having a : in front of the file spec).
>> + if (defined $input_params{'file_parent'}) {
>> + $input_params{'hash_parent'} ||= git_get_hash_by_path($input_params{'hash_parent_base'}, $input_params{'file_parent'});
>
> This line is bit long, and I think it should be wrapped..
By the way, on the first revision of the path_info patchset, you had me discard
$hash ||= git_get_hash_by_path($hash_base, $file_name);
in the simple case on the basis that it was an extra call to external git.
I actually forgot to remove it from this part of the patchset too at
the time, so this gets me wondering about this: should I put it back
in place in the simple case, or remove it from here too?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse parent..current syntax from pathinfo
From: Jakub Narebski @ 2008-10-04 7:48 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810040024q4dfad117uf719f0aaa17ae95b@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sat, Oct 4, 2008 at 3:31 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
>>
>>> This makes it possible to use an URL such as
>>> $project/somebranch..otherbranch:/filename to get a diff between
>>> different version of a file. Paths like
>>> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
>>> as well.
>>>
>>
>> In short, it allows to have link to '*diff' views using path_info URL,
>> or in general to pass $hash_[parent_]base and $file_parent using
>> path_info.
>
> Yes, that's probably a better form for the commit message.
I have thought about this rather as supplement (addition) to the
current commit message (which states explicitly new form of supported
path_info URL), than replacing it.
>> The following path_info layouts with '..' make sense:
>>
>> hpb:fp..hb:f
>> hpb..hb:f == hpb:f..hb:f
>> hp..h
>
> And these are matched by the above regexp
>
>> And the layout below can be though to make sense, but it is just
>> plain weird.
>>
>> hpb:fp..f == hpb:fp..HEAD:f
>
> I'm afraid I'm not going to support that, although it's probably easy
> to support hpb:fp..:f (i.e. accept a missing refname but on condition
> of having a : in front of the file spec).
No, not supporting this form is just fine.
>>> + if (defined $input_params{'file_parent'}) {
>>> + $input_params{'hash_parent'} ||= git_get_hash_by_path($input_params{'hash_parent_base'}, $input_params{'file_parent'});
>>
>> This line is bit long, and I think it should be wrapped..
>
> By the way, on the first revision of the path_info patchset, you had me discard
>
> $hash ||= git_get_hash_by_path($hash_base, $file_name);
>
> in the simple case on the basis that it was an extra call to external git.
>
> I actually forgot to remove it from this part of the patchset too at
> the time, so this gets me wondering about this: should I put it back
> in place in the simple case, or remove it from here too?
I think you should remove it here too. IMHO if needed, it should be
dealt with (and I think is dealt with) in appropriate action subroutine.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Jakub Narebski @ 2008-10-04 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081004041714.GA12413@coredump.intra.peff.net>
[Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Imre Deak <imre.deak@gmail.com>]
Jeff King wrote:
> On Thu, Oct 02, 2008 at 09:27:36PM +0300, Imre Deak wrote:
>
>> $ git apply patch
>> fatal: git diff header lacks filename information (line 4)
>> $ cat patch
>> diff --git a/dev/null b/a
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..1f2a4f5ef3df7f7456d91c961da36fc58904f2f1
>> GIT binary patch
>
> Hmm. The problem is that "git apply" doesn't accept that "a/dev/null"
> and "b/a" are the same, so it rejects them as a name. I
Shouldn't it be "/dev/null", not "a/dev/null"?
Besides git-diff(1) states:
1. It is preceded with a "git diff" header, that looks like
this:
diff --git a/file1 b/file2
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
Looks like a bug in patch generation code...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Build bug report: 'make check' needs sparse, but configure doesn't check it
From: Ed Avis @ 2008-10-04 13:19 UTC (permalink / raw)
To: git
When you build git-1.6.0.2 and 'make check', it tries to run sparse and fails if
sparse is not there. But the configure script does not check sparse is
installed.
I suggest that 'make check' skip the sparse tests if sparse is not there. As I
understand it, they are really more for the developers to get a report of
possible errors in the source code and not to test that the built executables
work, so it would not be dangerous to just skip running those tests for ordinary
users who don't have the tool.
Alternatively, if running sparse is really important for a thorough 'make
check', the configure script should check for it and warn you to install it.
--
Ed Avis <ed@membled.com>
^ permalink raw reply
* [PATCH v3] Add git-svn branch to allow branch creation in SVN repositories
From: Deskin Miller @ 2008-10-04 14:24 UTC (permalink / raw)
To: rafl, normalperson; +Cc: spearce, git
>From 7a8a811bbb229825da8c90e71c57a60634a9280b Mon Sep 17 00:00:00 2001
From: Florian Ragwitz <rafl@debian.org>
Date: Tue, 2 Sep 2008 14:20:39 +0000
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Eric Wong <normalperson <at> yhbt.net> writes:
> Florian Ragwitz <rafl <at> debian.org> wrote:
> > Signed-off-by: Florian Ragwitz <rafl <at> debian.org>
>
> The patch looks good, but can you add a test for this functionality?
Here's a new patch with tests for this feature. There are also some minor
changes to Florian's patch: branch now parses -t/--tag, and some of the
messages in cmd_branch change depending on $_tag also.
Florian, I apologise if I'm stepping on your toes here; this is a feature I
would've written if I was better at Perl, so I want to see it included, and I'm
glad for your work on it.
Documentation/git-svn.txt | 24 ++++++++++++++++-
git-svn.perl | 46 +++++++++++++++++++++++++++++++-
t/t9128-git-svn-cmd-branch.sh | 59 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 127 insertions(+), 2 deletions(-)
create mode 100755 t/t9128-git-svn-cmd-branch.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1e644ca..0fe4955 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -149,6 +149,22 @@ and have no uncommitted changes.
is very strongly discouraged.
--
+'branch'::
+ Create a branch in the SVN repository.
+
+-m;;
+--message;;
+ Allows to specify the commit message.
+
+-t;;
+--tag;;
+ Create a tag by using the tags_subdir instead of the branches_subdir
+ specified during git svn init.
+
+'tag'::
+ Create a tag in the SVN repository. This is a shorthand for
+ 'branch -t'.
+
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
@@ -372,7 +388,8 @@ Passed directly to 'git-rebase' when using 'dcommit' if a
-n::
--dry-run::
-This can be used with the 'dcommit' and 'rebase' commands.
+This can be used with the 'dcommit', 'rebase', 'branch' and 'tag'
+commands.
For 'dcommit', print out the series of git arguments that would show
which diffs would be committed to SVN.
@@ -381,6 +398,9 @@ For 'rebase', display the local branch associated with the upstream svn
repository associated with the current branch and the URL of svn
repository that will be fetched from.
+For 'branch' and 'tag', display the urls that will be used for copying when
+creating the branch or tag.
+
--
ADVANCED OPTIONS
@@ -498,6 +518,8 @@ Tracking and contributing to an entire Subversion-managed project
git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
+# Create a new branch in SVN
+ git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
git reset --hard remotes/trunk
diff --git a/git-svn.perl b/git-svn.perl
index 80a5728..e7b9254 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url);
+ $_git_format, $_commit_url, $_tag);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -131,6 +131,15 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
+ branch => [ \&cmd_branch,
+ 'Create a branch in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run,
+ 'tag|t' => \$_tag } ],
+ tag => [ sub { $_tag = 1; cmd_branch(@_) },
+ 'Create a tag in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
@@ -537,6 +546,41 @@ sub cmd_dcommit {
unlink $gs->{index};
}
+sub cmd_branch {
+ my ($branch_name, $head) = @_;
+
+ die ($_tag ? "tag" : "branch") . " name required\n"
+ unless $branch_name;
+ $head ||= 'HEAD';
+
+ my ($src, $rev, undef, $gs) = working_head_info($head);
+
+ my $remote = Git::SVN::read_all_remotes()->{svn};
+ my $glob = $remote->{ $_tag ? 'tags' : 'branches' };
+ my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
+ my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
+
+ my $ctx = SVN::Client->new(
+ auth => Git::SVN::Ra::_auth_providers(),
+ log_msg => sub {
+ ${ $_[0] } = defined $_message
+ ? $_message
+ : 'Create ' . ($_tag ? 'tag ' : 'branch ' )
+ . $branch_name;
+ },
+ );
+
+ eval {
+ $ctx->ls($dst, 'HEAD', 0);
+ } and die "branch ${branch_name} already exists\n";
+
+ print "Copying ${src} at r${rev} to ${dst}...\n";
+ $ctx->copy($src, $rev, $dst)
+ unless $_dry_run;
+
+ $gs->fetch_all;
+}
+
sub cmd_find_rev {
my $revision_or_hash = shift or die "SVN or git revision required ",
"as a command-line argument\n";
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
new file mode 100755
index 0000000..47c4d4d
--- /dev/null
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Deskin Miller
+#
+
+test_description='git svn partial-rebuild tests'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize svnrepo' '
+ mkdir import &&
+ (
+ cd import &&
+ mkdir trunk branches tags &&
+ cd trunk &&
+ echo foo > foo &&
+ cd .. &&
+ svn import -m "import for git-svn" . "$svnrepo" >/dev/null &&
+ cd .. &&
+ rm -rf import &&
+ svn co "$svnrepo"/trunk trunk &&
+ cd trunk &&
+ echo bar >> foo &&
+ svn ci -m "updated trunk" &&
+ cd .. &&
+ rm -rf trunk
+ )
+'
+
+test_expect_success 'import into git' '
+ git svn init --stdlayout "$svnrepo" &&
+ git svn fetch &&
+ git checkout remotes/trunk
+'
+
+test_expect_success 'git svn branch tests' '
+ git svn branch a &&
+ base=$(git rev-parse HEAD:) &&
+ test $base = $(git rev-parse remotes/a:) &&
+ git svn branch -m "created branch b blah" b &&
+ test $base = $(git rev-parse remotes/b:) &&
+ test_must_fail git branch -m "no branchname" &&
+ git svn branch -n c &&
+ test_must_fail git rev-parse remotes/c &&
+ test_must_fail git svn branch a &&
+ git svn branch -t tag1 &&
+ test $base = $(git rev-parse remotes/tags/tag1:) &&
+ git svn branch --tag tag2 &&
+ test $base = $(git rev-parse remotes/tags/tag2:) &&
+ git svn tag tag3 &&
+ test $base = $(git rev-parse remotes/tags/tag3:) &&
+ git svn tag -m "created tag4 foo" tag4 &&
+ test $base = $(git rev-parse remotes/tags/tag4:) &&
+ test_must_fail git svn tag -m "no tagname" &&
+ git svn tag -n tag5 &&
+ test_must_fail git rev-parse remotes/tags/tag5 &&
+ test_must_fail git svn tag tag1
+'
+
+test_done
--
1.6.0.2.307.gc427
^ permalink raw reply related
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