[RFC] git diff dira dirb file ...

[RFC] git diff dira dirb file ...

[Daniel Barkalow]

After a lot of trying, I finally found something that git diff doesn't 
handle. If you've got two trees of files with the same general structure, 
even if they aren't at all git-related, you can use:

$ git diff dira dirb

to get a nice diff between them. But then it would be intuitive and useful 
to be able to restrict by path the files within those directories that you 
want to compare (much like "git diff origin master file1 file2 ...") with:

$ git diff dira dirb file1 file2

That would, of course, compare dira/file1 with dirb/file1 and dira/file2 
with dirb/file2. Before I start looking into implementing this, is it 
incoherent for some reason I'm not seeing?

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] git diff dira dirb file ...

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> After a lot of trying, I finally found something that git diff doesn't 
> handle. If you've got two trees of files with the same general structure, 
> even if they aren't at all git-related, you can use:
>
> $ git diff dira dirb
>
> to get a nice diff between them. But then it would be intuitive and useful 
> to be able to restrict by path the files within those directories that you 
> want to compare (much like "git diff origin master file1 file2 ...") with:
>
> $ git diff dira dirb file1 file2
>
> That would, of course, compare dira/file1 with dirb/file1 and dira/file2 
> with dirb/file2. Before I start looking into implementing this, is it 
> incoherent for some reason I'm not seeing?

Incoherent?

I do not see anything fundamentally wrong with it, except that command
line parsing may get tricky, because we rely on the revision command line
parser, and logically you should be able to spell the above commandline as
"diff dira dirb -- file1 file2", revision parser wants anything that comes
before -- to be revisions, not paths.

Just make sure that you got two directories, at least one of which is
outside the work tree, mark your diff option as "no-index", then walk the
two directories in parallel to populate the diff_queue().  Once you are
done walking, let diffcore_std() to do its usual thing.

Having said that, that new "feature" is not git anymore, and I'd rather
wish to see competent git people to be working on hunting for and fixing
outstanding bugs during the -rc period, than spending their time on new
features and non-git hacking, but all of us do this as hobbies, so I
wouldn't stop you ;-)

Re: [RFC] git diff dira dirb file ...

[Daniel Barkalow]

On Fri, 6 Jun 2008, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > After a lot of trying, I finally found something that git diff doesn't 
> > handle. If you've got two trees of files with the same general structure, 
> > even if they aren't at all git-related, you can use:
> >
> > $ git diff dira dirb
> >
> > to get a nice diff between them. But then it would be intuitive and useful 
> > to be able to restrict by path the files within those directories that you 
> > want to compare (much like "git diff origin master file1 file2 ...") with:
> >
> > $ git diff dira dirb file1 file2
> >
> > That would, of course, compare dira/file1 with dirb/file1 and dira/file2 
> > with dirb/file2. Before I start looking into implementing this, is it 
> > incoherent for some reason I'm not seeing?
> 
> Incoherent?
> 
> I do not see anything fundamentally wrong with it, except that command
> line parsing may get tricky, because we rely on the revision command line
> parser, and logically you should be able to spell the above commandline as
> "diff dira dirb -- file1 file2", revision parser wants anything that comes
> before -- to be revisions, not paths.
> 
> Just make sure that you got two directories, at least one of which is
> outside the work tree, mark your diff option as "no-index", then walk the
> two directories in parallel to populate the diff_queue().  Once you are
> done walking, let diffcore_std() to do its usual thing.
> 
> Having said that, that new "feature" is not git anymore, and I'd rather
> wish to see competent git people to be working on hunting for and fixing
> outstanding bugs during the -rc period, than spending their time on new
> features and non-git hacking, but all of us do this as hobbies, so I
> wouldn't stop you ;-)

Actually, that came up in my day job, where I only really get to use git 
to work around the fact that the big commerical version control system 
doesn't make it easy to do stuff. So think of it as testing corner cases 
of the diff machinary on the side, when I can't justify working directly 
on git.

In any case, this goes on my list of things to work on someday.

Do you have a list of outstanding issues for the release?

	-Daniel
*This .sig left intentionally blank*