* 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: 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: [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: [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: [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: 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: 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: 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 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
* 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: [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
* 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: 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: 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] 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] 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
* 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] 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
* [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
* [PATCH] Fix argument handling for fetch-pack call when stdout is connected and -q/--quiet is supplied.
From: Tuncer Ayaz @ 2008-10-03 19:34 UTC (permalink / raw)
To: git; +Cc: barkalow, davej
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);
args.depth = data->depth;
for (i = 0; i < nr_heads; i++)
--
1.6.0.2
^ permalink raw reply related
* Re: [xfs-masters] git://oss.sgi.com broke
From: Christoph Hellwig @ 2008-10-03 19:27 UTC (permalink / raw)
To: xfs-masters; +Cc: git
In-Reply-To: <20081003121903.6c9a7ebc.akpm@linux-foundation.org>
On Fri, Oct 03, 2008 at 12:19:03PM -0700, Andrew Morton wrote:
> It was OK yesterday.
>
> (cc'ing the git list in case this is an faq?)
>
> The last two error messages there look wrong/misleading?
Git pull still works fine for me..
^ permalink raw reply
* git://oss.sgi.com broke
From: Andrew Morton @ 2008-10-03 19:19 UTC (permalink / raw)
To: xfs-masters; +Cc: git
y:/usr/src/git26> git --version
git version 1.5.6.rc0
y:/usr/src/git26> cat .git/branches/git-xfs
git://oss.sgi.com:8090/xfs/xfs-2.6.git#master
y:/usr/src/git26> git-fetch git-xfs
remote: usage: git-pack-objects [{ -q | --progress | --all-progress }]
remote: [--max-pack-size=N] [--local] [--incremental]
remote: [--window=N] [-remote: -window-memory=N] [--depth=N]
remote: [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
remote: [--threads=N] [--non-empty] [--reremote: vs [--unpacked | --all]*] [--reflog]
remote: [--stdout | base-name] [--keep-unreachable] [<ref-list | <object-list]
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
It was OK yesterday.
(cc'ing the git list in case this is an faq?)
The last two error messages there look wrong/misleading?
^ permalink raw reply
* [PATCH v2 RFC] Fix interactive rebase on dropped commits.
From: Stephen Haberman @ 2008-10-03 18:32 UTC (permalink / raw)
To: git; +Cc: ae, spearce
In-Reply-To: <20081001011107.0971ce32.stephen@exigencecorp.com>
Interactive rebase got it's rev-list of commits to keep by --left-right and
--cherry-pick. Adding --cherry-pick would throw out commits that were just
duplicating changes already in the rebase target.
Which is cool, except the dropped commit was forgotten about when it came to
rewriting the parents of its descendents, so the descendents would get
cherry-picked as-in and essentially make the rebase a noop.
This change adds a $DOTEST/dropped directory to remember dropped commits and
rewrite its children's parents as the children's grandparents (possibly
rewritten).
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
This includes 3410, which borrows the 3404 DAG in a separate
test to do more a complex test of the dropped commits than my
previous test.
The implementation is also simpler--instead of following all
of a dropped commit's parents, we follow just the first. We can
trust rev-list is telling us to drop it for a reason, so only
the first-parent is needed so we can correctly rewrite commits
based on top of ours.
t3404 is still passing. (Finally.)
git-rebase--interactive.sh | 37 +++++++-
t/t3410-rebase-preserve-dropped-merges.sh | 140 +++++++++++++++++++++++++++++
2 files changed, 175 insertions(+), 2 deletions(-)
create mode 100644 t/t3410-rebase-preserve-dropped-merges.sh
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index edb6ec6..e8cb8a2 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -37,6 +37,7 @@ DONE="$DOTEST"/done
MSG="$DOTEST"/message
SQUASH_MSG="$DOTEST"/message-squash
REWRITTEN="$DOTEST"/rewritten
+DROPPED="$DOTEST"/dropped
PRESERVE_MERGES=
STRATEGY=
ONTO=
@@ -169,8 +170,12 @@ pick_one_preserving_merges () {
# rewrite parents; if none were rewritten, we can fast-forward.
new_parents=
- for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
+ pend=" $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)"
+ while [ "$pend" != "" ]
do
+ p=$(expr "$pend" : ' \([^ ]*\)')
+ pend="${pend# $p}"
+
if test -f "$REWRITTEN"/$p
then
new_p=$(cat "$REWRITTEN"/$p)
@@ -183,7 +188,13 @@ pick_one_preserving_merges () {
;;
esac
else
- new_parents="$new_parents $p"
+ if test -f "$DROPPED"/$p
+ then
+ fast_forward=f
+ pend="$pend $(cat "$DROPPED"/$p)"
+ else
+ new_parents="$new_parents $new_p"
+ fi
fi
done
case $fast_forward in
@@ -582,6 +593,28 @@ first and then run 'git rebase --continue' again."
#
EOF
+ # Watch for commits that been dropped by --cherry-pick
+ if test t = "$PRESERVE_MERGES"
+ then
+ mkdir "$DROPPED"
+ # drop the --cherry-pick parameter this time
+ git rev-list $MERGES_OPTION --abbrev-commit \
+ --abbrev=7 $UPSTREAM...$HEAD --left-right | \
+ sed -n "s/^>//p" | while read rev
+ do
+ grep --quiet "$rev" "$TODO"
+ if [ $? -ne 0 ]
+ then
+ # Use -f2 because if rev-list is telling this commit is not
+ # worthwhile, we don't want to track its multiple heads,
+ # just the history of its first-parent for others that will
+ # be rebasing on top of us
+ full=$(git rev-parse $rev)
+ git rev-list --parents -1 $rev | cut -d' ' -f2 > "$DROPPED"/$full
+ fi
+ done
+ fi
+
has_action "$TODO" ||
die_abort "Nothing to do"
diff --git a/t/t3410-rebase-preserve-dropped-merges.sh b/t/t3410-rebase-preserve-dropped-merges.sh
new file mode 100644
index 0000000..7c8862b
--- /dev/null
+++ b/t/t3410-rebase-preserve-dropped-merges.sh
@@ -0,0 +1,140 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Stephen Haberman
+#
+
+test_description='git rebase preserve merges
+
+This test runs git rebase with preserve merges and ensures commits
+dropped by the --cherry-pick flag have their childrens parents
+rewritten.
+'
+. ./test-lib.sh
+
+# set up two branches like this:
+#
+# A - B - C - D - E
+# \
+# F - G - H
+# \
+# I
+#
+# where B, D and G touch the same file.
+
+test_expect_success 'setup' '
+ : > file1 &&
+ git add file1 &&
+ test_tick &&
+ git commit -m A &&
+ git tag A &&
+ echo 1 > file1 &&
+ test_tick &&
+ git commit -m B file1 &&
+ : > file2 &&
+ git add file2 &&
+ test_tick &&
+ git commit -m C &&
+ echo 2 > file1 &&
+ test_tick &&
+ git commit -m D file1 &&
+ : > file3 &&
+ git add file3 &&
+ test_tick &&
+ git commit -m E &&
+ git tag E &&
+ git checkout -b branch1 A &&
+ : > file4 &&
+ git add file4 &&
+ test_tick &&
+ git commit -m F &&
+ git tag F &&
+ echo 3 > file1 &&
+ test_tick &&
+ git commit -m G file1 &&
+ git tag G &&
+ : > file5 &&
+ git add file5 &&
+ test_tick &&
+ git commit -m H &&
+ git tag H &&
+ git checkout -b branch2 F &&
+ : > file6 &&
+ git add file6 &&
+ test_tick &&
+ git commit -m I &&
+ git tag I
+'
+
+# A - B - C - D - E
+# \ \ \
+# F - G - H -- L \ --> L
+# \ | \
+# I -- G2 -- J -- K I -- K
+# G2 = same changes as G
+test_expect_success 'skip same-resolution merges with -p' '
+ git checkout branch1 &&
+ ! git merge E &&
+ echo 23 > file1 &&
+ git add file1 &&
+ git commit -m L &&
+ git checkout branch2 &&
+ echo 3 > file1 &&
+ git commit -a -m G2 &&
+ ! git merge E &&
+ echo 23 > file1 &&
+ git add file1 &&
+ git commit -m J &&
+ echo file7 > file7 &&
+ git add file7 &&
+ git commit -m K &&
+ GIT_EDITOR=: git rebase -i -p branch1 &&
+ test $(git rev-parse branch2^^) = $(git rev-parse branch1) &&
+ test "23" = "$(cat file1)" &&
+ test "" = "$(cat file6)" &&
+ test "file7" = "$(cat file7)" &&
+
+ git checkout branch1 &&
+ git reset --hard H &&
+ git checkout branch2 &&
+ git reset --hard I
+'
+
+# A - B - C - D - E
+# \ \ \
+# F - G - H -- L \ --> L
+# \ | \
+# I -- G2 -- J -- K I -- G2 -- K
+# G2 = different changes as G
+test_expect_success 'keep different-resolution merges with -p' '
+ git checkout branch1 &&
+ ! git merge E &&
+ echo 23 > file1 &&
+ git add file1 &&
+ git commit -m L &&
+ git checkout branch2 &&
+ echo 4 > file1 &&
+ git commit -a -m G2 &&
+ ! git merge E &&
+ echo 24 > file1 &&
+ git add file1 &&
+ git commit -m J &&
+ echo file7 > file7 &&
+ git add file7 &&
+ git commit -m K &&
+ ! GIT_EDITOR=: git rebase -i -p branch1 &&
+ echo 234 > file1 &&
+ git add file1 &&
+ GIT_EDITOR=: git rebase --continue &&
+ test $(git rev-parse branch2^^^) = $(git rev-parse branch1) &&
+ test "234" = "$(cat file1)" &&
+ test "" = "$(cat file6)" &&
+ test "file7" = "$(cat file7)" &&
+
+ git checkout branch1 &&
+ git reset --hard H &&
+ git checkout branch2 &&
+ git reset --hard I
+'
+
+test_done
+
--
1.6.0.2
^ permalink raw reply related
* Re: Numeric Revision Names?
From: Stephen Haberman @ 2008-10-03 17:42 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jakub Narebski, marceloribeiro, git
In-Reply-To: <200810031913.55594.trast@student.ethz.ch>
> You might as well use the commit (not author!) timestamp for that
> purpose (assuming your clocks are all synced).
True. Revision numbers are typically shorter though. E.g. we're on
~19,000 now, which is less digits than 20081003122101.
> They do not convey history membership, only history non-membership,
> for the same obvious reason that commit timestamps do.
I know--see my explicit disclaimer about false negatives in my previous
post.
I'll nit pick, revision numbers if put together with branch name, can
actually occassionally convey history membership (subject to false
negatives).
For example, our bug fix hook will say "hashX committed on topica as
r100" and so if qa is looking at a build that was built while on topica
at r105 (so labeled) "topica-r105") then it is very likely hashX is on
the box.
Okay, not with branch renames, but for all intents and purposes. Of
course, as you point out, topicb-r106 says nothing about the
availability of hashX, but that is a less common question for our qa
team than the first two. And they ask the question often enough during
the day that addressing the major 2 of the 3 cases helps cut down "hey
dev--I've got this hash..." calls.
Do not confuse my willingness to hack commit numbers into our git repo
(and my willingness to share our hack with the original poster) with
full fledged support of the concept. Hashes are superior, but, when
they work, revision numbers are nice too. I did not see a reason we
could not have both, especially if it made people more comfortable with
git.
(I also face/faced a situation where "monotonic revision numbers" were
essentially a check box item on a required list of SCM features, so
despite whatever I/the-git-team/etc. thought about their technical
inferiority, it was a criteria that could have ruled git out for us.
Hence my mentioning an FAQ entry for others faced with my same
political situation.)
- Stephen
^ permalink raw reply
* Re: Numeric Revision Names?
From: Jeff King @ 2008-10-03 17:37 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Jakub Narebski, marceloribeiro, git
In-Reply-To: <20081003171434.GC30592@coredump.intra.peff.net>
On Fri, Oct 03, 2008 at 01:14:34PM -0400, Jeff King wrote:
> If you are constraining yourself to a central repo, then you could just
> add a receive hook that tags each new commit with a monotonically
> increasing revision number. Clients would get the tags upon fetch.
Oh, nevermind. I'm an idiot and didn't bother reading to the end of your
post, where you clearly attached a hook that does exactly that.
Sorry for the noise.
-Peff
^ 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