Re: [stgit] understanding why --diff-opts was dropped from stg status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2008-08-28 23:43:38 +0200, Yann Dirson wrote:

> It's been quite some time I have been away from stgit developement,
> so I have missed many things.

Yes, we've missed you!

> I just noticed that the post-0.14.3 stable branch contains a change
> that adds tests for "stg status --diff-opts", then one that removes
> that flag claiming it did not work.
>
> Quite puzzled (since it is a feature I heavily used), I tried "git
> co 15ad449" expecting the tests added there would break... but it
> does pass on my box. What problems did you see ?

This is the kind of output you get from git diff-index, diff-files, et
al (from Documentation/diff-format.txt):

in-place edit  :100644 100644 bcd1234... 0123456... M file0
copy-edit      :100644 100644 abcd123... 1234567... C68 file1 file2
rename-edit    :100644 100644 abcd123... 1234567... R86 file1 file3
create         :000000 100644 0000000... 1234567... A file4
delete         :100644 000000 1234567... 0000000... D file5
unmerged       :000000 000000 0000000... 0000000... U file6

Note that in the copy and rename cases (which are only triggered when
-C or -M are in effect) there are two filenames and not one. I don't
recall the details, but the code parsing this output barfed on it. (I
discovered this problem when I added stgit.diff-opts = -M to my global
config, and stg status started failing.) I considered fixing it, but
as I recall making it handle two filenames required more surgery than
I was prepared to do at that point, in the stable branch and all. But
I'm in no way opposed to the feature. Quite the contrary. As long as
it isn't broken ...

( In case you feel like fixing this:
  stgit.lib.git.Repository.diff_tree_files() knows how to parse the
  output including copy and rename records, so no need to write a new
  parser. Just make stg status use this one, and teach it to handle
  pairs of filenames. )

About the test succeeding for you -- are you sure? The stable branch
has an older version of the test suite lib, which just prints "OK" for
expected failures that indeed fail. Try changing that test from
test_expect_success to test_expect_failure, and you should see the
magic blue smoke coming out of your computer ...

-- 
Karl Hasselström, kha@xxxxxxxxxxx
      www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux