Re: [PATCH v4 11/12] convert: add filter.<driver>.process option

larsxschneider@gmail.com writes:

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capabilities=clean smudge\n

During the discussion on the future of pack-protocol, it was pointed
out that having to shove all capabilities on a single line/packet
was one of the things we would want to fix in the current protocol
when we revamp to v2.  As this exhange between the convert machinery
and an external process is a brand new one, I do not think you want
to mimic the limitation in the current pack protocol like this; the
limitation mostly came from the constraint that we cannot break
existing pack protocol clients and servers before we extended the
protocol to add capabilities.

You may not foresee that the caps won't grow very long beyond
clean/smudge right now, just like we did not foresee that we would
wish to be able to convey a lot longer capability values to the
other side when we added the capability exchange to the pack
protocol, so "but but but we will never have that many" is not a
good counter-argument.

On 03 Aug 2016, at 19:45, Junio C Hamano [off-list ref] wrote:

larsxschneider@gmail.com writes:

quoted

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capabilities=clean smudge\n

During the discussion on the future of pack-protocol, it was pointed
out that having to shove all capabilities on a single line/packet
was one of the things we would want to fix in the current protocol
when we revamp to v2.  As this exhange between the convert machinery
and an external process is a brand new one, I do not think you want
to mimic the limitation in the current pack protocol like this; the
limitation mostly came from the constraint that we cannot break
existing pack protocol clients and servers before we extended the
protocol to add capabilities.

You may not foresee that the caps won't grow very long beyond
clean/smudge right now, just like we did not foresee that we would
wish to be able to convey a lot longer capability values to the
other side when we added the capability exchange to the pack
protocol, so "but but but we will never have that many" is not a
good counter-argument.

OK. Is this the v2 discussion you are referring to?
http://public-inbox.org/git/1461972887-22100-1-git-send-email-sbeller%40google.com/

What format do you suggest?

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capability=clean\n
packet:          git< capability=smudge\n
packet:          git< 0000

or

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capability\n
packet:          git< clean\n
packet:          git< smudge\n
packet:          git< 0000

or  ... ?

I would prefer the first one, I think.

- Lars

On Wed, Aug 03, 2016 at 11:48:00PM +0200, Lars Schneider wrote:

OK. Is this the v2 discussion you are referring to?
http://public-inbox.org/git/1461972887-22100-1-git-send-email-sbeller%40google.com/

What format do you suggest?

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capability=clean\n
packet:          git< capability=smudge\n
packet:          git< 0000

or

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capability\n
packet:          git< clean\n
packet:          git< smudge\n
packet:          git< 0000

or  ... ?

I would prefer the first one, I think.

How about:

  version=2
  clean=true
  smudge=true
  0000

? Then we do not have to care about multiple "capability" keys (so
something naively parsing this could just store them in a string list,
for example).

You could also make "clean" a synonym for "clean=true" or something, and
have:

  version=2
  clean
  smudge
  0000

but it's probably better to have the protocol err on the side of
verbose-but-unambiguous. It's not like people are typing this routinely.

-Peff

On 04 Aug 2016, at 00:46, Jeff King [off-list ref] wrote:

On Wed, Aug 03, 2016 at 11:48:00PM +0200, Lars Schneider wrote:

quoted

OK. Is this the v2 discussion you are referring to?
http://public-inbox.org/git/1461972887-22100-1-git-send-email-sbeller%40google.com/

What format do you suggest?

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capability=clean\n
packet:          git< capability=smudge\n
packet:          git< 0000

or

packet:          git< git-filter-protocol\n
packet:          git< version=2\n
packet:          git< capability\n
packet:          git< clean\n
packet:          git< smudge\n
packet:          git< 0000

or  ... ?

I would prefer the first one, I think.

How about:

 version=2
 clean=true
 smudge=true
 0000

? Then we do not have to care about multiple "capability" keys (so
something naively parsing this could just store them in a string list,
for example).

Alright. I will go with this solution.

Thanks,
Lars