hg status + file metadata
Matt Mackall
mpm at selenic.com
Sat Dec 1 21:50:57 UTC 2007
On Sat, Dec 01, 2007 at 01:03:25PM -0800, Brendan Cully wrote:
> On Saturday, 01 December 2007 at 21:01, Patrick M?zard wrote:
> > Dustin Sallings a ?crit :
> > >
> > > On Nov 30, 2007, at 19:44, Steve Borho wrote:
> > >
> > >> This is another example where the normal diff format is simply not up to
> > >> the task. If you enable git diff format, then you can see changes of
> > >> permission.
> > >>
> > >> [diff]
> > >> git=1
> > >
> > > Is there a reason not to use git diffs by default?
> >
> > I think we should.
> >
> > The hard part is not breaking existing CLI too much. For instance --git has no --normal equivalent.
> > I would see a mq.git option too, overriding diff.git.
>
> I think there's a definite argument that we should produce git diffs
> when plain diffs would lose some of the content of the changes (mode
> changes, binary files). On the other hand, copy information isn't
> strictly necessary for a correct revision, it just makes the history
> more accurate. In the case of copies or copies+mods, git diffs
> needlessly break plain patch, so I don't think that should be the
> default format for that case.
The default has to do the right thing when fed to patch(1). That's a
requirement. Which means the git format's rename bits and binary bits
are out.
But we can insert text into the non-diff portions of the output that
mention mode changes (like we mention "binary files differ" currently)
and possibly even mention that we're looking at a merge diff.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list