* What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-11-27 0:28 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* cr/remote-update-v (Tue Nov 18 19:04:02 2008 +0800) 1 commit
+ git-remote: add verbose mode to git remote update
Should be in 1.6.1-rc1.
* rs/strbuf-expand (Sun Nov 23 00:16:59 2008 +0100) 6 commits
+ remove the unused files interpolate.c and interpolate.h
+ daemon: deglobalize variable 'directory'
+ daemon: inline fill_in_extra_table_entries()
+ daemon: use strbuf_expand() instead of interpolate()
+ merge-recursive: use strbuf_expand() instead of interpolate()
+ add strbuf_expand_dict_cb(), a helper for simple cases
Should be in 1.6.1-rc1.
* mv/fast-export (Sun Nov 23 12:55:54 2008 +0100) 2 commits
+ fast-export: use an unsorted string list for extra_refs
+ Add new testcase to show fast-export does not always exports all
tags
Should be in 1.6.1-rc1 and backmerged to 'maint'.
* st/levenshtein (Thu Nov 20 14:27:27 2008 +0100) 2 commits
+ Document levenshtein.c
+ Fix deletion of last character in levenshtein distance
Should be in 1.6.1-rc1.
* js/mingw-rename-fix (Wed Nov 19 17:25:27 2008 +0100) 1 commit
+ compat/mingw.c: Teach mingw_rename() to replace read-only files
Should be in 1.6.1-rc1 and backmerged to 'maint'.
* mv/clone-strbuf (Fri Nov 21 01:45:01 2008 +0100) 3 commits
+ builtin_clone: use strbuf in cmd_clone()
+ builtin-clone: use strbuf in clone_local() and
copy_or_link_directory()
+ builtin-clone: use strbuf in guess_dir_name()
Should be in 1.6.1-rc1.
* pw/maint-p4 (Wed Nov 26 13:52:15 2008 -0500) 1 commit
- git-p4: fix keyword-expansion regex
Waiting for Ack from git-p4 folks.
* cc/bisect-skip (Sun Nov 23 22:02:49 2008 +0100) 1 commit
- bisect: teach "skip" to accept special arguments like "A..B"
Should be in 1.6.1-rc1.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I really hate the idea of introducing a potentially much more useful
replacement of the existing graft mechanism and tie it very tightly to
bisect, making it unusable from outside.
(1) I do not think "bisect replace" workflow is a practical and usable
one;
(2) The underlying mechanism to express "this object replaces that other
object" is much easier to work with than what the graft does which is
"the parents of this commit are these", and idea to use the normal
ref to point at them means this can potentially be used for
transferring the graft information across repositories, which the
current graft mechanism cannot do.
(3) Because I like the aspect (2) of this series so much, it deeply
disappoints and troubles me that this is implemented minimally near
the surface, and that it is controlled by the "bisect" Porcelain
alone, by explicitly passing command line arguments.
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
----------------------------------------------------------------
[Graduated to "master"]
* bc/maint-keep-pack (Thu Nov 13 14:11:46 2008 -0600) 1 commit
+ repack: only unpack-unreachable if we are deleting redundant packs
This makes "repack -A -d" without -d do the same thing as "repack -a -d",
which makes sense. This does not have to go to 'maint', though.
* jk/commit-v-strip (Wed Nov 12 03:23:37 2008 -0500) 4 commits
+ status: show "-v" diff even for initial commit
+ Merge branch 'jk/maint-commit-v-strip' into jk/commit-v-strip
+ wt-status: refactor initial commit printing
+ define empty tree sha1 as a macro
----------------------------------------------------------------
[Will merge to "master" soon]
* lt/preload-lstat (Mon Nov 17 09:01:20 2008 -0800) 2 commits
+ Fix index preloading for racy dirty case
+ Add cache preload facility
* ta/quiet-pull (Mon Nov 17 23:09:30 2008 +0100) 2 commits
+ Retain multiple -q/-v occurrences in git pull
+ Teach/Fix pull/fetch -q/-v options
* nd/narrow (Tue Nov 18 06:33:16 2008 -0500) 10 commits
+ t2104: touch portability fix
+ grep: skip files outside sparse checkout area
+ checkout_entry(): CE_NO_CHECKOUT on checked out entries.
+ Prevent diff machinery from examining worktree outside sparse
checkout
+ ls-files: Add tests for --sparse and friends
+ update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
+ update-index: refactor mark_valid() in preparation for new options
+ ls-files: add options to support sparse checkout
+ Introduce CE_NO_CHECKOUT bit
+ Extend index to save more flags
* ph/send-email (Tue Nov 11 00:54:02 2008 +0100) 4 commits
+ git send-email: ask less questions when --compose is used.
+ git send-email: add --annotate option
+ git send-email: interpret unknown files as revision lists
+ git send-email: make the message file name more specific.
----------------------------------------------------------------
[Actively Cooking]
* cb/mergetool (Thu Nov 13 12:41:15 2008 +0000) 3 commits
- [DONTMERGE] Add -k/--keep-going option to mergetool
- Add -y/--no-prompt option to mergetool
- Fix some tab/space inconsistencies in git-mergetool.sh
Jeff had good comments on the last one; the discussion needs concluded,
and also waiting for comments from the original author (Ted).
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* Re: git cat-file blob does not convert crlf
From: Johannes Schindelin @ 2008-11-27 1:41 UTC (permalink / raw)
To: Quim K. Holland; +Cc: git
In-Reply-To: <20081127013456.6117@qkholland.gmail.com>
Hi,
On Thu, 27 Nov 2008, Quim K. Holland wrote:
> I think git is buggy.
You probably missed the difference between porcelain and plumbing. Git is
not buggy.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: Johannes Schindelin @ 2008-11-27 1:46 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492DB6C8.7010205@gmail.com>
Hi,
On Wed, 26 Nov 2008, William Pursell wrote:
> This sequence of 2 patches adds a '/' command to
> add --patch that allows the user to search for
> a hunk that matches a regex, and deals with j,k slightly
> more gracefully. (Rather than printing the
> help menu if k is invalid, it will print
> a relevant error message.)
I find these references to j and k not only confusing, but slightly
unnerving. Care to be a bit more explicit?
> (Please CC me in any response)
Always on this list; we respect netiquette.
Ciao,
Dscho
^ permalink raw reply
* [RFC] Git Perl bindings, and OO interface
From: Jakub Narebski @ 2008-11-27 1:58 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Lea Wiemann, Nadim Khemir
There exists many Git bindings for various programming languages, some
of them using git commands, some of them reimplementing Git, or parts
of Git. There is GitPython and PyGit (with some native implementation)
for Python, there is (deprecated) Ruby/Git and Grit (with some native
implementation) for Ruby, there is #Git for C#, there is ObjectiveGit
for Objective C (native), there is JGit (native) and JavaGit for Java,
there is Gat for Haskell and eWiki contains something for PHP.
And of course there is Git.pm (included with Git) and Git::Repo (part
of 'gitweb caching' GSoC 2008 project by Lea Wiemann) for Perl. Now
Git::Repo didn't get accepted into git.git codebase, but developing it
sparked a bit of discussion about Perl interface to Git commands, and
Object Oriented interface to Git.
I'd like to spawn a discussion in this thread about interfaces to Git
and Object Oriented interface to Git, mainly but not only in Perl.
I hope that the authors of mentioned (and not mentioned) bindings,
interfaces and implementations of Git would contribute to this thread.
0. One of points of disagreement between Git.pm and new Git::Repo was
using Error module for frontend error handling. While the
explanation in http://www.perl.com/pub/a/2002/11/14/exception.html
is compelling, it is not standard Perl technique. Additionally
adding "cmd_git_try { CODE } ERRORMSG" syntactic sugar was not very
good idea.
So the first thing I'd like to discuss: to use Error and try/catch,
or not in Perl interface (bindings) to Git? I would really like to
hear from Perl experts / Perl hackers here...
1. Git::Cmd
If I remember correctly Git.pm started as a way to gather in one
place safe_cmd and safe_pipe like construct from various git commands
implemented in Perl. The goal here is to provide portable, safe, and
working with old Perl interface:
* portable: this means trying to work with ActiveState Perl on
MS Windows; I don't know how important it is _now_ (if there are
common other Perl distributions on MS Windows).
* safe: if some of arguments to git commands come from variables,
then they have to be safe against shell expansion (whitespace,
quoting characters, escape characters, metacharacters, etc.).
* compatibile: it should work with as old Perl version as is
reasonable; it is possible that you can install git locally, but
cannot upgrade Perl.
Note that some git commands, for example 'git version', 'git
ls-remote' and 'git clone' doesn't need git repository to work on.
We would want to be able to catch git command output to scalar, to
list (line by line), and to filehandle. More advanced stuff is bidi
pipe (watch for deadlocks!), and redirecting both stdout and stderr
of git command to filehandle.
What instance of Git::Cmd should know is where to find 'git' binary
(what is $GIT in gitweb, for example). It could cache/store
internally exec_path.
2. Git::Config
If git command (a piece of code) uses more than one configuration
variable, then one would want to get relevant configuration using
as few calls to git commands as possible. Therefore using git-config
to read each config variable is usually out of the question (but it
is sometimes useful); we would want to read all config in one go,
either by using "git config -l -z", or by writing config parser in
Perl (as some command(s) did).
The problem with this solution is that we have to implement "type
casting", i.e. equivalent of --int and --bool options to git-config
ourselves. This mean converting to integer with optional size suffix,
converting to boolean, and asking for escape codes corresponding to
given color. And if we add new type (like proposed --path, expanding
for example '~' to HOME, and ~user to home directory of given user)
we would have to add it to Perl interface too.
3. Git::Repo::Bare and Git::Repo::Nonbare
Git.pm partially implements those, in a kind of mixed way. Git::Repo
from Lea Wiemann implements if I remember correctly bare repo only.
What Git::Repo::Bare (or just Git::Repo) should support is to pass
appropriate '--git-dir=<dir>' to Git::Cmd, and support accessing git
repository config via Git::Config. It could have also use
long-running pipe to "git cat-file --batch / --batch-check"
invocation. For gitweb we only need that part.
Git::Repo::Nonbare has to additionally pass '--work-tree=<dir>' if
needed, ant be able to take care and manipulate where in working
directory we are, i.e. what for example "git rev-parse --show-prefix"
does.
4. Git::Object: Git::Commit, Git::Tag, Git::Blob and Git::Tree
Here begins "true" object-oriented part of Git Perl API.
The easy part is for Git::Commit and Git::Tag to parse commit and tag
objects (perhaps Git::Object should have interface for long-lived
"git cat-file --batch") into headers and body (commit/tag message).
I think we can borrow / be inspired by parse_commit() and other such
code in gitweb; we have to remember that there might be in some time
some new headers we don't know about but are perfectly valid (see for
example "encoding" header in commit object format, which was added
later, not during initial design).
The harder part would be to be able to deal with author and committer
info, splitting it into parts (author name, author email, date and
timezone, etc.), and also generating dates in various formats, like
RFC-2822 or ISO-8601.
The easiest part would be structureless Git::Blob... but there we
might want size of blob.
A bit harder would be Git::Tree object and dealing with elements of
a tree (tree entries). I'm not sure if some kind of iterator access
would be useful here.
Note that for Git::Commit if we are to use plumbing like git-cat-file
we would have to take care of fake parents info, namely grafts and
shallow info by ourself, in Perl, to have 'effective parents'.
5. Git::Diff::Raw and Git::Diff::Patchset
Here I am thinking simply about parsing difftree (raw diff output
format) and patchset format, as it is used in gitweb. It is meant
to be able to access for example to permissions of a file, or diff
status, or diff stats, etc.
Here we would want to be able to deal also with merge commits and
combined diff output format.
6. Git::Log or Git::RevList
The only difference from list of Git::Commit objects is that
depending on parameters like path limiting it might have different
effective parents if there is history simplification.
7. Git::Refs
It is meant to represent references, mainly branches, and be filled
using git-for-each-ref... and for example used for ref markers.
There are probably a few things I have forgot about...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-27 2:05 UTC (permalink / raw)
To: Johannes Sixt
Cc: Michael J Gruber, Johannes Schindelin, Git Mailing List,
Fabian Seoane
In-Reply-To: <492D7AEF.5030908@viscovery.net>
Hi Johannes!
On Wed, Nov 26, 2008 at 5:35 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Ondrej Certik schrieb:
>> I am also trying to make the example simpler. I tried to squash the
>> first uninteresting ~1500 commits into one, but "git rebase -i"
>> uterrly fails after squashing about 600 commits. Still investigating.
>
> Don't use rebase. Set a graft and rewrite the history:
>
> $ echo $(git rev-parse HEAD) $(git rev-parse HEAD~1500) >> \
> .git/info/grafts
>
> Assuming "first 1500" means the "most recent 1500" commits. But you get
> the idea. You can truncate history as well by omitting the second SHA1.
> It's very convenient to keep gitk open and File->Reload after each graft
> that you set.
>
> When you're done with setting grafts:
>
> $ git filter-branch -f --tag-name-filter cat -- --all
Indeed, this seems to be working robustly. Thanks!
>
> (You are doing this on a copy of your repository, don't you?)
Yes.
I spent the whole today trying to isolate the bug, but so far I
haven't succeeded. Unfortunately, I need to work on other things now,
so I am postponing this to some later time. The repository that
reproduces it will stay online, so anyone feel free to produce a nice
and simple (failing) test for the bug.
Thanks,
Ondrej
^ permalink raw reply
* [PATCH 1/3] Change prompt separater from / to , in add --patch.
From: William Pursell @ 2008-11-27 4:07 UTC (permalink / raw)
To: git
To enable adding the '/' command as an option, it is advisable
not to use '/' as the command separater.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..f20b880 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -887,22 +887,22 @@ sub patch_update_file {
for ($i = 0; $i < $ix; $i++) {
if (!defined $hunk[$i]{USE}) {
$prev = 1;
- $other .= '/k';
+ $other .= ',k';
last;
}
}
if ($ix) {
- $other .= '/K';
+ $other .= ',K';
}
for ($i = $ix + 1; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$next = 1;
- $other .= '/j';
+ $other .= ',j';
last;
}
}
if ($ix < $num - 1) {
- $other .= '/J';
+ $other .= ',J';
}
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
@@ -913,13 +913,13 @@ sub patch_update_file {
last if (!$undecided);
if (hunk_splittable($hunk[$ix]{TEXT})) {
- $other .= '/s';
+ $other .= ',s';
}
- $other .= '/e';
+ $other .= ',e';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored $prompt_color, "Stage this hunk [y,n,a,d$other,?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 2/3] Add / command in add --patch
From: William Pursell @ 2008-11-27 4:07 UTC (permalink / raw)
To: git
This command allows the user to skip hunks that don't
match the specified regex.
BUG: if the user enters an invalid regex, perl will abort.
For example: /+\s*foo will abort with:
Quantifier follows nothing in regex
I am not a Perl hacker and would welcome suggestions
on the easiest way to deal with this.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index f20b880..547b5c8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -876,12 +877,14 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ my $search_s; # User entered string to match a hunk.
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
if ($num <= $ix) {
+ undef $search_s;
$ix = 0;
}
for ($i = 0; $i < $ix; $i++) {
@@ -916,11 +919,24 @@ sub patch_update_file {
$other .= ',s';
}
$other .= ',e';
- for (@{$hunk[$ix]{DISPLAY}}) {
- print;
+
+ my $line;
+ if (defined $search_s) {
+ my $text = join ("", @{$hunk[$ix]{DISPLAY}});
+ if ($text !~ $search_s) {
+ $line = "j\n";
+ } else {
+ print $text;
+ }
+ } else {
+ for (@{$hunk[$ix]{DISPLAY}}) {
+ print;
+ }
+ }
+ if (!$line) {
+ print colored $prompt_color, "Stage this hunk [y,n,a,d,/$other,?]? ";
+ $line = <STDIN>;
}
- print colored $prompt_color, "Stage this hunk [y,n,a,d$other,?]? ";
- my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -946,6 +962,9 @@ sub patch_update_file {
}
next;
}
+ elsif ($line =~ m|^/(.*)|) {
+ $search_s = qr{$1}m;
+ }
elsif ($other =~ /K/ && $line =~ /^K/) {
$ix--;
next;
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 3/3] In add --patch, Handle K,k,J,j slightly more gracefully.
From: William Pursell @ 2008-11-27 4:08 UTC (permalink / raw)
To: git
Instead of printing the help menu, this will print
"No next hunk" and then process the given hunk again.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 43 ++++++++++++++++++++++++++++---------------
1 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 547b5c8..66f6629 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -965,29 +965,42 @@ sub patch_update_file {
elsif ($line =~ m|^/(.*)|) {
$search_s = qr{$1}m;
}
- elsif ($other =~ /K/ && $line =~ /^K/) {
- $ix--;
+ elsif ($line =~ /^K/) {
+ if ($other =~ /K/) {
+ $ix--;
+ }
+ else {
+ print STDERR "No previous hunk\n";
+ }
next;
}
- elsif ($other =~ /J/ && $line =~ /^J/) {
- $ix++;
+ elsif ($line =~ /^J/) {
+ if ($other =~ /J/) {
+ $ix++;
+ }
+ else {
+ print STDERR "No next hunk\n";
+ }
next;
}
- elsif ($other =~ /k/ && $line =~ /^k/) {
- while (1) {
- $ix--;
- last if (!$ix ||
- !defined $hunk[$ix]{USE});
+ elsif ($line =~ /^k/) {
+ if ($other =~ /k/) {
+ while (1) {
+ $ix--;
+ last if (!$ix ||
+ !defined $hunk[$ix]{USE});
+ }
+ }
+ else {
+ print STDERR "No previous hunk\n";
}
next;
}
- elsif ($other =~ /j/ && $line =~ /^j/) {
- while (1) {
- $ix++;
- last if ($ix >= $num ||
- !defined $hunk[$ix]{USE});
+ elsif ($line =~ /^j/) {
+ if ($other !~ /j/) {
+ print STDERR "No next hunk\n";
+ next;
}
- next;
}
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split = split_hunk($hunk[$ix]{TEXT}, $hunk[$ix]{DISPLAY});
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* know wget URL, need git-clone URL
From: jidanni @ 2008-11-27 4:10 UTC (permalink / raw)
To: git; +Cc: smartphones-userland
I wish the git beginner documentation would tell one how to translate
e.g., http://git.debian.org/?p=pkg-fso/files.git&a=blob_plain&f=install.sh
which is good for wget, to the URL one needs for git-clone to get the
same file.
^ permalink raw reply
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: William Pursell @ 2008-11-27 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vod02cd3p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Use of eval is a good way to protect against this kind of breakage, but it
> should be done close to where the string is given by the user, perhaps in
> here:
>
>
> + elsif ($line =~ m|^/(.*)|) {
> + $search_s = $1;
> + }
>
> Something like...
>
> elsif ($line =~ m|^/(.*)|) {
> $search_string = $1;
> eval {
> $search_string =~ /$search_string/;
> };
> if ($@) {
> print STDERR "Regexp error in $search_string: $@";
> next;
> }
> ...
Thanks. The second set of patches that I just sent
up is fatally flawed--by changing to skip unmatched
hunks instead of deselecting them, it enters a loop
if no hunks match.
Before working on patches, I'd like some ideas on
functionality:
1) If a hunk doesn't match, should it be as if the user
selected 'n', or 'j'?
2) If no hunks match it is easiest to simply move to
the last hunk and display it, but I'm not sure that
is acceptable. Probably better to return to the
hunk that was being viewed when the search string
is entered, but that seems to require some restructuring
of the code. What would be the preferred behavior?
--
William Pursell
^ permalink raw reply
* [PATCH] Print hunk number in prompt of add --patch.
From: William Pursell @ 2008-11-27 6:17 UTC (permalink / raw)
To: git
I'm considering adding a command to skip to a hunk, and
just generally find myself confused about which hunk I'm
looking at, so having the number in the prompt is helpful.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..7974cd1 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -919,7 +919,7 @@ sub patch_update_file {
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored $prompt_color, "Stage hunk $ix [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: Junio C Hamano @ 2008-11-27 6:41 UTC (permalink / raw)
To: William Pursell; +Cc: Jeff King, git
In-Reply-To: <492E3811.6050603@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Before working on patches, I'd like some ideas on
> functionality:
>
> 1) If a hunk doesn't match, should it be as if the user
> selected 'n', or 'j'?
Is it an option to tell "nothing matched", stay at the same hunk and ask
the user to make the choice again?
^ permalink raw reply
* Re: [PATCH] Print hunk number in prompt of add --patch.
From: Junio C Hamano @ 2008-11-27 7:14 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492E3B6D.9090309@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index b0223c3..7974cd1 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -919,7 +919,7 @@ sub patch_update_file {
> for (@{$hunk[$ix]{DISPLAY}}) {
> print;
> }
> - print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
> + print colored $prompt_color, "Stage hunk $ix [y/n/a/d$other/?]? ";
> my $line = <STDIN>;
> if ($line) {
> if ($line =~ /^y/i) {
Do we know how many hunks we have at this point (and remember we need to
adjust the number of hunks after splitting)?
The original one was unfriendly in that it asked "Do you want this or not?
We'd rather not to say where you are nor how many more there are". Your
update is slightly better but not enough: "Do you want this one or not?
It is the second one but we still won't tell you how many more there are".
I'd prefer it to ask "Stage hunk 2 (of 35)?" if you are adding more words
here.
I doubt "jump to hunk specified by hunk number" is useful in general. You
wouldn't know what hunk number the hunk you are interested in has, until
you scroll through them all.
"Jump to hunk around line number X in the preimage", or "jump to a hunk in
function Y" may be useful (the latter you can do with "/^@@.*funcname"
with your slash-search patch).
^ permalink raw reply
* [PATCH] Fix typos in the documentation.
From: Ralf Wildenhues @ 2008-11-27 7:32 UTC (permalink / raw)
To: git
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
This patch is against pu.
Cheers, and thanks for git,
Ralf
Documentation/RelNotes-1.6.0.4.txt | 2 +-
Documentation/RelNotes-1.6.1.txt | 6 +++---
Documentation/config.txt | 2 +-
Documentation/git-add.txt | 2 +-
Documentation/git-bisect.txt | 6 +++---
Documentation/git-commit.txt | 2 +-
Documentation/git-svn.txt | 2 +-
Documentation/technical/pack-protocol.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.4.txt b/Documentation/RelNotes-1.6.0.4.txt
index fba3f30..d522661 100644
--- a/Documentation/RelNotes-1.6.0.4.txt
+++ b/Documentation/RelNotes-1.6.0.4.txt
@@ -30,7 +30,7 @@ Fixes since v1.6.0.3
* 'git status' incorrectly reported a submodule directory as an untracked
directory.
-* 'git svn' used deprecated 'git-foo' form of subcommand invocaition.
+* 'git svn' used deprecated 'git-foo' form of subcommand invocation.
* 'git update-ref -d' to remove a reference did not honor --no-deref option.
diff --git a/Documentation/RelNotes-1.6.1.txt b/Documentation/RelNotes-1.6.1.txt
index 7fdf83f..848541a 100644
--- a/Documentation/RelNotes-1.6.1.txt
+++ b/Documentation/RelNotes-1.6.1.txt
@@ -55,9 +55,9 @@ on.
to a non-zero value to accept the suggestion when git can uniquely
guess.
-* The packfile machinery hopefully is more robust when dealilng with
+* The packfile machinery hopefully is more robust when dealing with
corrupt packs if redundant objects involved in the corruption are
- available elsehwere.
+ available elsewhere.
* "git add -N path..." adds the named paths as an empty blob, so that
subsequent "git diff" will show a diff as if they are creation events.
@@ -157,7 +157,7 @@ on.
* "git log" learned "--source" to show what ref each commit was reached
from.
-* "git log" also learned "--simplify-by-decration" to show the
+* "git log" also learned "--simplify-by-decoration" to show the
birds-eye-view of the topology of the history.
* "git log --pretty=format:" learned "%d" format element that inserts
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2283300..6d51967 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -841,7 +841,7 @@ gui.fastcopyblame::
repositories at the expense of less thorough copy detection.
gui.copyblamethreshold::
- Specifies the theshold to use in 'git gui blame' original location
+ Specifies the threshold to use in 'git gui blame' original location
detection, measured in alphanumeric characters. See the
linkgit:git-blame[1] manual for more information on copy detection.
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 6fc20b0..7c129cb 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -98,7 +98,7 @@ OPTIONS
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
- such files with 'git diff' and commiting them with 'git commit
+ such files with 'git diff' and committing them with 'git commit
-a'.
--refresh::
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 2ac77fb..75083e6 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -192,10 +192,10 @@ Bisect replace
This subcommand can help when you have a branch or a part of a
branch that isn't easily bisectable because of a bug that has been
-fixed latter.
+fixed later.
We suppose that a bug as been introduced at some point, say A, and
-that it has been fixed latter at another point, say B, but that
+that it has been fixed later at another point, say B, but that
between these points the code is not easily testable because of the
bug, so it's not easy to bisect between these points.
@@ -244,7 +244,7 @@ because the bug introduced by commit A and fixed by commit B will not
annoy you anymore.
As the refs created by "git bisect replace" can be shared between
-developers, this feature might be especially usefull on big projects
+developers, this feature might be especially useful on big projects
where many people often bisect the same code base.
If you give the `--no-replace` to "git bisect start", then the
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a1ce9a8..6203461 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -95,7 +95,7 @@ OPTIONS
-s::
--signoff::
- Add Signed-off-by line by the commiter at the end of the commit
+ Add Signed-off-by line by the committer at the end of the commit
log message.
-n::
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ba94cd1..8d0c421 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -109,7 +109,7 @@ COMMANDS
This works similarly to `svn update` or 'git-pull' except that
it preserves linear history with 'git-rebase' instead of
-'git-merge' for ease of dcommiting with 'git-svn'.
+'git-merge' for ease of dcommitting with 'git-svn'.
This accepts all options that 'git-svn fetch' and 'git-rebase'
accept. However, '--fetch-all' only fetches from the current
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 7396f69..696dd00 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -59,13 +59,13 @@ When tellme-more extension is used:
C: SHA1 old-SHA1 -- This is ancestor of that, you might know
C: SHA1 old-SHA1
C: ...
- C: # flush -- have you heard ehough?
+ C: # flush -- have you heard enough?
S: tellme-more old-SHA1' -- I still want to know more about this one
S: # flush -- please give me more
C: SHA1 old-SHA1'
C: SHA1 old-SHA1'
C: ...
- C: # flush -- have you heard ehough?
+ C: # flush -- have you heard enough?
S: # flush -- yes, thanks, we've heard enough
S: XXXXXXX --- packfile contents.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c0d8caf..da9c6b2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -546,7 +546,7 @@ $ git bisect skip
-------------------------------------------------
In this case, though, git may not eventually be able to tell the first
-bad one between some first skipped commits and a latter bad commit.
+bad one between some first skipped commits and a later bad commit.
There are also ways to automate the bisecting process if you have a
test script that can tell a good from a bad commit. See
--
1.6.0.4.766.g6fc4a
^ permalink raw reply related
* git-svn clone behaves non-deterministic
From: Josef Wolf @ 2008-11-27 7:53 UTC (permalink / raw)
To: git
Hello,
I am new to git and decided to get my feet wet by first cloning and
playing with my existing svn repositories. Thus, I've done this:
cd /my/test/repos
for i in repo1 repo2 repo3; do
repos=https://my.repos.server/repos/$i/trunk
svn co $repos svn/$i
git-svn clone $repos git/$i
done
for i in `cd svn; echo *`; do diff --exclude /.svn -Nruw */$i; done
With this, I see that four of the repositories are cloned as expected,
but the fifth has only the .git directory in it. It appears that
the clone command stopped cloning at r2008, while the repository is
currently at r3761. So almost the half of the history was not
cloned at all. I've investigated the offending revision and the
revisions around it, but I can't see anything special about them.
The effect is perfectly reproducible and it stops always on the very
same revision. I get no error message at all. I've attached the
last lines of the clone operation at the end of this mail.
Then I go to another machine and enter exactly the same commands as
above. Both machines are fresh ubuntu-8.10 default installs.
To my surprise, on this other machine the clone operation seems to
have worked for all the repositories. But the diff command shows
me that arbitrary files are missing in _all_ of the repositories.
Since the repositories were not modified in the mean time, it looks
to me like there's a problem with the "git-svn clone" command.
Any ideas?
r2005 = e487699eb8f94d6c5e9b732ba75e1c50cae3bb5e (git-svn)
A misc/ubuntu-remaster/Rakefile
r2006 = 8b15a1a5bdc8e6a3bfd7e6eb717ef4c2db0f1dbf (git-svn)
M misc/ubuntu-remaster/Rakefile
r2007 = 27678a3bd98400abdaaaf9af543f9558593fc224 (git-svn)
M misc/ubuntu-remaster/Rakefile
r2008 = bbc2d0cbe4419a499d29afda281b85b5e744a5e6 (git-svn)
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 12446, done.
Compressing objects: 100% (11999/11999), done.
Writing objects: 100% (12446/12446), done.
Total 12446 (delta 7657), reused 0 (delta 0)
jw@vdr1:/my/test/repos$ l git/misc/
total 12
drwxr-xr-x 3 jw jw 4096 Nov 27 08:27 ./
drwxr-xr-x 3 jw jw 4096 Nov 27 08:27 ../
drwxr-xr-x 9 jw jw 4096 Nov 27 08:38 .git/
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Andreas Ericsson @ 2008-11-27 8:18 UTC (permalink / raw)
To: Ondrej Certik
Cc: Johannes Schindelin, Michael J Gruber, Git Mailing List,
Fabian Seoane
In-Reply-To: <85b5c3130811260921s474bc724hb74b54e21e8be912@mail.gmail.com>
Ondrej Certik wrote:
> On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>>
>>> I am also trying to make the example simpler. I tried to squash the
>>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>>> fails after squashing about 600 commits. Still investigating.
>> 1500... wow.
>>
>> The best idea would probably be to just "edit" the first, delete the rest
>> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
>> the command line (when git rebase stops after the "edit" command).
>
> That worked, thanks! My original repo:
>
> A -- B -- ... --- D --- E --- ...
>
> where E and the rest of the commits (there are branches and merges in
> there) are the ones that I need to preserve, but all the commits
> between B and D can be squashed (~1500 of them). So I created a
> branch:
>
> A -- B -- ... --- D
>
> then squashed the commits using the technique you described above, so
> now I have:
>
> A -- BD --
>
> and now I would like to append "E -- ..." to it -- is there any way to
> do that? I tried rebase, but that destroys all the branches and merges
> and those are necessary to reproduce the fast-export bug.
>
git rebase -p
If your git is old, you'll need
git rebase -i -p
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: know wget URL, need git-clone URL
From: Andreas Ericsson @ 2008-11-27 9:00 UTC (permalink / raw)
To: jidanni; +Cc: git, smartphones-userland
In-Reply-To: <87bpw1hkqx.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> I wish the git beginner documentation would tell one how to translate
> e.g., http://git.debian.org/?p=pkg-fso/files.git&a=blob_plain&f=install.sh
> which is good for wget, to the URL one needs for git-clone to get the
> same file.
You can't use "git clone" to get a single file. You can only get the
entire repository using "git clone". Usually, the clone-url is written
somewhere on the projects gitweb page, and that is also the case for
this repository.
If you visit http://git.debian.org/?p=pkg-fso/files.git;a=summary you'll
find this section on that page:
URL git://git.debian.org/git/pkg-fso/files.git
http://git.debian.org/git/pkg-fso/files.git
It's impossible to infer the clone url from the gitweb url, because there's
absolutely no connection between them (that will change if gitweb gains
fetch/clone support), and the paths/urls depends on the servers configuration
which we cannot know.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Fix typos in the documentation.
From: Andreas Ericsson @ 2008-11-27 9:10 UTC (permalink / raw)
To: Ralf Wildenhues, git
In-Reply-To: <20081127073201.GD8267@ins.uni-bonn.de>
Ralf Wildenhues wrote:
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> This patch is against pu.
>
'pu' is a moving target in git. For future reference, it's
better to send patches against 'master'.
Other than that:
Acked-by: Andreas Ericsson <ae@op5.se>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* How to know where a reference name comes from?
From: Matthieu Moy @ 2008-11-27 9:18 UTC (permalink / raw)
To: git
Hi,
I faced a simple problem: on a repository, doing almost anything with
the reference "git-svn" complained about ambiguous reference. I know I
have a remotes/git-svn branch, but I didn't know what the other
reference could be.
I didn't find a command telling me _why_ this "git-svn" was ambiguous.
I'd have loved a
$ git rev-parse --all-symbolic-full-names git-svn
or so, but I couldn't find one.
Did I miss anything obvious? (not that the problem was big, I'm just
curious).
(I ended up doing "strace -e open git rev-parse git-svn", and found
out I had a .git/git-svn file lying around)
Thanks,
--
Matthieu
^ permalink raw reply
* Re: git configure script
From: Mike Ralphson @ 2008-11-27 9:25 UTC (permalink / raw)
To: Neale T. Pickett; +Cc: git, Matthieu Moy
In-Reply-To: <vpq7i6q8azp.fsf@bauges.imag.fr>
2008/11/26 Matthieu Moy <Matthieu.Moy@imag.fr>
>
> neale@lanl.gov (Neale T. Pickett) writes:
>
> > But it installed everything in $HOME/bin and $HOME/libexec. Looking
> > into it, it seems the shipped Makefile doesn't look to see what --prefix
> > is, despite the configure script claiming that "make install" would
> > honor this.
>
> It does, since it includes config.mak.autogen which overrides prefix
> defined in Makefile.
>
> I'm 99% sure you did something wrong. You should investigate by
> looking into config.mak.autogen after running configure.
Indeed. I believe something goes a little funny if you build as root.
Can you try again running ./configure and (g)make as a non-root user,
then only (g)make install as root / under sudo etc.
Cheers, Mike
^ permalink raw reply
* Re: format-patch problem when using relative
From: Björn Steinbrink @ 2008-11-27 9:42 UTC (permalink / raw)
To: Nikola Knežević; +Cc: Jeff King, git
In-Reply-To: <06D676E3-6C24-4ACC-9874-8B19549BC3A1@gmail.com>
On 2008.11.26 19:58:34 +0100, Nikola Knežević wrote:
> On 26 Nov 2008, at 19:01 , Jeff King wrote:
>
>> So I think what you really want is:
>>
>> git format-patch --relative=click click/master myclick -- click
>>
>> to limit the path pruning to the 'click' directory.
>
> Yes, that did the trick. Also, when I think about it, it makes sense -
> do checks relative to a path, but prune using path.
Ah, now that makes sense to me, too. You just didn't use the actual
command I told you on IRC ;-)
<doener> git format-patch --relative=click/ click/master click
That already had the path limiting "click" in it, I really meant "click"
there, not "myclick" ;-) I guess the confusion was caused by how
format-patch takes the range it's supposed to work on. If you only give
it a single committish, that is interpreted as "since". So the above is
equal to
git format-patch --relative=click/ click/master..HEAD click
Björn
^ permalink raw reply
* Re: How to know where a reference name comes from?
From: Junio C Hamano @ 2008-11-27 9:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk5ap5xy1.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> (I ended up doing "strace -e open git rev-parse git-svn", and found
> out I had a .git/git-svn file lying around)
This has been proposed for a couple of times now but I think it might be
time to start insisting on a ref directly underneath $GIT_DIR to be in all
caps (plus underscore) to avoid issues like this while still allowing
traditional MERGE_HEAD, ORIG_HEAD and friends.
^ permalink raw reply
* Re: [PATCH] Fix typos in the documentation.
From: Junio C Hamano @ 2008-11-27 9:48 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20081127073201.GD8267@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> This patch is against pu.
While I appreciate your fix, it would have been nicer to have at least
three patches in this case, organized like this:
* patch 1 applies to 'maint'. Let's call the result of such application
'maint plus fix';
In other words:
$ git checkout -b rw/maint-typofix maint
$ git am -s patch-1
* patch 2 is to be applied on top of the result of merging 'maint plus
fix' into 'master';
In other words:
$ git checkout -b rw/typofix master
$ git merge rw/maint-typofix
$ git am -s patch-2
* patch 3 is to contain everything else (it would be even nicer if they
are split up to apply to individual topic branches that are responsible
for introducing the typos, but I realize that it would be asking too
much).
In other words:
$ git checkout pu
$ git merge rw/typofix
$ git am -s patch-3
I've done the above splitting myself and further did:
$ git checkout maint
$ git merge rw/maint-typofix
$ git branch -d rw/maint-typofix
$ git checkout master
$ git merge rw/typofix
$ git branch -d rw/typofix
I did not create a single "patch-3" but squashed the fixes in to the
respective commits on the topic branches, as they are only on 'pu' and not
part of 'next' (hence I am free to amend and rebase them).
Thanks.
^ permalink raw reply
* Re: git-svn clone behaves non-deterministic
From: Michael J Gruber @ 2008-11-27 9:55 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20081127075351.GA12716@raven.wolf.lan>
Josef Wolf venit, vidit, dixit 27.11.2008 08:53:
> Hello,
>
> I am new to git and decided to get my feet wet by first cloning and
> playing with my existing svn repositories. Thus, I've done this:
>
> cd /my/test/repos
> for i in repo1 repo2 repo3; do
> repos=https://my.repos.server/repos/$i/trunk
> svn co $repos svn/$i
> git-svn clone $repos git/$i
> done
>
> for i in `cd svn; echo *`; do diff --exclude /.svn -Nruw */$i; done
>
> With this, I see that four of the repositories are cloned as expected,
> but the fifth has only the .git directory in it. It appears that
> the clone command stopped cloning at r2008, while the repository is
> currently at r3761. So almost the half of the history was not
> cloned at all. I've investigated the offending revision and the
> revisions around it, but I can't see anything special about them.
> The effect is perfectly reproducible and it stops always on the very
> same revision. I get no error message at all. I've attached the
> last lines of the clone operation at the end of this mail.
First of all: What does git --version say? Is it self-compiled git or
git as it comes with U 8.10?
Then: I assume the above is not quite what you did, otherwise I would be
surprised you see a 4th and 5th clone...
Your repo is probably one giant svn repo. In any case, the fact that the
repo is at $rev does not imply that the last commit on trunk is at $rev.
What is the last commit on trunk?
Other than that: There are so many sins you can commit (!) in an svn
repo that it it is hard to tell which one threw git-svn off. Can you
share the repo?
> Then I go to another machine and enter exactly the same commands as
> above. Both machines are fresh ubuntu-8.10 default installs.
>
> To my surprise, on this other machine the clone operation seems to
> have worked for all the repositories. But the diff command shows
> me that arbitrary files are missing in _all_ of the repositories.
I don't think computers behave deterministically, at least not according
to my experience. After all they rely on quantum mechanics, and who has
ever understood the measurement process, the collapsing of the wave
function?
OK: Whenever I got 2 different results after doing the same twice I
found that indeed some hidden/forgotten variable was not the same... Any
chance you find one?
Michael
^ permalink raw reply
* Re: git-svn and svn branches
From: Michael J Gruber @ 2008-11-27 10:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Ryan Phillips, git
In-Reply-To: <20081125230823.GA6664@mayonaise>
Eric Wong venit, vidit, dixit 26.11.2008 00:08:
> Ryan Phillips <ryan@trolocsis.com> wrote:
>> I followed the following instructions on adding a remote svn branch to my
>> local git-svn repository. http://www.dmo.ca/blog/20070608113513
>>
>> Are these still accurate?
>>
>> I started the repository with
>> # git svn init [url/trunk]`
>> # cd project.git
>> # git svn fetch -r[HEAD revision]
>> which works fine. I added something like Snippet 1 to the .git/config and
>> issued a `git svn fetch -r[HEAD revision of the branch]` and nothing
>> happens. It takes git-svn a few seconds to run, but the git-remote svn
>> branch doesn't get initialized.
>>
>> Does this procedure only work with a full mirror of a git-svn repository?
>> or perhaps I'm doing something wrong. Any help would be appreciated.
>>
>> Thanks,
>> Ryan
>>
>> Snippet 1
>> =========
>>
>> [svn-remote "svn34"]
>> url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
>> fetch = :refs/remotes/git-svn-3.4
>
> Try this:
>
> git svn fetch -i svn34
>
> It's been a while since I've used this, but I believe a test
> case covers it so it probably still works :)
>
Uhm, I think it's rather "-R svn34" which tells git-svn to use the svn
remote config "svn34". -i sets GIT_SVN_ID.
Michael
^ 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