Re: [PATCH] git svn: reset invalidates the memoized mergeinfo caches
On Tue, Aug 07, 2012 at 08:45:10PM +, Eric Wong wrote:
> Peter Baumann 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/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",
-
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
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: merging confusion and question
Rich Pixley 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 ' 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: [PATCH/RFC v2 0/16] Introduce index file format version 5
Nguyen Thai Ngoc Duy 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
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 ' 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
Junio C Hamano 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
Re: [PATCH/RFC v2 0/16] Introduce index file format version 5
Thomas Rast 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
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
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 wrote: > Jeff King 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
Re: Android Replies to Git List getting rejected
On 7 August 2012 17:39, Theodore Ts'o wrote: > On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote: >> >> 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 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 > 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 > Signed-off-by: Junio C Hamano > --- 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: [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
Jeff King 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
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
Signed-off-by: Junio C Hamano
---
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: Android Replies to Git List getting rejected
On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote: > > 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. > The problem is that HTML messages is a really good signal for SPAM and exploits sent by spambots trying to break into Windows machines. So from the perspective of keeping the vger lists spam-free, it works very well. Also, from a practical point of view, most of the mailers which send HTML also tend to mangle patches, and since most of the vger lists are very developer centric, having users use MUA's that mangle patches is highly unfortunate. So having a hard requirement has been often useful for developers who, say, are unfortunate enough to work at a company that mandates the use of Lotus Notes, since it's a nice way to force the company to set up an alternate IMAP/SMTP infrastructure for developers who need to interact with the Linux Kernel community. Speaking as someone who used to work at IBM's Linux Technology Center, let me assure you there are some unappreciated, but still very valid, side effects of the current policies in force on vger. There are other solutions to the spam problem, of course --- such as diverting all of vger's mail through Postini, which is uses the same anti-spam technology that GMail uses, and which is pretty good. (Far better than Symantec's anti-virus filtering service, which is what mit.edu uses, so I've had experience with both.) But the tin foil hat community would probably be all suspicious about routing all of vger through Google's servers, even though pretty much all of the vger mailing lists are archived on web sites such as Gmane and truth to tell, the current solution which VGER has for filtering spam works pretty well, all things considered. It's rather unfortunate that Android-only GMail users are an unintended casualty. - 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: 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: Android Replies to Git List getting rejected
On Tue, Aug 7, 2012 at 4:55 PM, Theodore Ts'o 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. 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. 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: 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: [PATCH] git svn: reset invalidates the memoized mergeinfo caches
Peter Baumann 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
synchronization with Subversion
Greetings, we maintain a "central/main" git repository which our developers clone from. We want to synchronize this "central" git repository with Subversion. I know this is not the recommended way to do this, but this was the choice that was made. The "central" git repository was originally cloned from Subversion as that was our migration path to git. Currently I can't get the synchronization to work again after another sprint. I get the following error message: Unable to determine upstream SVN information from HEAD history. Perhaps the repository is empty. at /usr/libexec/git-core/git-svn line 525. This synchronization has worked a number of times, but now it always fails with the above error. I have read that it's best to have a linear commit history when synchronizing to Subversion, and I've read that "git rebase" is the way to accomplish this. I've attempted this, but I run into two problems trying to do this: 1. Any files/directories which get moved/renamed cause the rebase to stop and I have to tell git to skip the commit, though it appears to me that the move/rename actually worked. I am confused by this behavior, and don't understand why it happens at all. 2. There are a number of conflicts which occur during the rebase. This also confuses me. I think I understand why they happen, but I'm not clear about how to handle them. Our code base goes back many years and contains a huge number of commits (originally in CVS, then migrated to Subversion and Git). It isn't obvious what impact the conflict resolution would have. My suspicion, is that it will breed even more conflicts as the rebase continues from that point. As you might have guessed, Subversion is the corporate mandated repository, which is why we are attempting to maintain the synchronization. We have a "central" git repository as we want to have more control over which changes are accepted. I'm hoping for some suggestions for dealing with this. Any takers? Thnks/Brgds --Tad --- Tad K. Mannes Senior Developer SITA - Societe Internationale de Telecommunications Aeronautiques -- 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
---
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:
[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
---
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]
{title}
-
+
ifdef::doctype-manpage[]
.ft C
endif::doctype-manpage[]
@@ -53,7 +53,7 @@ ifdef::doctype-manpage[]
# The following two small workarounds insert a simple paragraph after screen
[listingblock]
{title}
-
+
|
{title#}
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]
{title}
-
+
|
{title#}
--
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
Re: info: display '--' as '-'
On Tue, Aug 07, 2012 at 09:17:50AM +0200, David Kastrup wrote: > Not really: @display does not change fonts, merely indentation. From > the Texinfo manual: > [...] > But in non-typewriter fonts, -- is a shorthand for an en-dash (see > "conventions" in the Texinfo manual): Thanks, that's the missing piece I didn't have. So it seems like docbook2-texi is at fault. The "--" does not have a special meaning in docbook XML, but is special markup specially in Texinfo source. By passing it through literally, docbook2-texi is changing the meaning of the text. It should be escaped somehow, just as you would escape other markup characters (e.g., "@display" literally in the text would also need to be escaped). I suppose you could argue that the "--" conversion is not markup, but a presentation choice for free-form text. I find that a little dubious when coming from docbook, which could use "&endash;" if it really wanted an en dash. > 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. I think that's a reasonable work-around for this particular incarnation of the bug. I still think it's wrong of the docbook to texinfo conversion process to leave "--" in place in general, but it matters most in fixed-font displays. It looks like some of our asciidoc workarounds were causing listing blocks not to be marked as monospace. I've got a patch to address that, and it fixes this particular class of bug. However, we also use literal "--" in lots of non-monospaced contexts. The whole documentation tree needs to be audited for use of "--" (e.g., every option mentioned in git-log.txt is currently wrong in the gitman.info result). I think the end result will look better, but it is going to be a giant pain. > > 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. I based my assumption on your 4739809 (Add support for an info version of the user manual, 2007-08-06). I don't think any of the regular contributors actually uses info, which is why it has remained largely untouched since then. Anyway, I was right; you were more clueful than I (not that it took much...). Thanks for pointing me in the right direction. -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
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). Before you ask, no I very much doubt vger will change it's policy with regards to HTML mail, and honestly it's a policy I fully support. Your only bet is to use a mail client that won't send HTML, K-9 or Kaiten should work. - John 'Warthog9' Hawley On 08/07/2012 01:24 PM, Drew Northup wrote: > 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:; > 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? > -- 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:; 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
Re: [PATCH/RFC v2 10/16] Read resolve-undo data
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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
> > Signed-off-by: Thomas Gummerer
> > ---
> > 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
Re: git repack vs git gc --aggressive
Jeff King writes: > So the packing parameters are the same these days for either method. > Note that "git gc --aggressive" will also use "-f" to recompute all > deltas. This is more expensive, but gives git more flexibility if the > old deltas were sub-optimal (typically, this is the case if the existing > pack was generated by fast-import, which favors speed of import versus > coming up with an optimal storage pattern). Also your fetch often results in storing the pack received from the other end straight to your local repository (with necessary objects to complete the pack the other end did not send appended at the end). If the server side hasn't been packed with "-f", you will inherit the badness until you repack with "-f". > Of course, every workload is different. One can develop pathological > cases where --depth=500 saves a lot of space. But it's unlikely that it > is the case for a normal repository. You can always try both and see the > result. For a dataset where ridiculously large depth really is a win, these objects would have to be reasonably large and cost of expanding the base and then applying hundreds of delta to recover one object may not be negligible. The user should consider if he is willing to pay the price every time he does a local Git operation. > In fact, I'd also test how just "git gc" behaves versus "git gc > --aggressive" for your repo. The former is much less expensive to run. > You really shouldn't need to be running "--aggressive" all the time, so > if you are looking at doing a nightly repack or similar, just "git gc" > is probably fine. As I am coming from "large depth is harmful" school, I would recommend - "git repack -a -d -f" with large "--window" with reasonably short "--depth" once, and mark the result with .keep; - "git repack -a -d -f" once every several weeks; and - "git gc" or "git repack" (without any other options) daily. and ignore "--aggressive" entirely. -- 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 08/16] Make in-memory format aware of stat_crc
On 08/05, Junio C Hamano wrote: > Thomas Gummerer writes: > > > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4); > > + stat = htonl(ce->ce_ino); > > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4); > > + stat = htonl(ce->ce_size); > > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4); > > + stat = htonl(ce->ce_dev); > > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4); > > + stat = htonl(ce->ce_uid); > > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4); > > + stat = htonl(ce->ce_gid); > > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4); > > + return stat_crc; > > What are these (Bytef *) casts are about? We do not use it in any > of our existing calls to crc32(). >From a quick look over the existing calls, their argument is always either a void* or a char* pointer. Using pointers other than those two or Bytef* gives compiler warnings. I can cast to either void* or char* if that's preferred. -- 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 repack vs git gc --aggressive
On Tue, Aug 07, 2012 at 08:22:21PM +0200, Felix Natter wrote:
> 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.
Note how old that post is. In fact, on the very same day it was posted,
the discussion on the mailing list resulted in this commit:
commit 1c192f3442414a6ce83f9a524806fc26a0861d2d
Author: Johannes Schindelin
Date: Thu Dec 6 12:03:38 2007 +
gc --aggressive: make it really aggressive
The default was not to change the window or depth at all. As suggested
by Jon Smirl, Linus Torvalds and others, default to
--window=250 --depth=250
So the packing parameters are the same these days for either method.
Note that "git gc --aggressive" will also use "-f" to recompute all
deltas. This is more expensive, but gives git more flexibility if the
old deltas were sub-optimal (typically, this is the case if the existing
pack was generated by fast-import, which favors speed of import versus
coming up with an optimal storage pattern).
> 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?
Yes, it's safe. Changing the depth parameter can never lose data.
However, it's probably not a good idea for two reasons:
1. It probably does nothing. You're not likely to hit a 500-depth
delta chain (the point of the "250" in --aggressive is that it is
already ridiculously high).
2. Even if you did come up with a 500-depth delta chain, it may not be
a good tradeoff. You might save a little bit of space, but keep in
mind that to generate the object data, it means that git will have
to follow a chain of 500 deltas to regenerate the object.
Of course, every workload is different. One can develop pathological
cases where --depth=500 saves a lot of space. But it's unlikely that it
is the case for a normal repository. You can always try both and see the
result.
In fact, I'd also test how just "git gc" behaves versus "git gc
--aggressive" for your repo. The former is much less expensive to run.
You really shouldn't need to be running "--aggressive" all the time, so
if you are looking at doing a nightly repack or similar, just "git gc"
is probably fine.
-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
[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 " to insert "exec " 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 AP
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
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 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/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
Re: [PATCH/RFC v2 01/16] Modify cache_header to prepare for other index formats
Thomas Gummerer 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 2/2] prune.c: only print informational message in show_only or verbose mode
Brandon Casey writes: > On Mon, Aug 6, 2012 at 11:03 PM, Jeff King 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] 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 Acked-by: Ben Walton 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/RFC v2 04/16] Modify write functions to prepare for other index formats
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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/RFC v2 01/16] Modify cache_header to prepare for other index formats
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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 0/16] Introduce index file format version 5
On Tue, Aug 7, 2012 at 12:46 AM, Junio C Hamano 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() 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: info: display '--' as '-'
Jeff King writes: > The data looks OK in user-manual.texi, 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. The texinfo manual says that @display does not change the font (unlike @example), so the body will be rendered like normal text apart from the extra indentation and preserved line breaks. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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: Re: [msysGit] Re: Re: File path not escaped in warning message
Hi Karsten, Thanks, you helped me a lot. I see now, that logoutputencoding is for commit header data, not for whole log output. The name is little missleading, so do description: i18n.logOutputEncoding Encoding to use when displaying logs. Regarding git-log / git-diff output, there are basically three different character set encodings involved: 1. commit log messages: re-coded to i18n.logoutputencoding (usually UTF-8) also commiter and author fields. 2. file content: printed verbatim (no re-coding); gui tools such as gitk may decode this based on gui.encoding or .gitattributes settings 3. everything else (file names, diff headers, error / warning messages): always UTF-8 (at least in Git for Windows) It is more like git encoding than UTF-8. Gui tools such as gitk decode this output line by line using the appropriate encoding. It would be easier to do it if output was displayed in consistent way. I see no reason why one part of output is quoted and other is not. Another example: $ git status warning: LF will be replaced by CRLF in 1ą.txt. The file will have its original line endings in your working directory. # On branch master # Your branch and 'origin/master' have diverged, # and have 2 and 2 different commit(s) each, respectively. # # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: "1\261.txt" # Git doesn't recode commit header when --pretty is set to format, but recodes when --pretty is set to full, raw, etc. Do you know if it is done by mistake or by design? Thanks again, Janusz Białobrzewski. -- 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 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 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
