Re: [OT] How to get the discussion details via notes

[Peter Baumann]

On Wed, Oct 31, 2012 at 10:10:24AM -0400, Jeff King wrote:
 On Wed, Oct 31, 2012 at 10:53:27AM +0100, Peter Baumann wrote:
 
   covers the basics (current behavior and intent of the change) in its
   first two paragraphs and anyone wanting more detail can use
   
 GIT_NOTES_REF=refs/remotes/charon/notes/full \
 git show --show-notes commit
   
   to find more details.
  
  I seem to miss something here, but I don't get it how the notes ref
  becomes magically filled with the details of this discussion.
 
 Thomas Rast (aka charon) keeps a mapping of commits to the email threads
 that led to them. You can fetch it from:
 
git://repo.or.cz/git/trast.git
 
 (try the notes/full and notes/terse refs).
 

Nice! I didn't know about that.

-Peter
--
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

[OT] How to get the discussion details via notes

[Peter Baumann]

Dropping the Cc list, as this is off topic

On Tue, Oct 30, 2012 at 11:05:29PM -0700, Jonathan Nieder wrote:
 Sverre Rabbelier wrote:
 
  Thanks for the thorough explanation. Perhaps some of that could make
  it's way into the commit message?
 
 It's fine with me if it doesn't, since the original commit message
 covers the basics (current behavior and intent of the change) in its
 first two paragraphs and anyone wanting more detail can use
 
   GIT_NOTES_REF=refs/remotes/charon/notes/full \
   git show --show-notes commit
 
 to find more details.

I seem to miss something here, but I don't get it how the notes ref
becomes magically filled with the details of this discussion.

Care to explain?

-Peter
--
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 svn clone, a non-standard layout question

[Peter Baumann]

On Sun, Aug 12, 2012 at 11:23:16PM -0400, Christopher Marshall wrote:
 I would like to use git svn to clone an svn repo with a non-standard
 branches layout roughly like this:
 trunk/
 tags/
 branches/
b1
b2
...
bdir/
   b3
   b4
   ...
 
 That is, every directory under branches is a branch except bdir, and
 every directory under bdir is a branch.
 
 One thing I have attempted is this:
git svn clone \
   --trunk=trunk \
   --branches=branches/bdir \
   --branches=branches \
   --tags=tags \
   --prefix=svn/ $SVN_REPO \
   git.svn
 
 That properly creates the remote tracking branches b1,b2,b3,b4 but
 also creates the remote tracking branch bdir, which I am trying to
 exclude.  If I were to settle for this, the bdir branch would have
 enormous trees committed to it (when I ran against the real svn repo I
 am targetting).
 
 I get can exactly the branch mapping I want by editing .git/config like this:
 [svn-remote svn]
 url = file:///home/chris/programs/svn/repo
 fetch = trunk:refs/remotes/svn/trunk
 tags = tags/*:refs/remotes/svn/tags/*
 branches = branches/{b1,b2}:refs/remotes/svn/*
 branches = branches/bdir/{b3,b4}:refs/remotes/svn/*
 
 but then I would have to manually add branches before every git svn
 fetch, or risk not importing new branches that other developers have
 created since I last fetched.
 

I had a similar problem, but I solved it using ignore-paths and ignore-refs.
If I remember correctly, you need to set both to ignore bdir directly without
ignoring b3, b4,...

For ignore-refs, pls see cdb51a13c3cf4830d499d1138160eacdd2b8aa46, as it is 
currently
undocumented.

So I would try experimenting with the following settings:

[svn-remote svn]
url = file:///home/chris/programs/svn/repo
fetch = trunk:refs/remotes/svn/trunk
tags = tags/*:refs/remotes/svn/tags/*
branches = branches/{b1,b2}:refs/remotes/svn/*
branches = branches/bdir/{b3,b4}:refs/remotes/svn/*

# Operates on the imported git branches
ignore-refs  = ^refs/remotes/bdir$

# Operates on the SVN branches; you might try it first without this 
statement
ignore-paths = ^branches/bdir$
--
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 svn clone, a non-standard layout question

[Peter Baumann]

On Mon, Aug 13, 2012 at 09:29:53AM -0400, Christopher Marshall wrote:
 
  I had a similar problem, but I solved it using ignore-paths and 
  ignore-refs.
  If I remember correctly, you need to set both to ignore bdir directly 
  without
  ignoring b3, b4,...
 
  For ignore-refs, pls see cdb51a13c3cf4830d499d1138160eacdd2b8aa46, as it is 
  currently
  undocumented.
 
  So I would try experimenting with the following settings:
 
  [svn-remote svn]
  url = file:///home/chris/programs/svn/repo
  fetch = trunk:refs/remotes/svn/trunk
  tags = tags/*:refs/remotes/svn/tags/*
  branches = branches/{b1,b2}:refs/remotes/svn/*
  branches = branches/bdir/{b3,b4}:refs/remotes/svn/*
 
  # Operates on the imported git branches
  ignore-refs  = ^refs/remotes/bdir$
 
  # Operates on the SVN branches; you might try it first without this 
  statement
  ignore-paths = ^branches/bdir$
  --
 
 Peter:
 
 Thanks for the advice.  I tried this:
 
 [svn-remote svn]
 url = file:///home/chris/programs/svn/repo
 fetch = trunk:refs/remotes/svn/trunk
 branches = branches/*:refs/remotes/svn/*
 tags = tags/*:refs/remotes/svn/tags/*
 branches = branches/bdir/*:refs/remotes/svn/bdir2/*
 ignore-paths  = ^branches/bdir$
 ignore-refs  = ^refs/remotes/bdir$
 
 It doesn't seem to change anything.
 

You need a git version new enough to include 
cdb51a13c3cf4830d499d1138160eacdd2b8aa46, otherwise
it won't have any effect and will be silently ignored.

 Chris
 --
 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
 
--
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 v2] git svn: reset invalidates the memoized mergeinfo caches

[Peter Baumann]

On Wed, Aug 08, 2012 at 10:52:58PM +, Eric Wong wrote:
 Peter Baumann waste.mana...@gmx.de wrote:
  On Tue, Aug 07, 2012 at 08:45:10PM +, Eric Wong wrote:
   Peter Baumann waste.mana...@gmx.de wrote:
+   for my $suffix (qw(yaml db)) {
+   unlink($cache_file.$suffix);
   
   Need to check for unlink() errors (and ignore ENOENT).
  
  I'm not sure what you mean here: Aren't we screwed either way if unlinking
  the file failed? There is nothhing we can do about it if e.g. the user 
  doesn't
  have the permissions to delete the file, besides terminating, e.g.
  
  for my $cache_file (($cache_path/lookup_svn_merge,
   $cache_path/check_cherry_pick,
   $cache_path/has_no_changes)) {
  for my $suffix (qw(yaml db)) {
  next unless (-e $cache_file.$suffix);
  unlink($cache_file.$suffix) or 
  die Failed to delete $cache_file.$suffix;
  }
 
 Yes we're screwed, but silent failure is the worst way to fail,
 especially if it can lead us back to the problems your patch is meant to
 address.
 
 Perhaps something like this (with $! to show the error):
 
   my $file = $cache_file.$suffix;
   next unless -e $file;
   unlink($file) or die unlink($file) failed: $!\n;

First, let me thank you for your review and your detailed explanation.
I really appreciate it.

I changed svn to svn_cmd in the test (and also some minor changes to
the comments and removing trailing whitespace) and switched the order of
clear_memoized_mergeinfo_caches and _rev_map_reset as you asked for, so 
hopefully this is ready to go in.

-- 8 --
From: Peter Baumann waste.mana...@gmx.de
Subject: [PATCH] git svn: reset invalidates the memoized mergeinfo caches

Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every 'git svn fetch'.

This memoization can cause problems, e.g consider the following case:

SVN repo:

  ... - a - b - c - m  - trunk
  \/
d  -  e- branch1

The Git import of the above repo is at commit 'a' and doesn't know about
the branch1. In case of an 'git svn rebase', only the trunk of the
SVN repo is imported. During the creation of the git commit 'm', git svn
uses the svn:mergeinfo property and tries to find the corresponding git
commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase
only imports the current branch so commit 'e' is not imported.
Therefore git svn fails to create commit 'm' as a merge commit, because one
of its parents is not known to git. The imported history looks like this:

  ... - a - b - c - m  - trunk

A later 'git svn fetch' to import all branches can't rewrite the commit 'm'
to add 'e' as a parent and to make it a real git merge commit, because it
was already imported.

That's why the imported history misses the merge and looks like this:

  ... - a - b - c - m  - trunk
  \
d  -  e- branch1

Right now the only known workaround for importing 'm' as a merge is to
force reimporting 'm' again from SVN, e.g. via

  $ git svn reset --revision $(git find-rev $c)
  $ git svn fetch

Sadly, this is where the behavior has regressed: git svn reset doesn't
invalidate the old mergeinfo cache, which is no longer valid for the
reimport, which leads to 'm' beeing imprted with only 'c' as parent.

As solution to this problem, this commit invalidates the mergeinfo cache
to force correct recalculation of the parents.

During development of this patch, several ways for invalidating the cache
where considered. One of them is to use Memoize::flush_cache, which will
call the CLEAR method on the underlying Memoize persistency implementation.
Sadly, neither Memoize::Storable nor the newer Memoize::YAML module
introduced in 68f532f4ba888 could optionally be used implement the
CLEAR method, so this is not an option.

Reseting the internal hash used to store the memoized values has the same
problem, because it calls the non-existing CLEAR method of the
underlying persistency layer, too.

Considering this and taking into account the different implementations
of the memoization modules, where Memoize::Storable is not in our control,
implementing the missing CLEAR method is not an option, at least not if
Memoize::Storable is still used.

Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be problematic, because the in-memory
representation would still exist and contain wrong data. Fortunately, the
memoization is active in memory only for a small portion of the code.
Invalidating the cache by deleting the files

Re: [PATCH] git svn: reset invalidates the memoized mergeinfo caches

[Peter Baumann]

On Tue, Aug 07, 2012 at 08:45:10PM +, Eric Wong wrote:
 Peter Baumann waste.mana...@gmx.de wrote:
  Therefore the easiest solution to clear the cache is to delete the files
  on disk in 'git svn reset'. Normally, deleting the files behind the back
  of the memoization module would be problematic, because the in-memory
  representation would still exist and contain wrong data. Fortunately, the
  memoization is active in memory only for a small portion of the code.
  Invalidating the cache by deleting the files on disk if it isn't active
  should be safe.
 
 Thanks for the patch and explanation.  A few comments below:
 
  +   sub clear_memoized_mergeinfo_caches {
  +   die Only call this method in non-memoized context if 
  ($memoized);
  +
  +   my $cache_path = $ENV{GIT_DIR}/svn/.caches/;
  +   return unless -d $cache_path;
  +
  +   for my $cache_file (($cache_path/lookup_svn_merge,
  +$cache_path/check_cherry_pick,
  +$cache_path/has_no_changes)) {
  +   for my $suffix (qw(yaml db)) {
  +   unlink($cache_file.$suffix);
 
 Need to check for unlink() errors (and ignore ENOENT).


I'm not sure what you mean here: Aren't we screwed either way if unlinking
the file failed? There is nothhing we can do about it if e.g. the user doesn't
have the permissions to delete the file, besides terminating, e.g.

for my $cache_file (($cache_path/lookup_svn_merge,
 $cache_path/check_cherry_pick,
 $cache_path/has_no_changes)) {
for my $suffix (qw(yaml db)) {
next unless (-e $cache_file.$suffix);
unlink($cache_file.$suffix) or 
die Failed to delete $cache_file.$suffix;
}
}

 
  @@ -2126,8 +2142,13 @@ sub rev_map_set {
   
  sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)
   or croak Couldn't open $db_lock: $!\n;
  -   $update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :
  -_rev_map_set($fh, $rev, $commit);
  +   if ($update_ref eq 'reset') {
  +   _rev_map_reset($fh, $rev, $commit);
  +   clear_memoized_mergeinfo_caches();
 
 Better to clear_memoized_mergeinfo_caches() before _rev_map_reset()
 in case unlink() (or anything else) fails when clearing the cache.

Will do.

 
  +test_expect_success 'initialize source svn repo' '
  +   svn_cmd mkdir -m create trunk $svnrepo/trunk 
  +   svn_cmd mkdir -m create branches $svnrepo/branches 
  +   svn_cmd co $svnrepo/trunk $SVN_TREE 
  +   (
  +   cd $SVN_TREE 
  +   touch foo 
  +   svn add foo 
 
 svn_cmd here, too.

Will do.
 
  +   svn commit -m a 
  +   svn cp -m branch $svnrepo/trunk $svnrepo/branches/branch1 
  +   svn switch $svnrepo/branches/branch1 
  +   touch bar 
  +   svn add bar 
  +   svn commit -m b 
  +   svn switch $svnrepo/trunk 
  +   touch baz 
  +   svn add baz 
  +   svn commit -m c 
  +   svn up 
  +   svn merge $svnrepo/branches/branch1 
  +   svn commit -m m
  +   ) 
 --
 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
 
--
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] git svn: reset invalidates the memoized mergeinfo caches

[Peter Baumann]

Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every 'git svn fetch'.

This memoization can cause problems, e.g consider the following case:

SVN repo:

  ... - a - b - c - m  - trunk
  \/
d  -  e- branch1

The Git import of the above repo is at commit 'a' and doesn't know about
the branch1. In case of an 'git svn rebase', only the trunk of the
SVN repo is imported. During the creation of the git commit 'm', git svn
uses the svn:mergeinfo property and tries to find the corresponding git
commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase
only imports the current branch so commit 'e' is not imported.
Therefore git svn fails to create commit 'm' as a merge commit, because one
of its parents is not known to git. The imported history looks like this:

  ... - a - b - c - m  - trunk

A later 'git svn fetch' to import all branches can't rewrite the commit 'm'
to add 'e' as a parent and to make it a real git merge commit, because it
was already imported.

That's why the imported history misses the merge and looks like this:

  ... - a - b - c - m  - trunk
  \
d  -  e- branch1

Right now the only known workaround for importing 'm' as a merge is to
force reimporting 'm' again from SVN, e.g. via

  $ git svn reset --revision $(git find-rev $c)
  $ git svn fetch

Sadly, this is where the behavior has regressed: git svn reset doesn't
invalidate the old mergeinfo cache, which is no longer valid for the
reimport, which leads to 'm' beeing imprted with only 'c' as parent.

As solution to this problem, this commit invalidates the mergeinfo cache
to force correct recalculation of the parents.

During development of this patch, several ways for invalidating the cache
where considered. One of them is to use Memoize::flush_cache, which will
call the CLEAR method on the underlying Memoize persistency implementation.
Sadly, neither Memoize::Storable nor the newer Memoize::YAML module
introduced in 68f532f4ba888 could optionally be used implement the
CLEAR method, so this is not an option.

Reseting the internal hash used to store the memoized values has the same
problem, because it calls the non-existing CLEAR method of the
underlying persistency layer, too.

Considering this and taking into account the different implementations
of the memoization modules, where Memoize::Storable is not in our control,
implementing the missing CLEAR method is not an option, at least not if
Memoize::Storable is still used.

Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be problematic, because the in-memory
representation would still exist and contain wrong data. Fortunately, the
memoization is active in memory only for a small portion of the code.
Invalidating the cache by deleting the files on disk if it isn't active
should be safe.

Signed-off-by: Peter Baumann waste.mana...@gmx.de
---
 perl/Git/SVN.pm| 25 ++-
 t/t9163-git-svn-reset-clears-caches.sh | 79 ++
 2 files changed, 102 insertions(+), 2 deletions(-)
 create mode 100755 t/t9163-git-svn-reset-clears-caches.sh

diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0889145..430b366 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1634,6 +1634,22 @@ sub tie_for_persistent_memoization {
Memoize::unmemoize 'has_no_changes';
}
 
+   sub clear_memoized_mergeinfo_caches {
+   die Only call this method in non-memoized context if 
($memoized);
+
+   my $cache_path = $ENV{GIT_DIR}/svn/.caches/;
+   return unless -d $cache_path;
+
+   for my $cache_file (($cache_path/lookup_svn_merge,
+$cache_path/check_cherry_pick,
+$cache_path/has_no_changes)) {
+   for my $suffix (qw(yaml db)) {
+   unlink($cache_file.$suffix);
+   }
+   }
+   }
+
+
Memoize::memoize 'Git::SVN::repos_root';
 }
 
@@ -2126,8 +2142,13 @@ sub rev_map_set {
 
sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)
 or croak Couldn't open $db_lock: $!\n;
-   $update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :
-_rev_map_set($fh, $rev, $commit);
+   if ($update_ref eq 'reset') {
+   _rev_map_reset($fh, $rev, $commit);
+   clear_memoized_mergeinfo_caches();
+   } else {
+   _rev_map_set($fh, $rev, $commit);
+   }
+
if ($sync) {
$fh-flush or die Couldn't flush $db_lock: $!\n;
$fh-sync or die Couldn't sync $db_lock

Re: [RFC] l10n: de.po: translate 29 new messages

[Peter Baumann]

On Fri, Jul 06, 2012 at 08:58:21PM +0200, Ralf Thielow wrote:
 On Fri, Jul 6, 2012 at 8:20 PM, Michael J Gruber
 g...@drmicha.warpmail.net wrote:
  Ralf Thielow venit, vidit, dixit 05.07.2012 20:16:
  Is rebase = Neuaufbau? My last thought on this wording was rebase 
  =
  Umpflanzen.
 
  Basisumbau?
 
 
  I have added both suggestions to the glossary that they don't get lost when
  we discuss about non-optimal and/or missing parts within the glossary.
 
  Not the base is being reconstructed, but what's on top of it. So,
  Basiswechsel would be more appropriate.
 
 
 I agree with you. There is no question what it means, but what are
 the best german words for it.
 
  But: Umpflanzen is really a great term which stays within the context
  of trees, roots and branches. Strictly speaking, Umpflanzen refers to
  something you do at the root level. The corresponding action for
  branches would be Umpfropfen. I think that also conveys the effort
  that is sometimes necessary ;)
 
 Neuaufbau: it contains the concept of rebase
 Umpflanzen: it contains the concept of rebase
 Umpfropfen: Actually, this word isn't familiar to me. It's a bit
 unusual, isn't it?
 (but it might contains the concept of rebase)
 
 The whole point is that the user needs to know what it actually meant
 in git-context.
 If a user read sie pflanzen gerade um or sie pfropfen gerade um, I
 don't think that
 this is the best solution. I haven't said that sie bauen gerade neu
 auf is the optimal one,
 for me it's better, though.
 
 We really need to discuss (and thats indeed also an issue on other
 translation teams), which
 git (or SCM) related words we shouldn't translate at all.

I have to agree with this last sentence. Most of the git gui terms are really
not understandable to me (and even the team I introduced it too). The only way 
to 
actually guess what it means is by knowing the position of the buttons and 
then
getting the actual command from the position. 

AFAIK it makes no senes to translate terms like commit to Abzeichen like it 
is used
in git gui. I don't know *anybody* here in my IT business environment who uses 
this word
or even would guess what it means.  Everyone is used to the Denglisch Version 
committen 
or einchecken.

But in case you insist of translating this word (which I wouldn't!!!),
may I toss in another suggestion: Umsetzen

-Peter
--
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