'pu' branch for StGIT

So I finally got my act together and published a 'pu'-like branch for StGIT. Get it at git://repo.or.cz/stgit/kha.git; gitweb at http://repo.or.cz/w/stgit/kha.git.

The idea is that I grab the StGIT patches that are posted to the list, put each series in its own topic branch (based on Catalin's master), and publish a merge of them. _After_ having made sure that the test suite passes, naturally. It then becomes much easier for everyone to test these patches.

This should lessen the pressure on Catalin to include patches in his master branch as soon as possible, which should in turn reduce the number of reverts in the official history.

Here's what's currently in there:

Karl Hasselström (8):
      Teach StGIT about core.excludesfile
      New test: make sure that popping doesn't change patch order
      Verify patch status during the test
      Make use of the get_patch() utility function
      Compute patch appliedness from commit DAG
      Test the new DAG appliedness machinery
      Fix bash completion after the DAG appliedness patch
      Speed up the appliedness test

Pavel Roskin (1):
      Add support for SMTP over Transport Layer Security (TLS)

Yann Dirson (7):
      Include contrib scripts in the release tarball.
      Improve stg-fold-files-from doc.
      New contrib scripts: stg-dispatch and stg-show.
      Add -O flag to stg-fold-files-from.
      Add a no-act flag to stg-dispatch and stg-fold-file-from.
      Provide file completion for add/resolved/refresh based on status.
      Fixed completion function hardcoding .git/.

(Does anyone know the incantation for Junio's status mails, with topic branches grouped nicely?)

NOTE: The DAG appliedness patch series is in there. They will upgrade
the format of any stgit branch they touch, and there's no convenient
way to change it back if you change your mind.

Karl Hasselstrm <kha@treskal.com> wrote:

Look at his todo branch; one of those scripts does the magic. Start with todo:WC, apparently it calls todo:git-topic.perl. Junio checks out the todo branch in a Meta/ subdirectory. :-)

On Tue, 2007-08-07 at 04:20 +0200, Karl Hasselström wrote:

Just a word of warning. This version converts all branches to version 3, so that the standard StGIT won't work with them anymore.

Also, "stg import" commits the patch, which seems wrong to me.

On 2007-08-08 01:03:53 -0400, Pavel Roskin wrote:

I believe I said (or tried to say) as much towards the end of my mail. Thanks for trying it out though! It seems my evil master plan is working. :-)

Hmm, I hadn't noticed. That would be an unintended side-effect of the DAG patches, presumably. I'll look into it tonight.

On 2007-08-08 11:20:27 +0200, Karl Hasselström wrote:

I can't reproduce. (Using master of git://repo.or.cz/stgit/kha.git.) The last subtest of t1800 actually tests that a mailbox was imported as a series of patches, and that works fine for me (the other subtests don't make sure that a patch was created; they just verify that we got the right tree). Furthermore, the following works for me:

kha@yoghurt:~/stgit/t> ./t1800-import.sh
*   ok 1: Initialize the StGIT repository
*   ok 2: Apply a patch created with "git diff"
*   ok 3: Apply a patch created with GNU diff
*   ok 4: Apply a patch created with "stg export"
*   ok 5: Apply a patch from an 8bit-encoded e-mail
*   ok 6: Apply a patch from a QP-encoded e-mail
*   ok 7: Apply several patches from an mbox file
* passed all 7 test(s)
kha@yoghurt:~/stgit/t> cd trash/
kha@yoghurt:~/stgit/t/trash> ls
foo.txt
kha@yoghurt:~/stgit/t/trash> PATH=/home/kha/stgit:$PATH stg series -d
kha@yoghurt:~/stgit/t/trash> PATH=/home/kha/stgit:$PATH stg import -m ../t1800-import/email-qp
Checking for changes in the working directory ... done
Finding uninteresting commits ... done
Importing patch "email-qp" ... done
Now at patch "email-qp"
kha@yoghurt:~/stgit/t/trash> PATH=/home/kha/stgit:$PATH stg series -d

So a patch is definitely created. Could you describe in more detail exactly what you do to make it fail?

Hello, Karl!

On Wed, 2007-08-08 at 23:39 +0200, Karl Hasselström wrote:

OK, it's trickier. There are some bad patch names that don't get imported properly. In particular, patches ending with ".diff" are committed after import.

Try changing this in the testsuite:

On 2007-08-08 18:18:34 -0400, Pavel Roskin wrote:

Ah, sneaky. And it turns out to be not a problem with import, but a problem with dots in patch names. It's just that import is the only place those are typically created.

It was all due to a sloppy regexp. This is the fix:

Quoting Karl Hasselström <kha@treskal.com>:

Thank you!

And by the way, please fix the description of the commit where you added --smtp-server option. You added it to "stg mail", not to "stg add".

On 2007-08-08 20:10:03 -0400, Pavel Roskin wrote:

You did all the work on this one.

Mmm, thanks. Will fix tonight.

I take it this all means you're actually using my branch? What's your opinion on its usefulness?

On Thu, 2007-08-09 at 09:38 +0200, Karl Hasselström wrote:

Well, I tried it, and then ran a script to update all local repositories. It converted everything to "version 3", so I'm sort of stuck with it. If the "version 3" code is not committed to the mainline StGIT, I'll have to convert my repositories back or even re-fetch them.

I have noticed two problems so far, but I cannot tell is they are specific to the "pu" branch.

1) Undead patches.

StGIT finds a patch I deleted long ago and shows it as unapplied. It cannot be deleted by "stg delete" because some files are missing.

$ stg delete at76_usb
Traceback (most recent call last):
  File "/home/proski/bin/stg", line 43, in <module>
    main()
  File "home/proski/lib/python2.5/site-packages/stgit/main.py", line 284, in main
  File "home/proski/lib/python2.5/site-packages/stgit/commands/delete.py", line 76, in func
  File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 1227, in delete_patch
  File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 1209, in delete_patch_data
  File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 160, in delete
OSError: [Errno 2] No such file or directory: '.git/patches/wireless-dev/patches/at76_usb'

That's Linux repository, and I'm on wireless-dev branch. There is a file .git/patches/wireless-dev/trash/at76_usb containing "None". There are two other files in that directory, but they have some SHA1 hashes.

There is also a file .git/patches/wireless-dev/patchorder, which contains "at76_usb".

I was updating the repository by "stg pull", there were two patches, "at76_usb" being first. It couldn't be merged, so I deleted it. I deleted the other patch as well, since I new it was applied upstream. After another "stg pull" at76_usb became "undead".

I cannot reproduce it on another repository.

2) Invisible branches.

StGIT stopped showing other branches. It's always showing the same branch, although it can switch to other branches:

[proski@dv linux-2.6]$ stg branch --list Available branches:

[proski@dv linux-2.6]$ stg branch wireless-2.6
Checking for changes in the working directory ... done
Switching to branch "wireless-2.6" ... done
[proski@dv linux-2.6]$ stg branch --list
Available branches:
  s     wireless-dev  | 
[proski@dv linux-2.6]$ stg branch linus       
Checking for changes in the working directory ... done
Switching to branch "linus" ... done
[proski@dv linux-2.6]$ stg branch --list
Available branches:
  s     wireless-dev  | 
[proski@dv linux-2.6]$ stg init
stg init: linus already initialized
[proski@dv linux-2.6]$

On 2007-08-09 09:24:43 -0400, Pavel Roskin wrote:

Thanks for the vote of confidence. :-)

You should be able to do something like

  $ stg applied > .git/patches/branch/applied
  $ stg unapplied > .git/patches/branch/unapplied

and then manually change the version from 3 to 2, and be ready to go. I haven't tested this, though!

I saw the same problem today. I haven't had time to look into it, but I believe it's due to stgit trying to directly modify files under .git/refs instead of using git-update-ref, which breaks with packed refs. The DAG patches rely much more on the refs, so the bug is more severe in that case.

https://gna.org/bugs/?9710

The patchorder file should be harmless. It's only used to determine patch order for those cases where the DAG information isn't sufficient. (That is, for unapplied patches.) It's strictly advisory, and _not_ used to determine which patches exist.

Until this is fixed, you can use git-show-ref and git-update-ref to manually delete the offending ref. That fixed the problem for me.

I haven't seen this problem at all -- in my repositories, "stg branch -l" just works. Will try to reproduce (hopefully tonight). Do you have a recepie on how to reproduce this from scratch?

On 2007-08-09 16:18:48 +0200, Karl Hasselström wrote:

git-gc started packing refs by default in late May. That's probably what's caused it to surface.

On Thu, 2007-08-09 at 16:18 +0200, Karl Hasselström wrote:

That seems to work. Thank you! "branch" should be substituted with the current branch, of course.

I've attached the test case to that bug.  You are right, git-gc is involved.

It's a problem with git-gc too! Just clone some repository and run "stg branch -l" in it. It with show master. Run git-gc, and "stg branch -l" will show "No branches".

I see that in my Linux repository there are files in .git/refs/remotes/wireless-dev but not in other directories under .git/refs/remotes/

On 2007-08-09 12:33:30 -0400, Pavel Roskin wrote:

What? You mean I didn't forget any step? ;-)

I was just too lazy to type the brackets. Or maybe I'm just evil and _want_ the lock-in effect. Who knows? :-)

Thanks.

Well, well! In that case, I'm off to kill two birds with one stone!

Presumably the only nonpacked refs are the ones that have been updated after the last ref packing. Or however it works.

On 09/08/2007, Pavel Roskin <proski@gnu.org> wrote:

I'll merge many of Karl's patches for the next stable release (which I hope to be sooner than the current 0.13) but I'm still on holiday for one more week and can't do much work (busy with DIY).

Thanks to Karl for setting up this experimental branch. BTW, what does 'pu' mean?

On 2007-08-09 22:31:09 +0100, Catalin Marinas wrote:

Great! Would you like me to select the "safe" topics and give you a single integration branch to pull, or do you want to be the one that does the selecting?

Proposed Updates, as I recall. But I just used that to explain how my branch is going to behave (meaning: it'll behave like Junio's pu branch); it isn't actually called "pu". Not so pedagogical if no one has heard of Junio's pu branch, I guess. :-)

Quoting Catalin Marinas <catalin.marinas@gmail.com>:

I'm on vacation for two more weeks, on a poor modem connection and away from anything POSIX-compatible (and pulling StGIT is too much for my modem anyway), so please don't wait for my replies.

I guess it's "pick-up", modeled after git's "pu" branch.