Re: [PATCH v2 1/2] Introduce config variable "diff.primer"
- From
Keith Cascio <keith@cs.ucla.edu>
- Date
- Feb 4, 2009, 06:36 UTC
- Message-ID
- <alpine.GSO.2.00.0902032217380.25760@kiwi.cs.ucla.edu>
- In-Reply-To
- <7v7i4692p4.fsf@gitster.siamese.dyndns.org>
On Tue, 3 Feb 2009, Junio C Hamano wrote:
Show 5 quoted lines
> Any codepath could call DIFF_OPT_SET()/CLR(), whether it is in response to end > user's input from the command line (e.g. "the user said --foo, so I am > flipping the foo bit on/off), or to enforce restriction to achieve sane > semantics (e.g. "it does not make any sense to run this internal diff without > --binary set, so I am using OPT_SET()").
Yes but the trick is the flips and maskings happen on different structs. We accumulate the shell command line flags/masks in a separate struct from the primer flags/masks. IOW, there's a whole lotta flags and masks!!
> Doesn't it suggest that you may want two layers of masks, not a flat one, if > you really want the mechanism to scale?
There are indeed two layers of masks (and there can be as many as needed). In my current patch, the shell command line becomes "master" and primer becomes "slave". Both layers exist independently of each other, in two separate diff_option structs, until just before "go time", when I flatten them (but that does not destroy the slave, it is reused). As Peff put it: "a master/slave pair of flag/mask pairs". I specifically designed the code to make it easy to create an arbitrary number of layers, then flatten them all together just before it's time to do something. The code only needs to keep track of the order of precedence, i.e. always pass the higher precedence struct to flatten_diff_options() as master and the lower precedence struct as slave, and the bit logic in that function does the rest. I was specifically thinking of GIMP or Photoshop when I wrote this patch. The concept is the same. Those programs support an arbitrary number of layers, and when they produce the final image, they call it "flatten layers".
If you and Peff like this design then I could clean up everything based on all of Peff's suggestions (i.e. xmalloc instead of malloc, etc) and hopefully move on to the stage of building consensus for the actual name. No rush of course. Just give me the word. Peff?
-- Keith