Re: Recent git changes and unmerged files

[Kai Willadsen <kai willadsen gmail com>]

On 9 May 2010 16:56, Peter Tyser <ptyser gmail com> wrote:
> Hi Kai,
>
>> Since I'm not a real git expert, I thought I'd solicit some help on
>> bug 617098 (https://bugzilla.gnome.org/show_bug.cgi?id=617098). The
>> short version is that now that we use git-diff-index, unmerged files
>> are not correctly detected. There's a patch at the bug, but I'd love
>> feedback and testing, particularly from anyone with an understanding
>> of git plumbing.
>
> I think we may need to get the status of files by combining the output of both:
> git diff-index HEAD --cached --name-status ./
> git diff-files --name-status -0 ./
>
> From the "Raw output format" section of
> http://www.kernel.org/pub/software/scm/git/docs/git-diff-index.html:
> git-diff-index --cached <tree-ish>
> compares the <tree-ish> and the index.
>
> git-diff-files [<pattern>…]
> compares the index and the files on the filesystem.
>
> The combination of those 2 commands should cover changes on the disk,
> as well as to the index.  My understanding is that the "git-diff-index
> HEAD --name-status" we currently use only compares the files on the
> disk, and ignores the fact that the index is also modified/conflicted.
> git-diff-index <tree-ish>
> compares the <tree-ish> and the files on the filesystem.

So this was a question on the bug report; what do we expect to see
when you run Meld on a git (or other VCS with staging area concepts)
repository?

Personally, I wouldn't expect to see any changes that I'd already
staged. In my mind, changes already present in the index are done, and
I don't need to worry about them. I just want Meld to help me get the
rest of it staged... but I realise that others may feel differently.

If we want to include already staged changes *and* deal with unmerged
statuses, etc. then your approach is probably the right one. If we
don't need staged changes and such, then will git-diff-files suffice?

cheers,
Kai