Re: [PATCH/RFC v2 0/16] Introduce index file format version 5
Thomas Rast tr...@student.ethz.ch writes: I like the general idea, too, but I think there is a long way ahead, and we shouldn't hold up v5 on this. We shouldn't rush, only to keep some deadline, and regret it later that we butchered the index format without thinking things through. When this was added to the GSoC idea page, I already said upfront that this was way too big a topic to be a GSoC project, didn't I? It would open some interesting possibilities. It is unclear why the current format is less easier to get the same kind of enhancement compared to the proposed v5 for the same kind of possibilities. This codepath currently does things this way because it is limited by the flat in-core index. That codepath does a similar thing, and that other one has the same issue. They all can benefit if we give them this API, and the implementation of the API could benefit if the underlying on-disk format is changed that way. And the other codepaths that use the current API won't be broken by the on-disk format change, as all the accesses are encapsulated with this patch without losing performance, readability nor modifiability is very much acceptable [*1*], but The new on-disk format is different from the current one, and as it is different from the current one, we can easily enhance it even more by hooking anything interesting to it! does not sound like a valid argument. For example, for v5 it would be far better if conflicted and resolve-undo entries were a property of the normal index entry, instead of something that so happens to be consecutive entries and in a completely different place, respectively. I am not sure I am convinced. Conflicts are already expressed by an attribute on a normal index entry (it is called stage), and because we check for is the index fully merged fairly often, it makes sense to have it in each entry. Actually having an unmerged entry is a rare event (happens only during a mergy operation that gave control back to you), so we do not lose much by expressing them as consecutive entries. Resolve-undo is far less often used, and is not an essential feature, so it makes perfect sense to have it as an optional index extension to allow versions of Git that are unaware of it to still use an index file that has it. I do not find your For example argument particularly convincing rationale to go to the proposed v5, even if I thought resolve-undo were one of the more important things in the index (which I don't). [Footnote] *1* Duy's 'ls-files $path' would benefit from a path-limited index file reader, and the function to do so would be an obvious new API that would benefit from tree-shaped on-disk format suggestion is a design going in the right direction, as long as it is accompanied with for the remaining users that need the whole index as a linear array, reading such a tree-shaped on-disk format can be supported without loss of performance with this patch. -- 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/RFC v2 0/16] Introduce index file format version 5
Junio C Hamano gits...@pobox.com writes:
Then of course you need to split the second patch into several logical
patches again. We can drop _v5 suffix in read-cache-v5.c (I haven't
done that). When we add partial read/write for v5, we can add more
func pointers to index_ops and implement them in v2 (probably as no-op
or assertion)
The index_ops abstraction is a right way to go, and I like it, but I
think the split illustrated in this patch might turn out to be at
wrong levels (and it is OK, as I understand this is a illustration
of concept patch).
For example, add_to_index() interface may be a good candidate to
have in index_ops. Because your in-core index may not be holding
everything in a flat array, find the location in the flat array the
entry would sit, replace the existing one if there is any, otherwise
insert cannot be a generic way to add a new entry. If you make the
whole thing an abstract API entry point, a sparse implementation of
the in-core index could still implement it without bringing the
untouched and irrelevant parts of the index to core.
[...]
I wish that the development of this topic was done more in a
top-down direction, instead of bottom-up, so that it identified the
necessary access patterns to the in-core index early and come up
with a good set of abstract API first, and then only after that is
done, came up with in-core and on-disk format to support the
necessary operations.
I like the general idea, too, but I think there is a long way ahead, and
we shouldn't hold up v5 on this.
Thomas and me -- it was mostly my bad idea -- spent some time going
through all the loops that iterate over the index. You can get some
taste of it with 'git grep ce_stage', mostly because many of them either
skip unmerged entries or specifically look for them. There are subtle
differences between the loops on many points: what do they do when they
hit an unmerged entry? Or a CE_REMOVED or CE_VALID one?
I gave up after treating half of them and horribly breaking the test
suite. I suppose eventually we will have to classify these loops by
properties like how they treat unmerged entries, and replace them by
some clever for_each_cache_entry macro.
It would open some interesting possibilities. For example, for v5 it
would be far better if conflicted and resolve-undo entries were a
property of the normal index entry, instead of something that so happens
to be consecutive entries and in a completely different place,
respectively.
--
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
merging confusion and question
I'm confused. What is the intended work flow here? Ie, aside from trashing my repository and starting over, what does one do to recover? rich@cobra git clone /home/rich/repos/webos webos Cloning into 'webos'... done. rich@cobra cd webos rich@cobra git remote add central g...@github.com:openwebos/webos.git rich@cobra git co master Already on 'master' rich@cobra git pull central master X11 forwarding request failed on channel 0 remote: Counting objects: 22, done. remote: Compressing objects: 100% (19/19), done. remote: Total 21 (delta 12), reused 11 (delta 2) Unpacking objects: 100% (21/21), done. From github.com:openwebos/webos * branchmaster - FETCH_HEAD warning: Failed to merge submodule meta-webos (not checked out) Auto-merging meta-webos CONFLICT (submodule): Merge conflict in meta-webos Auto-merging README.md Automatic merge failed; fix conflicts and then commit the result. rich@cobra git commit -a error: unable to index file meta-webos fatal: updating files failed rich@cobra git add meta-webos error: unable to index file meta-webos fatal: updating files failed rich@cobra git rm meta-webos meta-webos: needs merge rm 'meta-webos' fatal: git rm: 'meta-webos': Is a directory rich@cobra git merge meta-webos error: 'merge' is not possible because you have unmerged files. hint: Fix them up in the work tree, hint: and then use 'git add/rm file' as hint: appropriate to mark resolution and make a commit, hint: or use 'git commit -a'. fatal: Exiting because of an unresolved conflict. --rich -- 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/RFC v2 0/16] Introduce index file format version 5
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: add_to_index and remove_index_entry_at seem good places for the cut. But do we need to redefine the location? That is one of the things we need to think about carefully. Of course, if add_to_index() just takes a pathname out of the ce the caller wants to add, you can define remove_from_index() that takes a pathname (and possibly a stage), finds the ce with that pathname in the index and removes it. But that would unnecessrily penalize the callers that follow see if there is such an entry (i.e. locate), optionally inspect the entry and then decide to remove, especially if the locate is expensive. If a nonsignificant number of callers follow such a pattern, then having a separate locate API that can return a location that is expressed either as the number of entries to skip from the beginning (in a flat in-core array) or a pair of in-core directory structure and the index in the directory to let the caller find the entry quickly, and then later pass it to remove, would be more appropriate. add_index_entry_at() may also not a bad thing to have if many callers turn out to follow a similar access pattern (i.e. locate, decide to or not to replace when there already is one, and then add it). - for 3-5 years since v5 is released, we support v2 and v5 in parallel. Other code can take advantage of v5, but it must neither sacrifice v2 performance, compatibility nor maintainability - after that, we deprecate v2. v2 is automatically converted to v5 in memory. v2 perf may suffer but at that point we don't care any more as the majority of users should have been migrated to v5 (*) As long as the performance of Git on a working tree that used to get certain performance back when it was using v2 does not degrade when it is converted to v5 or later, I think the above is a good way forward. If the long term plan is actually that, we will need to stick to flat array implementation for forseeable future as moving from it most likely impacts v2 performance. I do not see why we need to stick to; I do not see why it is necessarily a bad thing if we end up choosing to stick to if the reason we choose it is because the flat in-core performs better. If the workload we _care_ about is served better by using an API that works over an in-core tree-shaped index data structure, I do not think it is unreasonable to read the v2 on-disk format and represent it as a tree-shaped index while we read it. Of course, there are things that are not as effective when reading from the flat v2 on-disk format (e.g. path limited reading will have to at least _scan_ the whole thing, even though it may process only the entries that match the pathspec) compared to reading from a tree-shaped on-disk format, but I doubt that the difference between the cost of reading into a flat array and the cost of reading and forming whatever non-flat data structure you seem to think is better is so big that it would negate the benefit of using a better in-core structure. This might not be the best way forward as v2 incompatible features (like keeping empty directories in index, what else?) may never come until v2 is deprecated. I do not think empty directories matter to begin with, but even if it did, I do not think v2 is inherently incapable of being enhanced to record one if you really wanted to. Either you come up with a new mode bits and add it as a regular cache entry, or record the fact that there is a directory in a new index extension. The real issue to solve is to decide what semantics you want (e.g. What to do when you earlier have added an empty directory, added a file in it and then removed the file, making it empty again? What if that happened during a merge?), to verify the semantics you define are sane, to add keep_empty_directory() function to read-cache.c, and to sprinkle callers to the API function as needed. These have to be done regardless of the actual on-disk format. -- 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: merging confusion and question
Rich Pixley rich.pix...@palm.com writes: I'm confused. What is the intended work flow here? Ie, aside from trashing my repository and starting over, what does one do to recover? rich@cobra git clone /home/rich/repos/webos webos Cloning into 'webos'... done. rich@cobra cd webos rich@cobra git remote add central g...@github.com:openwebos/webos.git rich@cobra git co master Already on 'master' rich@cobra git pull central master X11 forwarding request failed on channel 0 remote: Counting objects: 22, done. remote: Compressing objects: 100% (19/19), done. remote: Total 21 (delta 12), reused 11 (delta 2) Unpacking objects: 100% (21/21), done. From github.com:openwebos/webos * branchmaster - FETCH_HEAD warning: Failed to merge submodule meta-webos (not checked out) Auto-merging meta-webos CONFLICT (submodule): Merge conflict in meta-webos Auto-merging README.md Automatic merge failed; fix conflicts and then commit the result. rich@cobra git commit -a Why isn't there any fix conflicts and then step between this line and the friendly insn message on the previous line? error: unable to index file meta-webos fatal: updating files failed rich@cobra git add meta-webos error: unable to index file meta-webos fatal: updating files failed rich@cobra git rm meta-webos meta-webos: needs merge rm 'meta-webos' fatal: git rm: 'meta-webos': Is a directory rich@cobra git merge meta-webos error: 'merge' is not possible because you have unmerged files. hint: Fix them up in the work tree, hint: and then use 'git add/rm file' as hint: appropriate to mark resolution and make a commit, hint: or use 'git commit -a'. fatal: Exiting because of an unresolved conflict. If you are not interested in mucking with meta-webos with this merge, you would resolve meta-webos by taking either your (i.e. the one that came from /home/rich/repos/webos) version or their (i.e. the one that came from openwebos/webos.git) version. Go back to the state before git pull central master with reset --hard, init and update webos submodule, try the pull again and then git add webos to resolve to your version, perhaps? -- 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: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?
[..] - By design, the borrowed object store MUST not ever lose any object from it, as such an object loss can corrupt the borrowing repositories. In theory, it is OK for the object store whose objects are borrowed by repositories to acquire new objects, but losing existing objects is an absolute no-no. [...] In practice, this means that users who use clone -s to make a new repository can *never* prune the original repository without risking to corrupt its borrowing repository [*1*]. [...] Given your example of /git/linux.git being a clone of Linus' repository, cloning a related repository using it as --reference: $ cd /git $ git clone --reference /git/linux.git git://k.org/linux-next.git mine Wouldn't it be by far a less intrusive alternative to do the following (in the clone step above): - create the file /git/linux.git/objects/borrowing/_git_mine (This is where we borrow FROM). This file would hold a packed-ref list of HEADs from the /git/mine clone of the repository. _git_mine here is slash-stripped version of the destination path. Maybe the packed-ref format could also be extended by a single line containing a full path to the foreign repository. - On every update-ref to /git/mine, update the 'borrowing' refs in /git/linux.git - On any maintenance on /git/linux.git (gc, prune, repack, etc.) consider refs in the packed-refs at objects/borrowing to be valid references. If packed-ref format was adopted like stated above, we could stat() here if this directory still exists and error out if it doesn't (In this case the user should tell us if she moved or removed the clone). Any alternatives for looking up the packed-refs list for borrowing would also be doable; i.E. putting the list of valid borrowing-packed-refs-files into the config file (as opposed to lookup $GIT_DIR/objects/borrowing above). Putting this list into the config file would eliminate need for the packed-ref format change and give the user the ability to maintain her clones with well- known command 'git config' -- 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/RFC] git svn: handle errors and concurrent commits in dcommit
Eric Wong wrote:
Hi,
A few minor comments inline...
Please ensure all error messages and code are readable in
80-column terminals.
Also, keep opening { on the same line as the if/unless.
Backticks don't nest properly, nowadays, we prefer:
N=$(expr $N + 1)
+cp auto_updated_file auto_updated_file_saved
Need to check for failure on cp
+sed -i 1d auto_updated_file git commit -am commit change
$N.3
I don't believe sed -i is portable enough for this test.
Many thanks for the comments! I've fixed all of the above and will send
updated patch in next e-mail. Please let me know if you have any further
comments.
+echo PATH=\$PATH\; export PATH $hook
+echo svnconf=\$svnconf\ $hook
+cat $hook - 'EOF2'
+cd work-auto-commits.svn
+svn up --config-dir $svnconf
That doesn't seem to interact well with users who depend on
svn_cmd pointing to something non-standard. Not sure
what to do about it, though
I have no idea how to change it either. I've tried to source the
lib-git-svn.sh file inside the hook, but it sources test-lib.sh, and the
latter script doesn't work well if it is sourced by non-test script.
Anyway I the part of my original patch unchanged.
Regards,
robert
--
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/RFC] git svn: handle errors and concurrent commits in dcommit
dcommit didn't handle errors returned by SVN and coped very
poorly with concurrent commits that appear in SVN repository
while dcommit was running. In both cases it left git repository
in inconsistent state: index (which was reset with `git reset
--mixed' after a successful commit to SVN) no longer matched the
checkouted tree, when the following commit failed or needed to be
rebased. See http://bugs.debian.org/676904 for examples.
This patch fixes the issues by:
- introducing error handler for dcommit. The handler will try
to rebase or reset working tree before returning error to the
end user. dcommit_rebase function was extracted out of cmd_dcommit
to ensure consistency between cmd_dcommit and the error handler.
- calling `git reset --mixed' only once after all patches are
successfully committed to SVN. This ensures index is not touched
for most of the time of dcommit run.
---
git-svn.perl | 74 +---
t/t9164-git-svn-dcommit-concrrent.sh | 216 ++
2 files changed, 271 insertions(+), 19 deletions(-)
create mode 100755 t/t9164-git-svn-dcommit-concrrent.sh
diff --git a/git-svn.perl b/git-svn.perl
index 5711c57..828b8f0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -777,6 +777,44 @@ sub populate_merge_info {
return undef;
}
+sub dcommit_rebase {
+ my ($is_last, $current, $fetched_ref, $svn_error) = @_;
+ my @diff;
+
+ if ($svn_error) {
+ print STDERR \nERROR from SVN:\n,
+ $svn_error-expanded_message, \n;
+ }
+ unless ($_no_rebase) {
+ # we always want to rebase against the current HEAD,
+ # not any head that was passed to us
+ @diff = command('diff-tree', $current,
+ $fetched_ref, '--');
+ my @finish;
+ if (@diff) {
+ @finish = rebase_cmd();
+ print STDERR W: $current and , $fetched_ref,
+ differ, using @finish:\n,
+join(\n, @diff), \n;
+ } elsif ($is_last) {
+ print No changes between , $current, and ,
+ $fetched_ref,
+ \nResetting to the latest ,
+ $fetched_ref, \n;
+ @finish = qw/reset --mixed/;
+ }
+ command_noisy(@finish, $fetched_ref) if @finish;
+ }
+ if ($svn_error) {
+ die ERROR: Not all changes have been committed into SVN
+ .($_no_rebase ? .\n : , however the committed\n
+ .ones (if any) seem to be successfully integrated
+ .into the working tree.\n)
+ .Please see the above messages for details.\n;
+ }
+ return @diff;
+}
+
sub cmd_dcommit {
my $head = shift;
command_noisy(qw/update-index --refresh/);
@@ -904,6 +942,7 @@ sub cmd_dcommit {
}
my $rewritten_parent;
+ my $current_head = command_oneline(qw/rev-parse HEAD/);
Git::SVN::remove_username($expect_url);
if (defined($_merge_info)) {
$_merge_info =~ tr{ }{\n};
@@ -943,6 +982,14 @@ sub cmd_dcommit {
},
mergeinfo = $_merge_info,
svn_path = '');
+
+ my $err_handler = $SVN::Error::handler;
+ $SVN::Error::handler = sub {
+ my $err = shift;
+ dcommit_rebase(1, $current_head, $gs-refname,
+ $err);
+ };
+
if (!Git::SVN::Editor-new(\%ed_opts)-apply_diff) {
print No changes\n$d~1 == $d\n;
} elsif ($parents-{$d} @{$parents-{$d}}) {
@@ -950,31 +997,19 @@ sub cmd_dcommit {
$parents-{$d};
}
$_fetch_all ? $gs-fetch_all : $gs-fetch;
+ $SVN::Error::handler = $err_handler;
$last_rev = $cmt_rev;
next if $_no_rebase;
- # we always want to rebase against the current HEAD,
- # not any head that was passed to us
- my @diff = command('diff-tree', $d,
- $gs-refname, '--');
- my @finish;
- if (@diff) {
- @finish = rebase_cmd();
- print STDERR W: $d and , $gs-refname,
- differ, using @finish:\n,
-join(\n,
Re: [PATCH] git svn: reset invalidates the memoized mergeinfo caches
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
Re: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?
On Sun, Aug 05, 2012 at 11:38:12AM +0200, Michael Haggerty wrote: I have some other crazy ideas for making the concept even more powerful: * Support remote alternate repositories. Local repository obtains missing objects from the remote as needed. This would probably be insanely inefficient without also supporting... * Lazy copying of borrowed objects to the local repository. Any object fetched from the alternate object store is copied to the local object store. Together, I think that these two features would give fully-functional shallow clones. You might be interested in looking at my rough (_very_ rough) experiment with object db hooks: https://github.com/peff/git/commits/jk/external-odb The basic idea is to have helper programs that basically have two commands: give a list of sha1s you can provide, and fetch a specific object by sha1. That's enough for the low levels of git to fall-back to a helper on an object lookup failure, and copy the object to a local cache. Managing the cache could be done externally by helper-specific code. Sorry, there's no documentation on the format or behavior, and most of the changes are in one big patch. If you're interested and find it unreadable, I can try to clean it up. -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: [PATCH 2/2] prune.c: only print informational message in show_only or verbose mode
On Mon, Aug 6, 2012 at 11:03 PM, Jeff King p...@peff.net wrote: On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote: Anyone else? :) Sorry to gang up on you. :) Heh. :b I still think your 2/2 is worth doing independently, though. It is silly that git-prune will not mention pruned objects without -v, but will mention temporary files. They should be in the same category. As I mentioned in an earlier message, I think the original thinking was that removing a temporary object should be an unusual occurrence that indicates a failure of some sort, so you want to inform the user who may want to investigate (of course the file's gone, so what's to investigate). Removing a stale object file on the other hand is just part of the normal operation. That is why the former is always printed out and the latter only when -v is used. That was the original thinking, but I don't think it matters very much. Printing both using the same conditions seems valid. My commit message should be scrapped and replaced with something like your paragraph though.. -Brandon -- 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: info: display '--' as '-'
Jeff King p...@peff.net writes:
On Mon, Aug 06, 2012 at 11:08:39AM +0800, mofaph wrote:
I am using Git 1.7.11.4 now. I compile and then install it from the repo.
$ git checkout v1.7.11.4
$ make prefix=$HOME/opt/git/1.7.11.4 all doc info
$ make prefix=$HOME/opt/git/1.7.11.4 install{,-doc,-html,-info}
Recently, I found some problem when I read the git.info.
For example, you can see it in 3.7.1 Getting conflict-resolution
help during a
merge:
$ git log -merge
$ gitk -merge
See, it should be type like this:
$ git log --merge
$ gitk --merge
You will see this typo almost in the whole info file.
Yeah, I can reproduce it here. The data goes through these
transformations to get to the final info form:
user-manual.txt (source)
- user-manual.xml (via asciidoc)
- user-manual.texi (via docbook2x-texi)
- git.info (via makeinfo)
The data looks OK in user-manual.texi,
If you are interpreting it visually instead of as Texinfo source...
but -- is converted to - in git.info. So either:
1. There is a bug in makeinfo, which should not be doing this
conversion inside a @display section.
Not really: @display does not change fonts, merely indentation. From
the Texinfo manual:
The `@display' command begins a kind of example, where each line of
input produces a line of output, and the output is indented. It is
thus like the `@example' command except that, in a printed manual,
`@display' does not select the fixed-width font. In fact, it does not
specify the font at all, so that the text appears in the same font it
would have appeared in without the `@display' command.
This is an example of text written between an `@display' command
and an `@end display' command. The `@display' command
indents the text, but does not fill it.
But in non-typewriter fonts, -- is a shorthand for an en-dash (see
conventions in the Texinfo manual):
* Use three hyphens in a row, `---', to produce a long dash--like
this (called an em dash), used for punctuation in sentences.
Use two hyphens, `--', to produce a medium dash (called an en
dash), used primarily for numeric ranges, as in June 25-26.
Use a single hyphen, `-', to produce a standard hyphen used in
compound words. For display on the screen, Info reduces three
hyphens to two and two hyphens to one (not transitively!). Of
course, any number of hyphens in the source remain as they are in
literal contexts, such as `@code' and `@example'.
So somewhere in your conversion chains, you should try detecting code
examples and translate them into @example...@end example rather than the
merely indented @display ... @end display. It is likely that it will
look better in other parts of the production chain as well.
2. There is a bug in docbook2x-texi, which should be quoting the
contents of the literallayout when generating the @display
section.
Quoting won't help. You can likely get by with @w{-}@w{-} (putting the
hyphens separately in an unbreakable box), but the real formatting fix
is to use an environment suitable for literal character quotings rather
than free-flow text.
I don't know enough about texinfo to say which. But I'm sure that the
contents of user-manual.xml are correct, because I do actually speak
docbook, which means the problem happens after that step.
Cc-ing David Kastrup, who added the info version originally, and might
be more clueful about that part of the toolchain.
I think you are significantly overstating my contribution. Unless my
memory is failing me (always an option), I probably raised the main
stink at one time about the info documentation falling into a decrepit
state, but I don't think that I was all that much involved with getting
it up to scratch again, and I don't think I had been responsible for
originally implementing it.
--
David Kastrup
--
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/RFC v2 0/16] Introduce index file format version 5
On Tue, Aug 7, 2012 at 12:46 AM, Junio C Hamano gits...@pobox.com wrote: The index_ops abstraction is a right way to go, and I like it, but I think the split illustrated in this patch might turn out to be at wrong levels (and it is OK, as I understand this is a illustration of concept patch). For example, add_to_index() interface may be a good candidate to have in index_ops. Because your in-core index may not be holding everything in a flat array, find the location in the flat array the entry would sit, replace the existing one if there is any, otherwise insert cannot be a generic way to add a new entry. If you make the whole thing an abstract API entry point, a sparse implementation of the in-core index could still implement it without bringing the untouched and irrelevant parts of the index to core. Side note: with a tree-like implementation of the in-core index, find the location the entry would sit, get the entry at the location, insert the entry at the location, could still be a set of good abstract API, though. The definition of _location_ may be quite different from the offset of the entry counting from the beginning of a flat array, which is what index_name_pos() returns. The story is the same on the removal front. The current remove_index_entry_at() interface is tied to the flat array implementation, so remove the nth entry from the beginning is an inappropriate interface for anything but such an implementation (unless we come up with an abstract notion of the location that is usable efficiently in a tree-like implementation, that is). add_to_index and remove_index_entry_at seem good places for the cut. But do we need to redefine the location? I think we need to sketch out a long term plan first. In my mind it's like this: - for 3-5 years since v5 is released, we support v2 and v5 in parallel. Other code can take advantage of v5, but it must neither sacrifice v2 performance, compatibility nor maintainability - after that, we deprecate v2. v2 is automatically converted to v5 in memory. v2 perf may suffer but at that point we don't care any more as the majority of users should have been migrated to v5 (*) If the long term plan is actually that, we will need to stick to flat array implementation for forseeable future as moving from it most likely impacts v2 performance. When v5 is used, it must maintain two views, tree and list, at the same time. We can then postpone thinking about the redefinition until v2 is deprecated and in-core moved to tree view only. This might not be the best way forward as v2 incompatible features (like keeping empty directories in index, what else?) may never come until v2 is deprecated. (*) this is questionable though. Depending on the benchmarks, we may want to support both v2 and v5 for indefinite time with v2 recommended for small projects and v5 the rest. If it's so, yeah we need to think of better API now. I wish that the development of this topic was done more in a top-down direction, instead of bottom-up, so that it identified the necessary access patterns to the in-core index early and come up with a good set of abstract API first, and then only after that is done, came up with in-core and on-disk format to support the necessary operations. Yeah, which is why I asked to try out partial reading/writing early as I'm a learn by example kind of guy. Speaking of which, now that we have something substantial, what should be done before this may be considered for 'next'? I don't think we should wait until it reaches full potential (i.e. significant perf gain from all major index-related commands). Apart from patch preparation, more testing and benchmarking, should we wait until we get new public API or just use current index API? One API addition that I (if nobody else) will do soon is read_index_partial(pathspec) and adapt as many read-only commands as possible to it. (v2 just ignores the pathspec input and loads the whole thing, so all commands must be aware the the loaded may be more than what they asked). But this can wait until v5 gets in. -- Duy -- 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/RFC v2 01/16] Modify cache_header to prepare for other index formats
On 08/05, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: diff --git a/read-cache.c b/read-cache.c index 2f8159f..5d61d92 100644 --- a/read-cache.c +++ b/read-cache.c @@ -1433,7 +1446,7 @@ int read_index_from(struct index_state *istate, const char *path) errno = EINVAL; mmap_size = xsize_t(st.st_size); - if (mmap_size sizeof(struct cache_header) + 20) + if (mmap_size sizeof(struct cache_version_header) + 20) die(index file smaller than expected); At the design level, I have a large problem with this change. I understand that you wanted to make sure that some versions can lack the num-entries word in the header, but then what is the point of keeping that +20 here? Are all versions of the file format still required to have the 20-byte trailing SHA-1 sum over the whole file? No, index-v5 doesn't have the trailing SHA-1 over the whole file. Side note: I am actually fine with that sum at the end requirement, but then it needs to be documented what are assumed to be unomittable and why. I also do not see why v5 *needs* to drop the num-entries word from the header in the first place. v5 still has the num-entries word, but at a different position. The +20 however would still be wrong, because of the missing SHA-1 over the file. At the practical level, we used to error out, upon seeing a file that claims to be v2 in the header but is too small to hold the version header, the number of entries word and the trailing SHA-1 sum. We no longer do this and happily call verify_hdr() in the following code even when the file is too small, no? This part is called even before we know what version of the index we will read, and before the file is mmaped. The best solution i think is to drop the check and just call verify_hdr, since it will check the checksum anyway and detect the error, while not having a big cost on a index file that is very small. @@ -1442,11 +1455,13 @@ int read_index_from(struct index_state *istate, const char *path) die_errno(unable to map index file); hdr = mmap; + hdr_v2 = mmap + sizeof(*hdr); if (verify_hdr(hdr, mmap_size) 0) goto unmap; -- 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/RFC v2 04/16] Modify write functions to prepare for other index formats
On 08/05, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
-static int ce_write(git_SHA_CTX *context, int fd, void *data, unsigned int
len)
+static int ce_write_v2(git_SHA_CTX *context, int fd, void *data, unsigned
int len)
{
Mild NAK to name this function with any hint that it is for v2 only.
The type of data is not struct ondisk_index_entry_v2 and this is
just a way to stream data to fd while hashing, which is similar in
spirit to what csum-file.c sha1file'API does. Perhaps we may want
to update ce_write() interface to build on top of sha1file API?
At this step in the series, is it too early to split read-cache.c
into two files, move all the v2 specific part to read-cache-v2.c,
and keep static function names like write_index_ext_header() as they
are? After all, the main dispatch would become
+int write_index(struct index_state *istate, int newfd)
+{
+ if (!istate-version)
+ istate-version = INDEX_FORMAT_DEFAULT;
+
+ return write_index_v2(istate, newfd);
+}
so read-cache-v2.c would need to export write_index_v2() but the
functions to implement it like ce_write_entry() do not have to be
exposed outside the file, no?
No I think it makes sense to split them at this point. I'll do it along
the lines of what Duy suggested with his patch. [1]
[1] http://thread.gmane.org/gmane.comp.version-control.git/202923/focus=202964
--
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] Enable HAVE_DEV_TTY for Solaris
Excerpts from Jeff King's message of Tue Aug 07 00:10:26 -0400 2012: Signed-off-by: Jeff King p...@peff.net Acked-by: Ben Walton bwal...@artsci.utoronto.ca I agree with your assesment that this is the right way to go (vs migrating out of stdio) for now. If the changes Tay needs to make require the migration then it can become part of that series. Otherwise those changes would just be change for change's sake at this time. If my HAVE_DEV_TTY enabling patch for Solaris is added on top of this, I'm a happy camper. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -- 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/2] prune.c: only print informational message in show_only or verbose mode
Brandon Casey draf...@gmail.com writes: On Mon, Aug 6, 2012 at 11:03 PM, Jeff King p...@peff.net wrote: On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote: Anyone else? :) Sorry to gang up on you. :) Heh. :b I still think your 2/2 is worth doing independently, though. It is silly that git-prune will not mention pruned objects without -v, but will mention temporary files. They should be in the same category. As I mentioned in an earlier message, I think the original thinking was that removing a temporary object should be an unusual occurrence that indicates a failure of some sort, so you want to inform the user who may want to investigate (of course the file's gone, so what's to investigate). Removing a stale object file on the other hand is just part of the normal operation. That is why the former is always printed out and the latter only when -v is used. That matches my understanding, modulo may want to investigate is probably more like may want to be reminded of an earlier repack that was aborted. That was the original thinking, but I don't think it matters very much. Printing both using the same conditions seems valid. Yeah, I agree that it does not make much difference either way and both ways of thinking feel equally valid. -- 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/RFC v2 01/16] Modify cache_header to prepare for other index formats
Thomas Gummerer t.gumme...@gmail.com writes: This part is called even before we know what version of the index we will read, and before the file is mmaped. The best solution i think is to drop the check and just call verify_hdr, ... Exactly. And do the length checking inside verify_hdr() or its callee where we know what the minimum length is depending on the version as necessary to avoid over-reading. -- 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/RFC v2 06/16] t3700: sleep for 1 second, to avoid interfering with the racy code
On 08/05, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The new git racy code uses the mtime of cache-entries to smudge a racy clean entry, and loads the work, of checking the file-system -ECANTPARSE. The git racy code for index-v5 uses the mtime of the cache-entries as smudge markers. The work of checking the file-system is loaded of to the reader. if the entry has really changed, off to the reader. This interferes with this test, because the entry is racily smudged and thus has mtime 0. We wait 1 second to avoid smudging the entry and getting correct test results. Mild NAK, especially it is totally unclear why you even need to muck with racy-git check in the current format of the index in the first place, and even if it were necessary, it is unclear why this cannot be done with test-chmtime. The racy-git code needs to be changed, to avoid problems when implementing the partial writing for index-v5. Otherwise it could cause problems, when we have entries that should be smudged, but are not due to the different racy algorithms. I'll do it with test-chmtime in the reroll though. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/t3700-add.sh |1 + 1 file changed, 1 insertion(+) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index 874b3a6..4d70805 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -184,6 +184,7 @@ test_expect_success 'git add --refresh with pathspec' ' echo foo echo bar echo baz git add foo bar baz H=$(git rev-parse :foo) git rm -f foo echo 100644 $H 3 foo | git update-index --index-info + sleep 1 test-chmtime -60 bar baz expect git add --refresh bar actual -- 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 repack vs git gc --aggressive
hello, I read this: http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/ where git repack -a -d --depth=250 --window=250 is mentioned as a (recommended) alternative to git gc --aggressive. I am a bit confused, because the page also mentions that git gc --aggressive is recommended when a repo has been imported using git fast-import. So my questions are: 1. is the above repack command (with --depth=500) safe? Of course I want to be absolutely sure that our repo will be consistent. Do I need another command (git gc, git prune) as well? 2. is it the right tool for the job or shall I use git gc --aggressive? Thanks! -- Felix Natter -- 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 v1.7.12-rc2
A release candidate Git v1.7.12-rc2 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: f05297c883b958d04c00a7aba8f234261efd8844 git-1.7.12.rc2.tar.gz 931259a22e9d126c5c48deea0cbfeef246f93058 git-htmldocs-1.7.12.rc2.tar.gz 2262b31399f519b166f045f6aa63c8ec7e4ee515 git-manpages-1.7.12.rc2.tar.gz Also the following public repositories all have a copy of the v1.7.12-rc2 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.7.12 Release Notes (draft) = Updates since v1.7.11 - UI, Workflows Features * Git can be told to normalize pathnames it read from readdir(3) and all arguments it got from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8), in order to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * Per-user $HOME/.gitconfig file can optionally be stored in $HOME/.config/git/config instead, which is in line with XDG. * The value of core.attributesfile and core.excludesfile default to $HOME/.config/git/attributes and $HOME/.config/git/ignore respectively when these files exist. * Logic to disambiguate abbreviated object names have been taught to take advantage of object types that are expected in the context, e.g. XX in the git describe output v1.2.3-gXX must be a commit object, not a blob nor a tree. This will help us prolong the lifetime of abbreviated object names. * git apply learned to wiggle the base version and perform three-way merge when a patch does not exactly apply to the version you have. * Scripted Porcelain writers now have access to the credential API via the git credential plumbing command. * git help used to always default to man format even on platforms where man viewer is not widely available. * git clone --local $path started its life as an experiment to optionally use link/copy when cloning a repository on the disk, but we didn't deprecate it after we made the option a no-op to always use the optimization. The command learned --no-local option to turn this off, as a more explicit alternative over use of file:// URL. * git fetch and friends used to say remote side hung up unexpectedly when they failed to get response they expect from the other side, but one common reason why they don't get expected response is that the remote repository does not exist or cannot be read. The error message in this case was updated to give better hints to the user. * git help -w $cmd can show HTML version of documentation for git-$cmd by setting help.htmlpath to somewhere other than the default location where the build procedure installs them locally; the variable can even point at a http:// URL. * git rebase [-i] --root $tip can now be used to rewrite all the history leading to $tip down to the root commit. * git rebase -i learned -x cmd to insert exec cmd after each commit in the resulting history. * git status gives finer classification to various states of paths in conflicted state and offer advice messages in its output. * git submodule learned to deal with nested submodule structure where a module is contained within a module whose origin is specified as a relative URL to its superproject's origin. * A rather heavy-ish git completion script has been split to create a separate git prompting script, to help lazy-autoloading of the completion part while making prompting part always available. * gitweb pays attention to various forms of credits that are similar to Signed-off-by: lines in the commit objects and highlights them accordingly. Foreign Interface * mediawiki remote helper (in contrib/) learned to handle file attachments. * git p4 now uses Jobs: and p4 move when appropriate. * vcs-svn has been updated to clean-up compilation, lift 32-bit limitations, etc. Performance, Internal Implementation, etc. (please report possible regressions) * Some tests showed false failures caused by a bug in ecryptofs. * We no longer use AsciiDoc7 syntax in our documentation and favor a more modern style. * git am --rebasing codepath was taught to grab authorship, log message and the patch text directly out of existing commits. This will help rebasing commits that have confusing diff output in their log messages. * git index-pack and git pack-objects use streaming API to read from the object store to avoid having to
Re: [PATCH/RFC v2 10/16] Read resolve-undo data
On 08/05, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same time, and the resolve-undo
data is then converted to the in-memory format.
Helped-by: Thomas Rast tr...@student.ethz.ch
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
read-cache.c |1 +
resolve-undo.c | 36
resolve-undo.h |2 ++
3 files changed, 39 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index 70334f9..03370f9 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1942,6 +1942,7 @@ static struct directory_entry *read_entries_v5(struct
index_state *istate,
int i;
conflict_queue = read_conflicts_v5(de, mmap, mmap_size, fd);
+ resolve_undo_convert_v5(istate, conflict_queue);
for (i = 0; i de-de_nfiles; i++) {
ce = read_entry_v5(de,
entry_offset,
diff --git a/resolve-undo.c b/resolve-undo.c
index 72b4612..f96c6ba 100644
--- a/resolve-undo.c
+++ b/resolve-undo.c
@@ -170,3 +170,39 @@ void unmerge_index(struct index_state *istate, const
char **pathspec)
i = unmerge_index_entry_at(istate, i);
}
}
+
+void resolve_undo_convert_v5(struct index_state *istate,
+ struct conflict_entry *ce)
+{
It is unclear why this needs to be part of resolve-undo.c and
exported from it. Shouldn't it (and bulk of the previous few
patches) be part of a read-cache-v5.c file (with v2/3/4 specific
part separated out from read-cache.c to form read-cache-v2.c)?
I thought this should be part of resolve-undo.c, to keep everything
that has to do with resolve-undo in the same file, taking model
from resolve_undo_read and resolve_undo_write. But I don't care
to deeply about it, it can easily be moved to read-cache-v5.c.
+ int i;
+
+ while (ce) {
+ struct string_list_item *lost;
+ struct resolve_undo_info *ui;
+ struct conflict_part *cp;
+
+ if (ce-entries (ce-entries-flags CONFLICT_CONFLICTED)
!= 0) {
+ ce = ce-next;
+ continue;
+ }
+ if (!istate-resolve_undo) {
+ istate-resolve_undo = xcalloc(1, sizeof(struct
string_list));
+ istate-resolve_undo-strdup_strings = 1;
+ }
+
+ lost = string_list_insert(istate-resolve_undo, ce-name);
+ if (!lost-util)
+ lost-util = xcalloc(1, sizeof(*ui));
+ ui = lost-util;
+
+ cp = ce-entries;
+ for (i = 0; i 3; i++)
+ ui-mode[i] = 0;
+ while (cp) {
+ ui-mode[conflict_stage(cp) - 1] = cp-entry_mode;
+ hashcpy(ui-sha1[conflict_stage(cp) - 1], cp-sha1);
+ cp = cp-next;
+ }
+ ce = ce-next;
+ }
+}
diff --git a/resolve-undo.h b/resolve-undo.h
index 8458769..ab660a6 100644
--- a/resolve-undo.h
+++ b/resolve-undo.h
@@ -13,4 +13,6 @@ extern void resolve_undo_clear_index(struct index_state
*);
extern int unmerge_index_entry_at(struct index_state *, int);
extern void unmerge_index(struct index_state *, const char **);
+extern void resolve_undo_convert_v5(struct index_state *, struct
conflict_entry *);
+
#endif
--
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
Android Replies to Git List getting rejected
I am not 100% sure of the root cause of this, but I have gotten the following error message back from vger via GMail at least twice now: Delivery to the following recipient failed permanently: git@vger.kernel.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! BF:H 0.0255687; S1755748Ab2HGTHS (state 17). I was replying to 20120806223113.ga16...@sigill.intra.peff.net (Subject: Re: [PATCH] Avoid crippled getpass function on Solaris). Hopefully all of the direct replies went through, but the list denied it. Some other replies have worked just fine. Before the usual raft of you configured your mail client incorrectly I would like to note that such things are not configurable in the Android GMail App. If this is an app issue I'll (attempt to) take it up with them (and expect zero results). (I am writing this from the webmail interface in the hopes that it goes through.) Am I the ONLY ONE seeing this? -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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] docs: monospace listings in docbook output
When asciidoc converts a listing block like:
--
$ git log --merge
--
it marks it to be displayed in a monospace font. This works
fine when generating HTML output. However, when generating
docbook output, we override the expansion of a listingblock
to work around bugs in some versions of the docbook
toolchain. Our override did not mark the listingblock with
the monospaced class.
The main output that uses docbook as an intermediate format
is the manpages. We didn't notice any issue there because
the monospaced class seems to be ignored when generating
roff from the docbook manpages.
However, when generating texinfo to make info pages, docbook
does respect this class. The resulting texinfo output
properly uses @example blocks to display the listing in
this case. Besides possibly looking prettier in some texinfo
backends, one important effect is that the monospace font
suppresses texinfo's expansion of -- and --- into
en-dashes and em-dashes. With the current code, the example
above ends up looking like git log -merge, which is
confusing and wrong.
Signed-off-by: Jeff King p...@peff.net
---
I wonder if we can maybe just rip out our custom overrides entirely.
They date back to versions of docbook from 2006. I'm not sure I entirely
understand their purpose, though (they seem to also be about inserting
extra line breaks, and handling manual additions of roff).
This cleans up many of the problems with the info result. However, there
are still lots of places that use -- outside of a listing block or a
backtick literal. Those still look bad in the generated info page.
Documentation/asciidoc.conf| 4 ++--
Documentation/user-manual.conf | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index a26d245..1273a85 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -36,7 +36,7 @@ ifndef::git-asciidoc-no-roff[]
# v1.72 breaks with this because it replaces dots not in roff requests.
[listingblock]
exampletitle{title}/title
-literallayout
+literallayout class=monospaced
ifdef::doctype-manpage[]
#10;.ft C#10;
endif::doctype-manpage[]
@@ -53,7 +53,7 @@ ifdef::doctype-manpage[]
# The following two small workarounds insert a simple paragraph after screen
[listingblock]
exampletitle{title}/title
-literallayout
+literallayout class=monospaced
|
/literallayoutsimpara/simpara
{title#}/example
diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf
index 339b309..d87294d 100644
--- a/Documentation/user-manual.conf
+++ b/Documentation/user-manual.conf
@@ -14,7 +14,7 @@ ifdef::backend-docbook[]
# unbreak docbook-xsl v1.68 for manpages. v1.69 works with or without this.
[listingblock]
exampletitle{title}/title
-literallayout
+literallayout class=monospaced
|
/literallayout
{title#}/example
--
1.7.12.rc1.12.g5eaae48
--
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
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: [PATCH] git svn: reset invalidates the memoized mergeinfo caches
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).
@@ -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.
+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.
+ 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
Re: Android Replies to Git List getting rejected
On Tue, Aug 07, 2012 at 01:33:23PM -0600, John 'Warthog9' Hawley wrote: It's pretty simple: you sent HTML mail to vger.kernel.org, and it explicitly rejects all HTML e-mail. GMail, particularly from Android, apparently doesn't have a way to bypass sending HTML mail (it's been a much maligned bug). Yeah, sigh. Drew, I suggest that you star the following bug: http://code.google.com/p/android/issues/detail?id=8712 ... and perhaps leave a comment in the bug report that you can't interact with the git mailing list because of this limitation. I'm sure you know (since you indicated that you sent your e-mail via the web interface of Gmail), that this is at least something you can control in the desktop/web version of Gmail (just enable Plain text mode) --- but it would certainly be nice if users had the choice of whether they wanted to participate on vger mailing lists using the Android application, versus the Web interface, or using Mutt or Pine on a Linux box. Regards, - Ted -- 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: Android Replies to Git List getting rejected
On Tue, Aug 7, 2012 at 4:55 PM, Theodore Ts'o ty...@mit.edu wrote: On Tue, Aug 07, 2012 at 01:33:23PM -0600, John 'Warthog9' Hawley wrote: It's pretty simple: you sent HTML mail to vger.kernel.org, and it explicitly rejects all HTML e-mail. GMail, particularly from Android, apparently doesn't have a way to bypass sending HTML mail (it's been a much maligned bug). Yeah, sigh. Drew, I suggest that you star the following bug: http://code.google.com/p/android/issues/detail?id=8712 ... and perhaps leave a comment in the bug report that you can't interact with the git mailing list because of this limitation. I'm sure you know (since you indicated that you sent your e-mail via the web interface of Gmail), that this is at least something you can control in the desktop/web version of Gmail (just enable Plain text mode) --- but it would certainly be nice if users had the choice of whether they wanted to participate on vger mailing lists using the Android application, versus the Web interface, or using Mutt or Pine on a Linux box. Regards, - Ted -- 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 There were several discussions about that on the list and unfortunately list moderators didn't pay enough attention to it. Android Gmail sends totally valid multipart message that has HTML and plain-text part. List being unable to process those correctly and cut off HTML part is a limitation. I personally feel that i could and would be more active on the list if not for this limitation. rant Don't want to accept HTML messages - fine. But don't tell me which program to use for my email, especially when I'm sending totally valid message, so take my plain text message part and use it. /rant Thanks, Eugene -- 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: GSOC remote-svn: branch detection
On Saturday 04 August 2012 23:53:58 Ramkumar Ramachandra wrote: Hi, Florian Achleitner wrote: 1. Import linearly and split later: I think this approach will be a lot less messy if you can cleanly separate the fetching component from the mapper. Currently, svndump re-creates the layout of the SVN repository. And the series you posted last week contains a patch that attaches a note with SVN metadata to each commit. Do you have thoughts on how the mapping will take place? The mapping itself is currently a black box for me, it's internals could be rather complex. It could get a function like is_branch_start, that is called with a node ctx and tells if this is likely to be the start of branch. The detected branches are stored and upcoming changes in the associated directories are mapped to a commit on a branch. The detection of branch starts and the list of existing branches can be taken from whatever logic we want. So that's approx. the idea. Currently I'm working on more basic preparations. I want to split the creation of commits and the creation of blobs in svndump.c. This is necessary because fast import requires a branch name as an argument to the 'commit' command, and currently a 'commit' command is started when a new revision is encountered in the svndump. But to decide on which branch the commit should go, or even if it will be more than one commit, it is necessary to read all the nodes first. To prevent buffering the node content, I want to replace the inline data format (currently used) by 'blob' commands. While parsing the dump, every node change creates a blob command to feed the data immediately into fast-import while the node metadata (struct node_ctx) is stored at least until the revision ends. Then the blobs can be put on a linear master tree and other branch trees. The node metadata could also be read from notes, if remapping branches. That's not so easy to do, because the current implementation mixes tree- operations and blob-operations heavily, and relies on only one global node_ctx. Ram Flo -- 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/2] prune.c: only print informational message in show_only or verbose mode
Jeff King p...@peff.net writes: I still think your 2/2 is worth doing independently, though. It is silly that git-prune will not mention pruned objects without -v, but will mention temporary files. They should be in the same category. Ok, so I'll queue it as a separate topic with a different justification. -- 8 -- From: Brandon Casey draf...@gmail.com Date: Mon, 6 Aug 2012 22:01:49 -0700 Subject: [PATCH] prune.c: only print informational message in show_only or verbose mode git prune reports removal of loose object files that are no longer necessary only under the -v option, but unconditionally reports removal of temporary files that are no longer needed. The original thinking was that presence of a leftover temporary file should be an unusual occurrence that may indicate an earlier failure of some sort, and the user may want to be reminded of it. Removing an unnecessary loose object file, on the other hand, is just part of the normal operation. That is why the former is always printed out and the latter only when -v is used. But neither report is particularly useful. Hide both of these behind the -v option for consistency. Signed-off-by: Brandon Casey draf...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/prune.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/prune.c b/builtin/prune.c index b99b635..6cb9944 100644 --- a/builtin/prune.c +++ b/builtin/prune.c @@ -25,7 +25,8 @@ static int prune_tmp_object(const char *path, const char *filename) return error(Could not stat '%s', fullpath); if (st.st_mtime expire) return 0; - printf(Removing stale temporary file %s\n, fullpath); + if (show_only || verbose) + printf(Removing stale temporary file %s\n, fullpath); if (!show_only) unlink_or_warn(fullpath); return 0; -- 1.7.12.rc2.53.g9ec2ef6 -- 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/2] Add index-v5
Nguyễn Thái Ngọc Duy skrev 2012-08-06 16.36:
+++ b/read-cache-v5.c
@@ -0,0 +1,1170 @@
+#include cache.h
+#include read-cache.h
+#include resolve-undo.h
+#include cache-tree.h
+
+struct cache_header_v5 {
+ unsigned int hdr_ndir;
+ unsigned int hdr_nfile;
+ unsigned int hdr_fblockoffset;
+ unsigned int hdr_nextension;
+};
+
+struct ondisk_cache_entry_v5 {
+ unsigned short flags;
+ unsigned short mode;
+ struct cache_time mtime;
+ int stat_crc;
+ unsigned char sha1[20];
+};
I mentioned this before in another thread, but for JGit I'd like
to see size as a separate attribute. The rest of stat_crc is not
available to Java so when this index gets its way into JGit,
stat_crc will be zero and will never be checked.
-- robin
--
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/2] prune.c: only print informational message in show_only or verbose mode
On Tue, Aug 07, 2012 at 02:44:51PM -0700, Junio C Hamano wrote: Ok, so I'll queue it as a separate topic with a different justification. -- 8 -- From: Brandon Casey draf...@gmail.com Date: Mon, 6 Aug 2012 22:01:49 -0700 Subject: [PATCH] prune.c: only print informational message in show_only or verbose mode git prune reports removal of loose object files that are no longer necessary only under the -v option, but unconditionally reports removal of temporary files that are no longer needed. The original thinking was that presence of a leftover temporary file s/presence/the / should be an unusual occurrence that may indicate an earlier failure of some sort, and the user may want to be reminded of it. Removing an unnecessary loose object file, on the other hand, is just part of the normal operation. That is why the former is always printed out and the latter only when -v is used. But neither report is particularly useful. Hide both of these behind the -v option for consistency. Signed-off-by: Brandon Casey draf...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Looks fine to me. I think tmpfile removal is also not that interesting in general. A stale file can happen any time the user aborts an operation via ^C. But I think your justification is sufficient as-is (and this topic is not worth spending too much more time on). -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: Android Replies to Git List getting rejected
On 7 August 2012 17:39, Theodore Ts'o ty...@mit.edu wrote: On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote: rant Don't want to accept HTML messages - fine. But don't tell me which program to use for my email, especially when I'm sending totally valid Perhaps this one: https://code.google.com/p/k9mail/ which can send messages with a mere User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit You'll need to turn on imap access in your gmail account. Cheers! -p orpen (Yes, I know, I didn't send this from my android gadget.) -- 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/2] prune.c: only print informational message in show_only or verbose mode
On Tue, Aug 7, 2012 at 2:44 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: I still think your 2/2 is worth doing independently, though. It is silly that git-prune will not mention pruned objects without -v, but will mention temporary files. They should be in the same category. Ok, so I'll queue it as a separate topic with a different justification. Looks fine to me. Thanks. -Brandon -- 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
Issuing cat-blob or ls to fast-import from a remote helper
I've been toying with a git-remote-svn which uses fast-import (by advertising the 'import' capability) to get data into Git. Unfortunately, I can't get the result of any commands issued to fast-import, as its stdout is not redirected, and the remote helper API offers no alternative. I tried modifiying transport-helper.c to force redirection (fast-import's stdout - remote helper's stdin), but that breaks test t5800 (and possibly others). Is this a bug, or intended behaviour? Am I missing something? -- 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
