What's cooking in git.git (Oct 2009, #01; Wed, 07)

What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.

In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes.  The resulting system may not be strictly
backward compatible.  Currently planeed changes are:

 * refuse push to update the checked out branch in a non-bare repo by
   default

   Make "git push" into a repository to update the branch that is checked
   out fail by default.  You can countermand this default by setting a
   configuration variable in the receiving repository.

   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

 * refuse push to delete the current branch by default

   Make "git push $there :$killed" to delete the branch that is pointed at
   by its HEAD fail by default.  You can countermand this default by
   setting a configuration variable in the receiving repository.

   http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936

 * git-send-email won't make deep threads by default

   Many people said that by default when sending more than 2 patches the
   threading git-send-email makes by default is hard to read, and they
   prefer the default be one cover letter and each patch as a direct
   follow-up to the cover letter.  You can countermand this by setting a
   configuration variable.

   http://article.gmane.org/gmane.comp.version-control.git/109790

 * git-status won't be "git-commit --dry-run" anymore

   http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993

 * "git-diff -w --exit-code" will exit success if only differences it
   found are whitespace changes that are stripped away from the output.

   http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751

We are in pre-release feature freeze.  'next' will hold topics meant for
1.6.6 and 1.7.0.

Tonight's tip of 'master' is 1.6.5-rc3.

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

* ch/am-header (2009-09-25) 2 commits
  (merged to 'next' on 2009-09-25 at f86e197)
 + git-am: force egrep to use correct characters set
 + git-am: fixed patch_format detection according to RFC2822

* dk/blame-el (2009-09-29) 1 commit
 - git-blame.el: Change how blame information is shown.

* ef/msvc-noreturn (2009-09-30) 2 commits
  (merged to 'next' on 2009-10-07 at 66137a0)
 + add NORETURN_PTR for function pointers
 + increase portability of NORETURN declarations

jk: This is the latest round and I think should be ready for at least
'next' (maybe even 'master' as it is really about the build and not about
functionality).

* ef/msys-imap (2009-10-03) 7 commits
 - mingw: enable OpenSSL
 - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
 - imap-send: provide fall-back random-source
 - imap-send: build imap-send on Windows
 - imap-send: fix compilation-error on Windows
 - imap-send: use run-command API for tunneling
 - imap-send: use separate read and write fds

jk: This is from an RFC which has generated some comments. He should be
posting another round soon. 'pu' at best.

* fc/mutt-alias (2009-09-30) 1 commit
  (merged to 'next' on 2009-10-07 at df7ac20)
 + send-email: fix mutt regex for grouped aliases

jk: Latest round that addressed comments. Ready for 'next' if not
'master'.

* jk/reflog-date (2009-09-24) 1 commit
  (merged to 'next' on 2009-09-29 at 43d444a)
 + improve reflog date/number heuristic

* jn/gitweb-patch (2009-09-30) 1 commit
 - gitweb: Do not show 'patch' link in 'commit' view for merges

jk: After some comments with Jakub, I think the code is right but he
promised a re-roll with more in the commit message.

* mr/gitweb-snapshot (2009-09-26) 2 commits
 - gitweb: append short hash ids to snapshot files
 - gitweb: check given hash before trying to create snapshot

jk: He posted a v5 of his series. I didn't look at it closely, but Jakub
ack'd it.

* mr/instaweb-cgid (2009-09-26) 1 commit
  (merged to 'next' on 2009-09-29 at 3524604)
 + instaweb: support mod_cgid for apache2

* tf/doc-pt-br (2009-09-23) 1 commit
 - Documentation: update pt-BR

The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree).  Need to revert these headings (or change the length of the section
underlines to match the length of translated names).

* jc/pretty-lf (2009-10-04) 1 commit
 - Pretty-format: %[+-]x to tweak inter-item newlines

I am not happy with this one yet.  I am contemplating to introduce a new
syntax "%[magic(param)<anything>%]" to generalize expressions of this and
line wrapping features in an extensible way.

* js/log-rewrap (2008-11-10) 3 commits
 . Add "%w" to pretty formats, which rewraps the commit message
 - Add strbuf_add_wrapped_text() to utf8.[ch]
 - print_wrapped_text(): allow hard newlines

... and the first two from this series will be useful to implement an
example magic "wrap", e.g. "%{wrap(i,j,w)%s%+b%]".

* jg/log-format-body-indent (2009-09-19) 1 commit
 . git-log --format: Add %B tag with %B(x) option

I think we should redo this on top of the first two patches from
js/log-rewrap series; %B(x) is just a special case %B(x,x,0), no?  If a
magic value 0 (or negative) given to wrap-width does not disable wrapping,
we probably should make it so.  I merged this to 'pu' but then ejected it
because it seems to break at least t6006.

* bg/rebase-reword (2009-10-07) 1 commit
 - Teach 'rebase -i' the command "reword"

* js/diff-verbose-submodule (2009-10-04) 1 commit
 - Add the --submodule-summary option to the diff option family

Dscho sounded like he has some corrections after list comments, but I did
not pick up his interdiff in the middle.

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

* je/send-email-no-subject (2009-08-05) 1 commit
  (merged to 'next' on 2009-08-30 at b6455c2)
 + send-email: confirm on empty mail subjects

The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)

* jh/cvs-helper (2009-08-18) 8 commits
 - More fixes to the git-remote-cvs installation procedure
 - Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
 - Add simple selftests of git-remote-cvs functionality
 - git-remote-cvs: Remote helper program for CVS repositories
 - 2/2: Add Python support library for CVS remote helper
 - 1/2: Add Python support library for CVS remote helper
 - Basic build infrastructure for Python scripts
 - Allow helpers to request marks for fast-import
 (this branch uses db/vcs-helper-rest.)

Builds on db/vcs-helper.  There is a re-roll planned.

* ne/rev-cache (2009-09-07) 7 commits
 - support for commit grafts, slight change to general mechanism
 - support for path name caching in rev-cache
 - full integration of rev-cache into git, completed test suite
 - administrative functions for rev-cache, start of integration into git
 - support for non-commit object caching in rev-cache
 - basic revision cache system, no integration or features
 - man page and technical discussion for rev-cache

I merged this to 'pu' but then ejected it because it seems to break at
least t6001.

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

* jl/submodule-add-noname (2009-09-22) 1 commit
 - git submodule add: make the <path> parameter optional

Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used.  I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.

* jc/fix-tree-walk (2009-09-14) 9 commits
 - read-tree --debug-unpack
 - unpack-trees.c: look ahead in the index
 - unpack-trees.c: prepare for looking ahead in the index
 - traverse_trees(): handle D/F conflict case sanely
 - more D/F conflict tests
 - tests: move convenience regexp to match object names to test-lib.sh
 - unpack_callback(): use unpack_failed() consistently
 - unpack-trees: typofix
 - diff-lib.c: fix misleading comments on oneway_diff()

This is my replacement for Linus's lt/maint-traverse-trees-fix patch.  It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it.  It turned out that the index side also needed some hairy look-ahead,
and I am only half satisfied with the current status of the series.

To fix the resolve merge regression seen in t6035, git-merge-resolve needs
to be rewritten not to use the one-path-at-a-time "git merge-index".

* jp/fetch-tag-match (2009-09-17) 1 commit
 - fetch: Speed up fetch by rewriting find_non_local_tags

I did not have much energy left while dealing with the "fix-tree-walk"
series, so I just queued this without reading nor thinking about it very
much.  I personally liked my version that had far smaller number of lines
changed (which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain.  We'll see.

* jc/maint-blank-at-eof (2009-09-15) 0 commits.
 (this branch uses jc/maint-1.6.0-blank-at-eof.)

The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'.  It is a fix for longstanding bug and 1.6.5 will not contain
this topic.

* db/vcs-helper-rest (2009-09-03) 6 commits
 - Allow helpers to report in "list" command that the ref is unchanged
 - Add support for "import" helper command
 - Add a config option for remotes to specify a foreign vcs
 - Allow programs to not depend on remotes having urls
 - Allow fetch to modify refs
 - Use a function to determine whether a remote is valid
 (this branch is used by jh/cvs-helper.)

This holds the remainder of the db/vcs-helper topic that has already
merged for 1.6.5.

* jh/notes (2009-09-12) 13 commits
 - Selftests verifying semantics when loading notes trees with various fanouts
 - Teach the notes lookup code to parse notes trees with various fanout schemes
 - notes.[ch] fixup: avoid old-style declaration
 - Teach notes code to free its internal data structures on request.
 - Add '%N'-format for pretty-printing commit notes
 - Add flags to get_commit_notes() to control the format of the note string
 - t3302-notes-index-expensive: Speed up create_repo()
 - fast-import: Add support for importing commit notes
 - Teach "-m <msg>" and "-F <file>" to "git notes edit"
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes
 (this branch uses sr/gfi-options.)

Rerolled and queued.

* jn/gitweb-show-size (2009-09-07) 1 commit
 - gitweb: Add 'show-sizes' feature to show blob sizes in tree view

* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
 . Prepare 'traverse_trees()' for D/F conflict lookahead

Ejected from 'pu' (see jc/fix-tree-walk above).

* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
  (merged to 'next' on 2009-09-15 at 9cbfa00)
 + diff -B: colour whitespace errors
 + diff.c: emit_add_line() takes only the rest of the line
 + diff.c: split emit_line() from the first char and the rest of the line
 + diff.c: shuffling code around
 + diff --whitespace: fix blank lines at end
  (merged to 'next' on 2009-09-07 at 165dc3c)
 + core.whitespace: split trailing-space into blank-at-{eol,eof}
 + diff --color: color blank-at-eof
 + diff --whitespace=warn/error: fix blank-at-eof check
 + diff --whitespace=warn/error: obey blank-at-eof
 + diff.c: the builtin_diff() deals with only two-file comparison
 + apply --whitespace: warn blank but not necessarily empty lines at EOF
 + apply --whitespace=warn/error: diagnose blank at EOF
 + apply.c: split check_whitespace() into two
 + apply --whitespace=fix: detect new blank lines at eof correctly
 + apply --whitespace=fix: fix handling of blank lines at the eof
 (this branch is used by jc/maint-blank-at-eof.)

This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards.  jc/maint-blank-at-eof serves that purpose.

Will not be in 1.6.5.

* jn/gitweb-blame (2009-09-01) 5 commits
 - gitweb: Minify gitweb.js if JSMIN is defined
 - gitweb: Create links leading to 'blame_incremental' using JavaScript
  (merged to 'next' on 2009-09-07 at 3622199)
 + gitweb: Colorize 'blame_incremental' view during processing
 + gitweb: Incremental blame (using JavaScript)
 + gitweb: Add optional "time to generate page" info in footer

Ajax-y blame.

* sr/gfi-options (2009-09-06) 6 commits
  (merged to 'next' on 2009-09-07 at 5f6b0ff)
 + fast-import: test the new option command
 + fast-import: add option command
 + fast-import: test the new feature command
 + fast-import: add feature command
 + fast-import: put marks reading in it's own function
 + fast-import: put option parsing code in separate functions
 (this branch is used by jh/notes.)

Ping?

* nd/sparse (2009-08-20) 19 commits
 - sparse checkout: inhibit empty worktree
 - Add tests for sparse checkout
 - read-tree: add --no-sparse-checkout to disable sparse checkout support
 - unpack-trees(): ignore worktree check outside checkout area
 - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
 - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
 - unpack-trees.c: generalize verify_* functions
 - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
 - Introduce "sparse checkout"
 - dir.c: export excluded_1() and add_excludes_from_file_1()
 - excluded_1(): support exclude files in index
 - unpack-trees(): carry skip-worktree bit over in merged_entry()
 - Read .gitignore from index if it is skip-worktree
 - Avoid writing to buffer in add_excludes_from_file_1()
 - Teach Git to respect skip-worktree bit (writing part)
 - Teach Git to respect skip-worktree bit (reading part)
 - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
 - Add test-index-version
 - update-index: refactor mark_valid() in preparation for new options

--------------------------------------------------
[For 1.7.0]

* jk/1.7.0-status (2009-09-05) 5 commits
 - docs: note that status configuration affects only long format
  (merged to 'next' on 2009-09-07 at 8a7c563)
 + commit: support alternate status formats
 + status: add --porcelain output format
 + status: refactor format option parsing
 + status: refactor short-mode printing to its own function
 (this branch uses jc/1.7.0-status.)

Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".

* jc/1.7.0-status (2009-09-05) 4 commits
  (merged to 'next' on 2009-09-06 at 19d4beb)
 + status: typo fix in usage
  (merged to 'next' on 2009-08-22 at b3507bb)
 + git status: not "commit --dry-run" anymore
 + git stat -s: short status output
 + git stat: the beginning of "status that is not a dry-run of commit"
 (this branch is used by jk/1.7.0-status.)

With this, "git status" is no longer "git commit --dry-run".

* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
  (merged to 'next' on 2009-08-22 at 5106de8)
 + send-email: make --no-chain-reply-to the default

* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
  (merged to 'next' on 2009-08-30 at 0623572)
 + diff.c: fix typoes in comments
  (merged to 'next' on 2009-08-27 at 81fb2bd)
 + Make test case number unique
  (merged to 'next' on 2009-08-02 at 9c08420)
 + diff: Rename QUIET internal option to QUICK
 + diff: change semantics of "ignore whitespace" options

This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output.  It is a backward incompatible change, but
we could argue that it is a bugfix.

* jc/1.7.0-push-safety (2009-02-09) 2 commits
  (merged to 'next' on 2009-08-02 at 38b82fe)
 + Refuse deleting the current branch via push
 + Refuse updating the current branch in a non-bare repository via push

--------------------------------------------------
[I have been too busy to purge these]

* jc/log-tz (2009-03-03) 1 commit.
 - Allow --date=local --date=other-format to work as expected

Maybe some people care about this.  I dunno.

* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
 - mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker

Maybe some people care about this.  I dunno.

* lt/read-directory (2009-05-15) 3 commits.
 . Add initial support for pathname conversion to UTF-8
 . read_directory(): infrastructure for pathname character set conversion
 . Add 'fill_directory()' helper function for directory traversal

* cc/reset-merge (2009-09-16) 4 commits
 . reset: add test cases for "--merge-safe" option
 . reset: add option "--merge-safe" to "git reset"
 . reset: use "unpack_trees()" directly instead of "git read-tree"
 . reset: add a few tests for "git reset --merge"

* cc/sequencer-rebase-i (2009-08-28) 15 commits
 . rebase -i: use "git sequencer--helper --cherry-pick"
 . sequencer: add "--cherry-pick" option to "git sequencer--helper"
 . sequencer: add "do_commit()" and related functions working on "next_commit"
 . pick: libify "pick_help_msg()"
 . revert: libify cherry-pick and revert functionnality
 . rebase -i: use "git sequencer--helper --fast-forward"
 . sequencer: let "git sequencer--helper" callers set "allow_dirty"
 . sequencer: add "--fast-forward" option to "git sequencer--helper"
 . sequencer: add "do_fast_forward()" to perform a fast forward
 . rebase -i: use "git sequencer--helper --reset-hard"
 . sequencer: add "--reset-hard" option to "git sequencer--helper"
 . sequencer: add "reset_almost_hard()" and related functions
 . rebase -i: use "git sequencer--helper --make-patch"
 . sequencer: add "make_patch" function to save a patch
 . sequencer: add "builtin-sequencer--helper.c"

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Johannes Schindelin]

Hi,

On Wed, 7 Oct 2009, Junio C Hamano wrote:

> * sr/gfi-options (2009-09-06) 6 commits
>   (merged to 'next' on 2009-09-07 at 5f6b0ff)
>  + fast-import: test the new option command
>  + fast-import: add option command
>  + fast-import: test the new feature command
>  + fast-import: add feature command
>  + fast-import: put marks reading in it's own function
>  + fast-import: put option parsing code in separate functions
>  (this branch is used by jh/notes.)
> 
> Ping?

Shawn, last time I heard of this issue, it was stuck in your review queue.

Ciao,
Dscho

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Sverre Rabbelier]

Heya,

On Thu, Oct 8, 2009 at 08:49, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Shawn, last time I heard of this issue, it was stuck in your review queue.

Correct, am waiting for Shawn's decision on whether to drop options
and replace them with additional features or not.

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Marius Storm-Olsen]

Junio C Hamano said the following on 08.10.2009 08:33:
> * ef/msys-imap (2009-10-03) 7 commits
>  - mingw: enable OpenSSL
>  - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
>  - imap-send: provide fall-back random-source
>  - imap-send: build imap-send on Windows
>  - imap-send: fix compilation-error on Windows
>  - imap-send: use run-command API for tunneling
>  - imap-send: use separate read and write fds

Don't forget about the MSVC patch ontop of this series:
Message-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>
Subject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto

--
.marius

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Shawn O. Pearce]

Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Oct 8, 2009 at 08:49, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Shawn, last time I heard of this issue, it was stuck in your review queue.
> 
> Correct, am waiting for Shawn's decision on whether to drop options
> and replace them with additional features or not.

Uh.  Wow, it has been a while.

IIRC my problem with options was we weren't enforcing them, and yet
they were necessary for a successful import, e.g. import-marks or
export-marks.  A minor error could cause a successful looking import
that is wrong due to the marks being messed up, or not saved out.

So I was leaning towards making these features, but then they
aren't necessarily compatible with the other fast-import tools.
Which led me to a stalemate, and I forgot about the thread.

Dammit.

We should run this past the fast-import list but I think we want
to declare features for import-marks and export-marks:

  feature import-marks=in.marks
  feature export-marks=out.marks

and define these as paths to local files which store a VCS specific
formatted mapping of fast-import mark numbers to VCS labels.


Other options that are clearly git should be declared as:

  option git max-pack-size=2048

with the meaning of option being declared something like:

  If the parsing VCS name appears as the first argument, the parsing
  VCS must recognize and support the supplied option, and if not
  recognized or not supported must abort parsing altogether.

  If the parsing VCS name is not the first argument, it must entirely
  ignore the option command and not try to process its contents.

-- 
Shawn.

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Sverre Rabbelier]

Heya,

[edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]

On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:
> IIRC my problem with options was we weren't enforcing them, and yet
> they were necessary for a successful import, e.g. import-marks or
> export-marks.  A minor error could cause a successful looking import
> that is wrong due to the marks being messed up, or not saved out.
>
> So I was leaning towards making these features, but then they
> aren't necessarily compatible with the other fast-import tools.
>
> I think we want to declare features for import-marks and export-marks:
>
>  feature import-marks=in.marks
>  feature export-marks=out.marks
>
> and define these as paths to local files which store a VCS specific
> formatted mapping of fast-import mark numbers to VCS labels.
>
>
> Other options that are clearly git should be declared as:
>
>  option git max-pack-size=2048
>
> with the meaning of option being declared something like:
>
>  If the parsing VCS name appears as the first argument, the parsing
>  VCS must recognize and support the supplied option, and if not
>  recognized or not supported must abort parsing altogether.
>
>  If the parsing VCS name is not the first argument, it must entirely
>  ignore the option command and not try to process its contents.

I think it makes to ignore options that are not for our vcs, as long
as options that change import behavior (such as marks, date-format)
are combined with, say, 'feature tool=git'. This way we can be sure
that when outputting out a vcs specific stream, it is only parsed by
that vcs.

Note: yes, I know that marks and date-format are features now, but
there's really no other suitable example that I could think of).

vcs fast import devs please ack this idea (and perhaps suggest
something other than "feature tool=git" if preferable) so that I can
reroll my gfi-options series :).

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Erik Faye-Lund]

On Thu, Oct 8, 2009 at 8:58 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> Junio C Hamano said the following on 08.10.2009 08:33:
>>
>> * ef/msys-imap (2009-10-03) 7 commits
>>  - mingw: enable OpenSSL
>>  - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
>>  - imap-send: provide fall-back random-source
>>  - imap-send: build imap-send on Windows
>>  - imap-send: fix compilation-error on Windows
>>  - imap-send: use run-command API for tunneling
>>  - imap-send: use separate read and write fds
>
> Don't forget about the MSVC patch ontop of this series:
> Message-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>
> Subject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto

I will include it in the next round I send out (unless someone objects)

-- 
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Jakub Narebski]

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

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

> * jn/gitweb-patch (2009-09-30) 1 commit
>  - gitweb: Do not show 'patch' link in 'commit' view for merges
> 
> jk: After some comments with Jakub, I think the code is right but he
> promised a re-roll with more in the commit message.

Not only better commit message, but a more complete patch as well.
 
> * mr/gitweb-snapshot (2009-09-26) 2 commits
>  - gitweb: append short hash ids to snapshot files
>  - gitweb: check given hash before trying to create snapshot
> 
> jk: He posted a v5 of his series. I didn't look at it closely, but Jakub
> ack'd it.

Actually I acked first patch in series (the "check hash" one), but the
second needs review, and I think corrections.  First there is matter
of tests and matter of not calling git_get_short_hash if it would not
be used (what was mentioned in my review).  But what is more important
that now that gitweb doesn't use full SHA-1 unconditionally, we have
to deal with stripping prefix from refs/tags/v1.6.3-rc3 and
refs/heads/master, and with hierarchical branch names such as
'mr/gitweb-snapshot'.  I'll post improved review soon.

In short: first patch is a go, second needs more work.

> * jc/pretty-lf (2009-10-04) 1 commit
>  - Pretty-format: %[+-]x to tweak inter-item newlines
> 
> I am not happy with this one yet.  I am contemplating to introduce a new
> syntax "%[magic(param)<anything>%]" to generalize expressions of this and
> line wrapping features in an extensible way.
> 
> * js/log-rewrap (2008-11-10) 3 commits
>  . Add "%w" to pretty formats, which rewraps the commit message
>  - Add strbuf_add_wrapped_text() to utf8.[ch]
>  - print_wrapped_text(): allow hard newlines
> 
> ... and the first two from this series will be useful to implement an
> example magic "wrap", e.g. "%{wrap(i,j,w)%s%+b%]".

So... it is magic %[...%] or %{...} or %{...%}?

BTW we can take rpm's queryformat as an example (or counterexample).
Also perhaps we can reuse minilanguage of git-for-each-ref format,
i.e. %(field:modifier).
  
> --------------------------------------------------
> [Cooking]

> * jn/gitweb-show-size (2009-09-07) 1 commit
>  - gitweb: Add 'show-sizes' feature to show blob sizes in tree view

What this one requires (beside better name for a feature)?

> * jn/gitweb-blame (2009-09-01) 5 commits
>  - gitweb: Minify gitweb.js if JSMIN is defined
>  - gitweb: Create links leading to 'blame_incremental' using JavaScript
>   (merged to 'next' on 2009-09-07 at 3622199)
>  + gitweb: Colorize 'blame_incremental' view during processing
>  + gitweb: Incremental blame (using JavaScript)
>  + gitweb: Add optional "time to generate page" info in footer
> 
> Ajax-y blame.

I reordered patches so JSMIN one is first (as it is less
controversial), but the 'create blame_incremental links' one needs
more work.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> --------------------------------------------------
>> [New Topics]
>
>> * jn/gitweb-patch (2009-09-30) 1 commit
>>  - gitweb: Do not show 'patch' link in 'commit' view for merges
>> 
>> jk: After some comments with Jakub, I think the code is right but he
>> promised a re-roll with more in the commit message.
>
> Not only better commit message, but a more complete patch as well.

Ok; I'll wait.

>> * mr/gitweb-snapshot (2009-09-26) 2 commits
>>  - gitweb: append short hash ids to snapshot files
>>  - gitweb: check given hash before trying to create snapshot
>> 
>> jk: He posted a v5 of his series. I didn't look at it closely, but Jakub
>> ack'd it.
> ...
> In short: first patch is a go, second needs more work.

Ok; I'll merge fdb0c36 (gitweb: check given hash before trying to create
snapshot, 2009-09-26) to 'next'.

>> * jc/pretty-lf (2009-10-04) 1 commit
>>  - Pretty-format: %[+-]x to tweak inter-item newlines
>> 
>> I am not happy with this one yet.  I am contemplating to introduce a new
>> syntax "%[magic(param)<anything>%]" to generalize expressions of this and
>> line wrapping features in an extensible way.
>> ...
> So... it is magic %[...%] or %{...} or %{...%}?

The escape does not matter. %() is fine, too.  It is non-essential for the
purpose of the upcoming release so I have backburnered coming up with and
thinking the details through.

>> --------------------------------------------------
>> [Cooking]
>
>> * jn/gitweb-show-size (2009-09-07) 1 commit
>>  - gitweb: Add 'show-sizes' feature to show blob sizes in tree view
>
> What this one requires (beside better name for a feature)?

Name before 'next', and then the usual cooking, I guess.

>> * jn/gitweb-blame (2009-09-01) 5 commits
>> ...
>> Ajax-y blame.
>
> I reordered patches so JSMIN one is first (as it is less
> controversial), but the 'create blame_incremental links' one needs
> more work.

Ok; I'll wait.

Thanks.

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Junio C Hamano]

Erik Faye-Lund <kusmabite@googlemail.com> writes:

> On Thu, Oct 8, 2009 at 8:58 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
>> Junio C Hamano said the following on 08.10.2009 08:33:
>>>
>>> * ef/msys-imap (2009-10-03) 7 commits
>> ...
>> Don't forget about the MSVC patch ontop of this series:
>> Message-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>
>> Subject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto
>
> I will include it in the next round I send out (unless someone objects)

Thanks.

Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Matt McClure]

On Thu, Oct 8, 2009 at 1:58 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Other options that are clearly git should be declared as:
>>
>>  option git max-pack-size=2048
>>
>> with the meaning of option being declared something like:
>>
>>  If the parsing VCS name appears as the first argument, the parsing
>>  VCS must recognize and support the supplied option, and if not
>>  recognized or not supported must abort parsing altogether.
>>
>>  If the parsing VCS name is not the first argument, it must entirely
>>  ignore the option command and not try to process its contents.
>
> I think it makes to ignore options that are not for our vcs, as long
> as options that change import behavior (such as marks, date-format)
> are combined with, say, 'feature tool=git'. This way we can be sure
> that when outputting out a vcs specific stream, it is only parsed by
> that vcs.

I prefer option-scope VCS specifiers over stream-scope specifiers.
The latter would artificially reduce interoperability between VCSs.
Who is the fast-output developer to say that only one fast-import tool
should use his stream?

-- 
Matt
http://www.google.com/profiles/matthewlmcclure

Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Sverre Rabbelier]

Heya,

On Sun, Oct 11, 2009 at 13:40, Matt McClure <mlm@aya.yale.edu> wrote:
> Who is the fast-output developer to say that only one fast-import tool
> should use his stream?

He knows that a foreign tool that does not heed his 'option git
stream-changing-option' will mis-parse the stream. For example the
Bazaar people were talking about adding some Bazaar-specific options
so facilitate bzr-bzr traffic, it would be impossible for a non-bzr
importer to properly understand the stream if they were to ignore the
bzr-specific options. So either options should only affect things that
do not change semantics (such as perhaps whether or not to be quiet,
whether to try and limit memory usage, etc), or it should be possible
to indicate that an option is changes semantic and cannot be ignored.

-- 
Cheers,

Sverre Rabbelier

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Sverre Rabbelier]

Heya,

On Thu, Oct 8, 2009 at 10:58, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> I think it makes to ignore options that are not for our vcs, as long
> as options that change import behavior (such as marks, date-format)
> are combined with, say, 'feature tool=git'. This way we can be sure
> that when outputting out a vcs specific stream, it is only parsed by
> that vcs.
>
> Note: yes, I know that marks and date-format are features now, but
> there's really no other suitable example that I could think of).
>
> vcs fast import devs please ack this idea (and perhaps suggest
> something other than "feature tool=git" if preferable) so that I can
> reroll my gfi-options series :).

Shawn, what do you want to do with this, it seems the vcs devs are not
very interested in this feature, should I implement it as described
above? That is:
  * If you use any option that is stream-changing you should include
"feature tool=git" in your stream
  * import-marks and export-marks are made into features
  * "option vcs" is ignored if vcs is a different vcs
  * "option vcs" must be recognised if vcs is this vcs

-- 
Cheers,

Sverre Rabbelier

Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Ian Clatworthy]

Sverre Rabbelier wrote:

> Shawn, what do you want to do with this, it seems the vcs devs are not
> very interested in this feature, should I implement it as described
> above?

Sverre,

I'll try to take a look today. Sorry for the lack of response so far -
other stuff has been swamping my time and this hasn't reached the top of
my TODO list unfortunately.

Ian C.

Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Johannes Schindelin]

Hi,

On Wed, 28 Oct 2009, Sverre Rabbelier wrote:

> On Thu, Oct 8, 2009 at 10:58, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > I think it makes to ignore options that are not for our vcs, as long 
> > as options that change import behavior (such as marks, date-format) 
> > are combined with, say, 'feature tool=git'. This way we can be sure 
> > that when outputting out a vcs specific stream, it is only parsed by 
> > that vcs.
> >
> > Note: yes, I know that marks and date-format are features now, but
> > there's really no other suitable example that I could think of).
> >
> > vcs fast import devs please ack this idea (and perhaps suggest
> > something other than "feature tool=git" if preferable) so that I can
> > reroll my gfi-options series :).
> 
> Shawn, what do you want to do with this, it seems the vcs devs are not
> very interested in this feature, should I implement it as described
> above? That is:
>   * If you use any option that is stream-changing you should include
>     "feature tool=git" in your stream
>   * import-marks and export-marks are made into features
>   * "option vcs" is ignored if vcs is a different vcs
>   * "option vcs" must be recognised if vcs is this vcs

It would be quite nice if this issue moved forward for a change.

As a consequence of it moving forward, I could nudge Sverre into 
continuing with his git-remote-hg work that will allow me to work 
transparently on a Mercurial repository using Git.

Transparent as in "no hassles".

It also will serve nicely as a perfect excuse to fix some design mistakes 
in the foreign vcs stuff.

Ciao,
Dscho

Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Ian Clatworthy]

Sverre Rabbelier wrote:
> Heya,
> 
> [edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]

Thanks Sverre. Before I start, sorry for taking so long to reply to this.

> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:
>> IIRC my problem with options was we weren't enforcing them, and yet
>> they were necessary for a successful import, e.g. import-marks or
>> export-marks.  A minor error could cause a successful looking import
>> that is wrong due to the marks being messed up, or not saved out.
>>
>> So I was leaning towards making these features, but then they
>> aren't necessarily compatible with the other fast-import tools.

My strong preference is for:

* feature = anything impacting semantics
* option = tool-specific with no impact on semantics permitted.

Both features and options ought to OS independent (where possible).

>> I think we want to declare features for import-marks and export-marks:
>>
>>  feature import-marks=in.marks
>>  feature export-marks=out.marks
>>
>> and define these as paths to local files which store a VCS specific
>> formatted mapping of fast-import mark numbers to VCS labels.

+1 to making these features and to tightening up the semantics so we can
reliably use them across tools. Explicitly specifying the local path
names worries me though. Consider someone using fastimport tools to
maintain multiple mirrors in different tools:

1. Step 1 is fast-export from tool A
2. Step 2 is fast-import into tool B
3. Step 3 is fast-import into tool C

What should the stream look like then? Does it need to change if we want
an additional mirror in tool D? (Note that the mark files will need to
be reused to transfer changes back to the master.)

>> Other options that are clearly git should be declared as:
>>
>>  option git max-pack-size=2048
>>
>> with the meaning of option being declared something like:
>>
>>  If the parsing VCS name appears as the first argument, the parsing
>>  VCS must recognize and support the supplied option, and if not
>>  recognized or not supported must abort parsing altogether.
>>
>>  If the parsing VCS name is not the first argument, it must entirely
>>  ignore the option command and not try to process its contents.

+1. By forcing tools to know about options specific to them, we avoid a
range of bugs processing newer streams with older tools.

> I think it makes to ignore options that are not for our vcs, as long
> as options that change import behavior (such as marks, date-format)
> are combined with, say, 'feature tool=git'. This way we can be sure
> that when outputting out a vcs specific stream, it is only parsed by
> that vcs.

I don't think options should be permitted to change import behavior. In
other words, we should actively discourage vcs-specific streams. Any VCS
using features has a (moral) responsibility IMO to at least define those
publicly. Here's a poor start (EBNF syntax would be far better than just
text) on the Bazaar side:
http://doc.bazaar-vcs.org/migration/en/data-migration/fast-export.html#interoperability.

Maybe we need a central wiki page (say) where these can be registered?
I'd offer to setup a "fastimport" web site in a Bazaar branch and track
feature specification bugs in Launchpad but maybe a wiki page would be a
little more neutral ground. :-) :-)

Ian C.

Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)

[Sverre Rabbelier]

Heya,

On Thu, Oct 29, 2009 at 20:50, Ian Clatworthy
<ian.clatworthy@canonical.com> wrote:
>> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sverre Rabbelier wrote:
>> [edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]
>
> Thanks Sverre. Before I start, sorry for taking so long to reply to this.

Thanks for the review :).

> My strong preference is for:
>
> * feature = anything impacting semantics
> * option = tool-specific with no impact on semantics permitted.
>
> Both features and options ought to OS independent (where possible).

Even better, Shawn, if this LGTY I will reroll the series implementing this.

>>> I think we want to declare features for import-marks and export-marks
>>> and define these as paths to local files which store a VCS specific
>>> formatted mapping of fast-import mark numbers to VCS labels.
>
> Explicitly specifying the local path names worries me though. Consider someone
> using fastimport tools to maintain multiple mirrors in different tools.
> What should the stream look like then? Does it need to change if we want
> an additional mirror.

I think the stream should not have to change, which works if you
define the files to be local to the repo being exported to.  That is,
in git the line "feature export-marks=out.marks" would result in a
marks file located in "/path/to/repo/.git/fast-import/out.marks". Or
is that not what you mean?

> +1. By forcing tools to know about options specific to them, we avoid a
> range of bugs processing newer streams with older tools.

It is not possible to change the semantics using options though, what
kind of bugs could arise this way?

> I don't think options should be permitted to change import behavior. In
> other words, we should actively discourage vcs-specific streams

Sounds fair, I reckon that a wiki in addition to the
vcs-fast-import-devs list would not hurt :).

-- 
Cheers,

Sverre Rabbelier