* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Junio C Hamano @ 2010-01-31 19:21 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Jens Lehmann, Git Mailing List
In-Reply-To: <57518fd11001311116t1bde882dub1dd3ca4af201b2e@mail.gmail.com>
Jonathan del Strother <maillist@steelskies.com> writes:
>>> + strbuf_addf(&buf, "GIT_INDEX_FILE=");
>>
>> This should be:
>>
>> strbuf_addf(&buf, "GIT_INDEX_FILE");
>
> Sorry, I'm not sure I follow your amendment - it looks exactly like
> the patch you originally supplied?
Lack of the last "=" tells: "Instead of exporting GIT_INDEX_FILE with an
empty string as its value, unexport it."
^ permalink raw reply
* Re: [PATCH] bash: support user-supplied completion scripts for user's git commands
From: SZEDER Gábor @ 2010-01-31 19:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, David Rhodes Clymer, git
In-Reply-To: <20100129200431.GE22101@spearce.org>
On Fri, Jan 29, 2010 at 12:04:31PM -0800, Shawn O. Pearce wrote:
> SZEDER G?bor <szeder@ira.uka.de> wrote:
> >
> > _git_lgm () {
> > _git_log
> > }
> >
> > Unfortunately, it doesn't work at all.
> >
> > In _git() first we have 'lgm' in $command, which is ok, but then comes
> > this alias handling thing
> >
> > local expansion=$(__git_aliased_command "$command")
> > [ "$expansion" ] && command="$expansion"
> >
> > which writes '!sh' into $command, and that doesn't look quite right
>
> __git_aliased_command is returning the first word out of the alias.
Actually, it returns the first word from the alias which does not
start with a dash. It behaves this way since its introduction in
367dce2a (Bash completion support for aliases, 2006-10-28). I'm not
sure what the original intent was behind ignoring words starting with
a dash, but it gave me some ideas.
> I think we need to change this block here to:
>
> case "$expansion" of
> \!*) : leave command as alias ;;
> '') : leave command alone ;;
> *) command="$expansion" ;;
> esac
>
> Or something like that. Because an alias whose value starts with
> ! is a shell command to be executed, so we want to use _git_$command
> for completion, but other aliases are builtin commands and we should
> use their first word token (what __git_aliased_command returns)
> as the name of the completion function.
After pondering about it for a while, I think that in this case the
real issue is not _git() not handling __git_aliased_command()'s return
value corretly, but rather __git_aliased_command() returning junk in
case of a more advanced alias. And while fixing it up, we can also
improve on it to return the right command in some more cases, too.
Let's have an other look at Junio's alias:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
While it's clear that full parsing of something like that in the
completion code is unfeasible, we can easily get rid of stuff that is
definitely not a git command: !sh shell commands, options, and
environment variables.
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 45a393f..faddbdf 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -625,10 +625,15 @@ __git_aliased_command ()
local word cmdline=$(git --git-dir="$(__gitdir)" \
config --get "alias.$1")
for word in $cmdline; do
- if [ "${word##-*}" ]; then
- echo $word
+ case "$word" in
+ \!*) : shell command alias ;;
+ -*) : option ;;
+ *=*) : setting env ;;
+ git) : git itself ;;
+ *)
+ echo "$word"
return
- fi
+ esac
done
}
and this way it would correctly return 'log' for Junio's 'lgm' alias.
With a bit tweaking we could also extend it to handle !gitk aliases,
too.
Of course, it isn't perfect either, and could be fooled easily. It's
not hard to construct an alias, in which a word does not match any of
these filter patterns, but is still not a git command (e.g. by
setting an environment variable to a value which contains spaces). It
may even return false positives, when the output of a git command is
piped into an other git command, and the second gets the command line
options via $@, but the first command will be returned. However, such
problematic cases could be handled by a custom completion function
provided by the user.
What do you think?
Best,
Gábor
^ permalink raw reply related
* Re: [RFH] rpm packaging failure
From: Junio C Hamano @ 2010-01-31 19:18 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git, Johan Herland, Sverre Rabbelier
In-Reply-To: <20100131041236.GP29188@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> It is probably better to use %global rather than %define here.
Thanks; will fix.
^ permalink raw reply
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Jonathan del Strother @ 2010-01-31 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, Git Mailing List
In-Reply-To: <7vvdejmjaj.fsf@alter.siamese.dyndns.org>
On 30 January 2010 20:25, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Please try this.
>
> oops, but with this, too.
>
>> diff --git a/submodule.c b/submodule.c
>> index ca0527f..8bd0a30 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> ...
>> @@ -142,7 +142,9 @@ int is_submodule_modified(const char *path)
>> env[0] = strbuf_detach(&buf, NULL);
>> strbuf_addf(&buf, "GIT_DIR=%s/.git", path);
>> env[1] = strbuf_detach(&buf, NULL);
>> - env[2] = NULL;
>> + strbuf_addf(&buf, "GIT_INDEX_FILE=");
>
> This should be:
>
> strbuf_addf(&buf, "GIT_INDEX_FILE");
>
>> + env[2] = strbuf_detach(&buf, NULL);
>> + env[3] = NULL;
>>
>> memset(&cp, 0, sizeof(cp));
>> cp.argv = argv;
>
Sorry, I'm not sure I follow your amendment - it looks exactly like
the patch you originally supplied?
With that original patch applied, I no longer get the 'unable to find'
errors on stashing. However, git-status shows all my submodules as
being modified, but there appear to be no local changes :
[jon@gir:Developer/AudioBooWeb]$ git status
# On branch giterror
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: shared/vendor/plugins/acts_as_list
# modified: shared/vendor/plugins/cucumber
# modified: shared/vendor/plugins/delayed_job
# modified: shared/vendor/plugins/haml
# modified: shared/vendor/plugins/hoptoad_notifier
# modified: shared/vendor/plugins/machinist
# modified: shared/vendor/plugins/newrelic_rpm
# modified: shared/vendor/plugins/rspec
# modified: shared/vendor/plugins/rspec-rails
# modified: shared/vendor/rails
#
no changes added to commit (use "git add" and/or "git commit -a")
[jon@gir:Developer/AudioBooWeb]$ git diff
diff --git a/shared/vendor/plugins/acts_as_list
b/shared/vendor/plugins/acts_as_list
diff --git a/shared/vendor/plugins/cucumber b/shared/vendor/plugins/cucumber
diff --git a/shared/vendor/plugins/delayed_job
b/shared/vendor/plugins/delayed_job
diff --git a/shared/vendor/plugins/haml b/shared/vendor/plugins/haml
diff --git a/shared/vendor/plugins/hoptoad_notifier
b/shared/vendor/plugins/hoptoad_notifier
diff --git a/shared/vendor/plugins/machinist b/shared/vendor/plugins/machinist
diff --git a/shared/vendor/plugins/newrelic_rpm
b/shared/vendor/plugins/newrelic_rpm
diff --git a/shared/vendor/plugins/rspec b/shared/vendor/plugins/rspec
diff --git a/shared/vendor/plugins/rspec-rails
b/shared/vendor/plugins/rspec-rails
diff --git a/shared/vendor/rails b/shared/vendor/rails
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Junio C Hamano @ 2010-01-31 18:28 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq3a1maa4y.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I suggest s/pathspec/argument/ in the sentence above:
>
> * "git status" is not "git commit --dry-run" anymore. This change does
> not affect you if you run the command without argument.
Thanks; that makes sense.
^ permalink raw reply
* [PATCH] Fix memory leak in submodule.c
From: Jens Lehmann @ 2010-01-31 16:43 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
The strbuf used in add_submodule_odb() was never released. So for every
submodule - populated or not - we leaked its object directory name when
using "git diff*" with the --submodule option.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
submodule.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/submodule.c b/submodule.c
index 6f7c210..7d70c4f 100644
--- a/submodule.c
+++ b/submodule.c
@@ -10,17 +10,19 @@ static int add_submodule_odb(const char *path)
{
struct strbuf objects_directory = STRBUF_INIT;
struct alternate_object_database *alt_odb;
+ int ret = 0;
strbuf_addf(&objects_directory, "%s/.git/objects/", path);
- if (!is_directory(objects_directory.buf))
- return -1;
-
+ if (!is_directory(objects_directory.buf)) {
+ ret = -1;
+ goto done;
+ }
/* avoid adding it twice */
for (alt_odb = alt_odb_list; alt_odb; alt_odb = alt_odb->next)
if (alt_odb->name - alt_odb->base == objects_directory.len &&
!strncmp(alt_odb->base, objects_directory.buf,
objects_directory.len))
- return 0;
+ goto done;
alt_odb = xmalloc(objects_directory.len + 42 + sizeof(*alt_odb));
alt_odb->next = alt_odb_list;
@@ -31,7 +33,9 @@ static int add_submodule_odb(const char *path)
alt_odb->name[41] = '\0';
alt_odb_list = alt_odb;
prepare_alt_odb();
- return 0;
+done:
+ strbuf_release(&objects_directory);
+ return ret;
}
void show_submodule_summary(FILE *f, const char *path,
--
1.7.0.rc1.141.gd3fd.dirty
^ permalink raw reply related
* Re: [PATCH] Fix typos in technical documentation.
From: Matthieu Moy @ 2010-01-31 14:52 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20100131132438.GD23605@gmx.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> Hi there,
>
> stumbled upon a couple of these, then grepped for the rest
> in Documentation/.
Nice catches!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] cvsimport: new -R option: generate revision-to-commit mapping
From: Jeff King @ 2010-01-31 13:24 UTC (permalink / raw)
To: Aaron Crane; +Cc: git
In-Reply-To: <bc341e101001310443x18e02281i2e4d18334ead700b@mail.gmail.com>
On Sun, Jan 31, 2010 at 12:43:44PM +0000, Aaron Crane wrote:
> Signed-off-by: Aaron Crane <git@aaroncrane.co.uk>
> ---
Please put a bit of the rationale into the commit message. Even a
sentence or two can help later on when somebody is reading the output of
"git log".
> Documentation/git-cvsimport.txt | 15 ++++++++++++++-
> git-cvsimport.perl | 20 ++++++++++++++++----
> 2 files changed, 30 insertions(+), 5 deletions(-)
A basic test would be nice. You should be able to just use your new "-R"
during the import in t9600, and then check that it generated the correct
mapping.
> +-R <revision-to-commit-file>::
> + Generate a file containing a mapping from CVS revision numbers to
> + newly-created Git commit IDs. The generated file will contain one
> + line for each (filename, revision) pair found by 'cvsps'; each line
> + will look like
Is mentioning 'cvsps' right here? cvsps doesn't know about git commit
id's.
> +open my $revision_map, '>', $opt_R
> + or die "Can't open -R file $opt_R: $!\n"
> + if defined $opt_R;
You need to use munge_user_filename here to handle relative paths. See
commit f6fdbb6.
Also, should you perhaps be appending to the file instead of truncating
it? Remember that cvsimport can be used incrementally. I wonder if it
would be better to simply have "-R" without an argument to append the
revision map to a file .git/cvs-revisions or something. And then the
user can easily pull it from there after the import.
-Peff
^ permalink raw reply
* [PATCH] Fix typos in technical documentation.
From: Ralf Wildenhues @ 2010-01-31 13:24 UTC (permalink / raw)
To: git
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Hi there,
stumbled upon a couple of these, then grepped for the rest
in Documentation/.
Cheers, and thanks for git,
Ralf
Documentation/diff-format.txt | 2 +-
Documentation/git-bisect-lk2009.txt | 2 +-
Documentation/git-fast-export.txt | 2 +-
Documentation/git-fast-import.txt | 8 ++++----
Documentation/git-http-backend.txt | 2 +-
Documentation/git-remote-helpers.txt | 2 +-
Documentation/git-rev-parse.txt | 2 +-
Documentation/git-submodule.txt | 2 +-
Documentation/rev-list-options.txt | 8 ++++----
Documentation/technical/api-run-command.txt | 2 +-
Documentation/technical/pack-protocol.txt | 10 +++++-----
Documentation/technical/protocol-capabilities.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
13 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index b717124..15c7e79 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -19,7 +19,7 @@ git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
git-diff-files [<pattern>...]::
compares the index and the files on the filesystem.
-The "git-diff-tree" command begins its ouput by printing the hash of
+The "git-diff-tree" command begins its output by printing the hash of
what is being compared. After that, all the commands print one output
line per changed file.
diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index 6b7b2e5..86b3015 100644
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -799,7 +799,7 @@ fixed in the "main" branch by commit "F"?
The result of such a bisection would be that we would find that H is
the first bad commit, when in fact it's B. So that would be wrong!
-And yes it's can happen in practice that people working on one branch
+And yes it can happen in practice that people working on one branch
are not aware that people working on another branch fixed a bug! It
could also happen that F fixed more than one bug or that it is a
revert of some big development effort that was not ready to be
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index c24e14b..98ec6b5 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -37,7 +37,7 @@ unsigned, with 'verbatim', they will be silently exported
and with 'warn', they will be exported, but you will see a warning.
--tag-of-filtered-object=(abort|drop|rewrite)::
- Specify how to handle tags whose tagged objectis filtered out.
+ Specify how to handle tags whose tagged object is filtered out.
Since revisions and files to export can be limited by path,
tagged objects may be filtered completely.
+
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index ff4022c..fa7d2fe 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -152,7 +152,7 @@ fast-forward update, fast-import will skip updating that ref and instead
prints a warning message. fast-import will always attempt to update all
branch refs, and does not stop on the first failure.
-Branch updates can be forced with \--force, but its recommended that
+Branch updates can be forced with \--force, but it's recommended that
this only be used on an otherwise quiet repository. Using \--force
is not necessary for an initial import into an empty repository.
@@ -267,7 +267,7 @@ is always copied into the identity string at the time it is being
created by fast-import. There is no way to specify a different time or
timezone.
+
-This particular format is supplied as its short to implement and
+This particular format is supplied as it's short to implement and
may be useful to a process that wants to create a new commit
right now, without needing to use a working directory or
'git update-index'.
@@ -420,7 +420,7 @@ quoting or escaping syntax is supported within `<committish>`.
Here `<committish>` is any of the following:
* The name of an existing branch already in fast-import's internal branch
- table. If fast-import doesn't know the name, its treated as a SHA-1
+ table. If fast-import doesn't know the name, it's treated as a SHA-1
expression.
* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
@@ -759,7 +759,7 @@ assigned mark.
The mark command is optional here as some frontends have chosen
to generate the Git SHA-1 for the blob on their own, and feed that
-directly to `commit`. This is typically more work than its worth
+directly to `commit`. This is typically more work than it's worth
however, as marks are inexpensive to store and easy to use.
`data`
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 07931c6..5238820 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -14,7 +14,7 @@ DESCRIPTION
-----------
A simple CGI program to serve the contents of a Git repository to Git
clients accessing the repository over http:// and https:// protocols.
-The program supports clients fetching using both the smart HTTP protcol
+The program supports clients fetching using both the smart HTTP protocol
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol.
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 4685a89..1b5f61a 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -25,7 +25,7 @@ Commands are given by the caller on the helper's standard input, one per line.
'capabilities'::
Lists the capabilities of the helper, one per line, ending
- with a blank line. Each capability may be preceeded with '*'.
+ with a blank line. Each capability may be preceded with '*'.
This marks them mandatory for git version using the remote
helper to understand (unknown mandatory capability is fatal
error).
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index e7845d4..fc73152 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -33,7 +33,7 @@ OPTIONS
--stop-at-non-option::
Only meaningful in `--parseopt` mode. Lets the option parser stop at
the first non-option argument. This can be used to parse sub-commands
- that take options themself.
+ that take options themselves.
--sq-quote::
Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 63aa694..2502531 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -218,7 +218,7 @@ OPTIONS
This option is only valid for the update command.
Rebase the current branch onto the commit recorded in the
superproject. If this option is given, the submodule's HEAD will not
- be detached. If a a merge failure prevents this process, you will have
+ be detached. If a merge failure prevents this process, you will have
to resolve these failures with linkgit:git-rebase[1].
If the key `submodule.$name.update` is set to `rebase`, this option is
implicit.
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 3ef7117..6e9baf8 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -233,27 +233,27 @@ endif::git-rev-list[]
Pretend as if all the refs in `$GIT_DIR/refs/heads` are listed
on the command line as '<commit>'. If `pattern` is given, limit
branches to ones matching given shell glob. If pattern lacks '?',
- '*', or '[', '/*' at the end is impiled.
+ '*', or '[', '/*' at the end is implied.
--tags[=pattern]::
Pretend as if all the refs in `$GIT_DIR/refs/tags` are listed
on the command line as '<commit>'. If `pattern` is given, limit
tags to ones matching given shell glob. If pattern lacks '?', '*',
- or '[', '/*' at the end is impiled.
+ or '[', '/*' at the end is implied.
--remotes[=pattern]::
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
on the command line as '<commit>'. If `pattern`is given, limit
remote tracking branches to ones matching given shell glob.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
+ If pattern lacks '?', '*', or '[', '/*' at the end is implied.
--glob=glob-pattern::
Pretend as if all the refs matching shell glob `glob-pattern`
are listed on the command line as '<commit>'. Leading 'refs/',
is automatically prepended if missing. If pattern lacks '?', '*',
- or '[', '/*' at the end is impiled.
+ or '[', '/*' at the end is implied.
ifndef::git-rev-list[]
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
index b26c281..68bf4ca 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -51,7 +51,7 @@ The functions above do the following:
ENOENT; a diagnostic is printed only if .silent_exec_failure is 0.
. Otherwise, the program is run. If it terminates regularly, its exit
- code is returned. No diagnistic is printed, even if the exit code is
+ code is returned. No diagnostic is printed, even if the exit code is
non-zero.
. If the program terminated due to a signal, then the return value is the
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 7950eee..9a5cdaf 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -149,7 +149,7 @@ advertisement list at all, but other refs may still appear.
The stream MUST include capability declarations behind a NUL on the
first ref. The peeled value of a ref (that is "ref^{}") MUST be
immediately after the ref itself, if presented. A conforming server
-MUST peel the ref if its an annotated tag.
+MUST peel the ref if it's an annotated tag.
----
advertised-refs = (no-refs / list-of-refs)
@@ -261,7 +261,7 @@ Without either multi_ack or multi_ack_detailed:
* upload-pack sends "NAK" on a flush-pkt if no common object
has been found yet. If one has been found, and thus an ACK
- was already sent, its silent on the flush-pkt.
+ was already sent, it's silent on the flush-pkt.
After the client has gotten enough ACK responses that it can determine
that the server has enough information to send an efficient packfile
@@ -271,9 +271,9 @@ as common with the server, or the --date-order queue is empty), or the
client determines that it wants to give up (in the canonical implementation,
this is determined when the client sends 256 'have' lines without getting
any of them ACKed by the server - meaning there is nothing in common and
-the server should just send all it's objects), then the client will send
+the server should just send all of its objects), then the client will send
a 'done' command. The 'done' command signals to the server that the client
-is ready to receive it's packfile data.
+is ready to receive its packfile data.
However, the 256 limit *only* turns on in the canonical client
implementation if we have received at least one "ACK %s continue"
@@ -286,7 +286,7 @@ ACK after 'done' if there is at least one common base and multi_ack or
multi_ack_detailed is enabled. The server always sends NAK after 'done'
if there is no common base found.
-Then the server will start sending it's packfile data.
+Then the server will start sending its packfile data.
----
server-response = *ack_multi ack / nak
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index 1892d3e..fd1a593 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -60,7 +60,7 @@ doesn't, as in the following diagram:
If the client wants x,y and starts out by saying have F,S, the server
doesn't know what F,S is. Eventually the client says "have d" and
the server sends "ACK d continue" to let the client know to stop
-walking down that line (so don't send c-b-a), but its not done yet,
+walking down that line (so don't send c-b-a), but it's not done yet,
it needs a base for x. The client keeps going with S-R-Q, until a
gets reached, at which point the server has a clear base and it all
ends.
@@ -181,7 +181,7 @@ delete-refs
-----------
If the server sends back the 'delete-refs' capability, it means that
-it is capable of accepting an zero-id value as the target
+it is capable of accepting a zero-id value as the target
value of a reference update. It is not sent back by the client, it
simply informs the client that it can be sent zero-id values
to delete references.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index b169836..517daca 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1196,7 +1196,7 @@ the time, you will want to commit your changes before you can merge,
and if you don't, then linkgit:git-stash[1] can take these changes
away while you're doing the merge, and reapply them afterwards.
-If the changes are independant enough, Git will automatically complete
+If the changes are independent enough, Git will automatically complete
the merge and commit the result (or reuse an existing commit in case
of <<fast-forwards,fast-forward>>, see below). On the other hand,
if there are conflicts--for example, if the same file is
--
1.7.0.rc1.1.g28185
^ permalink raw reply related
* [PATCH] cvsimport: new -R option: generate revision-to-commit mapping
From: Aaron Crane @ 2010-01-31 12:43 UTC (permalink / raw)
To: git
Signed-off-by: Aaron Crane <git@aaroncrane.co.uk>
---
See also the thread beginning at
http://thread.gmane.org/gmane.comp.version-control.git/138079
This is my first Git submission, so I'd welcome any comments, especially
if there's something wrong with the way I'm sending this.
Documentation/git-cvsimport.txt | 15 ++++++++++++++-
git-cvsimport.perl | 20 ++++++++++++++++----
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index ddfcb3d..19e8c9f 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
- [-r <remote>] [<CVS_module>]
+ [-r <remote>] [-R <revision-to-commit-file>] [<CVS_module>]
DESCRIPTION
@@ -157,6 +157,19 @@ It is not recommended to use this feature if you intend to
export changes back to CVS again later with
'git cvsexportcommit'.
+-R <revision-to-commit-file>::
+ Generate a file containing a mapping from CVS revision numbers to
+ newly-created Git commit IDs. The generated file will contain one
+ line for each (filename, revision) pair found by 'cvsps'; each line
+ will look like
++
+---------
+src/widget.c 1.1 1d862f173cdc7325b6fa6d2ae1cfd61fd1b512b7
+---------
++
+This option may be useful if you have CVS revision numbers stored in commit
+messages, bug-tracking systems, email archives, and the like.
+
-h::
Print a short usage message and exit.
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 4853bf7..8ef89c6 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,7 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r);
+our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -40,7 +40,7 @@ Usage: git cvsimport # fetch/update GIT from CVS
[-o branch-for-HEAD] [-h] [-v] [-d CVSROOT] [-A author-conv-file]
[-p opts-for-cvsps] [-P file] [-C GIT_repository] [-z fuzz] [-i] [-k]
[-u] [-s subst] [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
- [-r remote] [CVS_module]
+ [-r remote] [-R revision-to-commit-file] [CVS_module]
END
exit(1);
}
@@ -110,7 +110,7 @@ sub read_repo_config {
}
}
-my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
+my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:R:";
read_repo_config($opts);
Getopt::Long::Configure( 'no_ignore_case', 'bundling' );
@@ -175,6 +175,10 @@ if (@opt_M) {
push (@mergerx, map { qr/$_/ } @opt_M);
}
+open my $revision_map, '>', $opt_R
+ or die "Can't open -R file $opt_R: $!\n"
+ if defined $opt_R;
+
# Remember UTC of our starting time
# we'll want to avoid importing commits
# that are too recent
@@ -742,7 +746,7 @@ sub write_tree () {
}
my ($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
-my (@old,@new,@skipped,%ignorebranch);
+my (@old,@new,@skipped,%ignorebranch,@commit_revisions);
# commits that cvsps cannot place anywhere...
$ignorebranch{'#CVSPS_NO_BRANCH'} = 1;
@@ -825,6 +829,11 @@ sub commit {
system('git' , 'update-ref', "$remote/$branch", $cid) == 0
or die "Cannot write branch $branch for update: $!\n";
+ if ($revision_map) {
+ print $revision_map "@$_ $cid\n" for @commit_revisions;
+ }
+ @commit_revisions = ();
+
if ($tag) {
my ($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
@@ -959,6 +968,7 @@ while (<CVS>) {
push(@skipped, $fn);
next;
}
+ push @commit_revisions, [$fn, $rev];
print "Fetching $fn v $rev\n" if $opt_v;
my ($tmpname, $size) = $cvs->file($fn,$rev);
if ($size == -1) {
@@ -981,7 +991,9 @@ while (<CVS>) {
unlink($tmpname);
} elsif ($state == 9 and
/^\s+(.+?):\d+(?:\.\d+)+->(\d+(?:\.\d+)+)\(DEAD\)\s*$/) {
my $fn = $1;
+ my $rev = $2;
$fn =~ s#^/+##;
+ push @commit_revisions, [$fn, $rev];
push(@old,$fn);
print "Delete $fn\n" if $opt_v;
} elsif ($state == 9 and /^\s*$/) {
--
1.6.6.1
^ permalink raw reply related
* git-svn and subversion revprops
From: Eli Barzilay @ 2010-01-31 11:39 UTC (permalink / raw)
To: git; +Cc: Eric Wong
[This is possible an RTFM -- but as much as I've been digging around,
I couldn't find anything about it.]
I'm trying to play with git-svn in a project that uses subversion, and
there's one feature that I'd like to have -- make git-svn specify some
revision properties (eg, the `--with-revprop' to `svn commit') that
will identify it as coming from git-svn.
The thing is that we have a continuous build server that runs a
complete build (and runs all tests) for every revision -- and I'm
trying to figure out a way to make it skip intermediate commits that
come from a git-svn. The simplest way to do that would be a way to
mark all git-svn revisions somehow, and I can later unmark the last
one in the chain so only that one will get built and tested. It would
be even more convenient if I have a way to control the revprops on the
last commit separately, so there's no additional step involved.
The only other alternative that I see is some wrapper around git-svn
that connects to some script that will run on the server before and
after dcommitting changes, and that script will do the necessary work.
Is there a way to specify hook scripts to run around a dcommit?
Actually, such hooks can also be used to lock the svn reposity while
git-svn is working -- I couldn't figure out what happens when there's
some commit that comes in while git-svn is running. My guess is
that it'll either get stuck and throw an error, or maybe try to
continue if possible. Such hooks could make that part more robust, as
well as guarantee that each batch of svn-git commits are always
together.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Tay Ray Chuan @ 2010-01-31 12:04 UTC (permalink / raw)
To: Larry D'Anna
Cc: git, Junio C Hamano, Ilari Liusvaara, Daniel Barkalow,
Shawn O. Pearce
In-Reply-To: <20100130020548.GA29343@cthulhu>
Hi,
On Sat, Jan 30, 2010 at 10:05 AM, Larry D'Anna <larry@elder-gods.org> wrote:
> --summary will cause git-push to output a one-line of each commit pushed.
> --summary=n will display at most n commits for each ref pushed.
>
> $ git push --dry-run --summary origin :
> To /home/larry/gitsandbox/a
> 80f0e50..5593a38 master -> master
> > 5593a38 foo
> > 81c03f8 bar
>
> Fetch works the same way.
I'm sorry for being late to this discussion; I see the time and work
you've put in this and all the previous revisions. But I do have an
objection to implementing this behaviour using the option --summary,
on the grounds of UI-consistency.
I believe git users are already familiar with --summary in git-diff
and git-log, and it might confuse them when the output of --summary
for git-push and git-fetch looks different.
Also, I wonder what is the motivation behind displaying this
information. Perhaps you are including this to produce output for an
IDE? If this is included upstream, then I believe this is the first
instance of such verbose information being displayed. Even a
fast-forward merge (the closest I can think of that matches this)
doesn't show this - I still have to do git log rev1^..rev2 to see.the
intervening revisions (inclusive).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Jakub Narebski @ 2010-01-31 11:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: J.H., git, John 'Warthog9' Hawley
In-Reply-To: <20100128173950.GH9553@machine.or.cz>
On Thu, Jan 28, 2010, Petr Baudis wrote:
> On Mon, Jan 25, 2010 at 12:32:37PM -0800, J.H. wrote:
> > This does 2 things in the end:
> >
> > 1) means there's only 1 copy of the page ever being generated, thus
> > meaning there isn't extraneous and dangerous disk i/o going on on the system
>
> But this has nothing to do with what you _do_ when there are multiple
> requests, whether you do the same as if caching was disabled (hang until
> content is generated) or doing something novel (creating redirects
> through "Generating..." page).
>
> > 2) prevents a user from reporting to the website that it's broken by
> > giving them a visual que that things aren't broken.
>
> But this has nothing to do with caching per se, right? I think it
> actually makes _no difference_ if caching is enabled or not to this
> problem, or am I missing something?
>
>
> My point is, I guess, that showing the Generating page doesn't seem to
> have actually anything to do with the caching itself?
The point is that without caching it is easy to streaming response, and
to consider early parts of page (like page header, generated before any
heavy work) to serve as activity indicator.
With caching it is difficult to have streaming response, both from
technical point of view (writer must generate to client and to cache
simultaneously, readers must know when writer finished work to close
connection), and from robustness point of view (what happens if writer
is interrupted / killed before finishing generating output). With
"generate then display" (which is not exclusive to caching, and is
another possible way of generating content even without caching) we
rather need some kind of activity indicator like "Generating..." page.
I think that "Generating..." page can be improved in two ways:
* Show "Generating..." page only if we are waiting for response for
more than one second. This might need mucking with alarms, as I think
that sleep 1 before $self->generating_info(...) would be not a good
solution.
* Stream response (using PerlIO::tee layer from PerlIO::Util, or
Capture::Tiny module, or tied filehandle like in CGI::Cache) for
writer (i.e. process generating data), and wait for it to be finished
(perhaps with "Generating...") in readers. This way you wouldn't get
"Generating..." page for rare views/URLs, and for common views/URLs
there is high probability that you would not need "Generating..."
page as there would be slightly stale response to serve.
Of course one can implement _both_ of those solutions, i.e. wait one
seconds in readers, and stream in writer.
I am not sure, but there might be another issue why activity indicator
is more important for the case with caching enabled. If you interrupt
writer, one of readers waiting for finished data would have to take
role of writer, which besides need for technical solution to this problem
would mean longer wait.
[..]
> > > (ii) Can't the locked gitwebs do the equivalent of tail -f?
> >
> > Not really going to help much, most of the gitweb operations won't
> > output much of anything beyond the header until it's collected all of
> > the data it needs anyway and then there will be a flurry of output. It
> > also means that this 'Generating...' page will only work for caching
> > schemes that tail can read out of, which I'm not sure it would work all
> > that well with things like memcached or a non-custom caching layer where
> > we don't necessarily have direct access to the file being written to.
> >
> > At least the way I had it (and I'll admit I haven't read through Jakub's
> > re-working of my patches so I don't know if it's still there) is that
> > with background caching you only get the 'Generating...' page if it's
> > new or the content is grossly out of data. If it's a popular page and
> > it's not grossly out of date it shows you the 'stale' data while it
> > generates the new content in the background anyway, only locking you out
> > when the new file is being written. Or at least that's how I had it.
>
> Well, my user experience with gitweb on kernel.org is that I get
> "Generating..." page all the time when I dive deep enough to the object
> tree. I just find it really distracting and sometimes troublesome when
> I want to wget some final object.
First, the user_agent checking would help there (it's a pity that all
web spiders (bots) and all non-interactive downloaders do not say what
they are explicitly in User-Agent string).
Second, I guess that waiting 1 second (or more) before showing
"Generating..." page would help in most cases.
>
> I think it's fine to take in the caching support with the Generating...
> page in the bundle, but I do want to declare my intention to get rid of
> it later, at least for caching backends that could do without it - for
> pages where content appears incrementally, tail -f, for pages where
> content appears all at once, show at least the header and some "I'm
> busy" notification without redirects.
In the final version this should be fully configurable. Note that
the series of patches I have send were just proof of concept for
splitting caching patch into smaller parts / individual features.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Matthieu Moy @ 2010-01-31 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaavvi4r5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * "git status" is not "git commit --dry-run" anymore. This change does
> not affect you if you run the command without pathspec.
This is not exactly true, since the list of command line options of
the new "status" are different. For example, the change affect people
who've been taught to always use "git commit" and "git status" with
-a.
I suggest s/pathspec/argument/ in the sentence above:
* "git status" is not "git commit --dry-run" anymore. This change does
not affect you if you run the command without argument.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Jeff King @ 2010-01-31 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wbeg0qp.fsf@alter.siamese.dyndns.org>
On Sun, Jan 31, 2010 at 12:03:10AM -0800, Junio C Hamano wrote:
> Perhaps. A patch with nice description, please?
How about this? We could also drop it from the "bells and whistles"
section; I don't have a preference.
-- >8 --
Subject: [PATCH] mention new shell execution behavior in release notes
This is already in the "bells and whistles" section, but it
also has a slight chance of breakage, so let's also mention
it in the "changed behaviors" section.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/RelNotes-1.7.0.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/RelNotes-1.7.0.txt b/Documentation/RelNotes-1.7.0.txt
index 997b026..f33e85d 100644
--- a/Documentation/RelNotes-1.7.0.txt
+++ b/Documentation/RelNotes-1.7.0.txt
@@ -38,6 +38,13 @@ Notes on behaviour change
whitespaces is reported with zero exit status when run with
--exit-code, and there is no "diff --git" header for such a change.
+ * external diff and textconv helpers are now executed using the shell.
+ This makes them consistent with other programs executed by git, and
+ allows you to pass command-line parameters to the helpers. Any helper
+ paths containing spaces or other metacharacters now need to be
+ shell-quoted. The affected helpers are GIT_EXTERNAL_DIFF in the
+ environment, and diff.*.command and diff.*.textconv in the config
+ file.
Updates since v1.6.6
--------------------
--
1.7.0.rc1.8.g1a26
^ permalink raw reply related
* [PATCH v2] Do not install shell libraries executable
From: Jonathan Nieder @ 2010-01-31 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, David Aguilar, git
In-Reply-To: <7vhbq2g3a9.fsf@alter.siamese.dyndns.org>
Some scripts are expected to be sourced instead of executed on
their own. Avoid some confusion by not marking them executable.
The executable bit was confusing the valgrind support of our test
scripts, which assumed that any executable without a #!-line
should be intercepted and run through valgrind. So during
valgrind-enabled tests, any script sourcing these files actually
sourced the valgrind interception script instead.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Can't you do something about this repetition from existing $(SCRIPT_SH)
> munging?
Sorry about that.
Last time I also missed git-parse-remote, so while at it, I am taking
the opportunity to add that to SCRIPT_LIB_SH, too.
Good night,
Jonathan
Makefile | 39 +++++++++++++++++++++++++--------------
1 files changed, 25 insertions(+), 14 deletions(-)
mode change 100755 => 100644 git-parse-remote.sh
mode change 100755 => 100644 git-sh-setup.sh
diff --git a/Makefile b/Makefile
index fd7f51e..ce42d93 100644
--- a/Makefile
+++ b/Makefile
@@ -342,6 +342,7 @@ LIB_OBJS =
PROGRAMS =
SCRIPT_PERL =
SCRIPT_SH =
+SCRIPT_LIB_SH =
TEST_PROGRAMS =
SCRIPT_SH += git-am.sh
@@ -353,20 +354,21 @@ SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-mergetool.sh
-SCRIPT_SH += git-mergetool--lib.sh
SCRIPT_SH += git-notes.sh
-SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
SCRIPT_SH += git-rebase--interactive.sh
SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
-SCRIPT_SH += git-sh-setup.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
+SCRIPT_LIB_SH += git-mergetool--lib.sh
+SCRIPT_LIB_SH += git-parse-remote.sh
+SCRIPT_LIB_SH += git-sh-setup.sh
+
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-difftool.perl
SCRIPT_PERL += git-archimport.perl
@@ -1428,7 +1430,7 @@ export TAR INSTALL DESTDIR SHELL_PATH
SHELL = $(SHELL_PATH)
-all:: shell_compatibility_test $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS) GIT-BUILD-OPTIONS
+all:: shell_compatibility_test $(ALL_PROGRAMS) $(SCRIPT_LIB_SH) $(BUILT_INS) $(OTHER_PROGRAMS) GIT-BUILD-OPTIONS
ifneq (,$X)
$(QUIET_BUILT_IN)$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), test -d '$p' -o '$p' -ef '$p$X' || $(RM) '$p';)
endif
@@ -1477,17 +1479,25 @@ common-cmds.h: ./generate-cmdlist.sh command-list.txt
common-cmds.h: $(wildcard Documentation/git-*.txt)
$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
+define cmd_munge_script
+$(RM) $@ $@+ && \
+sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|@SHELL_PATH@|$(SHELL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e $(BROKEN_PATH_FIX) \
+ $@.sh >$@+
+endef
+
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- $(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
- -e 's|@SHELL_PATH@|$(SHELL_PATH_SQ)|' \
- -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
- -e $(BROKEN_PATH_FIX) \
- $@.sh >$@+ && \
+ $(QUIET_GEN)$(cmd_munge_script) && \
chmod +x $@+ && \
mv $@+ $@
+$(patsubst %.sh,%,$(SCRIPT_LIB_SH)) : % : %.sh
+ $(QUIET_GEN)$(cmd_munge_script) && \
+ mv $@+ $@
+
ifndef NO_PERL
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
@@ -1792,6 +1802,7 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) -m 644 $(SCRIPT_LIB_SH) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_PERL
@@ -1901,7 +1912,7 @@ distclean: clean
clean:
$(RM) *.o block-sha1/*.o ppc/*.o compat/*.o compat/*/*.o xdiff/*.o \
$(LIB_FILE) $(XDIFF_LIB)
- $(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
+ $(RM) $(ALL_PROGRAMS) $(SCRIPT_LIB_SH) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
@@ -1930,7 +1941,7 @@ endif
### Check documentation
#
check-docs::
- @(for v in $(ALL_PROGRAMS) $(BUILT_INS) git gitk; \
+ @(for v in $(ALL_PROGRAMS) $(SCRIPT_LIB_SH) $(BUILT_INS) git gitk; \
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
@@ -1975,7 +1986,7 @@ check-docs::
documented,gittutorial-2 | \
sentinel,not,matching,is,ok ) continue ;; \
esac; \
- case " $(ALL_PROGRAMS) $(BUILT_INS) git gitk " in \
+ case " $(ALL_PROGRAMS) $(SCRIPT_LIB_SH) $(BUILT_INS) git gitk " in \
*" $$cmd "*) ;; \
*) echo "removed but $$how: $$cmd" ;; \
esac; \
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
old mode 100755
new mode 100644
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
old mode 100755
new mode 100644
--
1.7.0.rc1
^ permalink raw reply related
* Re: Stepping through a single file's history
From: Pete Harlan @ 2010-01-31 8:26 UTC (permalink / raw)
To: John Tapsell; +Cc: Ron Garret, git
In-Reply-To: <43d8ce651001281758x79965b5fn8760b69d4fe82a36@mail.gmail.com>
On 01/28/2010 05:58 PM, John Tapsell wrote:
> 2010/1/29 Ron Garret <ron@flownet.com>:
>> Hello,
>>
>> Is there an easy way to step through the history of a single file?
>> To be more specific:
> ...
>> (The use case here is remembering that back in the day there was
>> some useful code in this file that I want to retrieve, but not
>> remembering exactly when it was deleted. So I want to step back
>> through this file's history and do diffs against HEAD.)
>
> How about simply doing:
>
> git log -p filename
>
> and then you can search by pressing "/" and then typing whatever you
> remember.
>
> John
Have you tried "git log -Sfoo filename", which finds commits that
changed the number of occurrances of string "foo" in filename? I've
found that quite useful in digging up deleted code.
It's not as thorough as grepping "git log -p filename", but in practice
I've found it very effective.
--Pete
^ permalink raw reply
* Re: migrating to git: keep subversion revision numbers (as tags?)
From: Ilari Liusvaara @ 2010-01-31 8:04 UTC (permalink / raw)
To: fkater@googlemail.com; +Cc: git
In-Reply-To: <20100130230829.GA3544@comppasch2>
On Sun, Jan 31, 2010 at 12:08:29AM +0100, fkater@googlemail.com wrote:
> Hi,
>
> I would like to completely migrate from subversion to git
> (and NOT have subversion enabled anymore). However, I need
> to be able to lookup the old subversion revision numbers
> later from the git repository. The default seems to be
> though, that they are replaced by git sha-1 keys.
>
> It would be completely o.k. here to use git tags for all
> those subversion revision numbers (if possible), so, to
> create a tag for each subversion revision. However, I have
> neither seen any option in git nor found a script which does
> that upon cloning (converting) a subversion repo into a git
> repo.
>
> Is there a way to do so?
Another way would be to have SVN version numbers in commit
message (--grep option works fine, if those version numbers have
fixed format).
The version numbers git-svn outputs are ugly, but filter-branch
can be pretty easily rewrite those into more pretty form,
something like
"This was SVN r123" or "SVN-version: r123".
(adjust to taste)
-Ilari
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Junio C Hamano @ 2010-01-31 8:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100131073208.GA15268@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Jan 30, 2010 at 02:53:34PM -0800, Junio C Hamano wrote:
>
>> * Various commands given by the end user (e.g. diff.type.textconv,
>> and GIT_EDITOR) can be specified with command line arguments. E.g. it
>> is now possible to say "[diff "utf8doc"] textconv = nkf -w".
>
> Does this deserve a mention in the "behavior changes" section, too, as
> it may be breaking certain configs (most likely those with full paths to
> filters which have spaces in them)?
Perhaps. A patch with nice description, please?
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Ilari Liusvaara @ 2010-01-31 7:56 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e1001301712h3223f4c5xcf4742cde1642dfe@mail.gmail.com>
On Sun, Jan 31, 2010 at 02:12:19AM +0100, Sverre Rabbelier wrote:
> Heya,
>
> Feel free to tell me "go build 1.7.0.rc0 yourself and see" to any of
> these, but I can't right now, and am curious :).
>
> > * "git log" and friends learned "--glob=heads/*" syntax that is a more
> > flexible way to complement "--branches/--tags/--remotes".
>
> Not --glob=refs/*?
That does work. Even shorter would be '--glob=*'.
-Ilari
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-31 7:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jacob Helwig, Ron1, git
In-Reply-To: <alpine.DEB.1.00.1001292131330.3749@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Just as a general hint, I think the best documentation about Git was
> written by J. Bruce Fields (the user manual) and Scott Chacon (everything
> that has GitHub written on it, and Git Pro, and much, much more).
The last one is "Pro Git": http://progit.org/book/; highly recommended.
> ... If you
> happen to speak Japanese, Junio's book might help you understand the ideas
> behind the current Git user interface, too.
Nah, I don't talk about UIs. I talk more about concepts.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Jeff King @ 2010-01-31 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaavvi4r5.fsf@alter.siamese.dyndns.org>
On Sat, Jan 30, 2010 at 02:53:34PM -0800, Junio C Hamano wrote:
> * Various commands given by the end user (e.g. diff.type.textconv,
> and GIT_EDITOR) can be specified with command line arguments. E.g. it
> is now possible to say "[diff "utf8doc"] textconv = nkf -w".
Does this deserve a mention in the "behavior changes" section, too, as
it may be breaking certain configs (most likely those with full paths to
filters which have spaces in them)?
-Peff
^ permalink raw reply
* Re: [PATCH] Do not install shell libraries executable
From: Junio C Hamano @ 2010-01-31 7:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, Junio C Hamano, Johannes Schindelin, David Aguilar,
git
In-Reply-To: <20100129145025.GA22703@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> @@ -1488,6 +1490,15 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
> chmod +x $@+ && \
> mv $@+ $@
>
> +$(patsubst %.sh,%,$(SCRIPT_LIB_SH)) : % : %.sh
> + $(QUIET_GEN)$(RM) $@ $@+ && \
> + sed -e 's|@SHELL_PATH@|$(SHELL_PATH_SQ)|' \
> + -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
> + -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
> + -e $(BROKEN_PATH_FIX) \
> + $@.sh >$@+ && \
> + mv $@+ $@
> +
Can't you do something about this repetition from existing $(SCRIPT_SH)
munging? Other than that the patch looks like Ok.
^ permalink raw reply
* Re: [RFH] rpm packaging failure
From: Todd Zullinger @ 2010-01-31 4:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland, Sverre Rabbelier
In-Reply-To: <7vd40rjks4.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]
Junio C Hamano wrote:
> To allow us to go forward a bit easier, I am planning to use the
> attached, as we would need some parts of it when we do start
> generating a separate package, I think.
Sounds good. One minor nit, below... ;)
> %define path_settings ETC_GITCONFIG=/etc/gitconfig prefix=%{_prefix} mandir=%{_mandir} htmldir=%{_docdir}/%{name}-%{version}
> +%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
It is probably better to use %global rather than %define here. The
Fedora packaging guidelines now recommend this:
http://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
The rationale is that %define only really lasts until the closing
brace, while %global persists. A bug in rpm has masked this for a
long time, but it now fixed in upstream rpm, which is packaged for
Fedora's rawhide and possible other rpm-based distros. A bit more
detail is available at:
https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html
(Which is linked, with an incorrect trailing '|' character from the
Fedora guidelines URL above.)
Using %global should work on older rpm versions as well as current
versions, so there should be no downside to using s/%define/%global in
most cases.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The secret to success is knowing who to blame for your failures.
-- Demotivators (www.despair.com)
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.0.rc1
From: Anders Kaseorg @ 2010-01-31 3:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaavvi4r5.fsf@alter.siamese.dyndns.org>
On Sat, 30 Jan 2010, Junio C Hamano wrote:
> A release candidate Git 1.7.0.rc1 is available at the usual places
> for testing:
Looks like the tag is missing in git.git.
Anders
^ 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