All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Apr 2011, #04; Tue, 12)
@ 2011-04-12 22:43 Junio C Hamano
  2011-04-14 13:38 ` Piotr Krukowiecki
  2011-04-14 18:46 ` Jakub Narebski
  0 siblings, 2 replies; 8+ messages in thread
From: Junio C Hamano @ 2011-04-12 22:43 UTC (permalink / raw)
  To: git

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.

As we are already in pre-release feature freeze, some of the trivially
correct features and fixes to non-regression bugs are only queued to
'next' but not in 'master'.  They are marked as post 1.7.5 candidates in
this list.

--------------------------------------------------
[New Topics]

* ef/maint-strbuf-init (2011-04-10) 2 commits
  (merged to 'next' on 2011-04-11 at 1dd34d9)
 + config: support values longer than 1023 bytes
 + strbuf: make sure buffer is zero-terminated

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
release.

* jh/dirstat (2011-04-12) 4 commits
  (merged to 'next' on 2011-04-12 at dd2c308)
 + --dirstat: In case of renames, use target filename instead of source filename
  (merged to 'next' on 2011-04-11 at 33d0417)
 + Teach --dirstat not to completely ignore rearranged lines within a file
 + --dirstat-by-file: Make it faster and more correct
 + --dirstat: Describe non-obvious differences relative to --stat or regular diff

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
releases.

* jm/mergetool-submodules (2011-04-08) 1 commit
 - mergetool: Teach about submodules

Looked sane if inefficient when both branches have the submodule but was
dubious in delete/modify conflict case. Awaiting response and possibly a
reroll.

* rj/sparse (2011-04-07) 7 commits
 - sparse: Fix some "symbol not declared" warnings
 - sparse: Fix errors due to missing target-specific variables
 - sparse: Fix an "symbol 'merge_file' not decared" warning
 - sparse: Fix an "symbol 'format_subject' not declared" warning
 - sparse: Fix some "Using plain integer as NULL pointer" warnings
 - sparse: Fix an "symbol 'cmd_index_pack' not declared" warning
 - Makefile: Use cgcc rather than sparse in the check target

* ab/i18n-fixup (2011-04-12) 8 commits
  (merged to 'next' on 2011-04-12 at a94aa85)
 + i18n: do not overuse C_LOCALE_OUTPUT
 + i18n: mark init-db messages for translation
 + i18n: mark checkout plural warning for translation
 + i18n: mark checkout --detach messages for translation
 + i18n: mark clone nonexistent repository message for translation
 + i18n: mark merge CHERRY_PICK_HEAD messages for translation
 + i18n: mark merge "upstream" messages for translation
 + i18n: mark merge "Could not read from" message for translation

It would be nice to have this before 1.7.5 final; even if we didn't, we
would have to force people to build on top of this, not on 1.7.5, which
would essentially mean that we would commit to this series anyway.

* cn/format-patch-quiet (2011-04-12) 2 commits
  (merged to 'next' on 2011-04-12 at 915a915)
 + format-patch: document --quiet option
 + format-patch: don't pass on the --quiet flag

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
release.

--------------------------------------------------
[Stalled]

* jc/maint-add-p-overlapping-hunks (2011-04-06) 2 commits
 - "add -p": work-around an old laziness that does not coalesce hunks
 - add--interactive.perl: factor out repeated --recount option

This came from http://thread.gmane.org/gmane.comp.version-control.git/170685/focus=171000;
we may want to add tests before moving it forward.

* jh/gitweb-localtime (2011-03-23) 1 commit
 - gitweb: javascript ability to adjust time based on timezone

Re-roll posted on the list, but I haven't picked it up.

* mg/show-without-prune (2011-04-01) 1 commit
 - builtin/show: do not prune by pathspec
 (this branch uses mg/reflog-with-options.)

I wanted to like this, but it still feels like too much magic.

* gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit
 - Look for password in both CVS and CVSNT password files.

It seems that we need separate parsers for these two formats in order not
to regress the users of the original cvs.

* jc/index-pack (2011-02-25) 5 commits
 - index-pack --verify: read anomalous offsets from v2 idx file
 - write_idx_file: need_large_offset() helper function
 - index-pack: --verify
 - write_idx_file: introduce a struct to hold idx customization options
 - index-pack: group the delta-base array entries also by type

Still a WIP, and will not be ready for 1.7.5. Need to put histogram output
into index-pack --verify to really kill verify-pack.

* jk/tag-contains (2010-07-05) 4 commits
 - Why is "git tag --contains" so slow?
 - default core.clockskew variable to one day
 - limit "contains" traversals based on commit timestamp
 - tag: speed up --contains calculation

The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.

--------------------------------------------------
[Cooking]

* dm/stash-k-i-p (2011-04-07) 2 commits
  (merged to 'next' on 2011-04-11 at 8349531)
 + stash: ensure --no-keep-index and --patch can be used in any order
 + stash: add two more tests for --no-keep-index

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
releases.

* jc/magic-pathspec (2011-04-06) 3 commits
  (merged to 'next' on 2011-04-08 at c5247ce)
 + magic pathspec: add ":(icase)path" to match case insensitively
 + magic pathspec: futureproof shorthand form
 + magic pathspec: add tentative ":/path/from/top/level" pathspec support
 (this branch is tangled with jc/add-u-migration-2.)

Thanks to Peff, Duy, and Michael for helping to whip the syntax and
the basic semantics into a not-so-horrible shape.  Will not merge until
the 1.7.5 ships, though.

* jc/merge-dash-previous (2011-04-07) 1 commit
  (merged to 'next' on 2011-04-11 at 06480d1)
 + merge: allow "-" as a short-hand for "previous branch"

Should graduate soon after 1.7.5 ships.

* rr/doc-content-type (2011-04-07) 4 commits
  (merged to 'next' on 2011-04-11 at dca8914)
 + Documentation: Allow custom diff tools to be specified in 'diff.tool'
 + Documentation: Add diff.<driver>.* to config
 + Documentation: Move diff.<driver>.* from config.txt to diff-config.txt
 + Documentation: Add filter.<driver>.* to config

Is everybody happy with the new wording?

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
releases.

* dm/http-cleanup (2011-03-30) 2 commits
 - http-push: refactor curl_easy_setup madness
 - http: make curl callbacks match contracts from curl header

I didn't see anything glaringly wrong with this, but I would appreciate
extra sets of eyeballs from people who have worked on HTTP transports to
double check.

* jc/pack-objects-bigfile (2011-04-05) 1 commit
  (merged to 'next' on 2011-04-11 at 86c52b1)
 + Teach core.bigfilethreashold to pack-objects

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
releases.

* jk/maint-stash-oob (2011-04-06) 2 commits
  (merged to 'next' on 2011-04-11 at d882935)
 + stash: fix false positive in the invalid ref test.
 + stash: fix accidental apply of non-existent stashes

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
releases.

* nk/blame-abbrev (2011-04-06) 1 commit
  (merged to 'next' on 2011-04-11 at 19e8676)
 + blame: add --abbrev command line option and make it honor core.abbrev

Should graduate soon after 1.7.5 ships.

* nm/submodule-update-force (2011-04-01) 1 commit
  (merged to 'next' on 2011-04-11 at d94f6f3)
 + submodule: Add --force option for git submodule update

Are submodule users happy with this change?

Should graduate soon after 1.7.5 ships.

* jk/maint-upload-pack-shallow (2011-04-06) 1 commit
  (merged to 'next' on 2011-04-11 at 9104545)
 + upload-pack: start pack-objects before async rev-list

A sensible and low-impact fix.  Should graduate soon after 1.7.5 ships
and merged to 1.7.4.X and 1.7.5.1 releases.

* jk/stash-loosen-safety (2011-04-05) 1 commit
  (merged to 'next' on 2011-04-11 at b59c533)
 + stash: drop dirty worktree check on apply

Should graduate soon after 1.7.5 ships.

* dm/color-palette (2011-04-05) 1 commit
  (merged to 'next' on 2011-04-04 at 0244ef9)
 + Share color list between graph and show-branch

Should graduate soon after 1.7.5 ships.

* mg/sha1-path-advise (2011-03-31) 2 commits
  (merged to 'next' on 2011-04-04 at e429e0c)
 + sha1_name: Suggest commit:./file for path in subdir
 + t1506: factor out test for "Did you mean..."

Should graduate soon after 1.7.5 ships and merged to 1.7.5.1 release.

* ar/clean-rmdir-empty (2011-04-01) 1 commit
  (merged to 'next' on 2011-04-03 at c63fac8)
 + clean: unreadable directory may still be rmdir-able if it is empty

Should graduate soon after 1.7.5 ships and merged to 1.7.4.X and 1.7.5.1
releases.

* jk/maint-push-async-hang (2011-03-31) 4 commits
 - send-pack: abort sideband demuxer on pack-objects error
 - run-command: allow aborting async code prematurely
 - finish_async: be quiet when waiting for async process
 - teach wait_or_whine a "quiet" mode
 (this branch is used by jk/maint-push-async-hang-threads.)

* jk/maint-push-async-hang-threads (2011-03-31) 2 commits
 - run-command: implement abort_async for pthreads
 - Merge branch 'jk/maint-push-async-hang' into jk/maint-push-async-hang-threads
 (this branch uses jk/maint-push-async-hang.)

These two series aim for a good goal, but needs reroll after 1.7.5 with
sign-offs.

* mg/reflog-with-options (2011-04-01) 3 commits
  (merged to 'next' on 2011-04-03 at e69a95c)
 + reflog: fix overriding of command line options
 + t/t1411: test reflog with formats
 + builtin/log.c: separate default and setup of cmd_log_init()
 (this branch is used by mg/show-without-prune.)

Should graduate soon after 1.7.5 ships and merged to 1.7.5.1 release.

* mh/git-svn-automkdirs (2011-04-01) 1 commit
  (merged to 'next' on 2011-04-03 at 7fa4978)
 + git-svn: add an option to skip the creation of empty directories

Should be safe, but I'd like an Ack from git-svn folks.

* jc/diff-irreversible-delete (2011-02-28) 1 commit
  (merged to 'next' on 2011-04-03 at 5a23b23)
 + git diff -D: omit the preimage of deletes

Should graduate soon after 1.7.5 ships.

* jh/notes-add-ui (2011-03-30) 1 commit
  (merged to 'next' on 2011-04-11 at 72e7c39)
 + Make "git notes add" more user-friendly when there are existing notes

Should graduate soon after 1.7.5 ships and merged to 1.7.5.1 release.

* jk/notes-ui-updates (2011-03-30) 7 commits
  (merged to 'next' on 2011-04-11 at 313d6c4)
 + log/pretty-options: Document --[no-]notes and deprecate old notes options
 + revision.c: make --no-notes reset --notes list
 + revision.c: support --notes command-line option
 + notes: refactor display notes default handling
 + notes: refactor display notes extra refs field
 + revision.c: refactor notes ref expansion
 + notes: make expand_notes_ref globally accessible

Should graduate soon after 1.7.5 ships.

* nd/maint-setup (2011-03-26) 2 commits
  (merged to 'next' on 2011-03-31 at 2c36f6a)
 + Kill off get_relative_cwd()
 + setup: return correct prefix if worktree is '/'

This benefits only the minority who use /.git at the root level of the
filesystem, but the changed code is used from many codepaths.

Should graduate soon after 1.7.5 ships and merged to 1.7.5.1 release.

* mz/rebase (2011-02-28) 34 commits
  (merged to 'next' on 2011-03-31 at 3b1343c)
 + rebase: define options in OPTIONS_SPEC
  (merged to 'next' on 2011-02-25 at 52caa7a)
 + Makefile: do not install sourced rebase scripts
  (merged to 'next' on 2011-02-22 at 3219155)
 + rebase: use @{upstream} if no upstream specified
 + rebase -i: remove unnecessary state rebase-root
 + rebase -i: don't read unused variable preserve_merges
 + git-rebase--am: remove unnecessary --3way option
 + rebase -m: don't print exit code 2 when merge fails
 + rebase -m: remember allow_rerere_autoupdate option
 + rebase: remember strategy and strategy options
 + rebase: remember verbose option
 + rebase: extract code for writing basic state
 + rebase: factor out sub command handling
 + rebase: make -v a tiny bit more verbose
 + rebase -i: align variable names
 + rebase: show consistent conflict resolution hint
 + rebase: extract am code to new source file
 + rebase: extract merge code to new source file
 + rebase: remove $branch as synonym for $orig_head
 + rebase -i: support --stat
 + rebase: factor out call to pre-rebase hook
 + rebase: factor out clean work tree check
 + rebase: factor out reference parsing
 + rebase: reorder validation steps
 + rebase -i: remove now unnecessary directory checks
 + rebase: factor out command line option processing
 + rebase: align variable content
 + rebase: align variable names
 + rebase: stricter check of standalone sub command
 + rebase: act on command line outside parsing loop
 + rebase: improve detection of rebase in progress
 + rebase: remove unused rebase state 'prev_head'
 + rebase: read state outside loop
 + rebase: refactor reading of state
 + rebase: clearer names for directory variables

I wanted to wait for an independent Ack or two for the tip one, which was
a response to regression concerns raised by J6t, but ended up merging it
to 'next' after giving another look.  Will not merge before 1.7.5, as
there is no user visible improvements up to this point.

* jk/maint-merge-rename-create (2011-03-25) 3 commits
  (merged to 'next' on 2011-03-31 at b9bc9f1)
 + merge: turn on rewrite detection
 + merge: handle renames with replacement content
 + t3030: fix accidental success in symlink rename

Peff wanted to reroll this.

* mz/maint-rename-unmerged (2011-03-23) 1 commit
  (merged to 'next' on 2011-03-31 at c7b3d9a)
 + diffcore-rename: don't consider unmerged path as source

Will cook until 1.7.5 final.

* nd/struct-pathspec (2011-04-05) 5 commits
  (merged to 'next' on 2011-04-11 at ee794a5)
 + pathspec: rename per-item field has_wildcard to use_wildcard
  (merged to 'next' on 2011-03-31 at 66cbb7d)
 + Improve tree_entry_interesting() handling code
 + Convert read_tree{,_recursive} to support struct pathspec
 + Reimplement read_tree_recursive() using tree_entry_interesting()
 + Merge branch 'en/object-list-with-pathspec' into 'nd/struct-pathspec'

Will cook until 1.7.5 final.

* jc/rename-degrade-cc-to-c (2011-01-06) 4 commits
  (merged to 'next' on 2011-03-31 at 8d685d7)
 + diffcore-rename: fall back to -C when -C -C busts the rename limit
 + diffcore-rename: record filepair for rename src
 + diffcore-rename: refactor "too many candidates" logic
 + builtin/diff.c: remove duplicated call to diff_result_code()

Should graduate soon after 1.7.5 ships.

* cn/system-path-tweak (2011-03-17) 1 commit
 - system_path: use a static buffer

Don't see much point in this itself. Probably will drop.

* en/merge-recursive (2011-03-17) 4 commits
  (merged to 'next' on 2011-03-18 at a32016b)
 + merge-recursive: tweak magic band-aid
  (merged to 'next' on 2011-03-09 at 3762932)
 + merge-recursive: When we detect we can skip an update, actually skip it
 + t6022: New test checking for unnecessary updates of files in D/F conflicts
 + t6022: New test checking for unnecessary updates of renamed+modified files

I am not happy with these magic band aids.  Will hold.

--------------------------------------------------
[Discarded]

* jc/add-u-migration (2011-03-22) 3 commits
 . add: make "add -u/-A" update full tree without pathspec (step 3)
 . add: make "add -u/-A" update full tree without pathspec (step 2)
  (merged to 'next' on 2011-03-31 at 962e058)
 + add: make "add -u/-A" update full tree without pathspec
 (this branch is tangled with jc/add-u-migration-2.)

* jc/add-u-migration-2 (2011-04-08) 5 commits
  (merged to 'next' on 2011-04-08 at 524e365)
 + Revert "add -u" default change plans
  (merged to 'next' on 2011-04-06 at 4a6bb82)
 + add -u: get rid of "treewideupdate" configuration
 + Merge branch 'jc/magic-pathspec' into early parts of jc/add-u-migration
 + magic pathspec: add tentative ":/path/from/top/level" pathspec support
  (merged to 'next' on 2011-03-31 at 962e058)
 + add: make "add -u/-A" update full tree without pathspec
 (this branch is tangled with jc/add-u-migration and jc/magic-pathspec.)

These attempt "add -u" migration plans (two versions), but then revert
both of them at the end where they are merged to 'next'.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-12 22:43 What's cooking in git.git (Apr 2011, #04; Tue, 12) Junio C Hamano
@ 2011-04-14 13:38 ` Piotr Krukowiecki
  2011-04-14 13:50   ` Piotr Krukowiecki
  2011-04-14 15:21   ` Michael Haggerty
  2011-04-14 18:46 ` Jakub Narebski
  1 sibling, 2 replies; 8+ messages in thread
From: Piotr Krukowiecki @ 2011-04-14 13:38 UTC (permalink / raw)
  To: Junio C Hamano, Michael Haggerty; +Cc: git

On Wed, Apr 13, 2011 at 12:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * mh/git-svn-automkdirs (2011-04-01) 1 commit
>  (merged to 'next' on 2011-04-03 at 7fa4978)
>  + git-svn: add an option to skip the creation of empty directories
>
> Should be safe, but I'd like an Ack from git-svn folks.

I wanted to test performance of this change - what's the best way to do it?

I tried some ideas, but rebase was too fast for performance measurements.
I did not have new commits, but just some old, already in trunk changes, which
I tried to rebase - probably it was just fast forward?


-- 
Piotr Krukowiecki

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-14 13:38 ` Piotr Krukowiecki
@ 2011-04-14 13:50   ` Piotr Krukowiecki
  2011-04-14 15:21   ` Michael Haggerty
  1 sibling, 0 replies; 8+ messages in thread
From: Piotr Krukowiecki @ 2011-04-14 13:50 UTC (permalink / raw)
  To: Junio C Hamano, Michael Haggerty; +Cc: git

On Thu, Apr 14, 2011 at 3:38 PM, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 12:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * mh/git-svn-automkdirs (2011-04-01) 1 commit
>>  (merged to 'next' on 2011-04-03 at 7fa4978)
>>  + git-svn: add an option to skip the creation of empty directories
>>
>> Should be safe, but I'd like an Ack from git-svn folks.
>
> I wanted to test performance of this change - what's the best way to do it?
>
> I tried some ideas, but rebase was too fast for performance measurements.
> I did not have new commits, but just some old, already in trunk changes, which
> I tried to rebase - probably it was just fast forward?

I found some old not-yet-rebased branch (with 3 commits) and tried rebasing it.
I saw no time difference - maybe I'm doing it wrong?

I did following for both true and false config setting:

git checkout -b test_rebase old_branch
time git svn rebase
git checkout master
git branch -D test_rebase
<repeat>

Results I got:
13.7s 13.4s 13.6s (config: false)
13.6s 13.6s 16.6s (config: true)

The last "true" result is higher because rebase had to fetch one new revision.


-- 
Piotr Krukowiecki

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-14 13:38 ` Piotr Krukowiecki
  2011-04-14 13:50   ` Piotr Krukowiecki
@ 2011-04-14 15:21   ` Michael Haggerty
  2011-04-15  6:24     ` Piotr Krukowiecki
  1 sibling, 1 reply; 8+ messages in thread
From: Michael Haggerty @ 2011-04-14 15:21 UTC (permalink / raw)
  To: Piotr Krukowiecki; +Cc: Junio C Hamano, git

On 04/14/2011 03:38 PM, Piotr Krukowiecki wrote:
> On Wed, Apr 13, 2011 at 12:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * mh/git-svn-automkdirs (2011-04-01) 1 commit
>>  (merged to 'next' on 2011-04-03 at 7fa4978)
>>  + git-svn: add an option to skip the creation of empty directories
>>
>> Should be safe, but I'd like an Ack from git-svn folks.
> 
> I wanted to test performance of this change - what's the best way to do it?
> 
> I tried some ideas, but rebase was too fast for performance measurements.
> I did not have new commits, but just some old, already in trunk changes, which
> I tried to rebase - probably it was just fast forward?

The unhandled.log.gz file for trunk of our main project is 14 Mb and
uncompresses to 233 Mb.  About 90% of it consists of svn:mergeinfo
properties for file that were copied or renamed within the repository;
most of the rest is other random SVN file properties.

With such a huge unhandled.log file, "git svn mkdirs" took about 10s for
me.  I believe that "git svn rebase" should take at least as long, even
if it is a fast-forward.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-12 22:43 What's cooking in git.git (Apr 2011, #04; Tue, 12) Junio C Hamano
  2011-04-14 13:38 ` Piotr Krukowiecki
@ 2011-04-14 18:46 ` Jakub Narebski
  2011-04-14 19:14   ` Junio C Hamano
  1 sibling, 1 reply; 8+ messages in thread
From: Jakub Narebski @ 2011-04-14 18:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> --------------------------------------------------
> [Stalled]

> * jh/gitweb-localtime (2011-03-23) 1 commit
>  - gitweb: javascript ability to adjust time based on timezone
> 
> Re-roll posted on the list, but I haven't picked it up.

Should I post v2 of re-roll, or wait for after 1.7.5?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-14 18:46 ` Jakub Narebski
@ 2011-04-14 19:14   ` Junio C Hamano
  0 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2011-04-14 19:14 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> --------------------------------------------------
>> [Stalled]
>
>> * jh/gitweb-localtime (2011-03-23) 1 commit
>>  - gitweb: javascript ability to adjust time based on timezone
>> 
>> Re-roll posted on the list, but I haven't picked it up.
>
> Should I post v2 of re-roll, or wait for after 1.7.5?

Either way would work for me.

It is unlikely that I'll be reviewing and commenting on the topic very
much either before or after the release, but sending a v2 to the list
would give the stakeholders in gitweb a chance to review and comment on
the more recent version, and that can happen regardless of 1.7.5 schedule.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-14 15:21   ` Michael Haggerty
@ 2011-04-15  6:24     ` Piotr Krukowiecki
  2011-04-15  8:31       ` Michael Haggerty
  0 siblings, 1 reply; 8+ messages in thread
From: Piotr Krukowiecki @ 2011-04-15  6:24 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: Junio C Hamano, git

On Thu, Apr 14, 2011 at 5:21 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 04/14/2011 03:38 PM, Piotr Krukowiecki wrote:
>> On Wed, Apr 13, 2011 at 12:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * mh/git-svn-automkdirs (2011-04-01) 1 commit
>>>  (merged to 'next' on 2011-04-03 at 7fa4978)
>>>  + git-svn: add an option to skip the creation of empty directories
>>>
>>> Should be safe, but I'd like an Ack from git-svn folks.
>>
>> I wanted to test performance of this change - what's the best way to do it?
>>
>> I tried some ideas, but rebase was too fast for performance measurements.
>> I did not have new commits, but just some old, already in trunk changes, which
>> I tried to rebase - probably it was just fast forward?
>
> The unhandled.log.gz file for trunk of our main project is 14 Mb and
> uncompresses to 233 Mb.  About 90% of it consists of svn:mergeinfo
> properties for file that were copied or renamed within the repository;
> most of the rest is other random SVN file properties.
>
> With such a huge unhandled.log file, "git svn mkdirs" took about 10s for
> me.  I believe that "git svn rebase" should take at least as long, even
> if it is a fast-forward.

That might be the reason - my unhandled.log is 17MB (unpacked) and mkdirs
takes 0.5s


-- 
Piotr Krukowiecki

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: What's cooking in git.git (Apr 2011, #04; Tue, 12)
  2011-04-15  6:24     ` Piotr Krukowiecki
@ 2011-04-15  8:31       ` Michael Haggerty
  0 siblings, 0 replies; 8+ messages in thread
From: Michael Haggerty @ 2011-04-15  8:31 UTC (permalink / raw)
  To: Piotr Krukowiecki; +Cc: Junio C Hamano, git

On 04/15/2011 08:24 AM, Piotr Krukowiecki wrote:
> On Thu, Apr 14, 2011 at 5:21 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 04/14/2011 03:38 PM, Piotr Krukowiecki wrote:
>>> On Wed, Apr 13, 2011 at 12:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> * mh/git-svn-automkdirs (2011-04-01) 1 commit
>>>>  (merged to 'next' on 2011-04-03 at 7fa4978)
>>>>  + git-svn: add an option to skip the creation of empty directories
>>>>
>>>> Should be safe, but I'd like an Ack from git-svn folks.
>>>
>>> I wanted to test performance of this change - what's the best way to do it?
>>>
>>> I tried some ideas, but rebase was too fast for performance measurements.
>>> I did not have new commits, but just some old, already in trunk changes, which
>>> I tried to rebase - probably it was just fast forward?
>>
>> The unhandled.log.gz file for trunk of our main project is 14 Mb and
>> uncompresses to 233 Mb.  About 90% of it consists of svn:mergeinfo
>> properties for file that were copied or renamed within the repository;
>> most of the rest is other random SVN file properties.
>>
>> With such a huge unhandled.log file, "git svn mkdirs" took about 10s for
>> me.  I believe that "git svn rebase" should take at least as long, even
>> if it is a fast-forward.
> 
> That might be the reason - my unhandled.log is 17MB (unpacked) and mkdirs
> takes 0.5s

Yes, it is also my assumption that parsing so much text in Perl is what
causes the slowdown.  But as long as git-svn insists on plonking so much
information in unhandled.log but then handling it anyway, it seems like
a good policy to prevent it from reading this file any more than
necessary.  And for me, the creation of empty directories is not worth
10s.  (Even your 0.5s is pretty slow by git standards :-) ).

An alternative might be to move the emptydir information from
unhandled.log to a separate file.  The "empty_dir" lines in my unhandled
log are only about 0.1% of the file contents, and should be parseable in
a negligible amount of time.  But moving the data would presumably have
implications for backwards compatibility.

[Are there any design documents for git-svn?  I have had a hard time
deciphering the code and understanding what data it stores and where.]

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-04-15  8:31 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-12 22:43 What's cooking in git.git (Apr 2011, #04; Tue, 12) Junio C Hamano
2011-04-14 13:38 ` Piotr Krukowiecki
2011-04-14 13:50   ` Piotr Krukowiecki
2011-04-14 15:21   ` Michael Haggerty
2011-04-15  6:24     ` Piotr Krukowiecki
2011-04-15  8:31       ` Michael Haggerty
2011-04-14 18:46 ` Jakub Narebski
2011-04-14 19:14   ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.