Re: [PATCH QGit RFC] Fix "Save patch..." on a commit range

[Marco Costalba <mcostalba@gmail.com>]

On Tue, Jun 16, 2009 at 00:53, Markus
Heidelberg<markus.heidelberg@web.de> wrote:
>
> Yes, it works. Thanks. Would it make sense and be possible to fix it
> directly in ListView::getSelectedItems()?
>

I am not sure it is a problem of the selected items set. Unfortunatly
it is not ordered, but actually this was not documented, so it was my
bad to assume rows are always ordered because it happens they are
sorted with Qt4.3.3

And also ordering in Git::formatPatch() is easier because the "tools"
like appendNamesWithId() are already there and only there.

Another reason is that is Git::formatPatch() that needs the rows to be
ordered, so has a sense to do it there where is needed. Of corse if
other places of QGit requires that the rows returned by
ListView::getSelectedItems() should be ordered then we can move the
ordering in ListView::getSelectedItems() as you suggest, or, even
better, move the ordering in ListView::getSelectedItems() but from
there call a new helper function Git::sortShaByIndex() that does the
work and is defined in git.cpp because should use internal information
like the index and call directly the sha database.

Yes, a possible cleanup / reformat job could be to:

- Add a new public helper function Git::sortShaByIndex() defined in git.cpp

- Call from ListView::getSelectedItems() when we get the list of sha
user as select

- Document ListView::getSelectedItems() always returns a list of ordered sha's


> BTW, a nice way to see the created git-format-patch command without
> modifying the sources is to use a directory with spaces, which is not
> handled correctly by qgit.
>


????

I cannot test now, but this seems a bug.