This happened recently and I have not tried to reproduce it but thought it would be good to note it here.

I had a patch in the current branch called "diff". I also had a patch file called /tmp/diff. Without thinking, I used "stg import /tmp/diff" to pull that patch file into the current branch.

The result was two patches in the same branch called "diff". Subsequently, normal stg operations resulted in a Python exception.

To recover, I edited the branch's unapplied file and removed the second "diff".

To prevent stgit metadata corruption from happening, "stg import" could:

• Fail to import the patch file
• Select a distinct name for the imported patch (eg, "diff2")
• Create a new branch and use the expected patch name

It would be useful if stgit could maintain git notes entries when manipulating commits. Since git attached notes to commit IDs, this would require stgit to port those whenever the ID changes (patch reorder, refresh, etc).

This is useful for keeping track of revision notes for upstream patch submission...

After refreshing a patch, stgit generates this error when running stg series -d:

Error: Unhandled exception:
Traceback (most recent call last):
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/main.py", line 195, in _main
    ret = command.func(parser, options, args)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/commands/delete.py", line 102, in func
    allow_conflicts=allow_conflicts)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/transaction.py", line 132, in __init__
    self._assert_head_top_equal()
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/transaction.py", line 200, in _assert_head_top_equal
    if not self.stack.head_top_equal():
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 296, in head_top_equal
    top = self.patches.get(self.patchorder.applied[-1]).commit
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 235, in get
    return self._patches[name]
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/objcache.py", line 21, in __getitem__
    self.__objects[name] = self.__create(name)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 222, in create_patch
    p.commit  # raise exception if the patch doesn't exist
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 42, in commit
    return self._stack.repository.refs.get(self._ref)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/git/repository.py", line 79, in get
    return self._repository.get_commit(self._refs[ref])
KeyError: u'refs/patches/build-time/refresh-temp'

stg series works without generating an error (refresh-temp is at the top of the stack). Unfortunately, most stg commands now fail with either a KeyError or an AssertionError.

stg repair:

Error: Unhandled exception:
Traceback (most recent call last):
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/main.py", line 195, in _main
    ret = command.func(parser, options, args)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/commands/repair.py", line 94, in func
    patches = [stack.patches.get(pn) for pn in patchorder.all]
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 235, in get
    return self._patches[name]
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/objcache.py", line 21, in __getitem__
    self.__objects[name] = self.__create(name)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 222, in create_patch
    p.commit  # raise exception if the patch doesn't exist
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/stack.py", line 42, in commit
    return self._stack.repository.refs.get(self._ref)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/git/repository.py", line 79, in get
    return self._repository.get_commit(self._refs[ref])
KeyError: u'refs/patches/build-time/refresh-temp'

stg pop and stg delete refresh-temp generate the same exception (just a little different backtraces).

stg undo and stg reset (with various older states):

Error: Unhandled exception:
Traceback (most recent call last):
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/main.py", line 195, in _main
    ret = command.func(parser, options, args)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/commands/undo.py", line 71, in func
    return trans.run(stack.repository.default_iw, allow_bad_head=True)
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/transaction.py", line 257, in run
    self._check_consistency()
  File "/home/cvoltz/.local/lib/python2.7/site-packages/stgit/lib/transaction.py", line 244, in _check_consistency
    assert self.stack.patches.exists(pn)
AssertionError

The documentation doesn't indicate how one is supposed to recover from a situation like this. What needs to be done to get things working again?

Debug info

stgit version: 0.22
OS: CentOS 7.8

$ stg log | head -5
996a175   Wed, 6 May 2020 18:27:10 -0500   refresh (create temporary patch)
98538bd   Wed, 6 May 2020 18:26:54 -0500   refresh
91973e3   Wed, 6 May 2020 18:26:54 -0500   refresh (create temporary patch)
98b29c0   Wed, 6 May 2020 14:37:20 -0500   pop
131fe96   Wed, 6 May 2020 14:36:52 -0500   goto
stg log: git failed with code -13

(yikes, clicked submit without filling out the issue! sorry! writing it now)

I just learned about StackedGit and it's awesome! I basically have a manual flow that I use to basically do most of what this lib does, so finding this is a godsend.

We use GitHub at work, which means that I need to eventually get my patches into PRs. Right now, I have a patch stack that's like 52 patches long, and I obviously don't want to submit that as one huge PR (my coworkers would hate me!). Right now what I'm doing is creating a new branch, picking a range of patches to that branch using stg pick, and then putting that branch up for review. I do this with several branches from my stack. When I'm addressing comments, I address them in the base branch, update the patch, and then run sync to update the PR branch.

This workflow is still better than what I had before, but I think what would be better is being able to stg publish a range of patches to a branch, instead of always publishing all patches. This way, I could say stg publish -b pr-num-1 [patches for pr num 1], stg publish -b pr-num-2 [patches for pr num 2], and just continue doing that, merging or overriding any changes in the public branches (not really caring about the history there).

Is this something you would consider?

The one thing that might be kind of painful about this is the following case:

stg publish -b pr-foo patch-a
stg publish -b pr-bar patch-b (but patch-b depends on patch-b, so really we'd want to stack this on top of patch-a, and then make sure that in github we say the base branch of pr-bar is pr-foo)

So maybe an idea to solve this is that we could specify a base branch in stg publish as well?

Then, to publish updates to my stack, I could go:

stg publish --base-branch master -b pr-foo patch-a
stg publish --base-branch pr-foo -b pr-bar patch-b

I could script this ^^ for my use case :)

Curious to hear your thoughts, and thanks for keeping this great project alive!

$ python --version
Python 2.6.6
$ stg --version
Stacked GIT 0.18-101-g8fa6
git version 2.16.1
Python version 2.6.6 (r266:84292, Aug 9 2016, 06:11:56)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
$ stg show
Error: Unhandled exception:
Traceback (most recent call last):
File "/home/alwillia/lib/python2.6/site-packages/stgit/main.py", line 194, in _main
ret = command.func(parser, options, args)
File "/home/alwillia/lib/python2.6/site-packages/stgit/commands/show.py", line 83, in func
pager(commit_str)
File "/usr/lib64/python2.6/pydoc.py", line 1312, in pager
pager(text)
File "/usr/lib64/python2.6/pydoc.py", line 1326, in
return lambda text: pipepager(text, os.environ['PAGER'])
File "/usr/lib64/python2.6/pydoc.py", line 1353, in pipepager
pipe.write(text)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 75: ordinal not in range(128)

$ git show | head
commit c7d12e277b834d4a05a7d3529e143780c8cfedb2
Author: Christian König [email protected]
Date: Tue Jan 16 10:43:17 2018 +0100

x86/PCI: apply the AMD window fixup on resume as well

We need to reprogram the register content during resume.

Signed-off-by: Christian König <[email protected]>
Reported-by: Tom St Denis <[email protected]>

This is a patch that recently generated an upstream lkml thread with Bjorn Helgaas and Linus Torvalds over the handling of unicode in stg imported commits. The unicode appears to be handled correctly on import now and I can 'stg edit' the commit, but 'stg show' chokes on it.

It would be useful if the Message-ID header could be extracted from email imports and optionally included in the commit log. For example, a new --msgid option to the import command would result in the following being appended to the commit log before any new sign-offs/acks/reviews:
Message-Id: [email protected]

Ideally configuration options might allow the Message-Id string to be changed and the reference to be manipulated (via regex?), such that this same support could generate:
Link: https://lore.kernel.org/r/[email protected]

This support would align well with better patch tracking that many maintainers are adopting. Thanks!

It seems to me that pop, followed immediately by a push, with no changes in between, should be a no-op. It should leave the log in exactly the same state as it was before, because nothing important has changed. Couldn't this be accomplished by simply resetting the log branch to an earlier commit? It would be nice to not have the log cluttered up by operations that just cancel each other out.

some patches fail with stg import, while pass with patch. patch command automatically tries patch with smaller number of context lines.

i would like to pass -C as in git-apply

For some bizzare reason stg is hanging at the end of a lot of commands and if I Ctrl-C it spits out this:

^F^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/Cellar/[email protected]/3.8.5/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 1079, in wait
    return self._wait(timeout=timeout)
  File "/usr/local/Cellar/[email protected]/3.8.5/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 1804, in _wait
    (pid, sts) = self._try_wait(0)
  File "/usr/local/Cellar/[email protected]/3.8.5/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 1762, in _try_wait
    (pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt

Python Version: 3.8.5
OS: MacOS

STG VERSION:

stg version
waiting:  71677
Stacked GIT 0.23
git version 2.28.0
Python version 3.8.5 (default, Jul 21 2020, 10:48:26)
[Clang 11.0.3 (clang-1103.0.32.62)]

Possibly related: log2timeline/plaso#399

Update:

Looks like the offending process is: git diff-tree --stdin -r -z

Update:

Seems like I had git wrapper script that was doing something funky.

I am closing this task, but this might help a poor soul in the future with tips on where to look. =]

When trying to use the mail command on Fedora 31 w/ Python 3.7 it appears that the command will always fail with the message:
stg mail: cannot use TLS - no SSL support in Python

In digging into this I found the line generating it was:
if not hasattr(socket, 'ssl'):
raise CmdException("cannot use TLS - no SSL support in Python")

A bit of further digging seems to show that hasattr(socket, 'ssl') is not a valid away to test for if there is ssl support or not as socket.ssl was deprecated 1.

It appears the correct way to do this is to do an import in a try/except block as seen in this bugzilla 2, but I am not familiar enough with Python to be certain if this is the correct approach.

I pulled the latest version of stgit this morning and tried to install it:

[cel@klimt stgit]$ sudo python setup.py install
Traceback (most recent call last):
  File "setup.py", line 66, in <module>
    __check_git_version()
  File "setup.py", line 54, in __check_git_version
    gitver = Run('git', '--version').output_one_line().split()[2]
  File "/home/cel/src/stgit/stgit/run.py", line 262, in output_one_line
    outlines = self.output_lines(sep)
  File "/home/cel/src/stgit/stgit/run.py", line 253, in output_lines
    outdata = self._run_io()
  File "/home/cel/src/stgit/stgit/run.py", line 151, in _run_io
    raise self.exc('%s failed: %s' % (self._cmd[0], e))
stgit.run.RunException: git failed: [Errno 2] No such file or directory
[cel@klimt stgit]$ echo $PATH
/home/cel/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
[cel@klimt stgit]$ which git
/usr/local/bin/git
[cel@klimt stgit]$ git --version
git version 2.25.2
[cel@klimt stgit]$

Test case:

git init
echo a > file && git add file && git commit -m a
stg init
stg new -m b b && echo b > file && stg refresh
stg new -m c c && echo c > file && stg refresh
stg pop b # pops c and b, pushes c

This is supposed to result in a conflict, and it does. However, it leaves me no option to leave the conflict to be resolved later. I should be able to do git reset --hard && stg pop and have a subsequent stg push re-create the conflict. This does not work because the attempted push of c already updated the patch: git show reveals that the patch is completely empty.

(Edit: stg undo --hard does work but does something else: that restores things to the state where b and c are both pushed.)

When renaming a branch using stg branch --rename, the refs under refs/patches relating to hidden patches are missed. Any further attempt to use stgit on the affected branch gives a KeyError stacktrace.

In the particular example where I hit this problem, the refs in question (for the patchname itself, and patchname.log) were in .git/packed-refs rather than .git/refs/patches, but that shouldn't be relevant (provided stgit always uses git update-ref rather than directly editing files).

Version details:

Stacked GIT 0.19-1-g2f5bb-dirty
git version 2.26.0
Python version 2.7.5 (default, Sep 26 2019, 13:23:47)

When stg mail is executed from non-root directory, diff instead of file statistics contains only "0 files changed".

However, diff includes all the modified lines.

Mercurial Queues have an extremely useful feature when trying to maintain a patch queue for e.g. multiple base branches: patch guards.

Basically, each patch can be "tagged" positively or negatively, then qselect can be used to enable (or disable) guards.

Tags which have a positive guard which is not enabled, or a negative guard which is, will not be applied on push. This is rather useful when maintaning a number of patches against multiple branches but some of those patches only apply to a subset e.g. they patch features which have since been removed, or patch features recently added.

Is there anything similar in StGit currently, or being planned? Or a way to handle the general use case of "multiple patch queues which are largely identical but have some minor divergences"?

stgit-0.19

Is there a way to disable logging, either by an environment variable or a config option? I looked through the source and couldn't find anything relevant.

I'd like to disable either by global or by repo. If disabled globally, then one could override and enable by repo.

The reason I'd like to disable is it can clutter up the commit tree as I use the following quite a bit:

$ git log --graph --pretty=oneline --abbrev-commit --decorate --all --date-order
and
$ git log --abbrev-commit --all --boundary --branches --date-order --decorate --graph --oneline --pretty=oneline --simplify-by-decoration --topo-order

FWIW - I am aware of: stg log --clear

Thank you.

I still need to investigate this, but I need to write it down before I forget.

When using worktrees, if you check out a branch that you have previously initialized with stgit, if you type stg init, everything will be "OK", if "OK" means a separate stack per-worktree.

If you type stg series instead, it will half-initialize a folder under .git/worktrees/TREE/patches/BRANCH/ -- but then commands will fail, as it thinks it is both initialized and uninitialized simultaneously. stg init will fail, but stg series will assume we are uninitialized.

I think what we want is for stg to effectively ignore work trees and use the git-common-dir. git does not allow for one branch to be checked out simultaneously, so we don't need to worry about fighting ourselves for control over stg resources.

Note: stg init thinks we are properly initialized because of the presence of .git/worktrees/TREE/patches/BRANCH, but stg series fails because of the absence of the applied file.

It would be great to my workflow if I could GPG sign patches when exported (eg, with stg commit, stg export, or stg mail). Right now I'm having to stg commit the patch, then run git rebase -S on it.

I am having the problem that when viewing the repo state in SourceTree, my branch list is cluttered with the <mybranch>.stgit log entries from stgit (same argument as Issue #32).
Instead of not logging at all, would it be possible to not use a branch for the stgit log, but instead an abstract git ref like
refs/stgitlog/<mybranch>
to track the state of the log?

I did a quick test changing

I acknowledge that this would be a breaking change if just edited, so we might want to make the second part of the ref configurable.

If you could confirm that I am not missing anything and you would welcome such a change, I can give a shot at a pull request.

Running:

> python3 setup.py install --user

appears to produce a broken installation:

jhuston@probe (master) ~/s/stgit> which stg
/home/bos/jhuston/.local/bin/stg
jhuston@probe (master) ~/s/stgit> stg --help
Traceback (most recent call last):
  File "/home/bos/jhuston/.local/bin/stg", line 51, in <module>
    from stgit.main import main
  File "/home/bos/jhuston/.local/lib/python3.7/site-packages/stgit/main.py", line 15, in <module>
    from stgit import argparse, run, utils
  File "/home/bos/jhuston/.local/lib/python3.7/site-packages/stgit/argparse.py", line 20, in <module>
    from stgit.lib.git import Date
ModuleNotFoundError: No module named 'stgit.lib.git'

It doesn't look like it installs anything under lib/git:

jhuston@probe (master) ~/s/stgit> ls ~/.local/lib/python3.7/site-packages/stgit/lib
edit.py  __init__.py  log.py  objcache.py  __pycache__/  stack.py  stackupgrade.py  transaction.py

Editing the setup.py configuration appears to fix it:

diff --git a/setup.py b/setup.py
index 264a58b..1cc8936 100755
--- a/setup.py
+++ b/setup.py
@@ -110,7 +110,10 @@ setup(
     description='Stacked GIT',
     long_description='Push/pop utility on top of GIT',
     scripts=['stg'],
-    packages=list(map(str, ['stgit', 'stgit.commands', 'stgit.lib'])),
+    packages=list(map(str, ['stgit',
+                            'stgit.commands',
+                            'stgit.lib',
+                            'stgit.lib.git'])),
     data_files=[
         ('share/stgit/templates', glob('stgit/templates/*.tmpl')),
         ('share/stgit/examples', glob('examples/*.tmpl')),

If there's already a convenient way to do this, please let me know if I'm "doing it wrong". And apologies for being long-winded.

I frequently need to re-order patches in a series. I'm in the zone pushing and popping, and then suddenly I push a patch that doesn't apply cleanly and I realize I can't re-order the series that way without significant changes. But the workspace then needs to be cleaned up because it's full of conflicts, and the patch that didn't apply is now empty. It takes several minutes to hunt down the previous version of the patch, fix up the conflicts, and so on before I can get on with the original task. "stg undo" does not seem capable enough to make this painless (or perhaps I don't understand how to use it).

Instead, I'd like to propose possible tooling changes:

1. Make "stg undo" behave in a more convenient way -- instead of leaving the conflicts, can it actually undo things to the pre-push state and leave both the patch and the workspace in clean condition?
2. Add the ability to try out a push instead of actually performing it. Call it "stg try" or "stg push --dry-run", which would attempt to apply the patch and report either "the conflicts would be here and here" or "that will work fine, go ahead for real".
3. Or, make "stg push" always behave transactionally: if there are conflicts, then it simply fails and leaves the series in its pre-push state (I believe "stg import" behaves this way).
4. Or, make the default behavior of "stg push" transactional as above, as that as less surprising, but then add a new option to "stg push" that retains the current "just do it and I'll clean up the mess" behavior; say "stg push --force". This possibly adds a step or two when rebasing introduces conflicts in a series, so rebase could continue using "stg push --force".

As always, thanks very much for your efforts!

I have some rather large patches I'm trying to import.

It's been running on a single 28M patch for dozens of minutes. Running py-spy top shows:

Total Samples 19600
GIL: 0.00%, Active: 100.00%, Threads: 1

  %Own   %Total  OwnTime  TotalTime  Function (filename:line)
100.00% 100.00%   196.0s    196.0s   __split_descr_diff (stgit/commands/common.py:374)
  0.00%   0.00%   0.010s    0.010s   __split_descr_diff (stgit/commands/common.py:367)
  0.00% 100.00%   0.000s    196.0s   _main (stgit/main.py:193)
  0.00% 100.00%   0.000s    196.0s   parse_patch (stgit/commands/common.py:430)
  0.00% 100.00%   0.000s    196.0s   main (stgit/main.py:221)
  0.00% 100.00%   0.000s    196.0s   <module> (stg:39)
  0.00% 100.00%   0.000s    196.0s   func (stgit/commands/imprt.py:486)
  0.00% 100.00%   0.000s    196.0s   __import_file (stgit/commands/imprt.py:272)

This is with v0.23.

Unfortunately, I can't post the patch. It's a patch that contains changes to 630 files, 700k inserts, some binary files, etc...

It looks like it's getting stuck on parsing the patch, looking for a description...

Packages like https://github.com/typicode/husky are making git hooks great again easy.

Example husky pre-commit hooks setup: https://github.com/web-padawan/aybolit/blob/master/package.json#L75

Example package.json "lint-staged" key: https://github.com/web-padawan/aybolit/blob/master/package.json#L80

I'm noticing neither stg refresh or stg commit trigger these (at least?) pre-commit hooks. This creates risks of offroading commit quality and causes future PR difficulties, because stg users commits aren't being auto-corrected by prettier --fix, but native git users commits are. Their PRs now often also include involuntary corrections of previous stg commits, or require special attention to exclude hunks.

Any thoughts towards what a solution could be? Am I missing something simple about how I should configure stgit to work with commit hooks?

Hello, there was a bug reported on the previous site of stgit [1] about $title. The patch can be found in the wayback machine. Would you consider to accept that patch? I'm writing because we are carrying that patch in Fedora as some people are using that feature [2]. Thanks.

[1] https://web.archive.org/web/20170205225257/https://gna.org/bugs/?20349
[2] https://bugzilla.redhat.com/show_bug.cgi?id=872651

There are some use cases where stg edit <some-earlier-patch> should keep all following timestamps intact, because let's say some system /etc configuration tracking automation failed and you just want to fixup a couple of errors, without altering anything else.

Using a .23 build of stgit I could reproduce this every time just by running stg pull:

$ stg pull
Popping all applied patches ... done
Pulling from "origin"
Already up to date.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "C:\src\Python27\lib\atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "C:\src\Python27\lib\site-packages\stgit\lib\git\repository.py", line 122, in _shutdown
    os.kill(self._proc.pid(), signal.SIGTERM)
WindowsError: [Error 5] Access is denied
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\src\Python27\lib\atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "C:\src\Python27\lib\site-packages\stgit\lib\git\repository.py", line 122, in _shutdown
    os.kill(self._proc.pid(), signal.SIGTERM)
WindowsError: [Error 5] Access is denied

I fixed this with the following update:

    def _shutdown(self):
        if self._proc:
            self._proc.stdin.close()
            try:
                os.kill(self._proc.pid(), signal.SIGTERM)
            except OSError:
                pass
            self._proc.wait()

I believe what's happening here is that the PID is no longer valid and we're trying to kill an already-dead process.

Richard argues that most elisp packages derive from Emacs. Following that logic they have to be releases under a compatible license. I do not really agree with the former assessment, but acknowledge that it is not without merit.

As a result I cannot continue to distribute packages that use a license that is not compatible with the third version of the GPL. Unfortunately GPLv2 is not compatible with GPLv3. Please consider updating the license of the library. If you do, then please add this permission statement to the library header:

;; This file is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3, or (at your option)
;; any later version.

;; This file is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <http://www.gnu.org/licenses/>.

Thanks!

I decided to replace the EPEL 7 version of stgit on my RHEL 7 system with the latest upstream stgit. Things mostly work, but this happened this morning:

[cel@klimt linux]$ stg edit --sign
git: 'interpret-trailers' is not a git command. See 'git --help'.
stg edit: git failed with code 1
[cel@klimt linux]$ stg version
Stacked GIT 0.22
git version 1.8.3.1
Python version 2.7.5 (default, Apr 11 2018, 17:41:36) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)]
[cel@klimt linux]$

A newer version of git is not available through RHEL 7 channels, but I can build and use an upstream copy on this system.

When using the "-a" and "-e" options together on "stg mail", an exception occurs. Using either alone, or specifying all the patches in the series using a range expression (ie, xxx..yyy) does not cause a problem.

[cel@klimt linux]$ stg mail -e -a -vv1 --to=nfs --to=rdma
Checking the validity of the patches ... done
Error: Unhandled exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/stgit/main.py", line 193, in _main
    ret = command.func(parser, options, args)
  File "/usr/lib/python2.7/site-packages/stgit/commands/mail.py", line 816, in func
    msg_id = __send_message('cover', tmpl, options, patches)
  File "/usr/lib/python2.7/site-packages/stgit/commands/mail.py", line 368, in __send_message
    'patch': (__build_message, 'patch "%s"' % args[0]),
TypeError: not all arguments converted during string formatting
[cel@klimt linux]$ stg mail -e -a -vv1 --to=nfs --to=rdma
Checking the validity of the patches ... done
Error: Unhandled exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/stgit/main.py", line 195, in _main
    ret = command.func(parser, options, args)
  File "/usr/lib/python2.7/site-packages/stgit/commands/mail.py", line 877, in func
    msg_id = __send_message('cover', tmpl, options, patches)
  File "/usr/lib/python2.7/site-packages/stgit/commands/mail.py", line 427, in __send_message
    'patch': (__build_message, 'patch "%s"' % args[0]),
TypeError: not all arguments converted during string formatting
[cel@klimt linux]$ stg version
Stacked GIT 0.22-19-gca7d-dirty
git version 2.25.2
Python version 2.7.5 (default, Apr 11 2018, 17:41:36) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)]
[cel@klimt linux]$

According to https://stackoverflow.com/questions/18053500/typeerror-not-all-arguments-converted-during-string-formatting-python, the % operator in the following code is incorrect or deprecated:

363 def __send_message(type, tmpl, options, *args):
364     """Message sending dispatcher.
365     """
366     (build, outstr) = {
367         'cover': (__build_cover, 'the cover message'),
368         'patch': (__build_message, 'patch "%s"' % args[0]),
369     }[type]

When rewritten thusly:

363 def __send_message(type, tmpl, options, *args):
364     """Message sending dispatcher.
365     """
366     (build, outstr) = {
367         'cover': (__build_cover, 'the cover message'),
368         'patch': (__build_message, 'patch "{0}"'.format(args[0])),
369     }[type]

Then "stg mail -a -e" works as expected.

When using stg squash and editing the patch description, I'd like stg squash to preserve the text below the --- line, because I keep a list of changes between the patch's published revisions there.
Currently I need to replace --- with something else before I finish editing in stg squash and later change it back with stg edit, but it would be more convenient if I could pass an option to stg squash that would cause it to perserve the text.

Sometimes, I want to stop using stgit on a branch. The tutorial suggests that stg commit --all gets rid of metadata but it doesn't seem to be enough. For a branch foo, even if you do that, perform stg log --clear, git branch -D foo.stgit, and git branch -D fooyou still have cruft lying around. To see this, try creating branchgit co -b fooagain and note that it complains that it is already initialized when you runstg init`.

So what are the full steps to "uninit" a branch fully on which you have run stg init ?

There's been a lot of work on StGit since the last release, including support for Python 3. Is there a timeline on when we might see the next release? Are there current blockers?

I couldn't work out how to publish to a remote branch, (though maybe this is user error).

My main use case would be to publish to a github/gitlab/whatever branch that has a pull request open. I presume right now you need to stg publish then do a git push. Is that correct?

This has happened in a couple of repos. I made a very large commit with a number of files (e.g. deleting an entire repo) and then hang on stg refresh. Every other command on that branch is now broken, e.g. stg push or stg delete -t. Only reproduced on Windows right now.

Hello,

When rebasing a branch with local commits that lead to conflicts stgit will throw the following backtrace and crash:

% stg rebase upstream/staging
Checking for changes in the working directory ... done
Popping all applied patches ... done
Rebasing to "upstream/staging" ... done
Pushing patch "func_fn" ... done (empty patch)
Pushing patch "devfn_sbdf" ... done (empty patch)
Pushing patch "pdev_union" ... done (empty patch)
Pushing patch "pci_sbdf" ...
  CONFLICT (content): Merge conflict in xen/include/xen/pci.h
Error: The merge failed during "push".
       Revert the operation with "stg undo".
xen/include/xen/pci.h: unmerged (b03927cd28d85c2fe9325e9f8912c66990e3473d)
xen/include/xen/pci.h: unmerged (04a9f46cc32ffc56452efa022b03ea19d6e0f06a)
xen/include/xen/pci.h: unmerged (12f1cea19bc50738b64fac172cbbe6f41894b25a)
fatal: git-write-tree: error building trees
Traceback (most recent call last):
  File "/usr/local/bin/stg", line 47, in <module>
    main()
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/main.py", line 213, in main
    _main()
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/main.py", line 192, in _main
    directory.write_log(cmd)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/commands/common.py", line 599, in write_log
    log.compat_log_entry(msg)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/log.py", line 383, in compat_log_entry
    log_entry(Fakestack(stack), msg)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/log.py", line 336, in log_entry
    new_log = LogEntry.from_stack(last_log, stack, msg)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/log.py", line 191, in from_stack
    for pn in stack.patchorder.all),
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/log.py", line 191, in <genexpr>
    for pn in stack.patchorder.all),
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/log.py", line 366, in get
    return stack.patches.get(pn)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/stack.py", line 189, in get
    return self.__patches[name]
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/git.py", line 569, in __getitem__
    self.__objects[name] = self.__create(name)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/stack.py", line 179, in create_patch
    p.commit # raise exception if the patch doesn't exist
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/stack.py", line 34, in commit
    return self.__stack.repository.refs.get(self.__ref)
  File "/usr/local/Cellar/stgit/0.19/lib/python2.7/site-packages/stgit/lib/git.py", line 532, in get
    return self.__repository.get_commit(self.__refs[ref])
KeyError: u'refs/patches/pci_sbdf_t/add_fn_field'

Sometimes I run into the exception shown below. Unfortunately this happens in a rather large project and I have not yet been able to find out which file causes this. However this error should of course not happen. After the exception has been shown, I find my commit in 'refresh-temp'. I am unable to squash the commit with the one I had originally wanted to update with the same error.

It is worthwhile mentioning that this problem has started to occur after upgrading from stg 0.17 to stg 0.18. It has happened on different Linux systems with different Python versions (currently I am using Python 2.7.14 on a Fedora 27 system). Temporarily downgrading to stg 0.17 helps in such a situation, I can then cleanly squash, refresh or whatever it is I want.

    Error: Unhandled exception:
    Traceback (most recent call last):
      File "/usr/lib/python2.7/site-packages/stgit/main.py", line 194, in _main
        ret = command.func(parser, options, args)
      File "/usr/lib/python2.7/site-packages/stgit/commands/refresh.py", line 267, in func
        stack, patch_name, paths, temp_index = path_limiting)
      File "/usr/lib/python2.7/site-packages/stgit/commands/refresh.py", line 140, in make_temp_patch
        print_current_patch = False), temp_name
      File "/usr/lib/python2.7/site-packages/stgit/lib/transaction.py", line 272, in run
        write(self.__msg)
      File "/usr/lib/python2.7/site-packages/stgit/lib/transaction.py", line 269, in write
        log.log_entry(self.__stack, msg)
      File "/usr/lib/python2.7/site-packages/stgit/lib/log.py", line 341, in log_entry
        new_log.write_commit()
      File "/usr/lib/python2.7/site-packages/stgit/lib/log.py", line 296, in write_commit
        tree = self.__tree(metadata)
      File "/usr/lib/python2.7/site-packages/stgit/lib/log.py", line 290, in __tree
        patches = dict((pn, pf(c)) for pn, c in self.patches.items())
      File "/usr/lib/python2.7/site-packages/stgit/lib/log.py", line 290, in <genexpr>
        patches = dict((pn, pf(c)) for pn, c in self.patches.items())
      File "/usr/lib/python2.7/site-packages/stgit/lib/log.py", line 288, in pf
        r = patch_file(self.__repo, c.data)
      File "/usr/lib/python2.7/site-packages/stgit/lib/log.py", line 132, in patch_file
        repo.diff_tree(cd.parent.data.tree, cd.tree, ['-M']).strip(),
      File "/usr/lib/python2.7/site-packages/stgit/lib/git.py", line 832, in diff_tree
        t1.sha1, t2.sha1)
      File "/usr/lib/python2.7/site-packages/stgit/lib/git.py", line 676, in diff_trees
        s = data.decode('utf-8')
      File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
        return codecs.utf_8_decode(input, errors, True)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 1356: invalid start byte

such as stg new feature/core has no error.

but stg refresh will cause error

When using stg import -M path/to/mail.mbox, the output cannot be redirected to file:

jhuston@probe (review) ~/s/qemu> stg import -M etc.mbox > output.txt
jhuston@probe (review) ~/s/qemu> cat output.txt
jhuston@probe (review) ~/s/qemu>

The file does have valid patches in it, though:

jhuston@probe (review) ~/s/qemu> stg import -M etc.mbox
Checking for changes in the working directory ... done
Importing patch "iotests-fix-_filter_img_create" ... done
Importing patch "vmdk-use-bdrv_dirname-for" ... done
Importing patch "iotests-keep-testing-broken" ... done
Importing patch "vmdk-reject-invalid-compressed" ... done
Importing patch "iotests-disable-broken" ... done
Importing patch "iotests-disable-110-for-vmdk" ... done
Importing patch "iotests-disable-126-for-flat" ... done
Now at patch "iotests-disable-126-for-flat"

And the command will succeed with redirected output, but the output isn't displayed on screen OR in the file.

I guess this is from: from stgit.out import out, which is a MessagePrinter();
which makes this look unfortunately intentional:

if file or sys.stdout.isatty():
        self.__out = self.__stdout
    else:
        self.__out = Output(None)

The reason I would like this to work is to be able to script using stgit in other tools, and the same isatty check prevents me from getting output via e.g. python's subprocess call or other scripts.

Empty commit messages can occur for example with stg import /some/patch.diff.

Then. from another branch:

$ stg pick 2ea43760dc34
Checking for changes in the working directory ... done                                               
Importing commit 2ea43760dc3491e79b67e50eefb3ad13faed6d9b ... 
  Pushing patch "None" ... warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 1699 and retry the command.
done (conflict)                                                                                           
Error: 1 merge conflict(s)                
       CONFLICT (content): Merge conflict in Kconfig                                                                                                                                                                 
Error: Unhandled exception:         
Traceback (most recent call last):                                                                        
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/main.py", line 202, in _main
    ret = command.func(parser, options, args)                                                             
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/commands/pick.py", line 314, in func
    stack, ref_stack, iw, commit, patchname, options                                                      
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/commands/pick.py", line 242, in __pick_commit
    retval = trans.run(iw, print_current_patch=False)                                                                                                                                                                
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/transaction.py", line 311, in run
    write(self.__msg + ' (CONFLICT)')                                                                     
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/transaction.py", line 301, in write
    self.__stack.patches.new(pn, commit, msg)                                                                                                                                                                        
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/stack.py", line 231, in new
    p.set_commit(commit, msg)                                                                                                                                                                                        
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/stack.py", line 112, in set_commit
    self.__write_compat_files(commit, msg)                                                                
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/stack.py", line 82, in __write_compat_files                            
    write('authname', d.author.name)
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/stack.py", line 61, in write                                                                                                                       
    fn = os.path.join(self.__compat_dir, name)                                                                                                                                                                       
  File "/home/leho/.local/lib64/python3.6/site-packages/stgit/lib/stack.py", line 56, in __compat_dir
    return os.path.join(self.__stack.directory, 'patches', self.__name)                                                                                                                                              
  File "/usr/lib/python-exec/python3.6/../../../lib64/python3.6/posixpath.py", line 94, in join                                                                                                                      
    genericpath._check_arg_types('join', a, *p)                                                                                                                                                                      
  File "/usr/lib/python-exec/python3.6/../../../lib64/python3.6/genericpath.py", line 149, in _check_arg_types
    (funcname, s.__class__.__name__)) from None   
TypeError: join() argument must be str or bytes, not 'NoneType'

$ python --version
Python 2.6.6
$ git describe
v0.18-90-ga56e7126a7c5
$ make
python setup.py build
Traceback (most recent call last):
File "setup.py", line 10, in
from stgit import version
File "/home/alwillia/Work/stgit.git/stgit/version.py", line 8, in
from stgit import run, utils
File "/home/alwillia/Work/stgit.git/stgit/run.py", line 96
for k, v in self.__env.items()}
^
SyntaxError: invalid syntax
make: *** [all] Error 1

Code originates from:

commit 3bb4bb8
Author: Peter Grayson [email protected]
Date: Sun Sep 24 22:38:32 2017 -0400

Unicode support for Run()

It would be great if I could install using pip

[cel@klimt linux]$ stg version
Stacked GIT 0.22
git version 2.26.0.rc1.11.g30e9940356dc
Python version 2.7.5 (default, Apr 11 2018, 17:41:36)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)]
[cel@klimt linux]$

After the cover letter is constructed, shortlog shows the short description for only the last patch in the mailed series, and the cover letter's diffstat is performed on the entire branch (or perhaps all applied patches?) instead of only the requested patches.

I'm guessing that 5b99acc ("Migrate stg mail to new lib infrastructure") is the cause of both problems.

The shortlog issue appears to be that "git log" does not understand multiple commits on its command line. It outputs a log entry only for the last "commit ^commit" pair. Changing the __shortlog function to use "git show" instead of "git log" fixes the problem, and then the for loop needs to be changed to process the patch list in reverse order.

For the diffstat issue, I'm not smart enough to figure out a solution, but this new bit of code looks incorrect:

        'diffstat': repository.diff_tree(
            stack.base.data.tree,
            stack.top.data.tree,
            diff_opts=options.diff_flags,
            stat=True,

The diffed trees need to be derived from the patches that are being mailed, not from the base and top of the current stack.

Stacked GIT 0.22
Attempting "stg import -m " when the subject of the patch contains a colon followed by a space results in:

Error: Unhandled exception:
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/stgit/main.py", line 195, in _main
    ret = command.func(parser, options, args)
  File "/usr/lib/python3.8/site-packages/stgit/commands/imprt.py", line 498, in func
    __import_mail(filename, options)
  File "/usr/lib/python3.8/site-packages/stgit/commands/imprt.py", line 355, in __import_mail
    __import_mail_path(mail_path, filename, options)
  File "/usr/lib/python3.8/site-packages/stgit/commands/imprt.py", line 394, in __import_mail_path
    mailinfo = dict(line.split(b': ') for line in mailinfo_lines if line)
ValueError: dictionary update sequence element #2 has length 3; 2 is required

This patch fixes the problem:

diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index aa4a27238cca..6a7213f391aa 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -391,7 +391,7 @@ def __import_mail_path(mail_path, filename, options):
         'git', 'mailinfo', msg_path, patch_path
     ).encoding(None).decoding(None).raw_input(mail).output_lines(b'\n')
 
-    mailinfo = dict(line.split(b': ') for line in mailinfo_lines if line)
+    mailinfo = dict(line.split(b': ', 1) for line in mailinfo_lines if line)
 
     with open(msg_path, 'rb') as f:
         msg_body = f.read()

while playing with patch queue for kernel, i realized, that some patches already landed in mainline kernel.
using 'patch -R -p1 -i patches/some.patch' i verified, that patch was completely accepted, so i commented it out.
it would be nice to have option for import command to check using revert if patch is alreay in current code base

--reject is nice, but I often like to try --3way first.

(Use case is using stg to load patchsets from QEMU mailing list as a stack for review purposes. Sometimes the patches are slightly out of date and --3way or --reject is needed to get the patches loaded.)

I could likely write a patch to just "plumb" a --3way option through, but I was wondering if a more general purpose solution for passing "arbitrary" arguments to git apply would be wanted instead, or if "the stupid approach" here was actually best. It might also be nice, because mbox files can have multiple patches within them, to allow the --interactive mode, too.

Please advise!
--js

The current setup.py tries to read the version it is installing from the git repository. This, naturally, does not work when installing from the tarball. As a consequence, stgit reports 'unkown-version'.

Fix: Add the correct builtin_version.py to the tarball and remove the call to write_builtin_version from the released setup.py.

There are cases where I would like to stg import a GNU patch, but would like to update an existing patch rather than creating a new one.

Currently the closest I managed to get to this is

stg edit -d -f diff.patch PATCH_NAME

However this replaces the contents of the patch with the diff overwriting the message. Would be nice to be able to replace just the diff portion of the patch.

Update:

I have attempted to implement this. Initially I tried to wedge this into edit command, but I feel like a new command is a better approach for this one. So far I have so far opted for this:

stg replace [ -p PATCH_NAME ] [ --import-description ] diff.patch

Is there a way to get stg rebase to remove empty patches automatically?

The reason the patches are empty as they were merged upstream.

Hi. Homebrew maintainer here.

The checksum of your 0.21 archive changed. Did somebody do something malicious with your account and hijacked your artifacts?

==> Downloading https://github.com/ctmarinas/stgit/archive/v0.21.tar.gz
Error: An exception occurred within a child process:
  ChecksumMismatchError: SHA256 mismatch
Expected: ba1ccbbc15beccc4648ae3b3a198693be7e6b1b1e330f45605654d56095dac0d
  Actual: 67a5b93c832e8ce1349afbddca93d834fc6f78ae8fd9e45c99206dc87eb3440c

For reference: https://github.com/Homebrew/linuxbrew-core/pull/19745

stg mail has the option of editing a cover letter and/or reading it in from a file, but if I'm working on several different series in parallel (and sending new iterations of each one), I'd like to be able to store a cover letter with the branch that I can just edit and update every time I send a new version. It seems like it would be pretty straightforward to have stg store it in .git/patches/$branch, and maybe edit it using a command like stg cover or something. That would solve the biggest missing piece of functionality wrt stackgit in my workflow.