A 'g' merge as opposed to a 'G' merge mean the file wasn't changed. This
provides useful information. This usually happens if you merge something
that had already been merged before (due to merge tracking not being used or
the merge tracking metadata being out of date, or someone using diff+patch
to bring a change forward). An alternative would be to display nothing,
which since the file didn't change might work, but you'd not be telling the
user about the conflict free duplicate merge.
Michael
On 4/5/07, Paul Burba <pburba@collab.net> wrote:
>
> > -----Original Message-----
> > From: Michael Brouwer [mailto:mb.7766@gmail.com]
> > Sent: Wednesday, April 04, 2007 11:19 AM
> > To: Kamesh Jayachandran
> > Cc: Paul Burba; Mark Phippard; Subversion Development; Daniel
> > Rall; Peter N. Lundblad; philip@codematters.co.uk
> > Subject: Re: [PATCH]: Stop mer'G'e notification for files
> > with local mods that are unchanged by merge
> >
> > Rather than outright hiding that the file changed why not
> > implement what svk does, and show a lower case 'g' for files
> > that had local changes, but where unmodified by the merge
> > since they already contained the changes being merged into them?
>
> Hi Michael,
>
> Assuming that 'g' (or more likely some other capital letter code) were
> used, what you suggest is certainly doable, but do people actually find
> that information useful at all? What would one typically do with this
> information?
>
> I favor less, but more meaningful output from merge: conflicts and
> 'real' merges. I put 'g' in the same class as changes to svn:mergeinfo,
> reporting these would just add information of questionable* value.
>
> *Of course take all this with the requisite grain of salt, the merges I
> do are infrequent and relatively simple, so there may be some real value
> in 'g' that my world doesn't typically require...
>
> Paul B.
>
Received on Thu Apr 5 21:50:00 2007