Re: [PATCH 2/6] path: Make the 'get_st_mode_bits' symbol a file static
On 2013-04-27 20.42, Ramsay Jones wrote:
On MinGW, sparse issues an 'get_st_mode_bits' not declared. Should
it be static? warning. The MinGW and MSVC builds do not see the
declaration of this function, within git-compat-util.h, due to it's
placement within an preprocessor conditional. (So, one solution would
be to simply move the declaration to the top level of the header.)
In order to suppress the warning, since this symbol does not need
more than file visibility, we simply remove the declaration from
the header and add the static modifier to the function definition.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
git-compat-util.h | 1 -
path.c| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index e955bb5..3a990b3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -163,7 +163,6 @@
typedef long intptr_t;
typedef unsigned long uintptr_t;
#endif
-int get_st_mode_bits(const char *path, int *mode);
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include grp.h
diff --git a/path.c b/path.c
index 04ff148..cc2e9ac 100644
--- a/path.c
+++ b/path.c
@@ -11,7 +11,7 @@
* may return wrong permission bits. Most of the time we do not care,
* but the callsites of this wrapper do care.
*/
-int get_st_mode_bits(const char *path, int *mode)
+static int get_st_mode_bits(const char *path, int *mode)
{
struct stat st;
if (lstat(path, st) 0)
Sorry for breaking the MiNGW/MSVC builds.
It seams that the get_st_mode_bits is badly placed.
It should be in git compat-util.h, so that both compat/cygwin.c and path.c can
see it.
So from my understanding, it should be placed here:
(I will send an official patch later)
/Torsten
diff -C 3 git-compat-util.h.~9526aa461f6c6900cb892a6fe248150ad436c0d~
git-compat-util.h.new
*** git-compat-util.h.~9526aa461f6c6900cb892a6fe248150ad436c0d~ 2013-04-28
07:53:28.0 +0200
--- git-compat-util.h.new 2013-04-28 07:53:58.0 +0200
***
*** 127,132
--- 127,133
#else
#include poll.h
#endif
+ int get_st_mode_bits(const char *path, int *mode);
#if defined(__MINGW32__)
/* pull in Windows compatibility stuff */
#include compat/mingw.h
***
*** 163,169
typedef long intptr_t;
typedef unsigned long uintptr_t;
#endif
- int get_st_mode_bits(const char *path, int *mode);
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include grp.h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents
On 28/04/2013 02:02, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
In the event of an odd merge, we may find ourselves TREESAME to
apparently redundant parents. Prevent simplify_merges() from removing
every TREESAME parent - in the event of such a merge it's useful to see
where we came actually from came.
came from :)
@@ -2106,8 +2106,32 @@ static int remove_marked_parents(struct rev_info *revs,
struct commit *commit)
{
struct treesame_state *ts = lookup_decoration(revs-treesame,
commit-object);
struct commit_list **pp, *p;
+ struct commit *su = NULL, *sm = NULL;
What do su and sm stand for?
same, unmarked and same, marked were what was in my head.
Could you explain here a bit more the reason why we do not want to
remove them and why -s ours is so significant that it deserves to
be singled out? And why randomly picking one that is redundant
(because it is an ancestor of some other parent) is an improvement?
I feel it's consistent with the default non-full-history behaviour. The
parent that we choose not to remove is the same one that the default
log with simplify_history==1 would have followed: the first parent we
are TREESAME to. Or at least that's the intent. So this parent would
normally be singled out, and it's not an arbitrary (or random) choice.
It feels wrong to me that --full-history --simplify-merges could produce
a disjoint history from the default. I think it should include the
default simple history. If this code triggered, it should produce
something quite distinctive in a graphical view, which will help find
odd/broken merges.
The remove-redundant logic first marks commits that are ancestors
of other commits in the original set, without taking treesame[] into
account at all. If the final objective of the code is to keep paths
that consists of non-treesame[] commits, perhaps the logic needs to
be changed to reject non-treesame[] commits that are ancestors of
other non-treesame[] commits, or something?
Maybe - the main simplify_merges machinery could certainly make use of
the treesame[] information, and one of the motivations for introducing
it was to open up the possibility of richer analysis. I'll spend a
little time to think about whether we want a more fundamental change to
the original scan.
But this patch as it stands was an easy change to make with clearly
limited scope and relatively little risk - I specifically wanted just to
include our default simple parent.
Kevin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges
On 28/04/2013 01:36, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
Historically TREESAME was set on a commit if it was TREESAME to _any_ of
its parents. This is not optimal, as such a merge could still be worth
showing, particularly if it is an odd -s ours merge that (possibly
accidentally) dropped a change.
... and with options like --full-history or --simplify-merges are
used to get more complete history, I think. git log path without
these options is a tool to get one version of simplified history
that explains the end result, and by definition, the side branch
merged by -s ours did _not_ contribute anything to the end result.
Yeah, I'm not happy with this commit message - I knocked it up
separately from my first pass, which I didn't have to hand. Next version
will combine it with the original, which better distinguished the
default mode, and specifically addressed the --full-history -S search
problem.
That's key - that I really want such searches to be able to track the
entire life of a change on a side branch, not potentially showing just
its birth as now, but also always including any ultimate merge death. (I
think that we may be able to refine --ancestry-path to give an even
tighter pinpoint, but --full-history should definitely include the
information, as per its name).
Do we want to discard the decoration data when the commit becomes a
non-merge?
Would seem reasonable, and would also help make concrete why we update
TREESAME immediately, and not in update_treesame(), but I didn't spot a
mechanism to discard decoration. I'll recheck.
+ commit-object.flags |= TREESAME;
+ for (n = 0; n st-nparents; n++) {
+ if (!st-treesame[n]) {
+ commit-object.flags = ~TREESAME;
+ break;
+ }
+ }
Can a commit that earlier was marked as TREESAME become not TREESAME?
Wouldn't simplification only increase sameness, never decrease?
That's true - I paid attention to that earlier when it really mattered
due to the cost of recalculating it with try_to_simplify_commit(). Not
sure that it matters so much any more, and I don't see how we can use
that information to change this scan for !treesame loop.
I could insert an if (!commit-object.flags TREESAME) test to skip
the entire update. I'd be inclined to do that as the caller of
update_treesame(). I think update_treesame() itself should be
general-purpose without assumptions about what changes have been made,
so it's a pure treesame[]-TREESAME calculation, without TREESAME as an
input.
(Aside - just occurred to me we could swap the loop for
strlen(st-treesame) == st-nparents, if we kept a zero terminator in
the array. Maybe a bit too smart-ass?)
+ for (pp = commit-parents;
+(parent = *pp) != NULL;
+pp = parent-next, nth_parent++) {
I see the reason to change from while to for is because you wanted
to count, and I think it makes sense; but it is more readable to
initialise the counter here, too, if that is the case. I.e.
for (pp = commit-parents, nth_parent = 0;
!(parent = *pp);
pp = parent-next, nth_parent++) {
Agree on nth_parent, but !(parent = *pp) isn't (parent = *pp) !=
NULL, mind. Did you mean !!? In which case I still prefer it my way.
+ if (!tree_changed)
+ ts-treesame[0] = 1;
Have we made any two tree comparison at this point to set this one?
Ahh, this is tricky. You do this in the _second_ iteration of the
loop, so tree_changed here is from inspecting the first parent, not
the one we are looking at (i.e. *p).
Yes, this is the we've reached our second iteration, so from now on
we're dealing a merge if {} block. I'll clarify this in the comment at
the top, and note that we're populating the newly-allocated treesame[]
from our first iteration.
@@ -773,6 +861,9 @@ static void limit_to_ancestry(struct commit_list *bottom, struct commit_list *li
* NEEDSWORK: decide if we want to remove parents that are
* not marked with TMP_MARK from commit-parents for commits
* in the resulting list. We may not want to do that, though.
+*
+* Maybe it should be considered if we are TREESAME to such
+* parents - now possible with stored per-parent flags.
*/
Hmm, that is certainly a thought.
My comment's wrong though. Reconsidering, what I think needs removing is
actually off-ancestry parents that we are !TREESAME to, when we are
TREESAME on the ancestry path.
I've realised while testing this that there's been one thing that's
confused me repeatedly, and I think this comment was an example of it.
The example in the rev-list-options manual is wrong.
.-A---M---N---O---P
/ / / / /
I B C D E
\ / /
[PATCH 1/2] git-svn: fix occasional Failed to strip path error on fetch next commit
When --stdlayout and --preserve-empty-dirs flags are used and a
directory becomes empty, sometimes no empty dir placeholder file
created. Then on fetch next commit git-svn dies with Failed to strip
path error.
Test script:
rm -rf testrepo.svn testrepo.gitsvn
svnadmin create testrepo.svn
url=file://`pwd`/testrepo.svn
svn mkdir -m $url/trunk $url/branches $url/tags
rm -rf testrepo
svn co $url testrepo
cd testrepo/trunk
mkdir -p foo/bar/
svn add foo/
svn commit -mx
svn rm foo/bar/
svn commit -mx
svn up
mkdir -p baz/
svn add baz/
svn commit -mx
echo x fil.txt
svn add fil.txt
svn commit -mx
cd ../..
git svn clone --stdlayout --preserve-empty-dirs $url testrepo.gitsvn
---
perl/Git/SVN/Fetcher.pm | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index 046a7a2..4f96076 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -129,6 +129,7 @@ sub is_path_ignored {
sub set_path_strip {
my ($self, $path) = @_;
+ $self-{pathprefix_strip} = length $path ? ($path . /) : ;
$self-{path_strip} = qr/^\Q$path\E(\/|$)/ if length $path;
}
@@ -458,9 +459,12 @@ sub find_empty_directories {
my $skip_added = 0;
foreach my $t (qw/dir_prop file_prop/) {
foreach my $path (keys %{ $self-{$t} }) {
- if (exists $self-{$t}-{dirname($path)}) {
- $skip_added = 1;
- last;
+ if (length $self-git_path($path)) {
+ $path = dirname($path);
+ if ($dir eq $self-git_path($path)
exists $self-{$t}-{$path}) {
+ $skip_added = 1;
+ last;
+ }
}
}
last if $skip_added;
@@ -477,7 +481,7 @@ sub find_empty_directories {
delete $files{$_} foreach (@deleted_gpath);
# Report the directory if there are no filenames left.
- push @empty_dirs, $dir unless (scalar %files);
+ push @empty_dirs, ($self-{pathprefix_strip} . $dir) unless
(scalar %files);
}
@empty_dirs;
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] git-svn: fix svn fetch erroneously recreating empty dir placeholder deleted earlier
The Fetcher accumulates deleted paths in an array and doesn't reset the
array on next commit. This causes different results when interrupting
and resuming the fetch.
When --preserve-empty-dirs flag is used, a path in the array can be
erroneously treated as just deleted, although it was deleted in the
previous commit and cause the creation of an empty dir placeholder.
Test script:
(
set -e
rm -rf testrepo.svn testrepo.gitsvn
svnadmin create testrepo.svn
url=file://`pwd`/testrepo.svn
rm -rf testrepo
svn co $url testrepo
cd testrepo
mkdir -p foo/bar
echo aaa foo/bar/fil.txt
svn add foo
svn commit -mx
svn rm -mx $url/foo/bar/fil.txt
svn rm -mx $url/foo/bar
echo aaa fil.txt
svn add fil.txt
svn commit -mx
cd ..
rm -rf testrepo.gitsvn git svn clone --preserve-empty-dirs $url
testrepo.gitsvn
if [ -e testrepo.gitsvn/foo/bar/.gitignore ]; then
echo error: testrepo.gitsvn/foo/bar/.gitignore exists
false
fi
)
---
perl/Git/SVN/Fetcher.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index 4f96076..e658889 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -19,6 +19,7 @@ sub new {
my ($class, $git_svn, $switch_path) = @_;
my $self = SVN::Delta::Editor-new;
bless $self, $class;
+ @deleted_gpath = ();
if (exists $git_svn-{last_commit}) {
$self-{c} = $git_svn-{last_commit};
$self-{empty_symlinks} =
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-svn: fix occasional Failed to strip path error on fetch next commit
Ilya Basin basini...@gmail.com writes:
You should Cc Eric on git-svn related patches.
Test script:
rm -rf testrepo.svn testrepo.gitsvn
svnadmin create testrepo.svn
url=file://`pwd`/testrepo.svn
svn mkdir -m $url/trunk $url/branches $url/tags
rm -rf testrepo
svn co $url testrepo
cd testrepo/trunk
mkdir -p foo/bar/
svn add foo/
svn commit -mx
svn rm foo/bar/
svn commit -mx
svn up
mkdir -p baz/
svn add baz/
svn commit -mx
echo x fil.txt
svn add fil.txt
svn commit -mx
cd ../..
git svn clone --stdlayout --preserve-empty-dirs $url testrepo.gitsvn
Please add an actual regression test, probably to t9160.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git.pm with recent File::Temp fail
On Sat, 23 Mar 2013 16:32:47 +, Ben Walton bdwal...@gmail.com
wrote:
Hello,
Still failing in 1.8.2.2
Short fix:
--8---
diff --git a/perl/Git.pm b/perl/Git.pm
index dc48159..7a252ef 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1265,7 +1265,7 @@ sub _temp_cache {
$tmpdir = $self-repo_path();
}
- ($$temp_fd, $fname) = File::Temp-tempfile(
+ ($$temp_fd, $fname) = File::Temp::tempfile(
'Git_XX', UNLINK = 1, DIR = $tmpdir,
) or throw Error::Simple(couldn't open new temp file);
--8---
Long fix inlined
On Fri, Mar 22, 2013 at 7:57 PM, H.Merijn Brand h.m.br...@xs4all.nl wrote:
git-1.8.2, perl-5.16.3, File::Temp-0.23
Without patch:
$ git svn fetch
'tempfile' can't be called as a method at
/pro/lib/perl5/site_perl/5.16.3/Git.pm line 1117.
After patch:
$ git svn fetch
M t/06virtual.t
r15506 = 6c65be7ff36ffc6fd9b960a4b470ca297103004e (refs/remotes/git-svn)
⋮
patch attached
This list prefers patches to be inline so that they can easily be
commented on, etc. I took a quick look at your patch and while it
looks fine to me, fwiw.
You may want to resubmit using git send-email though so that others
will look at it and possibly apply it.
From b3be713101469f8bea14b854eb7840132ffdca8a Mon Sep 17 00:00:00 2001
From: H.Merijn Brand - Tux h.m.br...@xs4all.nl
Date: Sun, 28 Apr 2013 11:03:15 +0200
Subject: [PATCH] Git.pm with recent File::Temp fail
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=1.8.2.1
This is a multi-part message in MIME format.
--1.8.2.1
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
git-1.8.2{,.1,.2}, perl-5.16.3, File::Temp-0.23
Without patch:
$ git svn fetch
'tempfile' can't be called as a method at
/pro/lib/perl5/site_perl/5.16.3/Git.pm line 1117.
After patch:
$ git svn fetch
M t/06virtual.t
r15506 = 6c65be7ff36ffc6fd9b960a4b470ca297103004e (refs/remotes/git-svn)
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--1.8.2.1
Content-Type: text/x-patch; name=0001-Git.pm-with-recent-File-Temp-fail.patch
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename=0001-Git.pm-with-recent-File-Temp-fail.patch
diff --git a/perl/Git.pm b/perl/Git.pm
index dc48159..7a252ef 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1265,7 +1265,7 @@ sub _temp_cache {
$tmpdir = $self-repo_path();
}
- ($$temp_fd, $fname) = File::Temp-tempfile(
+ ($$temp_fd, $fname) = File::Temp::tempfile(
'Git_XX', UNLINK = 1, DIR = $tmpdir,
) or throw Error::Simple(couldn't open new temp file);
--1.8.2.1--
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] path: Make the 'get_st_mode_bits' symbol a file static
On 2013-04-28 08.02, Torsten Bögershausen wrote:
On 2013-04-27 20.42, Ramsay Jones wrote:
On MinGW, sparse issues an 'get_st_mode_bits' not declared. Should
it be static? warning. The MinGW and MSVC builds do not see the
declaration of this function, within git-compat-util.h, due to it's
placement within an preprocessor conditional. (So, one solution would
be to simply move the declaration to the top level of the header.)
In order to suppress the warning, since this symbol does not need
more than file visibility, we simply remove the declaration from
the header and add the static modifier to the function definition.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
git-compat-util.h | 1 -
path.c| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index e955bb5..3a990b3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -163,7 +163,6 @@
typedef long intptr_t;
typedef unsigned long uintptr_t;
#endif
-int get_st_mode_bits(const char *path, int *mode);
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include grp.h
diff --git a/path.c b/path.c
index 04ff148..cc2e9ac 100644
--- a/path.c
+++ b/path.c
@@ -11,7 +11,7 @@
* may return wrong permission bits. Most of the time we do not care,
* but the callsites of this wrapper do care.
*/
-int get_st_mode_bits(const char *path, int *mode)
+static int get_st_mode_bits(const char *path, int *mode)
{
struct stat st;
if (lstat(path, st) 0)
Sorry for breaking the MiNGW/MSVC builds.
It seams that the get_st_mode_bits is badly placed.
It should be in git compat-util.h, so that both compat/cygwin.c and path.c
can see it.
So from my understanding, it should be placed here:
(I will send an official patch later)
/Torsten
diff -C 3 git-compat-util.h.~9526aa461f6c6900cb892a6fe248150ad436c0d~
git-compat-util.h.new
*** git-compat-util.h.~9526aa461f6c6900cb892a6fe248150ad436c0d~ 2013-04-28
07:53:28.0 +0200
--- git-compat-util.h.new 2013-04-28 07:53:58.0 +0200
***
*** 127,132
--- 127,133
#else
#include poll.h
#endif
+ int get_st_mode_bits(const char *path, int *mode);
#if defined(__MINGW32__)
/* pull in Windows compatibility stuff */
#include compat/mingw.h
***
*** 163,169
typedef long intptr_t;
typedef unsigned long uintptr_t;
#endif
- int get_st_mode_bits(const char *path, int *mode);
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include grp.h
I probably change my mind:
Declaring get_st_mode_bits() static in path.c makes sense.
And for cygwin we have the re-define in compat/cygwin.h:
int cygwin_get_st_mode_bits(const char *path, int *mode);
#define get_st_mode_bits(p,m) cygwin_get_st_mode_bits((p),(m))
So, (besides the typo found by Eric),
Thanks. Reviewed,and tested OK here. In short:
Acked-By: Torsten Bögershausen tbo...@web.de
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git merge/rebase ref -P ref
The inverted meaning of {ours,theirs} for rebase could be very
confusing to some, especially to new uses, for me every time I
merge/rebase I need to think about it to make sure I've made it right.
What about making it more intuitive?
We can and a new option (like '-P') for people to specify the
preferred branch/ref by it's name.
E.g. assume I have two branches, namely 'dev' and 'exp', and I prefer
the changeset on the 'dev' branch when I merge or rebase, so that I
can do it with
# using merge
git checkout dev
git merge exp -P dev
OR
# using rebase
git checkout exp
git rebase dev -P dev
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
`git describe` in an export-subst format string?
I originally posted this as a question about getting `git log` to output the same thing that `git describe` does to the git-users mailing list, and was directed here. The actual thing I want to do is something like this: static const char *project_version = $Format:...$; where ... is something that `git archive` will replace with the output of `git describe`, given the file has the export-subst property, possibly with arguments to git describe (--tags, --all, etc.). In a normal build I can do this with the build system just calling git directly, but if I'm archiving a tarball off there doesn't seem to be a way to do this (other than manually replacing the format string myself as some secondary step). Does this seem like a reasonable thing to do, or am I overlooking a better alternative? If this is something that seems reasonable, I wouldn't mind taking a stab at implementing it. If that sounds okay, could make sure I'm pointed in the right direction? E.g., should `git log --format=...` have options that spit out `git describe` strings since that's what export-subst currently uses, or should there be a separate $Format:...$ option that runs git describe? Thanks, John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents
Kevin Bracey ke...@bracey.fi writes: Could you explain here a bit more the reason why we do not want to remove them and why -s ours is so significant that it deserves to be singled out? And why randomly picking one that is redundant (because it is an ancestor of some other parent) is an improvement? I feel it's consistent with the default non-full-history behaviour. The parent that we choose not to remove is the same one that the default log with simplify_history==1 would have followed: the first parent we are TREESAME to. Or at least that's the intent. So this parent would normally be singled out, and it's not an arbitrary (or random) choice. It feels wrong to me that --full-history --simplify-merges could produce a disjoint history from the default. Finally ;-) That avoid creating a disjoint history is the why we do not want to remove them I wanted to see in the same comment. But this patch as it stands was an easy change to make with clearly limited scope and relatively little risk - I specifically wanted just to include our default simple parent. Yeah, I think it all makes sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges
Kevin Bracey ke...@bracey.fi writes:
Do we want to discard the decoration data when the commit becomes a
non-merge?
Would seem reasonable, and would also help make concrete why we update
TREESAME immediately, and not in update_treesame(), but I didn't spot
a mechanism to discard decoration. I'll recheck.
What I meant was a simple free(it) and a call to add_decoration()
to register a NULL for the object whose treesame[] we no longer
need.
I could insert an if (!commit-object.flags TREESAME) test to skip
the entire update. I'd be inclined to do that as the caller of
update_treesame(). I think update_treesame() itself should be
general-purpose without assumptions about what changes have been made,
so it's a pure treesame[]-TREESAME calculation, without TREESAME as
an input.
Makes sense.
(Aside - just occurred to me we could swap the loop for
strlen(st-treesame) == st-nparents, if we kept a zero terminator
in the array. Maybe a bit too smart-ass?)
Probably ;-)
+ for (pp = commit-parents;
+(parent = *pp) != NULL;
+pp = parent-next, nth_parent++) {
I see the reason to change from while to for is because you wanted
to count, and I think it makes sense; but it is more readable to
initialise the counter here, too, if that is the case. I.e.
for (pp = commit-parents, nth_parent = 0;
!(parent = *pp);
pp = parent-next, nth_parent++) {
Agree on nth_parent, but !(parent = *pp) isn't (parent = *pp) !=
NULL, mind. Did you mean !!? In which case I still prefer it my
way.
Droppage of NULL check was a typo. I only meant A part of for(A;B;C).
@@ -773,6 +861,9 @@ static void limit_to_ancestry(struct
commit_list *bottom, struct commit_list *li
* NEEDSWORK: decide if we want to remove parents that are
* not marked with TMP_MARK from commit-parents for commits
* in the resulting list. We may not want to do that, though.
+*
+* Maybe it should be considered if we are TREESAME to such
+* parents - now possible with stored per-parent flags.
*/
Hmm, that is certainly a thought.
My comment's wrong though. Reconsidering, what I think needs removing
is actually off-ancestry parents that we are !TREESAME to, when we are
TREESAME on the ancestry path.
I thought I read you meant exactly that, i.e. !TREESAME, but now I
re-read what is quoted, you did say we are TREESAME ;-). I think
I agree with you that we do not want any side branch that is not on
the ancestry path we are interested in to affect the sameness
assigned to the merge commit.
I've realised while testing this that there's been one thing that's
confused me repeatedly, and I think this comment was an example of
it. The example in the rev-list-options manual is wrong.
* *
.-A---M---N---O---P
/*/ /* /* /*
I B C D E
\ /* / /* /
`-'
I've added '*' next to each arc between a commit-pair whose contents
at 'foo' are different to the illustration, following the set-up the
manual describes. E is the same as I for 'foo' and P would resolve
'foo' to be the same as O.
Contrary to the manual, merge P is !TREESAME to E (or I). E's base is
old enough that E isn't up-to-date w.r.t. foo. Thus merge P is no
longer TREESAME and does become subject to display with the new
--full-history:
I A B N D O P
Assuming N's parents-list is rewritten to be A and B, this sounds
sensible.
I believe this is correct, because P is a merge that determined the
fate of foo, so merits --full-history inspection. (--simplify-merges
obviously knocks P back out again: --simplify-merges becomes more
important if --full-history gets fuller).
E simplifies to I which is already an ancestor of O and is redundant
when inspecting P, hence P becomes a single-parent child of O and
further simplifies to O because it has the same 'foo'. Makes sense.
Given this error, and this change, I think this example may want a
slight rethink. Do we want a proper messing with other paths but
TREESAME merge example? Say if E's parent was O, P would not be
TREESAME and not included in --full-history.
I am not sure if I follow your last sentence.
Do you mean this topology, where E's sole parent is O, i.e.
E
/ \
N---O---P
/*
D
and E does not change 'foo' from O? Then P is TREESAME to all its
parents and would not have to appear in the full history for the
same reason M does not appear in your earlier IABNDOP output, no?
OK, even though the use of TMP_MARK (meant to be very localized)
across two functions feel somewhat yucky, they are file scope
statics next to each other and hopefully are called back to back.
Well, by the end of the series you've got two functions setting it, in
preparation for later input to this function.
As long as setting and using and then cleaning after done are
localized enough so
Re: [PATCH 12/20] remote-bzr: split marks file
Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. You didn't. I am already way too deep into today's 1.8.3-rc0 integration cycle and I won't waste a couple of hours work just to revert this. Oh, I was lucky ;-) I mistook this with the other 9-patch bzr clean-up series that I applied to 'master' for -rc0. Pushing out a tagged-tip takes a lot longer than the normal tip because a lot more than what people see have to happen on my end. Reverting a single patch is simple, but we do not want to do that on top of Git 1.8.3-rc0 commit and move the unpublished tag to point at the revert. Which means pretty much everything needs to be redone (one example among many is that the tagname will propagate to the htmldocs and manpages repositories, so their unpublished histories need to be rewound). But I didn't have to do that in the end ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Minor additions to git-completion.bash
Felipe Contreras felipe.contre...@gmail.com writes: On Wed, Apr 24, 2013 at 2:49 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Ramkumar Ramachandra wrote: [...] Any updates on this? FWIW they all look OK to me. I do not have the original series, so a resend with Felipe's Acked-by after your original Sign-off would be nice. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] merge-tree: fix typo in both changed identically
Thanks, both. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] path: Make the 'get_st_mode_bits' symbol a file static
Ramsay Jones ram...@ramsay1.demon.co.uk writes: On MinGW, sparse issues an 'get_st_mode_bits' not declared. Should it be static? warning. The MinGW and MSVC builds do not see the declaration of this function, within git-compat-util.h, due to it's placement within an preprocessor conditional. (So, one solution would be to simply move the declaration to the top level of the header.) Well, the idea was that the user of this function in path.c will call get_st_mode_bits(), and whatever platform that provides a replacement implementation would do #define get_st_mode_bits(a,b) cygwin_get_st_mode_bits((a),(b)) so that the calling site in path.c will end up calling that replacement implementation. So if anything get_st_mode_bits() declaration may want to go at the _end_ (not top) after including all the compatibility crufts. We could make the declaration static to path.c, but then nobody other than path.c would be able to make use of it in the future, and we'll have the same discussion when somebody wants to hoist the declaration to git-compat-util.h, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
consistency problem on ZFS
Hi, I have a weird problem that seems to manifest itself only on ZFS (actually the Zevo distribution, on OSX). With git 1.8.2.1 by the way. I just switched to ZFS, so I can't blame that particular version of git. Sometimes (I'd say something like 10-15% of the time, fairly reproducible anyway), git diff-files will see changes that don't exist for some time, then will catch up with the actual state of the file: $ git checkout next; git diff-files; git checkout next; git diff-files Already on 'next' :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80 M magit.el Already on 'next' $ Here it was pretty quick, but sometimes I would see those phantom diffs for more than 5 seconds. Interestingly, if I manage to run git diff during that time, this one reports no changes. See https://gist.github.com/sigma/5477827 for a more complex trace: git merge was complaining about changes, yet neither git diff nor git status did show any. That's the scenario I tried to minimize to the invocation above. I'm willing to accept that the filesystem has some responsibility there, but the inconsistency bothers me. Anything I can provide to help finding the root cause of the issue ? Thanks for any hint (and workarounds are highly welcome, as it breaks many of my scripts, and magit too :)) Yann. -- A Duke must always take control of his household, for if he does not rule those closest to him, he cannot hope to govern a planet. -- DUKE PAULUS ATREIDES -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-email: improve recipients_cmd()
Felipe Contreras felipe.contre...@gmail.com writes:
We don't need to quote the filename to pass to the command, we can use
an array of all the arguments to pass to the command, which is safer,
and more extensible.
Commit a47eab0 (send-email: use the three-arg form of open in
recipients_cmd) stated we couldn't pass $file directly, but in fact, we
can, the multi-word string is passed as is, and we can pass an array
too.
I think the comment is not about passing $file directly, but is
about passing $cmd that could be multi-word string directly. The
caller expects it be split into command and its earlier part of
command line parameters, so that you can say
$cmd = cccmd --frotz --nitfol
but the non-string form of open would not give you that, unless you
rewrite it to
open $fh, -|, qw(sh -c), $cmd, @args
or something, no?
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..7880d12 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1452,11 +1452,11 @@ foreach my $t (@files) {
# Execute a command (e.g. $to_cmd) to get a list of email addresses
# and return a results array
sub recipients_cmd {
- my ($prefix, $what, $cmd, $file) = @_;
+ my ($prefix, $what, $cmd, @args) = @_;
my $sanitized_sender = sanitize_address($sender);
my @addresses = ();
- open my $fh, -|, $cmd \Q$file\E
+ open my $fh, -|, $cmd, @args
or die ($prefix) Could not execute '$cmd';
while (my $address = $fh) {
$address =~ s/^\s*//g;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] compat/nedmalloc: Fix compiler warnings on linux
Ramsay Jones ram...@ramsay1.demon.co.uk writes: On linux, when the build variable USE_NED_ALLOCATOR is set, gcc issues the following warnings: In file included from compat/nedmalloc/nedmalloc.c:63: .../malloc.c.h: In function 'mmap_resize': .../malloc.c.h:3762: warning: implicit declaration of function 'mremap' .../malloc.c.h: In function 'sys_trim': .../malloc.c.h:4195: warning: comparison between pointer and integer The warnings are caused by the sys/mman.h header not enabling the (conditional) declaration of the mremap() function. The declaration can be enabled by defining the _GNU_SOURCE symbol prior to including certain system header files. In particular, it may not be sufficient to simply define _GNU_SOURCE just prior to including the sys/mman.h header. (e.g. defining the symbol after including sys/types.h will be completely ineffective.) In order to suppress the warnings, we define the _GNU_SOURCE symbol at the start of the malloc.c.h header file. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- H, is this even worth worrying about? I somehow thought this was only meant to replace malloc on non GNU systems... compat/nedmalloc/malloc.c.h | 4 1 file changed, 4 insertions(+) diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h index fdcca82..5a44dea 100644 --- a/compat/nedmalloc/malloc.c.h +++ b/compat/nedmalloc/malloc.c.h @@ -484,6 +484,10 @@ MAX_RELEASE_CHECK_RATE default: 4095 unless not HAVE_MMAP #define DLMALLOC_VERSION 20804 #endif /* DLMALLOC_VERSION */ +#if defined(linux) +#define _GNU_SOURCE 1 +#endif + #ifndef WIN32 #ifdef _WIN32 #define WIN32 1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] sparse: Fix mingw_main() argument number/type errors
René Scharfe rene.scha...@lsrfire.ath.cx writes: Why not take the opposite direction with a patch like this? ... diff --git a/compat/mingw.h b/compat/mingw.h index 389ae01..74e7b87 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -452,11 +452,11 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t utflen); void mingw_startup(); #define main(c,v) dummy_decl_mingw_main(); \ -static int mingw_main(); \ +static int mingw_main(int, const char **); \ int main(int argc, const char **argv) \ But traditionally main is declared like int main(int argc, char *argv[]); without const, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: consistency problem on ZFS
Yann Hodique yann.hodi...@gmail.com writes:
I have a weird problem that seems to manifest itself only on ZFS
(actually the Zevo distribution, on OSX). With git 1.8.2.1 by the way.
I just switched to ZFS, so I can't blame that particular version of git.
Sometimes (I'd say something like 10-15% of the time, fairly
reproducible anyway), git diff-files will see changes that don't exist
for some time, then will catch up with the actual state of the file:
$ git checkout next; git diff-files; git checkout next; git diff-files
Already on 'next'
:100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80
Mmagit.el
Already on 'next'
$
git-diff-files doesn't refresh the index. Why are you using it? It's
the plumbing version of 'git diff' (without args), which does the same
but *does* refresh the index.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: consistency problem on ZFS
Thomas == Thomas Rast tr...@inf.ethz.ch writes: Yann Hodique yann.hodi...@gmail.com writes: I have a weird problem that seems to manifest itself only on ZFS (actually the Zevo distribution, on OSX). With git 1.8.2.1 by the way. I just switched to ZFS, so I can't blame that particular version of git. Sometimes (I'd say something like 10-15% of the time, fairly reproducible anyway), git diff-files will see changes that don't exist for some time, then will catch up with the actual state of the file: $ git checkout next; git diff-files; git checkout next; git diff-files Already on 'next' :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80 M magit.el Already on 'next' $ git-diff-files doesn't refresh the index. Why are you using it? It's the plumbing version of 'git diff' (without args), which does the same but *does* refresh the index. Well, as I said, I'm mostly trying to minimize the case here (which might or might not be successful, as it's essentially guesswork). But whatever git-diff-files does, it seems odd that it doesn't report the same thing twice, no ? The actual real problem I have is the one that's exposed in the longer trace I posted: git merge kindly asks me to fix a problem that a) doesn't exist and b) isn't reported by porcelain commands (git diff, and git status), and then magically stops asking after a couple of seconds. Thanks, Yann. -- Battle? There's always a desire for breathing space motivating it somewhere. -- The Bashar Teg -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] git-svn: fix occasional Failed to strip path error on fetch next commit, try #2
When --stdlayout and --preserve-empty-dirs flags are used and a
directory becomes empty, two things happen:
Sometimes find_empty_directories() returns empty list and no empty dir
placeholder file created. This happens, because find_empty_directories()
marks all directories as non-empty, if at least one updated directory is
non-empty.
Sometimes git-svn dies with Failed to strip path error. This happens,
because find_empty_directories() returns git paths and
add_placeholder_file() expects svn paths
---
perl/Git/SVN/Fetcher.pm| 12
t/t9160-git-svn-preserve-empty-dirs.sh | 18 +-
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index 046a7a2..4f96076 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -129,6 +129,7 @@ sub is_path_ignored {
sub set_path_strip {
my ($self, $path) = @_;
+ $self-{pathprefix_strip} = length $path ? ($path . /) : ;
$self-{path_strip} = qr/^\Q$path\E(\/|$)/ if length $path;
}
@@ -458,9 +459,12 @@ sub find_empty_directories {
my $skip_added = 0;
foreach my $t (qw/dir_prop file_prop/) {
foreach my $path (keys %{ $self-{$t} }) {
- if (exists $self-{$t}-{dirname($path)}) {
- $skip_added = 1;
- last;
+ if (length $self-git_path($path)) {
+ $path = dirname($path);
+ if ($dir eq $self-git_path($path)
exists $self-{$t}-{$path}) {
+ $skip_added = 1;
+ last;
+ }
}
}
last if $skip_added;
@@ -477,7 +481,7 @@ sub find_empty_directories {
delete $files{$_} foreach (@deleted_gpath);
# Report the directory if there are no filenames left.
- push @empty_dirs, $dir unless (scalar %files);
+ push @empty_dirs, ($self-{pathprefix_strip} . $dir) unless
(scalar %files);
}
@empty_dirs;
}
diff --git a/t/t9160-git-svn-preserve-empty-dirs.sh
b/t/t9160-git-svn-preserve-empty-dirs.sh
index b4a4434..1b5a286 100755
--- a/t/t9160-git-svn-preserve-empty-dirs.sh
+++ b/t/t9160-git-svn-preserve-empty-dirs.sh
@@ -51,13 +51,21 @@ test_expect_success 'initialize source svn repo containing
empty dirs' '
echo Conflict file 5/.placeholder
mkdir 6/.placeholder
svn_cmd add 5/.placeholder 6/.placeholder
- svn_cmd commit -m Placeholder Namespace conflict
+ svn_cmd commit -m Placeholder Namespace conflict
+
+ echo x fil.txt
+ svn_cmd add fil.txt
+ svn_cmd commit -m this commit should not kill git-svn
)
rm -rf $SVN_TREE
'
-test_expect_success 'clone svn repo with --preserve-empty-dirs' '
- git svn clone $svnrepo/trunk --preserve-empty-dirs $GIT_REPO
+test_expect_success 'clone svn repo with --preserve-empty-dirs --stdlayout' '
+ git svn clone $svnrepo --preserve-empty-dirs --stdlayout $GIT_REPO
|| (
+ cd $GIT_REPO
+ git svn fetch # fetch the rest can succeed even if clone failed
+ false # this test still failed
+ )
'
# $GIT_REPO/1 should only contain the placeholder file.
@@ -81,11 +89,11 @@ test_expect_success 'add entry to previously empty
directory' '
test -f $GIT_REPO/4/a/b/c/foo
'
-# The HEAD~2 commit should not have introduced .gitignore placeholder files.
+# The HEAD~3 commit should not have introduced .gitignore placeholder files.
test_expect_success 'remove non-last entry from directory' '
(
cd $GIT_REPO
- git checkout HEAD~2
+ git checkout HEAD~3
)
test_must_fail test -f $GIT_REPO/2/.gitignore
test_must_fail test -f $GIT_REPO/3/.gitignore
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: consistency problem on ZFS
On Sun, Apr 28, 2013 at 3:11 PM, Yann Hodique yann.hodi...@gmail.com wrote: Hi, I have a weird problem that seems to manifest itself only on ZFS (actually the Zevo distribution, on OSX). With git 1.8.2.1 by the way. I just switched to ZFS, so I can't blame that particular version of git. Sometimes (I'd say something like 10-15% of the time, fairly reproducible anyway), git diff-files will see changes that don't exist for some time, then will catch up with the actual state of the file: $ git checkout next; git diff-files; git checkout next; git diff-files Already on 'next' :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80 M magit.el Already on 'next' $ Since you're running with Mac OS X, can I ask what version? Have you seen this with the regular file system (HFS) at all? It might be that you need to disable core.trustctime. -John PS Sorry for the repeat Yann... I forgot to CC the list. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] git-svn-test: don't test for possible bug Failed to strip path, try #2
In the previous commit a showcase was added to t9160-git-svn-preserve-empty-dirs.sh for the Failed to strip path bug. Now the flag --stdlayout should be enough. --- t/t9160-git-svn-preserve-empty-dirs.sh | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/t/t9160-git-svn-preserve-empty-dirs.sh b/t/t9160-git-svn-preserve-empty-dirs.sh index 1b5a286..43b1852 100755 --- a/t/t9160-git-svn-preserve-empty-dirs.sh +++ b/t/t9160-git-svn-preserve-empty-dirs.sh @@ -51,21 +51,13 @@ test_expect_success 'initialize source svn repo containing empty dirs' ' echo Conflict file 5/.placeholder mkdir 6/.placeholder svn_cmd add 5/.placeholder 6/.placeholder - svn_cmd commit -m Placeholder Namespace conflict - - echo x fil.txt - svn_cmd add fil.txt - svn_cmd commit -m this commit should not kill git-svn + svn_cmd commit -m Placeholder Namespace conflict ) rm -rf $SVN_TREE ' test_expect_success 'clone svn repo with --preserve-empty-dirs --stdlayout' ' - git svn clone $svnrepo --preserve-empty-dirs --stdlayout $GIT_REPO || ( - cd $GIT_REPO - git svn fetch # fetch the rest can succeed even if clone failed - false # this test still failed - ) + git svn clone $svnrepo --preserve-empty-dirs --stdlayout $GIT_REPO ' # $GIT_REPO/1 should only contain the placeholder file. @@ -89,11 +81,11 @@ test_expect_success 'add entry to previously empty directory' ' test -f $GIT_REPO/4/a/b/c/foo ' -# The HEAD~3 commit should not have introduced .gitignore placeholder files. +# The HEAD~2 commit should not have introduced .gitignore placeholder files. test_expect_success 'remove non-last entry from directory' ' ( cd $GIT_REPO - git checkout HEAD~3 + git checkout HEAD~2 ) test_must_fail test -f $GIT_REPO/2/.gitignore test_must_fail test -f $GIT_REPO/3/.gitignore -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] git-svn: fix svn fetch erroneously recreating empty dir placeholder deleted earlier, try #2
The Fetcher accumulates deleted paths in an array and doesn't reset the
array on next commit. This causes different results when interrupting
and resuming the fetch.
When --preserve-empty-dirs flag is used, a path in the array can be
erroneously treated as just deleted (although it was deleted in the
previous commit) and cause the creation of an empty dir placeholder.
---
perl/Git/SVN/Fetcher.pm| 1 +
t/t9160-git-svn-preserve-empty-dirs.sh | 18 --
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index 4f96076..e658889 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -19,6 +19,7 @@ sub new {
my ($class, $git_svn, $switch_path) = @_;
my $self = SVN::Delta::Editor-new;
bless $self, $class;
+ @deleted_gpath = ();
if (exists $git_svn-{last_commit}) {
$self-{c} = $git_svn-{last_commit};
$self-{empty_symlinks} =
diff --git a/t/t9160-git-svn-preserve-empty-dirs.sh
b/t/t9160-git-svn-preserve-empty-dirs.sh
index 43b1852..d50314d 100755
--- a/t/t9160-git-svn-preserve-empty-dirs.sh
+++ b/t/t9160-git-svn-preserve-empty-dirs.sh
@@ -15,18 +15,27 @@ say 'define NO_SVN_TESTS to skip git svn tests'
GIT_REPO=git-svn-repo
test_expect_success 'initialize source svn repo containing empty dirs' '
+ #exec 1/dev/tty 21
svn_cmd mkdir -m x $svnrepo/trunk
svn_cmd co $svnrepo/trunk $SVN_TREE
(
cd $SVN_TREE
- mkdir -p 1 2 3/a 3/b 4 5 6
+ mkdir -p 1 2 3/a 3/b 4 5 6 7
echo First non-empty file 2/file1.txt
echo Second non-empty file 2/file2.txt
echo Third non-empty file 3/a/file1.txt
echo Fourth non-empty file 3/b/file1.txt
- svn_cmd add 1 2 3 4 5 6
+ echo x 7/file.txt
+ svn_cmd add 1 2 3 4 5 6 7
svn_cmd commit -m initial commit
+ svn_cmd del 7/file.txt
+ svn_cmd commit -m delete last entry in directory
+ svn_cmd up
+
+ svn_cmd del 7
+ svn_cmd commit -m delete empty dir that had files in it;
subsequent commits should not recreate it
+
mkdir 4/a
svn_cmd add 4/a
svn_cmd commit -m nested empty directory
@@ -60,6 +69,11 @@ test_expect_success 'clone svn repo with
--preserve-empty-dirs --stdlayout' '
git svn clone $svnrepo --preserve-empty-dirs --stdlayout $GIT_REPO
'
+# $GIT_REPO/7/ should not be recreated
+test_expect_success 'no recreating empty dir deleted earlier' '
+ test_must_fail test -d $GIT_REPO/7/
+'
+
# $GIT_REPO/1 should only contain the placeholder file.
test_expect_success 'directory empty from inception' '
test -f $GIT_REPO/1/.gitignore
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: consistency problem on ZFS
John == John Szakmeister j...@szakmeister.net writes: On Sun, Apr 28, 2013 at 3:11 PM, Yann Hodique yann.hodi...@gmail.com wrote: Hi, I have a weird problem that seems to manifest itself only on ZFS (actually the Zevo distribution, on OSX). With git 1.8.2.1 by the way. I just switched to ZFS, so I can't blame that particular version of git. Sometimes (I'd say something like 10-15% of the time, fairly reproducible anyway), git diff-files will see changes that don't exist for some time, then will catch up with the actual state of the file: $ git checkout next; git diff-files; git checkout next; git diff-files Already on 'next' :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80 M magit.el Already on 'next' $ Since you're running with Mac OS X, can I ask what version? Have you seen this with the regular file system (HFS) at all? It might be that you need to disable core.trustctime. Sure, it's OS X 10.8.3 And no, I don't see this on HFS+ at all. I've just tried numerous times without success. And setting core.trustctime seems to do the trick indeed. Many thanks, that's helping a lot in the short term ! Yann. -- At the age of fifteen, he had already learned silence. -- from A Child's History of Muad'Dib by the Princess Irulan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.3-rc0
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/27/2013 04:24 AM, shawn wilson wrote:
On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano gits...@pobox.com wrote:
* There was no good way to ask I have a random string that came from
outside world. I want to turn it into a 40-hex object name while
making sure such an object exists. A new peeling suffix ^{object}
can be used for that purpose, together with rev-parse --verify.
What does this mean / what is the reason behind this? I can only think
it might be useful in a test suite to make sure git isn't doing
anything stupid with hashes...?
The topic is discussed here:
http://git.661346.n2.nabble.com/Bug-in-quot-git-rev-parse-verify-quot-td7580929.html
As discussed in the thread, when verifying that an argument names an
existing object, it is usually also appropriate to verify that the named
object is of a particular type (or can be converted to a particular
type), which could already be done with syntax like
$userstring^{commit}. But if, for example, you want to avoid
unwrapping tags but also want to verify that the named object really
exists, $userstring^{object} now provides a way.
And what do you have against test suites? :-)
And it is not about test in the first place. Git is designed to be
scriptable, and it is not unreasonable for a scripted Porcelain to
want to learn the full object name of the object that is referred to
by a string that it suspects may be an object name. Perhaps you are
feeding the entire git mailing list archive to a script that picks
up any object name in the messages and tallying the number of times
each object is mentioned. Then you would want to key the table that
counts the number of appearances for each object with the object
name, because different message may spell the name of the same
object differently, e.g. f9fc12cf3, v1.8.3-rc0, etc. With a helper
function found_one_more_instance that records the fact you saw
another mention of an object, such a program may do something like
this:
tokenize_git_mailing_list_message |
while read userstring
do
canonical=$(git rev-parse $userstring^{object})
found_one_more_instance $canonical
done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git describe` in an export-subst format string?
John Gallagher johnkgallag...@gmail.com writes: The actual thing I want to do is something like this: static const char *project_version = $Format:...$; where ... is something that `git archive` will replace with the output of `git describe`,... You need to find an appropriate pair of placeholders that can represent git describe $it and git describe --contains $it. I am tempted to suggest a more generalized way that is not limited to describe at all, perhaps like this: $ git show --format='%x( git describe %H )' $ git show --format='%x( git describe --contains %H )' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: consistency problem on ZFS
Yann Hodique yann.hodi...@gmail.com writes: $ git checkout next; git diff-files; git checkout next; git diff-files Already on 'next' :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80 Mmagit.el Already on 'next' $ If you run git update-index --refresh between the first checkout and diff-files, do you still see the issue? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: `git describe` in an export-subst format string?
Junio C Hamano gits...@pobox.com writes: John Gallagher johnkgallag...@gmail.com writes: The actual thing I want to do is something like this: static const char *project_version = $Format:...$; where ... is something that `git archive` will replace with the output of `git describe`,... You need to find an appropriate pair of placeholders that can represent git describe $it and git describe --contains $it. I am tempted to suggest a more generalized way that is not limited to describe at all, perhaps like this: $ git show --format='%x( git describe %H )' $ git show --format='%x( git describe --contains %H )' Just in case anybody takes it too seriously, this particular implementaiton will never be acceptable at least for use in $Format: of export-subst. I am tempted to suggest, but am not crazy enough to actually doing so ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git.pm with recent File::Temp fail
On Sun, Apr 28, 2013 at 11:09:33AM +0200, H.Merijn Brand wrote:
Still failing in 1.8.2.2
Short fix:
--8---
diff --git a/perl/Git.pm b/perl/Git.pm
index dc48159..7a252ef 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1265,7 +1265,7 @@ sub _temp_cache {
$tmpdir = $self-repo_path();
}
- ($$temp_fd, $fname) = File::Temp-tempfile(
+ ($$temp_fd, $fname) = File::Temp::tempfile(
'Git_XX', UNLINK = 1, DIR = $tmpdir,
) or throw Error::Simple(couldn't open new temp
file);
I think this fix is the right thing. Your patch probably didn't get
applied because it did not follow the guidelines in SubmittingPatches.
Please make sure the subject-line of your email says [PATCH].
I.e., this part:
From b3be713101469f8bea14b854eb7840132ffdca8a Mon Sep 17 00:00:00 2001
From: H.Merijn Brand - Tux h.m.br...@xs4all.nl
Date: Sun, 28 Apr 2013 11:03:15 +0200
Subject: [PATCH] Git.pm with recent File::Temp fail
Should be your actual email header, not just in the body of the message.
git-1.8.2{,.1,.2}, perl-5.16.3, File::Temp-0.23
Without patch:
$ git svn fetch
'tempfile' can't be called as a method at
/pro/lib/perl5/site_perl/5.16.3/Git.pm line 1117.
After patch:
$ git svn fetch
M t/06virtual.t
r15506 = 6c65be7ff36ffc6fd9b960a4b470ca297103004e (refs/remotes/git-svn)
I think the relevant thing is that File::Temp 0.23 started complaining
about this. From their Changes file:
2013-03-14 Tim Jenness tjenn...@cpan.org
Release V0.23 CPAN
[...]
* Temp.pm: Calling tempfile or tempdir as a class method now
produce a more useful fatal error message
So I think the right commit message is something like:
We call File::Temp's tempfile function as a class method, but it was
never designed to be called this way. Older versions seemed to
tolerate it, but as of File::Temp 0.23, it blows up like this:
$ git svn fetch
'tempfile' can't be called as a method at .../Git.pm line 1117.
Fix it by calling it as a regular function, just inside the File::Temp
namespace.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
Michael Heemskerk mheemsk...@atlassian.com writes: Re-sent to the mailing list because the original was bounced (HTML subpart): ... With the patch applied, the server ignores the shallow line mentioned by the server and will not send a shallow or unshallow line for it back to the client. This scenario is not explicitly described in pack-protocol.txt but I'd be happy to add it to. I'll also update the comment to cover this aspect. As Duy pointed out, it doesn't cause problems in the current C Git implementation: the client adds a new entry to the shallow file for each shallow line it receives from the server and removes an entry for each unshallow line it receives. Any current shallow object that is not mentioned by the server is still marked as shallow after the fetch. I think that's how it should be: it should be the client's responsibility to track the list of objects it only has in shallow form. It should not rely on the server to tell it what that list is. Again, an extra line or two in pack-protocol.txt would help to clear this up. ... I do not seem to find the patch you are responding to, so I do not know how the patch handled the unshallowing part, but the impression I got from reading the log message quoted is that the patch was not even aware of the issue. I can't find it on gmane.org either. Patch quoted below. OK, the change the patch text shows looks sensible to me. Can you resend it in full, with the log message, your sign-off, and Duy's Reviewed-by:, so that it can be applied? Thanks. On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk mheemsk...@atlassian.com wrote: diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index f1a51ed..b898e97 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -228,8 +228,7 @@ obtained through ref discovery. ... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.3-rc0
John Keeping j...@keeping.me.uk writes: On Fri, Apr 26, 2013 at 05:22:22PM -0700, Junio C Hamano wrote: * git difftool allows the user to write into the temporary files being shown; if the user makes changes to the working tree at the same time, one of the changes has to be lost in such a case, but it tells the user what happened and refrains from overwriting the copy in the working tree. This feels slightly misleading to me, perhaps something like this would be clearer? git difftool allows the user to write into the temporary files being shown; if the user makes changes to the working tree at the same time, it now refrains from overwriting the copy in the working tree and leaves the temporary file so that changes can be merged manually. Probably. I'll keep the above in my stash and roll it in by -rc1. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git merge/rebase ref -P ref
ryenus rye...@gmail.com writes:
The inverted meaning of {ours,theirs} for rebase could be very
confusing to some, especially to new uses, for me every time I
merge/rebase I need to think about it to make sure I've made it right.
The key point to remember is git rebase origin master is *not*
about integrating other people's changes to your work. It is a way
to replay your work on top of others' work.
When I try to rebase a topic, e.g.
git checkout jc/format-patch
git rebase 8ee3860
The conflicts in pretty.c looks like this:
HEAD
static const char *show_ident_date(const struct ident_split *ident,
enum date_mode mode)
{
...
return show_date(date, tz, mode);
===
static int is_current_user(const struct pretty_print_context *pp,
const char *email, size_t emaillen,
const char *name, size_t namelen)
{
...
!memcmp(myname, name, namelen));
format-patch: --inline-single
}
We are replaying the commits on jc/format-patch topic on a history
that leads to 8ee3860, and the line shows what commit we are
replaying
$ git log --oneline 8ee3860..jc/format-patch
be1a07f format-patch: --inline-single
47d6c5f format-patch: rename no_inline field
On the other hand, when I try to do the same integration with a
merge, e.g.
git checkout 8ee3860
git merge jc/format-patch
We would see the same conflicts like this:
HEAD
static const char *show_ident_date(const struct ident_split *ident,
enum date_mode mode)
{
...
return show_date(date, tz, mode);
===
static int is_current_user(const struct pretty_print_context *pp,
const char *email, size_t emaillen,
const char *name, size_t namelen)
{
...
!memcmp(myname, name, namelen));
jc/format-patch
}
Again, the name of the branch that is merged appears on
line.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git.pm with recent File::Temp fail
Jeff King p...@peff.net writes:
On Sun, Apr 28, 2013 at 11:09:33AM +0200, H.Merijn Brand wrote:
Still failing in 1.8.2.2
Short fix:
--8---
diff --git a/perl/Git.pm b/perl/Git.pm
index dc48159..7a252ef 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1265,7 +1265,7 @@ sub _temp_cache {
$tmpdir = $self-repo_path();
}
- ($$temp_fd, $fname) = File::Temp-tempfile(
+ ($$temp_fd, $fname) = File::Temp::tempfile(
'Git_XX', UNLINK = 1, DIR = $tmpdir,
) or throw Error::Simple(couldn't open new temp
file);
I think this fix is the right thing. Your patch probably didn't get
applied because it did not follow the guidelines in SubmittingPatches.
It was more like It managed to miss people's attention because the
subject didn't say [PATCH], but yes you are right that the change
the patch text itself shows looks reasonable and that I cannot apply
a patch that is not signed off (and worse yet in multipart/mixed).
...
So I think the right commit message is something like:
We call File::Temp's tempfile function as a class method, but it was
never designed to be called this way. Older versions seemed to
tolerate it, but as of File::Temp 0.23, it blows up like this:
$ git svn fetch
'tempfile' can't be called as a method at .../Git.pm line 1117.
Fix it by calling it as a regular function, just inside the File::Temp
namespace.
-Peff
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/20] remote-bzr: split marks file
On Sun, Apr 28, 2013 at 1:47 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: And in case anybody is thinking that remote-bzr is really a too fast moving target; even if this managed to land in 'master', it's likely that people were not able to push at all, and in fact, many were not even able to clone in 1.8.2. So, hardly could be considered a regression. Nevertheless, I caught it in time. You didn't. I am already way too deep into today's 1.8.3-rc0 integration cycle and I won't waste a couple of hours work just to revert this. Oh, I was lucky ;-) I mistook this with the other 9-patch bzr clean-up series that I applied to 'master' for -rc0. Pushing out a tagged-tip takes a lot longer than the normal tip because a lot more than what people see have to happen on my end. Reverting a single patch is simple, but we do not want to do that on top of Git 1.8.3-rc0 commit and move the unpublished tag to point at the revert. Which means pretty much everything needs to be redone (one example among many is that the tagname will propagate to the htmldocs and manpages repositories, so their unpublished histories need to be rewound). But I didn't have to do that in the end ;-) Yeah, I realized you were talking about that one later on. I haven't heard anything bad from this new branch from emacs developers, so I think it's OK to merge it. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Minor additions to git-completion.bash
On Sun, Apr 28, 2013 at 1:48 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Wed, Apr 24, 2013 at 2:49 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Ramkumar Ramachandra wrote: [...] Any updates on this? FWIW they all look OK to me. I do not have the original series, so a resend with Felipe's Acked-by after your original Sign-off would be nice. I only gave them a quick look. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] compat/nedmalloc: Fix compiler warnings on linux
Hi, Ramsay Jones wrote: --- a/compat/nedmalloc/malloc.c.h +++ b/compat/nedmalloc/malloc.c.h @@ -484,6 +484,10 @@ MAX_RELEASE_CHECK_RATE default: 4095 unless not HAVE_MMAP #define DLMALLOC_VERSION 20804 #endif /* DLMALLOC_VERSION */ +#if defined(linux) +#define _GNU_SOURCE 1 +#endif If we want to do this, I'd suggest defining _GNU_SOURCE unconditionally. Other platforms using glibc would benefit from it, too, and other platforms not using glibc shouldn't care. Alternatively it could make sense to see if the latest version from Niall Douglas[1] works, which includes the following: #ifndef HAVE_MREMAP #ifdef linux #define HAVE_MREMAP 1 #ifndef _GNU_SOURCE #define _GNU_SOURCE /* Turns on mremap() definition */ #endif #else /* linux */ #define HAVE_MREMAP 0 #endif /* linux */ #endif /* HAVE_MREMAP */ It looks equally wrong there, but since it comes from upstream we could just punt to him if anyone runs into problems. ;-) My two cents, Jonathan [1] http://www.nedprod.com/programs/portable/nedmalloc/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mingw: rename WIN32 cpp macro to GIT_NATIVE_WINDOWS
Ramsay Jones wrote: After this change, it should be possible to drop the CYGWIN_V15_WIN32API setting without any negative effect. [rj: %s/NATIVE_WINDOWS/GIT_NATIVE_WINDOWS/g ] Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk Yay! Thanks for finishing it. For what it's worth, Reviewed-by: Jonathan Nieder jrnie...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-email: improve recipients_cmd()
On Sun, Apr 28, 2013 at 2:18 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: We don't need to quote the filename to pass to the command, we can use an array of all the arguments to pass to the command, which is safer, and more extensible. Commit a47eab0 (send-email: use the three-arg form of open in recipients_cmd) stated we couldn't pass $file directly, but in fact, we can, the multi-word string is passed as is, and we can pass an array too. I think the comment is not about passing $file directly, but is about passing $cmd that could be multi-word string directly. The caller expects it be split into command and its earlier part of command line parameters, so that you can say $cmd = cccmd --frotz --nitfol I see. but the non-string form of open would not give you that, unless you rewrite it to open $fh, -|, qw(sh -c), $cmd, @args That doesn't seem to work for me. It would have to be: open $fh, -|, qw(sh -c), $cmd \Q$args\E So we end up in the same place. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] git-submodule-ext, git-new-workdir (updates for supermodules), and git-emeld (using git-new-workdir)
Hello, I have been working on some of the following utilities for working with submodules: * git-submodule-ext - Experimental extensions to git-submodule. Includes 'foreach' with --top-level, --post-order, and --constrain options. (Been using this to prototype patches for git-submodule) * git-new-workdir - Modified from git/contrib, I've added support for using this on supermodules and submodules. It does so by changing some of the config (which I figured did not matter if the new workdir's are meant to be short-lived) * git-emeld - Inspired by git-meld / git-diffall, compare editable versions of your repos, so you can then go back and make commits. Since it uses git-new-workdir, it can be used for supermodules as well. These are available here: https://github.com/eacousineau/util [Kind of generic name, may change later] I have also put together a small primer on Git submodules: https://github.com/eacousineau/util/blob/master/SUBMODULES.md Let me know of any suggestions you have for these tools or the primer. I plan to submit these modifications as patches in the future. Thank you, - Eric Cousineau -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-email: improve recipients_cmd()
Felipe Contreras felipe.contre...@gmail.com writes: open $fh, -|, qw(sh -c), $cmd, @args That doesn't seem to work for me. My fault. It needs to form a command line like this: sh -c 'cccmd --frotz --nitfol $@' - a r g s [jc: goes and tries $ sh -c 'echo X Y $@' - a r g s X Y a r g s ] so if we want to get rid of \Q\E, it would be: open $fh, '-|', qw(sh -c), $cmd . '$@', '-', @args -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
Junio C Hamano gits...@pobox.com writes:
OK, the change the patch text shows looks sensible to me. Can you
resend it in full, with the log message, your sign-off, and Duy's
Reviewed-by:, so that it can be applied?
I managed to reassemble what I _think_ is close to the original from
a few messages by dequoting and fixing MUA whitespace breakages in
them.
Here is with a slight tweak to the log message. Please holler if I
grabbed a wrong version of the patch or made any silly mistakes.
Thanks.
-- 8 --
From: Michael Heemskerk mheemsk...@atlassian.com
Subject: [PATCH] upload-pack: ignore 'shallow' lines with unknown obj-ids
When the client sends a 'shallow' line for an object that the server does
not have, the server currently dies with the error: did not find object
for shallow obj-id. The client may have truncated the history at
the commit by fetching shallowly from a different server, or the commit
may have been garbage collected by the server. In either case, this
unknown commit is not relevant for calculating the pack that is to be
sent and can be safely ignored, and it is not used when recomputing where
the updated history of the client is cauterised.
The documentation in technical/pack-protocol.txt has been updated to
remove the restriction that Clients MUST NOT mention an obj-id which it
does not know exists on the server. This requirement is not realistic
because clients cannot know whether an object has been garbage collected
by the server.
Signed-off-by: Michael Heemskerk mheemsk...@atlassian.com
Reviewed-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/technical/pack-protocol.txt | 3 +--
upload-pack.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index f1a51ed..b898e97 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -228,8 +228,7 @@ obtained through ref discovery.
The client MUST write all obj-ids which it only has shallow copies
of (meaning that it does not have the parents of a commit) as
'shallow' lines so that the server is aware of the limitations of
-the client's history. Clients MUST NOT mention an obj-id which
-it does not know exists on the server.
+the client's history.
The client now sends the maximum commit history depth it wants for
this transaction, which is the number of commits it wants from the
diff --git a/upload-pack.c b/upload-pack.c
index bfa6279..127e59a 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,7 +592,7 @@ static void receive_needs(void)
die(invalid shallow line: %s, line);
object = parse_object(sha1);
if (!object)
- die(did not find object for %s, line);
+ continue;
if (object-type != OBJ_COMMIT)
die(invalid shallow object %s,
sha1_to_hex(sha1));
if (!(object-flags CLIENT_SHALLOW)) {
--
1.8.3-rc0-117-g5915a95
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-email: improve recipients_cmd()
On Mon, Apr 29, 2013 at 12:24 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: open $fh, -|, qw(sh -c), $cmd, @args That doesn't seem to work for me. My fault. It needs to form a command line like this: sh -c 'cccmd --frotz --nitfol $@' - a r g s [jc: goes and tries $ sh -c 'echo X Y $@' - a r g s X Y a r g s ] so if we want to get rid of \Q\E, it would be: open $fh, '-|', qw(sh -c), $cmd . '$@', '-', @args I don't know if that would be better, or converting @args to a list of quoted strings, essentially keeping the current behavior. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH/RFC] upload-pack: ignore 'shallow' lines with unknown obj-ids
Thanks Junio,
That looks fine to me. I'll try to find some time this week to create a
follow-up patch for removing pruned commits from the shallow file as
well.
Cheers,
Michael
On 29 April 2013 15:32, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
OK, the change the patch text shows looks sensible to me. Can you
resend it in full, with the log message, your sign-off, and Duy's
Reviewed-by:, so that it can be applied?
I managed to reassemble what I _think_ is close to the original from
a few messages by dequoting and fixing MUA whitespace breakages in
them.
Here is with a slight tweak to the log message. Please holler if I
grabbed a wrong version of the patch or made any silly mistakes.
Thanks.
-- 8 --
From: Michael Heemskerk mheemsk...@atlassian.com
Subject: [PATCH] upload-pack: ignore 'shallow' lines with unknown obj-ids
When the client sends a 'shallow' line for an object that the server does
not have, the server currently dies with the error: did not find object
for shallow obj-id. The client may have truncated the history at
the commit by fetching shallowly from a different server, or the commit
may have been garbage collected by the server. In either case, this
unknown commit is not relevant for calculating the pack that is to be
sent and can be safely ignored, and it is not used when recomputing where
the updated history of the client is cauterised.
The documentation in technical/pack-protocol.txt has been updated to
remove the restriction that Clients MUST NOT mention an obj-id which it
does not know exists on the server. This requirement is not realistic
because clients cannot know whether an object has been garbage collected
by the server.
Signed-off-by: Michael Heemskerk mheemsk...@atlassian.com
Reviewed-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/technical/pack-protocol.txt | 3 +--
upload-pack.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index f1a51ed..b898e97 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -228,8 +228,7 @@ obtained through ref discovery.
The client MUST write all obj-ids which it only has shallow copies
of (meaning that it does not have the parents of a commit) as
'shallow' lines so that the server is aware of the limitations of
-the client's history. Clients MUST NOT mention an obj-id which
-it does not know exists on the server.
+the client's history.
The client now sends the maximum commit history depth it wants for
this transaction, which is the number of commits it wants from the
diff --git a/upload-pack.c b/upload-pack.c
index bfa6279..127e59a 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,7 +592,7 @@ static void receive_needs(void)
die(invalid shallow line: %s, line);
object = parse_object(sha1);
if (!object)
- die(did not find object for %s, line);
+ continue;
if (object-type != OBJ_COMMIT)
die(invalid shallow object %s,
sha1_to_hex(sha1));
if (!(object-flags CLIENT_SHALLOW)) {
--
1.8.3-rc0-117-g5915a95
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mingw: rename WIN32 cpp macro to GIT_NATIVE_WINDOWS
Jonathan Nieder jrnie...@gmail.com writes: Ramsay Jones wrote: After this change, it should be possible to drop the CYGWIN_V15_WIN32API setting without any negative effect. [rj: %s/NATIVE_WINDOWS/GIT_NATIVE_WINDOWS/g ] Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk Yay! Thanks for finishing it. For what it's worth, Reviewed-by: Jonathan Nieder jrnie...@gmail.com Wait. The proposed commit log message talks about native-windows but throughout the code it is windows-native [I'll reword when I rebase-i to add your reviewed-by]. While I really like seeing an unfinished topic completed by tying its loose ends like this patch does, it feels a bit too late for the cycle, especially given that we _know_ the changes still need to be tested on a platform that the series is expected to affect. Could somebody who builds regularly on Cygwin 1.7 try to see if these two patches are OK? Reports from people without previous experience with Git on Cygwin who freshly install Cygwin 1.7 only to test these two patches do not count, because they do not know what is expected and cannot tell regressions from know limitations. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git.pm with recent File::Temp fail
On Sun, 28 Apr 2013 20:59:16 -0700, Junio C Hamano gits...@pobox.com
wrote:
Jeff King p...@peff.net writes:
On Sun, Apr 28, 2013 at 11:09:33AM +0200, H.Merijn Brand wrote:
Still failing in 1.8.2.2
Short fix:
--8---
diff --git a/perl/Git.pm b/perl/Git.pm
index dc48159..7a252ef 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1265,7 +1265,7 @@ sub _temp_cache {
$tmpdir = $self-repo_path();
}
- ($$temp_fd, $fname) = File::Temp-tempfile(
+ ($$temp_fd, $fname) = File::Temp::tempfile(
'Git_XX', UNLINK = 1, DIR = $tmpdir,
) or throw Error::Simple(couldn't open new temp
file);
I think this fix is the right thing. Your patch probably didn't get
applied because it did not follow the guidelines in SubmittingPatches.
It was more like It managed to miss people's attention because the
subject didn't say [PATCH], but yes you are right that the change
the patch text itself shows looks reasonable and that I cannot apply
a patch that is not signed off (and worse yet in multipart/mixed).
My first attempt (when git-1.8.2 was released) had the patch attached
and the reply was
On Sat, 23 Mar 2013 16:32:47 +, Ben Walton bdwal...@gmail.com
wrote:
This list prefers patches to be inline so that they can easily be
commented on, etc. I took a quick look at your patch and while it
looks fine to me, fwiw.
You may want to resubmit using git send-email though so that others
will look at it and possibly apply it.
So I retried inlining. No mention about *how* to inline or that the
subject should have the word PATCH.
I don't need any credits. I just want git to work from scratch :)
...
So I think the right commit message is something like:
We call File::Temp's tempfile function as a class method, but it was
never designed to be called this way. Older versions seemed to
tolerate it, but as of File::Temp 0.23, it blows up like this:
$ git svn fetch
'tempfile' can't be called as a method at .../Git.pm line 1117.
Fix it by calling it as a regular function, just inside the File::Temp
namespace.
Sounds about right.
-Peff
Thanks.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git.pm with recent File::Temp fail
H.Merijn Brand h.m.br...@xs4all.nl writes: I don't need any credits. I just want git to work from scratch :) The sign-off procedure is not about giving credits to you. It is to protect us from others (e.g. your employer) by having a record that you claimed that you had the authority to give us the change. For a single-liner change like this, this often does not matter in practice, but we try to be consistent as it makes everybody's life simpler to have a single procedure for all the patches. Thanks ... So I think the right commit message is something like: We call File::Temp's tempfile function as a class method, but it was never designed to be called this way. Older versions seemed to tolerate it, but as of File::Temp 0.23, it blows up like this: $ git svn fetch 'tempfile' can't be called as a method at .../Git.pm line 1117. Fix it by calling it as a regular function, just inside the File::Temp namespace. Sounds about right. -Peff Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
