patch, 17 partsSeries short description

The following series an emacs interface to stgit patch stacks. It shows a buffer with the the output of "stg series" and allows you to do some common operations on it, such as push/pop, commit/uncommit, edit, rename, repair, and coalesce.

The coalesce command obviosly requires the kha/experimental branch. The edit command requires the edit fixes in kha/safe.

---

David Kågedal (10):
      Emacs mode: coalesce command
      Emacs mode: Add mark command
      Emacs mode: Added stgit-new
      Emacs mode: added fontification
      Emacs mode: Add stgit-edit command
      Emacs mode: added stgit-commit and stgit-uncommit
      Emacs mode: add stgit-repair
      Emacs mode: Bind n and p
      Emacs mode: Improve the output buffer state
      Add an StGit mode for emacs

Karl Hasselström (7):
      Emacs mode: show patches' short description
      Emacs mode: Bind "G" to "stg goto"
      Emacs mode: Let "P" push or pop patch at point
      Emacs mode: push/pop next patch, not patch at point
      Emacs mode: Makefile for building stgit.el
      Emacs mode: Add an explanatory header
      Emacs mode: Show keybindings when user presses "h" or "?"

 contrib/Makefile |   19 +++
 contrib/stgit.el |  377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 396 insertions(+), 0 deletions(-)
 create mode 100644 contrib/Makefile
 create mode 100644 contrib/stgit.el

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---

 contrib/stgit.el |  141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 141 insertions(+), 0 deletions(-)
 create mode 100644 contrib/stgit.el

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

These are the same keys the git emacs mode uses.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

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

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

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

Shamelessly stolen from git's contrib/emacs/Makefile.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/Makefile |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 contrib/Makefile

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

The three operations we should have are:

  * Pop the topmost applied patch, no matter where point is.

  * Push the first unapplied patch, no matter where point is.

  * Push/pop the patch at point, depending on whether it's currently
    applied.

This patch makes "<" and ">" do the first two operations. The third is coming in a later patch.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   22 ++++++++--------------
 1 files changed, 8 insertions(+), 14 deletions(-)

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

When the user presses "P", push or pop the patch at point depending on whether it's applied or unapplied.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

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

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

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

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

Make the output buffer have the correct default-directory, and make it read-only and unmodified.

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   44 +++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 43 insertions(+), 1 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   76 +++++++++++++++++++++++++++++++++++++++++-------------
 1 files changed, 57 insertions(+), 19 deletions(-)

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---

 contrib/stgit.el |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

On 14/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:

That's really cool stuff! Thanks.

I'll start this week merging patches from kha/experimental (I'm a bit slow because of the Christmas activities).

On 2007-12-17 11:09:06 +0000, Catalin Marinas wrote:

Yes, incredibly useful.

I've put this series in kha/safe -- except for the mark and coalesce patches, which are at the tip of kha/experimental. The latter because it obviously has to be, the former because the latter is the only thing using it and it's _extremely annoying_ to be able to mark patches but not, say, push or pop all marked patches.

My stack is now 53 patches deep, so running the test suite on every patch is getting time consuming -- I'd guess about two hours on my poor laptop. And I plan to sleep while that runs, so I won't actually push this until tomorrow.

Be careful about merging past the "goto" patch -- I'm pretty sure it breaks when called from a subdirectory, and I don't have time to fix that right now. (It should be a clean fix, though -- just adjust the cwd for precisely those git subprocesses that need it, which is very few. I think.)

If you like, I can advance "safe" to include as many patches as I think you should merge right now.

On 2007-12-17 23:48:12 +0100, Karl Hasselström wrote:

And here it is:

The following changes since commit 5be69cd8d89bd89be31364e9c0fd9e947b6ef644:
  Karl Hasselström (1):
        Name the exit codes to improve legibility

are available in the git repository at:

  git://repo.or.cz/stgit/kha.git safe

David Kågedal (17):
      Add an StGit mode for emacs
      Emacs mode: Improve the output buffer state
      Emacs mode: Bind n and p
      Emacs mode: add stgit-repair
      Emacs mode: added stgit-commit and stgit-uncommit
      Emacs mode: Add stgit-edit command
      Emacs mode: added fontification
      Emacs mode: Added stgit-new
      Check bottom and invariants
      Remove the 'bottom' field
      Remove the 'top' field
      Split git.merge into two functions
      Leave working dir and index alone after failed (conflicting) push
      Added a test case to check what happens when push finds a conflict
      Simplify merge_recursive
      Use the output from merge-recursive to list conflicts
      Ask git about unmerged files

Karl Hasselström (24):
      Emacs mode: Show keybindings when user presses "h" or "?"
      Emacs mode: Add an explanatory header
      Emacs mode: Makefile for building stgit.el
      Emacs mode: push/pop next patch, not patch at point
      Emacs mode: Let "P" push or pop patch at point
      Emacs mode: Bind "G" to "stg goto"
      Emacs mode: show patches' short description
      Write removed fields for backwards compatibility
      Nicer conflict markers
      Better error message if merge fails
      Fix "stg resolved" to work with new conflict representation
      Refactoring: pass more than one file to resolved()
      We keep the different stages of a conflict in the index now
      "stg status --reset" is not needed anymore
      Remove "stg add"
      Remove "stg rm"
      Remove "stg cp"
      Remove "stg resolved"
      New StGit core infrastructure: repository operations
      Write metadata files used by the old infrastructure
      Upgrade older stacks to newest version
      Let "stg clean" use the new infrastructure
      Add "stg coalesce"
      Let "stg applied" and "stg unapplied" use the new infrastructure

 Documentation/stg-cp.txt      |   63 --------
 Documentation/stg.txt         |    2 -
 Documentation/tutorial.txt    |   31 +++--
 contrib/Makefile              |   19 +++
 contrib/stgit-completion.bash |    4 +-
 contrib/stgit.el              |  318 +++++++++++++++++++++++++++++++++++++++++
 examples/gitconfig            |   19 +---
 setup.py                      |    2 +-
 stgit/commands/add.py         |   44 ------
 stgit/commands/applied.py     |   27 ++--
 stgit/commands/clean.py       |   68 +++++-----
 stgit/commands/coalesce.py    |   84 +++++++++++
 stgit/commands/common.py      |   39 +++---
 stgit/commands/copy.py        |   45 ------
 stgit/commands/pick.py        |    2 +-
 stgit/commands/resolved.py    |   94 ------------
 stgit/commands/rm.py          |   48 ------
 stgit/commands/status.py      |   31 ++---
 stgit/commands/sync.py        |    1 -
 stgit/commands/unapplied.py   |   23 ++--
 stgit/config.py               |    1 -
 stgit/git.py                  |   75 ++++++----
 stgit/gitmergeonefile.py      |   97 +------------
 stgit/lib/__init__.py         |   18 +++
 stgit/lib/git.py              |  260 +++++++++++++++++++++++++++++++++
 stgit/lib/stack.py            |  172 ++++++++++++++++++++++
 stgit/lib/stackupgrade.py     |   96 ++++++++++++
 stgit/lib/transaction.py      |   79 ++++++++++
 stgit/main.py                 |   10 +-
 stgit/run.py                  |    3 +
 stgit/stack.py                |  156 ++++----------------
 stgit/utils.py                |   24 +++
 t/t0002-status.sh             |   15 +-
 t/t1200-push-modified.sh      |    2 +-
 t/t1202-push-undo.sh          |    6 +-
 t/t1203-push-conflict.sh      |   70 +++++++++
 t/t1204-pop-keep.sh           |    2 +-
 t/t1205-push-subdir.sh        |    8 +-
 t/t1300-uncommit.sh           |    4 +-
 t/t1301-repair.sh             |    2 +-
 t/t1400-patch-history.sh      |    4 +-
 t/t1500-float.sh              |   14 +-
 t/t1600-delete-one.sh         |   12 +-
 t/t1601-delete-many.sh        |    2 +-
 t/t1700-goto-top.sh           |    2 +-
 t/t2000-sync.sh               |   12 +-
 t/t2100-pull-policy-fetch.sh  |    4 +-
 t/t2101-pull-policy-pull.sh   |    4 +-
 t/t2102-pull-policy-rebase.sh |    4 +-
 t/t2300-refresh-subdir.sh     |    2 +-
 t/t2600-coalesce.sh           |   31 ++++
 51 files changed, 1420 insertions(+), 735 deletions(-)
 delete mode 100644 Documentation/stg-cp.txt
 create mode 100644 contrib/Makefile
 create mode 100644 contrib/stgit.el
 delete mode 100644 stgit/commands/add.py
 create mode 100644 stgit/commands/coalesce.py
 delete mode 100644 stgit/commands/copy.py
 delete mode 100644 stgit/commands/resolved.py
 delete mode 100644 stgit/commands/rm.py
 create mode 100644 stgit/lib/__init__.py
 create mode 100644 stgit/lib/git.py
 create mode 100644 stgit/lib/stack.py
 create mode 100644 stgit/lib/stackupgrade.py
 create mode 100644 stgit/lib/transaction.py
 create mode 100755 t/t1203-push-conflict.sh
 create mode 100755 t/t2600-coalesce.sh

                                 -+-

The following changes since commit 1189271615e7157ca3da3288a9ce3c9bcaeb2d5f:
  Karl Hasselström (1):
        Let "stg applied" and "stg unapplied" use the new infrastructure

are available in the git repository at:

  git://repo.or.cz/stgit/kha.git experimental

David Kågedal (2):
      Emacs mode: Add mark command
      Emacs mode: coalesce command

Karl Hasselström (10):
      Teach the new infrastructure about the index and worktree
      Let "stg clean" use the new transaction primitives
      Let "stg goto" use the new infrastructure
      Convert "stg uncommit" to the new infrastructure
      New infrastructure: Make sure that the branch is initialized
      Expose transaction abort function
      stg coalesce: Support --file and --save-template
      Set exit code to 3 on merge conflict
      Convert "stg commit" to new infrastructure
      Make "stg commit" fancier

 contrib/stgit.el           |   97 +++++++++++++++++++-----
 stgit/commands/clean.py    |   35 ++-------
 stgit/commands/coalesce.py |  118 +++++++++++++++++++----------
 stgit/commands/commit.py   |  111 +++++++++++++++++----------
 stgit/commands/goto.py     |   52 +++++---------
 stgit/commands/uncommit.py |   81 +++++++++-----------
 stgit/lib/git.py           |  127 +++++++++++++++++++++++++++++++
 stgit/lib/stack.py         |   10 ++-
 stgit/lib/stackupgrade.py  |    6 +-
 stgit/lib/transaction.py   |  178 ++++++++++++++++++++++++++++++++++++++------
 stgit/main.py              |    4 +-
 stgit/utils.py             |    1 +
 t/t1300-uncommit.sh        |   12 ++--
 13 files changed, 588 insertions(+), 244 deletions(-)

Thanks again for maintaining these branches.

On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:

[...]

I'll drop git.merge() entirely since it is only used by the 'sync' command due to the performance issues I had in the past with rename detection in git-merge-recursive. Hopefully, these are gone now.

I'll try to fix the automatic invocation of the interactive merger in case of conflicts (it is only present in git.merge()).

For some reason, the interactive resolving keeps invoking the merger. I'll have a look.

I would keep this as an alias for 'git reset --hard' (see below as well).

I plan to add a generic command for these kind of aliases. The reason is that I don't really like mixing GIT and StGIT commands (I think at some point I'll get confused and try to run stg commands with git).

I'd like to keep this command. git-mergetool doesn't support the tool I use (emacs + ediff and more stgit-specific file extensions like current, patch etc.). I also don't find 'git add' to be meaningful for marking a conflict as solved.

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

I also would like to have this command kept (and shown in 'stg help'!). Contrary to 'git add' it can check and add to index / update index only for files with conflict; we have -r (ancestor|current|patched) to choose one side, and we could add --check to check if there are no conflict markers with files (useful with -a/--all).

On 18/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:

I'd also like to re-add the stgit.keeporig option and additional functionality so that the *.{ancestor,current,patched} can be left in the working tree. Some people might use them when manually fixing conflicts (I have a look at them from time to time when the emacs + ediff shows a hard to understand conflict).

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

Since all the information is in git, it is of course easy to recreate it. But the important question to ask is: how do you use these extra files? git.el provides a way to diff against both parent versions, and maybe that is actually what you need.

I don't mind that you want these files, but they are mostly clutter to me.

David Kågedal <davidk@lysator.liu.se> writes:

Note that I'm talking about the kha/experimental branch here. The point of my patches there are to make sure that the git index is left in the unmerged state so that normal git tools can be used. This means that git diff-files -2 and -3 does what you want.

On 19/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:

You can set stgit.keeporig to 'no' if you don't want these files.

For people not using emacs + git.el, the files might be useful. As you said, you could use 'git diff -2/-3' but, in various occasions I just wanted to copy a block of code from one of the checked-out stages. Without this feature, I would have to use plain git and remember what stage corresponds to my patch.

Note that there are other users (apart from me) that use StGIT almost exclusively. I really don't like forcing them to use more and more plain git commands (at some point, they might even discover 'git rebase -i' to be good enough and give up on StGIT :-)).

On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:

This too sounds like stuff that could profitably be added to "git add". Except for the ancestor/current/patched words, it is not specific to patch stacks, so the implementation should be in git and not in stg.

IMHO, of course. :-)

On Wed, 19 Dec 2007, Karl Hasselström wrote:

No it cannot, at least the '-r (ancestor|current|patched)' part for resetting file to given version, even if we change the wording to ancestor, ours and theirs. The git-add command is about adding contents, which updates index, which almost as a intended side-effect clears merge state, i.e. stages; and not about resetting to stage.

Besides with "stg resolved" you can update index _only_ for files which were in the conflict, also for -a/--all, and not all the files not only those which were in the conflict like "git add -u" does.

"stg resolved --check" could happily ignore things that only look like conflict markers, but must have been intended, because they are in files not in conflict.

Unless you are talking about adding "resolve"/"resolved" command to git-core, as a porcelain wrapper around git-update-index, like "git add"...

P.S. I have just noticed that 'git-checkout' [<tree-ish>] <paths>... form of operation is not documented; you can derive what it do only from examples.

On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:

  git checkout-index --stage=1|2|3 <filename>

does what you want. But "git cat-file" knows this handy syntax for getting at particular index stages:

  :stage:<filename>

It would be very convenient to be able to do

  git checkout :stage:<filename>

but it doesn't seem to work currently. Does anyone know the "best" way of manually checking out a particular index stage in git?

This sounds like a straightforward addition to "git add".

git knows about conflicting files too.

Yes, that's what I want. You and others like what "stg resolved" does, but I don't want it in StGit because it's a generic git enhancement that has nothing to with patch stacks. People who don't use StGit would presumably like it as well.

On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:

The --reset option would never be added to git, at least not with the same name for arguments since git doesn't manage patches. As I said, I would have to remember what stage my 'patched' file is in.

Karl Hasselström wrote:

I always forget which stage is which. It would be nice if git-checkout-index implemented human-friendly names, just like git-diff-files has --base, --ours, --theirs, i.e. if it would be possible to write

  git checkout-index --stage=base|ours|theirs <filename>

and perhaps even

  :base|ours|theirs:<filename>.

(but there is a problem with files containing ':'...).

It's a pity it doesn't work. Or if not this, then perhaps

  git checkout --stage=ours -- <filename>

You mean adding another option to git-add, similar to '-u' option, but updating only the files which were (are) in merge conflict; '-c'/'-r'/'-s' perhaps? This would be replacement for "stg resolved --all", wouldn't it (and with filename replacement for "stg resolved <filename>", of course)?

P.S. Sidenote: it would be nice if git-mergetool was updated to understand StGIT style interactive 2-way and 3-way merge configuration, and not offer only limited choice of pre-defined interactive merge tools (although pre-defined are nice, too).

On 19/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:

This gets even more confusing with StGIT. For plain git, after a git merge or pull conflict, 'theirs' is stage 3. With StGIT, we first advance the base of the stack and merge the patches onto it, in which case the 'patched' (which I would normally call 'ours' rather than 'theirs') is 3.

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

True. And the same problem obviously exists for "git rebase".

On 2007-12-19 17:23:27 +0100, Jakub Narebski wrote:

<ref>:<path> is already accepted, so I don't think this would be much worse.

And yes, I agree that the base/ours/theirs aliases are nice, and should be accepted by at least the porcelain commands.

Yes. That _is_ the operation you want, isn't it?

Yes. Though with a filename argument, you wouldn't need the new flag.

On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:

How should these aliases be presented in the documentation etc.? I suggest making it very clear that they are only aliases.

So why have a separate command instead of fixing git-mergetool?

So maybe let "stg resolved" be an alias for "git add"?

This is all our usual disagreement: You want stg to be a fairly standalone tool, and I want it to be a tool to use side by side with git. The problem I see with your approach is that stg risks ending up like Cogito: it'll provide inspiration for improving git, but will itself become obsolete because of the simple fact that git has so much more development manpower. I think it'd be more productive to let stg do one thing -- patch stacks -- and do it well, and rely on git for everything else.

Of course, if stuff like "stg add" and "stg resolved" are really implemented as three-line wrappers around git commands, we don't have that problem.

On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:

Yes, 'stg help' should clearly mark them as aliases of git commands. I'm not sure how I'll do this yet. For the 'status --reset', I'll keep it if we have a separate 'resolved' command.

In the past, StGIT only used the core git functionality and stayed away from the porcelain scripts. We now started to use some of the built-in commands more and more and I think it is fine but the git scripts look more volatile to me than the C code (look at the many variants the git merging went through, from shell scripts to python and only now seems to be stabilised with the recursive merge as a built-in command).

Adding the functionality I need to git-mergetool would also mean always using the latest GIT with StGIT. Anyway, if you like git-mergetool, I think you can easily change the StGIT configuration to

It's not a simple alias, if you use 'stg resolved -a'. Now, if we allow stgit.keeporig, it needs even more functionality.

If GIT would have all the functionality I need for my workflow, I wouldn't mind giving up StGIT (I started StGIT because I needed easier patch management on top of GIT and modifying Quilt would've been too intrusive).

In principle, yes, but I have some minor problems with the UI of GIT (like resolved == add). I think there is also a fundamental difference between 'git commit' and 'stg refresh'. The former requires explicit marking of the files to commit (or use the -a option) while the latter always adds all the local changes to the current patch. Maybe GIT users are more used to running 'git add' after fixing a conflict but I use StGIT almost exclusively.

For add/rm/cp, they should just be a generic wrapper which doesn't even parse the command line options. That's not the case with 'resolved'.

On 2007-12-19 10:09:40 +0000, Catalin Marinas wrote:

?

Hmm? Have we started to use more porcelain lately?

It wouldn't keep being the latest git version, though.

I don't use interactive merging at all. What I wanted was to get rid of StGit's own interactive merging.

Hmm, yes.

(I still don't quite like it, because I think that if there's anything that "stg resolved" does that "git add" can't do, then "git add" should learn to do it. But until it has learned it, it's a hypothetical argument.)

So you want StGit to do two things: patch stacks, and fix some git UI warts. Hey, I can live with that. :-) But I firmly believe that the wart fixing parts of StGit should be (1) optional, so that the same job can easily be done with just git; and (2) as thin as possible, to make them easy to explain in terms of git, and cheap to maintain.

OK.

No, I see.

On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:

It needs to call the resolved_all to remove checked-out stages if stgit.keeporig == 'yes'. Maybe it could also do some sanity check if HEAD != top. With 'git reset --hard', people might easily add an argument and break the whole stack.

I think Yann was complaining about using git-show since it looks more like a porcelain command.

Yes, but at least initially it should be pretty recent.

I use it quite often and I even invoke it automatically (stgit.autoimerge). I'll push some patches tonight together with most of your safe branch and we can alter them afterwards.

Unless you need the keeporig functionality, you can now always use plain git for solving merges, add/rm/cp, 'reset --hard' etc. At some point, we could make it safe for 'git rebase' but I think we need the DAG patches.

As I said, if you don't need keeporig, just use git-add (or stg-add when I'll add the alias).

On 2007-12-19 11:40:41 +0000, Catalin Marinas wrote:

Ah, right.

True.

We should probably use cat-file or something instead.

:-)

Jolly good! My stack was getting unwieldy ...

Yes, with David's conflict series.

I wouldn't resurrect the DAG patches for this; I'd just invoke "stg repair" automatically when we detect that top != HEAD.

But I think that for "git rebase", we'd want to teach "repair" to detect that the patches' commits have been changed, rather than just marking them unapplied.

On 18/12/2007, Catalin Marinas <catalin.marinas@gmail.com> wrote:

I found the problem. git.ls_files() now returns all three stages if there was a conflict and the file list got longer. I added a set to remove the duplicates.

On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:

[...]

This patch wrongly assumes that there is a stage 2 entry in the index. Test t1202-push-undo.sh fails because a file is added, differently, in both master and patch but it doesn't exist in ancestor (no stage 2). Using stage 3 doesn't fix it either because a patch might remove a file.

I fixed it by using a set to get the unique names.

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

That sounds reasonable.

On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:

Other useful commands would be support for 'patches' and a local diff/status (and maybe a menu).

Why not just change the cwd when the command starts and it should be safe for all the git subprocesses.

OK, thanks.

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

I have some ideas for some way of showing the current status, but nothing is implemented yet. For some of the more complex cases, I'd like to refer to git.el, although I think that needs some improvements.

I don't think I ever used the 'patches' command, so I'm not sure what the best way to implement it would be.

And my emacs has no menu, so I'm probably not the best person to adda menu, either :-)

On 2007-12-18 09:11:00 +0000, Catalin Marinas wrote:

It doesn't feel very clean to require the caller of some unspecified subset of git calls to remember to set the correct piece of global state.

And the correct solution should really be very simple, since it's precisely the worktree operations (specifically, the subset thereof that have to operate on the whole tree) that require setting cwd. And those are very clearly separated out from the rest in the new infrastructure.

---

Karl Hasselström (2):
      Make "stg goto" subdirectory safe
      Test that "stg goto" can be called from a subdirectory

 stgit/lib/git.py       |    5 ++--
 stgit/run.py           |    9 +++++--
 t/t2800-goto-subdir.sh |   59 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 68 insertions(+), 5 deletions(-)
 create mode 100755 t/t2800-goto-subdir.sh

It currently can't; therefore, the tests are marked as known failures.

Signed-off-by: Karl Hasselström <kha@treskal.com>

---

 t/t2800-goto-subdir.sh |   59 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)
 create mode 100755 t/t2800-goto-subdir.sh

This is not specific to "stg goto" -- it affects all commands that use the new infrastructure. (But of those, only goto and coalesce were subdirectory unsafe.)

Signed-off-by: Karl Hasselström <kha@treskal.com>

---

On 2007-12-18 10:24:19 +0100, Karl Hasselström wrote:

And here it is! Note that not counting the cwd support in run.py and changing the test to expect success, I had to change just three lines to fix this problem for _all_ "new infrastructure" commands. And no unintended side effects, since the cwd is changed only where it's necessary.

 stgit/lib/git.py       |    5 +++--
 stgit/run.py           |    9 ++++++---
 t/t2800-goto-subdir.sh |    4 ++--
 3 files changed, 11 insertions(+), 7 deletions(-)

On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:

And with that, I don't see any reason to not recommend that you pull every patch I have. Which is:

The following changes since commit 5be69cd8d89bd89be31364e9c0fd9e947b6ef644:
  Karl Hasselström (1):
        Name the exit codes to improve legibility

are available in the git repository at:

  git://repo.or.cz/stgit/kha.git safe

David Kågedal (19):
      Add an StGit mode for emacs
      Emacs mode: Improve the output buffer state
      Emacs mode: Bind n and p
      Emacs mode: add stgit-repair
      Emacs mode: added stgit-commit and stgit-uncommit
      Emacs mode: Add stgit-edit command
      Emacs mode: added fontification
      Emacs mode: Added stgit-new
      Check bottom and invariants
      Remove the 'bottom' field
      Remove the 'top' field
      Split git.merge into two functions
      Leave working dir and index alone after failed (conflicting) push
      Added a test case to check what happens when push finds a conflict
      Simplify merge_recursive
      Use the output from merge-recursive to list conflicts
      Ask git about unmerged files
      Emacs mode: Add mark command
      Emacs mode: coalesce command

Karl Hasselström (36):
      Emacs mode: Show keybindings when user presses "h" or "?"
      Emacs mode: Add an explanatory header
      Emacs mode: Makefile for building stgit.el
      Emacs mode: push/pop next patch, not patch at point
      Emacs mode: Let "P" push or pop patch at point
      Emacs mode: Bind "G" to "stg goto"
      Emacs mode: show patches' short description
      Write removed fields for backwards compatibility
      Nicer conflict markers
      Better error message if merge fails
      Fix "stg resolved" to work with new conflict representation
      Refactoring: pass more than one file to resolved()
      We keep the different stages of a conflict in the index now
      "stg status --reset" is not needed anymore
      Remove "stg add"
      Remove "stg rm"
      Remove "stg cp"
      Remove "stg resolved"
      New StGit core infrastructure: repository operations
      Write metadata files used by the old infrastructure
      Upgrade older stacks to newest version
      Let "stg clean" use the new infrastructure
      Add "stg coalesce"
      Let "stg applied" and "stg unapplied" use the new infrastructure
      Teach the new infrastructure about the index and worktree
      Let "stg clean" use the new transaction primitives
      Let "stg goto" use the new infrastructure
      Convert "stg uncommit" to the new infrastructure
      New infrastructure: Make sure that the branch is initialized
      Expose transaction abort function
      stg coalesce: Support --file and --save-template
      Set exit code to 3 on merge conflict
      Convert "stg commit" to new infrastructure
      Make "stg commit" fancier
      Test that "stg goto" can be called from a subdirectory
      Make "stg goto" subdirectory safe

 Documentation/stg-cp.txt      |   63 -------
 Documentation/stg.txt         |    2 -
 Documentation/tutorial.txt    |   31 ++--
 contrib/Makefile              |   19 ++
 contrib/stgit-completion.bash |    4 +-
 contrib/stgit.el              |  377 +++++++++++++++++++++++++++++++++++++++
 examples/gitconfig            |   19 +--
 setup.py                      |    2 +-
 stgit/commands/add.py         |   44 -----
 stgit/commands/applied.py     |   27 ++--
 stgit/commands/clean.py       |   49 ++----
 stgit/commands/coalesce.py    |  122 +++++++++++++
 stgit/commands/commit.py      |  111 ++++++++-----
 stgit/commands/common.py      |   39 ++---
 stgit/commands/copy.py        |   45 -----
 stgit/commands/goto.py        |   52 ++----
 stgit/commands/pick.py        |    2 +-
 stgit/commands/resolved.py    |   94 ----------
 stgit/commands/rm.py          |   48 -----
 stgit/commands/status.py      |   31 ++--
 stgit/commands/sync.py        |    1 -
 stgit/commands/unapplied.py   |   23 ++--
 stgit/commands/uncommit.py    |   81 ++++-----
 stgit/config.py               |    1 -
 stgit/git.py                  |   75 +++++---
 stgit/gitmergeonefile.py      |   97 +----------
 stgit/lib/__init__.py         |   18 ++
 stgit/lib/git.py              |  388 +++++++++++++++++++++++++++++++++++++++++
 stgit/lib/stack.py            |  176 +++++++++++++++++++
 stgit/lib/stackupgrade.py     |   98 +++++++++++
 stgit/lib/transaction.py      |  209 ++++++++++++++++++++++
 stgit/main.py                 |   14 +-
 stgit/run.py                  |   12 +-
 stgit/stack.py                |  156 ++++-------------
 stgit/utils.py                |   25 +++
 t/t0002-status.sh             |   15 +-
 t/t1200-push-modified.sh      |    2 +-
 t/t1202-push-undo.sh          |    6 +-
 t/t1203-push-conflict.sh      |   70 ++++++++
 t/t1204-pop-keep.sh           |    2 +-
 t/t1205-push-subdir.sh        |    8 +-
 t/t1300-uncommit.sh           |   16 +-
 t/t1301-repair.sh             |    2 +-
 t/t1400-patch-history.sh      |    4 +-
 t/t1500-float.sh              |   14 +-
 t/t1600-delete-one.sh         |   12 +-
 t/t1601-delete-many.sh        |    2 +-
 t/t1700-goto-top.sh           |    2 +-
 t/t2000-sync.sh               |   12 +-
 t/t2100-pull-policy-fetch.sh  |    4 +-
 t/t2101-pull-policy-pull.sh   |    4 +-
 t/t2102-pull-policy-rebase.sh |    4 +-
 t/t2300-refresh-subdir.sh     |    2 +-
 t/t2600-coalesce.sh           |   31 ++++
 t/t2800-goto-subdir.sh        |   59 ++++++
 55 files changed, 1959 insertions(+), 867 deletions(-)
 delete mode 100644 Documentation/stg-cp.txt
 create mode 100644 contrib/Makefile
 create mode 100644 contrib/stgit.el
 delete mode 100644 stgit/commands/add.py
 create mode 100644 stgit/commands/coalesce.py
 delete mode 100644 stgit/commands/copy.py
 delete mode 100644 stgit/commands/resolved.py
 delete mode 100644 stgit/commands/rm.py
 create mode 100644 stgit/lib/__init__.py
 create mode 100644 stgit/lib/git.py
 create mode 100644 stgit/lib/stack.py
 create mode 100644 stgit/lib/stackupgrade.py
 create mode 100644 stgit/lib/transaction.py
 create mode 100755 t/t1203-push-conflict.sh
 create mode 100755 t/t2600-coalesce.sh
 create mode 100755 t/t2800-goto-subdir.sh

kha/experimental points to the same commit as kha/safe, for now.

On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:

Please rebase again when you have time since I already merged most of this branch and added some patches that might conflict with yours.

On 2007-12-19 23:17:42 +0000, Catalin Marinas wrote:

You hadn't pushed any of it out when I last checked about two hours ago ...

Will do, but not tonight. In fact, it may be a few days, I'm afraid.

On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:

I just pushed the changes a few minutes ago.

No problem. Anyway, if I don't here from you in the meantime, have a good Christmas :-).

On 2007-12-19 23:29:13 +0000, Catalin Marinas wrote:

So I guessed. :-)

You too! (Or anything else you may prefer to celebrate this time of year.)

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

The conflict series of patches from me works for me, but I know that I don't use all the merging features that other users use, so I can't guarantee that everything works. But it seems that Catalin has been looking over it, so I guess it's ok.

On 2007-12-20 00:24:11 +0100, David Kågedal wrote:

I've been running it for quite some time too. And the criteria for getting into kha/stable aren't _that_ onerous: I don't guarantee that there are no bugs, just that the patches seem to be ready for widespread testing.

On 2007-12-19 23:19:23 +0100, Karl Hasselström wrote:

I forgot to say, but this goes on top of kha/experimental. The test makes use of the "return exit code 3 when there was conflicts" patch to make sure that there was a conflict and not another error.