* [PATCH 0/14] misc test-suite patches
From: Ramsay Jones @ 2010-12-14 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Hi Junio,
I've had many of these test-suite related patches lying around for
a while, so I'm passing these along now in the hope I can remove
some old branches...
[PATCH 01/14] t3600-rm.sh: Don't pass a non-existent prereq to test #15
[PATCH 02/14] t9142: Move call to start_httpd into the setup test
[PATCH 03/14] lib-git-svn.sh: Avoid setting web server variables unnecessarily
[PATCH 04/14] lib-git-svn.sh: Add check for missing mod_dav_svn module
[PATCH 05/14] lib-git-svn.sh: Add check for mis-configured web server variables
[PATCH 06/14] t9501-*.sh: Fix a test failure on Cygwin
[PATCH 07/14] t7800-difftool.sh: Fix a test failure on Cygwin
[PATCH 08/14] help.c: Fix detection of custom merge strategy on cygwin
[PATCH 09/14] t1301-*.sh: Fix the 'forced modes' test on cygwin
[PATCH 10/14] t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
[PATCH 11/14] t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
[PATCH 12/14] t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
[PATCH 13/14] t4135-*.sh: Skip the "backslash" tests on cygwin
[PATCH 14/14] t{3032,6038}-*.sh: Allow SED_BIN_OPT to override the -b sed option
These patches don't really have too much in common, well 2-5 and 10-12 are
somewhat related, other than fixing tests! (These were mostly done on Linux
and Cygwin but, since I also test on MinGW, one or two are just for MinGW)
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH] branch: do not attempt to track HEAD implicitly
From: Thomas Rast @ 2010-12-14 18:38 UTC (permalink / raw)
To: git
With branch.autosetupmerge=always, 'HEAD' becomes a valid target for
branch tracking. This is a bit silly, and in fact the code already
guards against it when attempting it explicitly:
$ git checkout HEAD^0
$ g branch -t foo
fatal: Cannot setup tracking information; starting point is not a branch.
Silently drop the HEAD candidate in the implicit (i.e. without -t
flag) case, so that the branch starts out without an upstream.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
branch.c | 8 ++++++--
t/t3200-branch.sh | 9 +++++++++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/branch.c b/branch.c
index 93dc866..19310e4 100644
--- a/branch.c
+++ b/branch.c
@@ -176,8 +176,12 @@ void create_branch(const char *head,
break;
case 1:
/* Unique completion -- good, only if it is a real ref */
- if (explicit_tracking && !strcmp(real_ref, "HEAD"))
- die("Cannot setup tracking information; starting point is not a branch.");
+ if (!strcmp(real_ref, "HEAD")) {
+ if (explicit_tracking)
+ die("Cannot setup tracking information; starting point is not a branch.");
+ else
+ real_ref = NULL;
+ }
break;
default:
die("Ambiguous object name: '%s'.", start_name);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index f308235..0fa5c91 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -488,6 +488,15 @@ test_expect_success 'autosetuprebase always on an untracked remote branch' '
test "z$(git config branch.myr20.rebase)" = z
'
+test_expect_success 'autosetuprebase always on detached HEAD' '
+ git config branch.autosetupmerge always &&
+ test_when_finished git checkout master &&
+ git checkout HEAD^0 &&
+ git branch my11 &&
+ test -z "$(git config branch.my11.remote)" &&
+ test -z "$(git config branch.my11.merge)"
+'
+
test_expect_success 'detect misconfigured autosetuprebase (bad value)' '
git config branch.autosetuprebase garbage &&
test_must_fail git branch
--
1.7.3.3.797.g7a32f
^ permalink raw reply related
* Re: [PATCH 09/19] tree-diff.c: reserve space in "base" for pathname concatenation
From: Junio C Hamano @ 2010-12-14 17:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, git
In-Reply-To: <AANLkTikXvx7-Q8B_dqG5mMHGK_Rw-dFaeQdXi0zW98SD@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Just googled around and found this [1]. I'm going with strbuf so it
> can be reallocated if necessary. A bit tricky because "base" can be
> moved, but I think it's worth it.
Thanks---I was about to suggest using strbuf but you figured it out
already, which is good ;-).
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Junio C Hamano @ 2010-12-14 17:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexandre Erwin Ittner, git
In-Reply-To: <20101214090707.GA11890@brick.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> OK, I re-did the top commit using the lowercase name. Please do a
> git pull -f to get the new version of that commit.
Thanks. Will do.
^ permalink raw reply
* Re: [ANNOUNCE] GitJungle is out!
From: psantosl @ 2010-12-14 16:42 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, David Suárez
In-Reply-To: <4D079155.4020102@alum.mit.edu>
Hi Michael,
The commits are walked from the heads, starting on master. Once a commit
is assigned to a branch, it stays there. So the diagram would have a
different aspect if the heads were walked in a different order.
David (in CC) is the one to ask for details, he's still struggling to
get a better render than what we have right now.
Thanks,
pablo
On 12/14/2010 16:46, Michael Haggerty wrote:
> On 12/13/2010 12:12 PM, psantosl@codicesoftware.com wrote:
>> We've just released GitJungle
>> [...] The drawing approach we use is a little bit
>> different from what other git tools are using: we draw horizontally
>> instead of vertically, we think it is a better way but, you know, it is
>> probably a matter of preference.
>
> Given that git doesn't permanently record the branch that a commit was
> first made on, how do you decide on what row to draw a commit? E.g., if
> I have two branches A and B that share a common ancestor
>
> o-o <- A
> /
> o-o-o
> \
> o-o <- B
>
> how do you decide whether to draw the ancestor on the row for A vs. the
> row for B?
>
> Michael
>
^ permalink raw reply
* Re: duplicate commits after git rebase -i HEAD~10
From: Gavin Guo @ 2010-12-14 16:07 UTC (permalink / raw)
To: Jeff King; +Cc: Mathieu Malaterre, git
In-Reply-To: <20101203153435.GA6069@sigill.intra.peff.net>
The first one:
> git checkout master
> git reset --hard HEAD^
> git merge your-branch
The second:
> git checkout tmp-branch M^
> git merge your-branch
> git rebase --onto tmp-branch M master
> git branch -d tmp-branch
I don't exactly know what the difference between the two methods to
solve the duplicate problem. Why if there is already a built under
master need to use the second solution? It seems the same to me to
solve the problem.
Gavin Guo
^ permalink raw reply
* [PATCH] gitweb: Fix handling of whitespace in generated links
From: Jakub Narebski @ 2010-12-14 15:54 UTC (permalink / raw)
To: git; +Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley
When creating path_info part of link, don't encode space as '+', because
while $cgi->param('foo') translates '+' in query param to ' ', neither
$ENV{'PATH_INFO'} nor $cgi->path_info() do.
This fixes the issue with pathnames with embedded whitespace and
$feature{'pathinfo'} / path_info links. It is done bu using newly
introduced esc_path_info() instead of esc_url() in href() subroutine.
Also while links are more clear not escaping space (' ') characters in
generated links, the trailing space must be URI-encoded, otherwise would
get discarded.
Issue noticed thanks to John 'Warthog9' Hawley.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
J.H., this fixes the noticed issue.
gitweb/gitweb.perl | 31 +++++++++++++++++++++++--------
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d0dd4d..f5bfb87 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1230,7 +1230,7 @@ sub href {
$href =~ s,/$,,;
# Then add the project name, if present
- $href .= "/".esc_url($params{'project'});
+ $href .= "/".esc_path_info($params{'project'});
delete $params{'project'};
# since we destructively absorb parameters, we keep this
@@ -1240,7 +1240,8 @@ sub href {
# Summary just uses the project path URL, any other action is
# added to the URL
if (defined $params{'action'}) {
- $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
+ $href .= "/".esc_path_info($params{'action'})
+ unless $params{'action'} eq 'summary';
delete $params{'action'};
}
@@ -1250,13 +1251,13 @@ sub href {
|| $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
if (defined $params{'hash_parent_base'}) {
- $href .= esc_url($params{'hash_parent_base'});
+ $href .= esc_path_info($params{'hash_parent_base'});
# skip the file_parent if it's the same as the file_name
if (defined $params{'file_parent'}) {
if (defined $params{'file_name'} && $params{'file_parent'} eq $params{'file_name'}) {
delete $params{'file_parent'};
} elsif ($params{'file_parent'} !~ /\.\./) {
- $href .= ":/".esc_url($params{'file_parent'});
+ $href .= ":/".esc_path_info($params{'file_parent'});
delete $params{'file_parent'};
}
}
@@ -1264,19 +1265,19 @@ sub href {
delete $params{'hash_parent'};
delete $params{'hash_parent_base'};
} elsif (defined $params{'hash_parent'}) {
- $href .= esc_url($params{'hash_parent'}). "..";
+ $href .= esc_path_info($params{'hash_parent'}). "..";
delete $params{'hash_parent'};
}
- $href .= esc_url($params{'hash_base'});
+ $href .= esc_path_info($params{'hash_base'});
if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
- $href .= ":/".esc_url($params{'file_name'});
+ $href .= ":/".esc_path_info($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= esc_url($params{'hash'});
+ $href .= esc_path_info($params{'hash'});
delete $params{'hash'};
}
@@ -1309,6 +1310,9 @@ sub href {
}
$href .= "?" . join(';', @result) if scalar @result;
+ # final transformation: trailing spaces must be escaped (URI-encoded)
+ $href =~ s/(\s+)$/CGI::escape($1)/e;
+
return $href;
}
@@ -1391,6 +1395,17 @@ sub esc_param {
return $str;
}
+# the quoting rules for path_info fragment are slightly different
+sub esc_path_info {
+ my $str = shift;
+ return undef unless defined $str;
+
+ # path_info doesn't treat '+' as space (specially), but '?' must be escaped
+ $str =~ s/([^A-Za-z0-9\-_.~();\/;:@&= +]+)/CGI::escape($1)/eg;
+
+ return $str;
+}
+
# quote unsafe chars in whole URL, so some characters cannot be quoted
sub esc_url {
my $str = shift;
^ permalink raw reply related
* Re: [ANNOUNCE] GitJungle is out!
From: Michael Haggerty @ 2010-12-14 15:46 UTC (permalink / raw)
To: psantosl@codicesoftware.com; +Cc: git
In-Reply-To: <4D05FF8D.7080306@codicesoftware.com>
On 12/13/2010 12:12 PM, psantosl@codicesoftware.com wrote:
> We've just released GitJungle
> [...] The drawing approach we use is a little bit
> different from what other git tools are using: we draw horizontally
> instead of vertically, we think it is a better way but, you know, it is
> probably a matter of preference.
Given that git doesn't permanently record the branch that a commit was
first made on, how do you decide on what row to draw a commit? E.g., if
I have two branches A and B that share a common ancestor
o-o <- A
/
o-o-o
\
o-o <- B
how do you decide whether to draw the ancestor on the row for A vs. the
row for B?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 14/19] Convert ce_path_match() use to match_pathspec()
From: Nguyen Thai Ngoc Duy @ 2010-12-14 15:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjy1zcyg.fsf@alter.siamese.dyndns.org>
2010/12/14 Junio C Hamano <gitster@pobox.com>:
> I imagine that eventually ce_path_match() will also take "struct pathspec *"
> not "const char **" when the series is completed, yes? Or there is no
> real need for that?
But I do have the patches to convert ce_path_match to struct
pathspec*. Hmm.. I did. Need to look into reflogs..
--
Duy
^ permalink raw reply
* Re: [PATCH 12/19] tree_entry_interesting(): support wildcard matching
From: Nguyen Thai Ngoc Duy @ 2010-12-14 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaak935ob.fsf@alter.siamese.dyndns.org>
2010/12/14 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> tree-walk.c | 33 ++++++++++++++++++++++++++++++---
>> tree-walk.h | 2 +-
>> 2 files changed, 31 insertions(+), 4 deletions(-)
>
> ;-) Looks almost too easy.
Much better, yes. I went the wrong way and allowed wildcards in
directory matching too. It turned tree_entry_interesting() into hell.
>> + never_interesting = 0;
>
> When we have wildcard we would want to disable the never-interesting
> optimization, but I wonder if doing so only when we do not have exact hit
> is what we want. If a sick person had a path "a?b" tracked, and asked to
> match a pathspec "a?b", don't we still want to say "'a?b' of course
> matches, but 'a1b' ('1' comes earlier than '?' in the sort order) and
> 'aAb' ('A' comes later) also match"?
Heck, yeah. Easier for me though, just put this at top :-)
int never_interesting = ps->has_wildcard ? 0 : -1;
--
Duy
^ permalink raw reply
* Re: [PATCH 11/19] tree_entry_interesting: support depth limit
From: Nguyen Thai Ngoc Duy @ 2010-12-14 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrnd1r2s.fsf@alter.siamese.dyndns.org>
2010/12/14 Junio C Hamano <gitster@pobox.com>:
>> +int within_depth(const char *name, int namelen,
>> + int depth, int max_depth)
>> +{
>> + const char *cp = name, *cpe = name + namelen;
>> +
>> + while (cp < cpe) {
>> + if (*cp++ != '/')
>> + continue;
>> + depth++;
>> + if (depth > max_depth)
>> + return 0;
>> + }
>> + return 1;
>> +}
>
> Makes me almost suspect that it may make more sense to keep track of the
> "depth" in a similar way as "base" and "baselen" as "traversal state" on
> the side of the caller so that you do not have to scan the string for
> slashes over and over again. But given the codeflow, doing so might make
> the result look too ugly, so I won't recommend that without thinking,
> though.
Moreover, this function is also used by match_pathspec_depth().
>> - if (!ps || !ps->nr)
>> + if (!ps)
>> return 1;
>>
>> + if (!ps->nr) {
>> + if (!ps->recursive || ps->max_depth == -1)
>> + return 1;
>> + return !!within_depth(base, baselen,
>> + !!S_ISDIR(entry->mode),
>> + ps->max_depth);
>> + }
>
> This gives different behaviour to between callers that give you NULL as
> pathspec and callers that give you a pathspec with zero elements. Is this
> intended? What is the use case (iow, what does an end user give from the
> command line to experience this difference)?
Old pathspec type's legacy. When pathspec is of "const char **", it
can be NULL. When struct pathspec is used, I don't think we need to
support NULL pathspec. Will remove that "if (!ps)" clause.
>> @@ -571,7 +580,13 @@ int tree_entry_interesting(const struct name_entry *entry,
>> if (!match_dir_prefix(base, baselen, match, matchlen))
>> /* Just a random prefix match */
>> continue;
>> - return 2;
>> +
>> + if (!ps->recursive || ps->max_depth == -1)
>> + return 2;
>> +
>> + return !!within_depth(base+matchlen+1, baselen-matchlen-1,
>> + !!S_ISDIR(entry->mode),
>> + ps->max_depth);
>> }
>
> If two pathspecs that overlap with each other (e.g. "Documentation/" and
> "Documentation/technical") are given, and if the shorter one comes before
> the longer one in ps[], wouldn't this give you an unexpected result? When
> inspecting "Documentation/technical/api/foo.txt" with depth limit of 2, if
> you didn't have "Documentation/" pathspec, you count "api/foo.txt"
> relative to "Documentation/technical", declare that the path is within
> limit, and show it. But if you have "Documentation/" in ps[], you look at
> it, decide "technical/api/foo.txt" is too deep and return false without
> even looking at "Documentation/technical" that may appear later in ps[],
> no?
Right. Hmm.. grep's pathspec_matches() probably has this problem too.
--
Duy
^ permalink raw reply
* Re: Corruption in the repository
From: Sylvestre Ledru @ 2010-12-14 14:37 UTC (permalink / raw)
To: git, Simon Gareste, Bruno JOFRET
In-Reply-To: <AANLkTinoD2qn7ZqMtGbSjJgkVUNE--fOsrSKzqTLCLpP@mail.gmail.com>
Le mardi 14 décembre 2010 à 12:59 +0100, Christian Couder a écrit :
> On Tue, Dec 14, 2010 at 10:47 AM, Sylvestre Ledru
> <sylvestre.ledru@scilab.org> wrote:
> > Le mardi 14 décembre 2010 à 10:29 +0100, Christian Couder a écrit :
> >> On Mon, Dec 13, 2010 at 7:11 PM, Sylvestre Ledru
> >> <sylvestre.ledru@scilab.org> wrote:
> >> > Le lundi 13 décembre 2010 à 18:02 +0100, Christian Couder a écrit :
> >> >> On Mon, Dec 13, 2010 at 5:47 PM, Sylvestre Ledru
> >> >> <sylvestre.ledru@scilab.org> wrote:
> >> >> >
> >> >> > Le lundi 13 décembre 2010 à 17:34 +0100, Christian Couder a écrit :
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Mon, Dec 13, 2010 at 4:59 PM, Sylvestre Ledru
> >> >> >> <sylvestre.ledru@scilab.org> wrote:
> >> >> >> > Hello guys,
> >> >> >> >
> >> >> >> > I have a small problem with a git repository and I haven't find a way to
> >> >> >> > fix my problem.
> >> >> >> > I am using git with gerrit [1] as frontend (even if I don't think it is
> >> >> >> > related here).
> >> >> >> > For an unknown reason, the repository just became corrupted.
> >> >> >> >
> >> >> >> > When I try to clone the repository straight with the file system, the
> >> >> >> > following error is displayed:
> >> >> >> > error: refs/changes/98/398/1 does not point to a valid object!
> >> >> >> > error: refs/changes/98/398/2 does not point to a valid object!
> >> >> >> > fatal: object cff52c24fba28408e7d021a8f35a717bef31521d is corrupted
> >> >> >> > fatal: The remote end hung up unexpectedly
> >> >> >> >
> >> >> >> > git-prune & git-fsck both fail.
> >> >> >> >
> >> >> >> > Does anyone know how to repair this error ?
> >> >> >>
> >> >> >> Did you try what the FAQ suggests:
> >> >> >>
> >> >> >> https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F
> >> >> > Yes. It shows an other error and it doesn't match the error described on
> >> >> > this URL [1].
> >> >> >
> >> >> > I get the following:
> >> >> > error: refs/tags/5.3.0-beta-4 does not point to a valid object!
> >> >> > fatal: object 555a7c359b2e589ec10822d9b56cdfeee0105fe0 is corrupted
> >> >>
> >> >> The FAQ says that you should try to replace any broken and/or missing
> >> >> objects, so you should try to do that with object
> >> >> 555a7c359b2e589ec10822d9b56cdfeee0105fe0 (as described in the FAQ)
> >> >> even if the error message is not exactly the same.
> >> > Well, after clean the error about the tags, it does not provide any
> >> > interesting feedbacks like in the FAQ.
> >> >
> >> > Just some information [1] about some dangling commits (probably commit
> >> > under review in gerrit). Nothing valuable and the problem still occurs
> >> > on the client side.
> >>
> >> So you say that "git fsck --full" gives only dangling commits on the
> >> server, and you still get messages like "fatal: object XXXXX is
> >> corrupted" on the client when you try to clone with gerrit?
> > Not exactly, when I try to clone it through gerrit, it is working:
> > git clone ssh://sylvestre.ledru@git.scilab.org:29418/scilab
> > A bare clone works also.
> >
> > It is failing when I am using git-daemon (git clone
> > git://git.scilab.org/scilab) or a straight clone (git
> > clone /home/git/repositories/repo.git).
>
> This is very strange, are you sure you cannot use the resulting repo
> when it "fails"?
> What happens when you run "git fsck --full" on the resulting repos?
>
> > Both with the same error:
> > error: refs/changes/98/398/1 does not point to a valid object!
> > error: refs/changes/98/398/2 does not point to a valid object!
>
> Did you try to see which objects these refs are pointing to, and if
> they are on the server?
In fact, we have some progress on the issue.
It looks like, at some point, two tags have been badly created [1].
Here is what Bruno did to fix the issue:
1 - Add valid references
I put some valid commit id in refs/changes/98/398/{1,2}
2 - Find out what the corrupted object was for
$> git cat-file -t cff52c24fba28408e7d021a8f35a717bef31521d
tag
$> cat refs/tags/5.3.0-beta-4
cff52c24fba28408e7d021a8f35a717bef31521d
$> git tag -d 5.3.0-beta-4
3 - Server complains :
fatal: git upload-pack: unable to fork git-pack-objects
$> git gc (on the server)
Solved this problem.
Hope this helps for others,
Sylvestre
[1] Looks at my mail archive, the guy who created the tag did it this
way:
[$SHELL] cd /home/git/repositories/scilab.git
[$SHELL] git tag -d 5.3.0-beta-4
[$SHELL] git tag -m "Scilab 5.3.0 Beta 4 Version" 5.3.0-beta-4
96b0b8e6d621a7ea7c88d63e10d57908689632ed
^ permalink raw reply
* Re: Revert-style merge/Working tree-only checkout?
From: Neal Kreitzinger @ 2010-12-14 14:36 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTi=ioX25aqXg-yWDA0oXBTATkFe+J25g-dB7-psS@mail.gmail.com>
"Yuriy Romanenko" <groman@gmail.com> wrote in message
news:AANLkTi=ioX25aqXg-yWDA0oXBTATkFe+J25g-dB7-psS@mail.gmail.com...
> Hello,
>
> I am somewhat new to Git and I keep running into having to accomplish
> a certain task and reading through the documentation I can't seem to
> find any way of doing this easily.
>
> The problem is when branches diverge and I want to sync a branch to
> another branch with full overwrite, but maintain history and maintain
> separate branches.
>
> For example, say there is a branch "master" and I create a branch "b1"
> from master at some point. After this, there are 5 commits
> (C1,C2,C3,C4,C5) to master and
> 17 commits to b1 (let's call them cb1, cb2, cb3, ..., cb17). Say I
> want to create an 18-th commit to "b1" that makes it identical to the
> C5 (current) state of master. Essentially a single commit wipe of
> changes cb1 -> cb17 as well as application of C1->C5. So far I have
> found one way of accomplishing this, but it is difficult, error prone,
> slow and I just plain don't like it. I feel like there should be an
> easier way.
>
> What I currently do:
>
> $ rm -rf *
> $ git checkout -f master
> $ tar -cvzf /tmp/master.tar.gz *
> $ git checkout b1
> $ rm -rf *
> $ tar -xvzf /tmp/master.tar.gz
> $ git add
> $ git commit -a
> $ git merge master
>
>
> I've considered doing something like the following
>
> $ git checkout b1
> $ git revert b1~17..b1
> $ git merge master
>
> but it also seems wrong, and requires me to count the submits by hand,
> which seems silly --> I'm not actually reverting anything. I don't
> know if this would even work.
>
>
> Any suggestions on how to accomplish this easier? Some sort of a
> force-checkout that affects working tree only but not the index?
>
Have you looked at the vendor branch methodology in the git-rm manpage? It
may give you some ideas you're interested in.
v/r,
Neal
^ permalink raw reply
* Re: [git-svn] always prompted for passphrase with subversion 1.6
From: Edward Rudd @ 2010-12-14 14:33 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <4AA84F46.6010706@hp.com>
On 09/09/2009 08:58 PM, Tim Potter wrote:
> It's probably just a matter of adding another entry to the
> _auth_providers() function in git-svn. My thought was that there might
> be a new auth provider in the Subversion 1.6 client library for GNOME
> Keyring support that could be used for this.
>
> I'll have a search through and see what I can find.
I've been tracking subversion bug # 3612
(http://subversion.tigris.org/issues/show_bug.cfg?id=3612 ) which is on
this issue of perl binding not supporting platform specific providers.
A patch was added into subversion 1.6.15 that finally adds bindings for
perl to access this functionality via a call to
SVN::Core::auth_get_platform_specific_client_providers and adding it's
contents to the array returned by _auth_providers..
The "test" modification I did to git-svn is as follows.
sub _auth_providers () {
(
SVN::Core::auth_get_platform_specific_client_providers(undef,undef),
[
SVN::Client::get_simple_provider(),
.... the rest of the static provider ...
]
)
}
I'm honestly not sure if it should be at the beginning or end, and this
also needs some run-time checking to determine if the user has at least
SVN 1.6.15 installed
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Yaroslav Halchenko @ 2010-12-14 14:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4D071B60.2040906@viscovery.net>
On Tue, 14 Dec 2010, Johannes Sixt wrote:
> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;) unfortunately it doesn't produce a merge
> > for me :-/ -- just a simple commit with the state taken from the other tree:
> How about:
> git merge --no-commit -s ours 0.2
> git read-tree -m -u 0.2
> git commit -m "Reset to 0.2"
Thank you Johannes for chewing it up to ease the digestion by my
brainless stomach -- works just fine ;)
I guess this could be the alias for my needs:
mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u "$1"' -
but since it might be a generic pattern for the use case(s) I have
stated I still see no objective reason why simple '-s theirs' should not
be there.
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
^ permalink raw reply
* Re: [PATCH 09/19] tree-diff.c: reserve space in "base" for pathname concatenation
From: Nguyen Thai Ngoc Duy @ 2010-12-14 13:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4D0728F0.9020807@viscovery.net>
On Tue, Dec 14, 2010 at 3:21 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 12/14/2010 8:43, schrieb Nguyen Thai Ngoc Duy:
>> On Tue, Dec 14, 2010 at 2:32 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Am 12/14/2010 6:32, schrieb Junio C Hamano:
>>>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>>>
>>>>> All paths should not exceed PATH_MAX, right?
>>>>
>>>> Your PATH_MAX may be a lot shorter than the PATH_MAX on the system I
>>>> created my trees on that you are reading.
>>>
>>> And that is not just gray theory: On Windows, PATH_MAX is whopping 260
>>> characters!
>>
>> Does that mean Windows won't accept any path longer than that, or
>> PATH_MAX is defined just for fun?
>
> It is the limit for path names that we can have without MAJOR extra
> efforts. It is not a limit implied by the file system.
Just googled around and found this [1]. I'm going with strbuf so it
can be reallocated if necessary. A bit tricky because "base" can be
moved, but I think it's worth it.
[1] http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
--
Duy
^ permalink raw reply
* Re: [PATCH 01/19] Add struct pathspec
From: Nguyen Thai Ngoc Duy @ 2010-12-14 12:50 UTC (permalink / raw)
To: Thiago Farina; +Cc: git, Junio C Hamano
In-Reply-To: <AANLkTim+6d+XZ7j4pxE+WwBCsAvcZfN2qYu4=1rs6AAn@mail.gmail.com>
2010/12/14 Thiago Farina <tfransosi@gmail.com>:
>> +void free_pathspec(struct pathspec *pathspec)
>> +{
>> + ; /* do nothing */
>
> Of curse this ; here is not necessary :)
>
Well, can't please everyone [1]. It's for clarity only.
free_pathspec() becomes real in the next patches.
[1] http://mid.gmane.org/7vbp7ix20u.fsf@alter.siamese.dyndns.org
--
Duy
^ permalink raw reply
* Re: Corruption in the repository
From: Christian Couder @ 2010-12-14 11:59 UTC (permalink / raw)
To: Sylvestre Ledru; +Cc: git, Simon Gareste, Bruno JOFRET
In-Reply-To: <1292320068.25237.28773.camel@korcula.inria.fr>
On Tue, Dec 14, 2010 at 10:47 AM, Sylvestre Ledru
<sylvestre.ledru@scilab.org> wrote:
> Le mardi 14 décembre 2010 à 10:29 +0100, Christian Couder a écrit :
>> On Mon, Dec 13, 2010 at 7:11 PM, Sylvestre Ledru
>> <sylvestre.ledru@scilab.org> wrote:
>> > Le lundi 13 décembre 2010 à 18:02 +0100, Christian Couder a écrit :
>> >> On Mon, Dec 13, 2010 at 5:47 PM, Sylvestre Ledru
>> >> <sylvestre.ledru@scilab.org> wrote:
>> >> >
>> >> > Le lundi 13 décembre 2010 à 17:34 +0100, Christian Couder a écrit :
>> >> >> Hi,
>> >> >>
>> >> >> On Mon, Dec 13, 2010 at 4:59 PM, Sylvestre Ledru
>> >> >> <sylvestre.ledru@scilab.org> wrote:
>> >> >> > Hello guys,
>> >> >> >
>> >> >> > I have a small problem with a git repository and I haven't find a way to
>> >> >> > fix my problem.
>> >> >> > I am using git with gerrit [1] as frontend (even if I don't think it is
>> >> >> > related here).
>> >> >> > For an unknown reason, the repository just became corrupted.
>> >> >> >
>> >> >> > When I try to clone the repository straight with the file system, the
>> >> >> > following error is displayed:
>> >> >> > error: refs/changes/98/398/1 does not point to a valid object!
>> >> >> > error: refs/changes/98/398/2 does not point to a valid object!
>> >> >> > fatal: object cff52c24fba28408e7d021a8f35a717bef31521d is corrupted
>> >> >> > fatal: The remote end hung up unexpectedly
>> >> >> >
>> >> >> > git-prune & git-fsck both fail.
>> >> >> >
>> >> >> > Does anyone know how to repair this error ?
>> >> >>
>> >> >> Did you try what the FAQ suggests:
>> >> >>
>> >> >> https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F
>> >> > Yes. It shows an other error and it doesn't match the error described on
>> >> > this URL [1].
>> >> >
>> >> > I get the following:
>> >> > error: refs/tags/5.3.0-beta-4 does not point to a valid object!
>> >> > fatal: object 555a7c359b2e589ec10822d9b56cdfeee0105fe0 is corrupted
>> >>
>> >> The FAQ says that you should try to replace any broken and/or missing
>> >> objects, so you should try to do that with object
>> >> 555a7c359b2e589ec10822d9b56cdfeee0105fe0 (as described in the FAQ)
>> >> even if the error message is not exactly the same.
>> > Well, after clean the error about the tags, it does not provide any
>> > interesting feedbacks like in the FAQ.
>> >
>> > Just some information [1] about some dangling commits (probably commit
>> > under review in gerrit). Nothing valuable and the problem still occurs
>> > on the client side.
>>
>> So you say that "git fsck --full" gives only dangling commits on the
>> server, and you still get messages like "fatal: object XXXXX is
>> corrupted" on the client when you try to clone with gerrit?
> Not exactly, when I try to clone it through gerrit, it is working:
> git clone ssh://sylvestre.ledru@git.scilab.org:29418/scilab
> A bare clone works also.
>
> It is failing when I am using git-daemon (git clone
> git://git.scilab.org/scilab) or a straight clone (git
> clone /home/git/repositories/repo.git).
This is very strange, are you sure you cannot use the resulting repo
when it "fails"?
What happens when you run "git fsck --full" on the resulting repos?
> Both with the same error:
> error: refs/changes/98/398/1 does not point to a valid object!
> error: refs/changes/98/398/2 does not point to a valid object!
Did you try to see which objects these refs are pointing to, and if
they are on the server?
Regards,
Christian.
^ permalink raw reply
* Re: Corruption in the repository
From: Sylvestre Ledru @ 2010-12-14 9:59 UTC (permalink / raw)
To: Simon Gareste, Bruno JOFRET, git
In-Reply-To: <20101214094601.GA21755@burratino>
Le mardi 14 décembre 2010 à 03:46 -0600, Jonathan Nieder a écrit :
> Christian Couder wrote:
>
> > When I try "git grep corrupted" on the git and gerrit sources I don't
> > find anything relevant.
>
> The error message was changed by b6c4cec (read_sha1_file(): report
> correct name of packfile with a corrupt object, 2010-10-28) and
> especially v1.7.3-rc0~73^2 (sha1_file: Show the the type and path to
> corrupt objects, 2010-06-10).
>
> Random guess: maybe a corrupt but redundant packed object was removed
> in the course of investigation?
We haven't tried to delete files. We have been careful (at least, try
to)
> Sylvestre, are you still able to get errors from the repository?
Sure
> If you still have a copy of the original
> corrupt version of the repository, I would be interested (to learn
> something about how it got damaged in the first place).
Me too.
I send you the URL in private (it is 344M).
Sylvestre
^ permalink raw reply
* Re: Corruption in the repository
From: Sylvestre Ledru @ 2010-12-14 9:47 UTC (permalink / raw)
To: git, Simon Gareste, Bruno JOFRET
In-Reply-To: <AANLkTikP3CTNX_S=fAWTBVbt0OwQMLr+mq8f72OFd0j6@mail.gmail.com>
Le mardi 14 décembre 2010 à 10:29 +0100, Christian Couder a écrit :
> On Mon, Dec 13, 2010 at 7:11 PM, Sylvestre Ledru
> <sylvestre.ledru@scilab.org> wrote:
> > Le lundi 13 décembre 2010 à 18:02 +0100, Christian Couder a écrit :
> >> On Mon, Dec 13, 2010 at 5:47 PM, Sylvestre Ledru
> >> <sylvestre.ledru@scilab.org> wrote:
> >> >
> >> > Le lundi 13 décembre 2010 à 17:34 +0100, Christian Couder a écrit :
> >> >> Hi,
> >> >>
> >> >> On Mon, Dec 13, 2010 at 4:59 PM, Sylvestre Ledru
> >> >> <sylvestre.ledru@scilab.org> wrote:
> >> >> > Hello guys,
> >> >> >
> >> >> > I have a small problem with a git repository and I haven't find a way to
> >> >> > fix my problem.
> >> >> > I am using git with gerrit [1] as frontend (even if I don't think it is
> >> >> > related here).
> >> >> > For an unknown reason, the repository just became corrupted.
> >> >> >
> >> >> > When I try to clone the repository straight with the file system, the
> >> >> > following error is displayed:
> >> >> > error: refs/changes/98/398/1 does not point to a valid object!
> >> >> > error: refs/changes/98/398/2 does not point to a valid object!
> >> >> > fatal: object cff52c24fba28408e7d021a8f35a717bef31521d is corrupted
> >> >> > fatal: The remote end hung up unexpectedly
> >> >> >
> >> >> > git-prune & git-fsck both fail.
> >> >> >
> >> >> > Does anyone know how to repair this error ?
> >> >>
> >> >> Did you try what the FAQ suggests:
> >> >>
> >> >> https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F
> >> > Yes. It shows an other error and it doesn't match the error described on
> >> > this URL [1].
> >> >
> >> > I get the following:
> >> > error: refs/tags/5.3.0-beta-4 does not point to a valid object!
> >> > fatal: object 555a7c359b2e589ec10822d9b56cdfeee0105fe0 is corrupted
> >>
> >> The FAQ says that you should try to replace any broken and/or missing
> >> objects, so you should try to do that with object
> >> 555a7c359b2e589ec10822d9b56cdfeee0105fe0 (as described in the FAQ)
> >> even if the error message is not exactly the same.
> > Well, after clean the error about the tags, it does not provide any
> > interesting feedbacks like in the FAQ.
> >
> > Just some information [1] about some dangling commits (probably commit
> > under review in gerrit). Nothing valuable and the problem still occurs
> > on the client side.
>
> So you say that "git fsck --full" gives only dangling commits on the
> server, and you still get messages like "fatal: object XXXXX is
> corrupted" on the client when you try to clone with gerrit?
Not exactly, when I try to clone it through gerrit, it is working:
git clone ssh://sylvestre.ledru@git.scilab.org:29418/scilab
A bare clone works also.
It is failing when I am using git-daemon (git clone
git://git.scilab.org/scilab) or a straight clone (git
clone /home/git/repositories/repo.git).
Both with the same error:
error: refs/changes/98/398/1 does not point to a valid object!
error: refs/changes/98/398/2 does not point to a valid object!
> By the way could you tell us which version of git and gerrit you are using?
git 1.7.2.3 & gerrit 2.1.5
Sylvestre
^ permalink raw reply
* Re: Corruption in the repository
From: Jonathan Nieder @ 2010-12-14 9:46 UTC (permalink / raw)
To: Christian Couder; +Cc: Sylvestre Ledru, git, Simon Gareste, Bruno JOFRET
In-Reply-To: <AANLkTikP3CTNX_S=fAWTBVbt0OwQMLr+mq8f72OFd0j6@mail.gmail.com>
Christian Couder wrote:
> When I try "git grep corrupted" on the git and gerrit sources I don't
> find anything relevant.
The error message was changed by b6c4cec (read_sha1_file(): report
correct name of packfile with a corrupt object, 2010-10-28) and
especially v1.7.3-rc0~73^2 (sha1_file: Show the the type and path to
corrupt objects, 2010-06-10).
Random guess: maybe a corrupt but redundant packed object was removed
in the course of investigation? Sylvestre, are you still able to get
errors from the repository? If you still have a copy of the original
corrupt version of the repository, I would be interested (to learn
something about how it got damaged in the first place).
^ permalink raw reply
* Re: Corruption in the repository
From: Christian Couder @ 2010-12-14 9:29 UTC (permalink / raw)
To: Sylvestre Ledru; +Cc: git, Simon Gareste, Bruno JOFRET
In-Reply-To: <1292263868.25237.27772.camel@korcula.inria.fr>
On Mon, Dec 13, 2010 at 7:11 PM, Sylvestre Ledru
<sylvestre.ledru@scilab.org> wrote:
> Le lundi 13 décembre 2010 à 18:02 +0100, Christian Couder a écrit :
>> On Mon, Dec 13, 2010 at 5:47 PM, Sylvestre Ledru
>> <sylvestre.ledru@scilab.org> wrote:
>> >
>> > Le lundi 13 décembre 2010 à 17:34 +0100, Christian Couder a écrit :
>> >> Hi,
>> >>
>> >> On Mon, Dec 13, 2010 at 4:59 PM, Sylvestre Ledru
>> >> <sylvestre.ledru@scilab.org> wrote:
>> >> > Hello guys,
>> >> >
>> >> > I have a small problem with a git repository and I haven't find a way to
>> >> > fix my problem.
>> >> > I am using git with gerrit [1] as frontend (even if I don't think it is
>> >> > related here).
>> >> > For an unknown reason, the repository just became corrupted.
>> >> >
>> >> > When I try to clone the repository straight with the file system, the
>> >> > following error is displayed:
>> >> > error: refs/changes/98/398/1 does not point to a valid object!
>> >> > error: refs/changes/98/398/2 does not point to a valid object!
>> >> > fatal: object cff52c24fba28408e7d021a8f35a717bef31521d is corrupted
>> >> > fatal: The remote end hung up unexpectedly
>> >> >
>> >> > git-prune & git-fsck both fail.
>> >> >
>> >> > Does anyone know how to repair this error ?
>> >>
>> >> Did you try what the FAQ suggests:
>> >>
>> >> https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F
>> > Yes. It shows an other error and it doesn't match the error described on
>> > this URL [1].
>> >
>> > I get the following:
>> > error: refs/tags/5.3.0-beta-4 does not point to a valid object!
>> > fatal: object 555a7c359b2e589ec10822d9b56cdfeee0105fe0 is corrupted
>>
>> The FAQ says that you should try to replace any broken and/or missing
>> objects, so you should try to do that with object
>> 555a7c359b2e589ec10822d9b56cdfeee0105fe0 (as described in the FAQ)
>> even if the error message is not exactly the same.
> Well, after clean the error about the tags, it does not provide any
> interesting feedbacks like in the FAQ.
>
> Just some information [1] about some dangling commits (probably commit
> under review in gerrit). Nothing valuable and the problem still occurs
> on the client side.
So you say that "git fsck --full" gives only dangling commits on the
server, and you still get messages like "fatal: object XXXXX is
corrupted" on the client when you try to clone with gerrit? Did you
try to clone using git? Please try it and give us the exact command
and result that you get.
By the way could you tell us which version of git and gerrit you are using?
When I try "git grep corrupted" on the git and gerrit sources I don't
find anything relevant.
Regards,
Christian.
^ permalink raw reply
* [PATCH 1/2] git-difftool.txt: correct the description of $BASE and describe $MERGED
From: Michael J Gruber @ 2010-12-14 9:18 UTC (permalink / raw)
To: git; +Cc: David Aguilar
In-Reply-To: <4D073619.2010103@drmicha.warpmail.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-difftool.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 6fffbc7..756d95d 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -56,8 +56,9 @@ the configured command line will be invoked with the following
variables available: `$LOCAL` is set to the name of the temporary
file containing the contents of the diff pre-image and `$REMOTE`
is set to the name of the temporary file containing the contents
-of the diff post-image. `$BASE` is provided for compatibility
-with custom merge tool commands and has the same value as `$LOCAL`.
+of the diff post-image. `$MERGED` is the name of the file which is
+being compared. `$BASE` is provided for compatibility
+with custom merge tool commands and has the same value as `$MERGED`.
-x <command>::
--extcmd=<command>::
--
1.7.3.3.739.g52f77.dirty
^ permalink raw reply related
* [PATCH 2/2] difftool: provide basename to external tools
From: Michael J Gruber @ 2010-12-14 9:18 UTC (permalink / raw)
To: git; +Cc: David Aguilar
In-Reply-To: <0833a4451b70db4c4e0be5753be53e262a9c5628.1292317348.git.git@drmicha.warpmail.net>
Currently, only configured diff helpers get the basename of the file
being compared. Tools specified with "git difftool -x" only get the
names of temporary files for the different versions.
Export BASE so that an external tool can read the name from the
environment. Rather than using a third argument, this avoids breaking
existing scripts which may somewhat carelessly be using "$@" rather than
"$1" "$2".
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-difftool.txt | 1 +
git-difftool--helper.sh | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 756d95d..db87f1d 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -65,6 +65,7 @@ with custom merge tool commands and has the same value as `$MERGED`.
Specify a custom command for viewing diffs.
'git-difftool' ignores the configured defaults and runs
`$command $LOCAL $REMOTE` when this option is specified.
+ Additionally, `$BASE` is set in the environment.
-g::
--gui::
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 524f5ea..0594bf7 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -49,6 +49,7 @@ launch_merge_tool () {
fi
if use_ext_cmd; then
+ export BASE
eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
else
run_merge_tool "$merge_tool"
--
1.7.3.3.739.g52f77.dirty
^ permalink raw reply related
* Re: how to create a diff in old file new file format (for code reviews)
From: Michael J Gruber @ 2010-12-14 9:17 UTC (permalink / raw)
To: aerosmith; +Cc: git
In-Reply-To: <1292285257962-5832810.post@n2.nabble.com>
aerosmith venit, vidit, dixit 14.12.2010 01:07:
>
> Hi,
>
> I am trying to create a diff such that the original file (entire file) is
> saved something like file1.h.old and the new modified file as file1.h.new. I
> have read the various options for git-diff* tools but could not find one
> such utility. All I get is the removals and additions as a diff. Does anyone
> know how to create one with the help the available git utils? The only
> method that I can think of is to do everything manually. Any help w.r.t.
> this is really appreciated. Thanks in advance.
You could script around this e.g. with an external diff-helper. The
easiest way is to reuse difftool. For example,
git difftool -y -x echo <revexpression>
will give you pairs of names of temporary files for old/new, where
<revexpression> is what you would give to "git diff" to specify what to
diff.
With the patch I'm sending in a minute, the helper you specify with "-x"
can also access the basename easily, so that you could use "-x oldnew"
with a script "oldnew" containing
#!/bin/sh
cp "$1" "$BASE".old
cp "$2" "$BASE".new
Even without the patch, you could use
git difftool -y -x 'cp "$LOCAL" "$BASE".old; cp "$REMOTE" "$BASE.new";
#' <revexpression>
(all on one line) directly. But this requires insider knowledge and may
break some day.
Cheers,
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