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 ...
[ message continues ]

Hi,


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

Ciao,
Dscho
--

[ message continues ]

Heya,

On Thu, Oct 8, 2009 at 08:49, Johannes Schindelin

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

-- 
Cheers,

Sverre Rabbelier
--

[ message continues ]

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

[ message continues ]

Heya,

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


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

[ message continues ]

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

[ message continues ]

Heya,


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

[ message continues ]

Heya,


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

[ message continues ]

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

[ message continues ]

Hi,


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

--

[ message continues ]

My strong preference is for:

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


+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

+1. By forcing tools to know about options specific to them, we avoid a

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

[ message continues ]

Heya,

On Thu, Oct 29, 2009 at 20:50, Ian Clatworthy



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

It is not possible to change the semantics using options though, what

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

-- 
Cheers,

Sverre Rabbelier
--

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

Thanks.
--

[ message continues ]

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.


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

[ message continues ]

Ok; I'll merge fdb0c36 (gitweb: check given hash before trying to create

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


Ok; I'll wait.

Thanks.
--

[ message continues ]