StGIT: Trouble adding files to non-topmost patch

StGIT: Trouble adding files to non-topmost patch

[Matt McCutchen]

I keep a copy of the Eclipse source code checked out from CVS, and I use
StGIT to manage both long-term and short-term local changes to the
source.  (StGIT is so much nicer than shuffling patches by hand!)  My
StGIT patch stack is based on an empty tree; the bottom-most patch
(named "origin") contains the original Eclipse source and the others
contain my changes.  I use "cvs up" to pull updates from Eclipse's
repository, a custom script to load the updates into the git index, and
"stg refresh -p origin" to load them into the patch stack.

However, when the Eclipse developers create new files, I can't seem to
add them to "origin" this way.  After my index-updating script runs,
"git status" shows that the new files have been added to the index,
but "stg refresh -p origin" doesn't change "origin" and the new files
show as untracked again.  Some investigation revealed that the problem
is that, whenever StGIT pops a patch (including as part of "stg refresh
-p"), it resets the index.  Here's the relevant code in git.py:

        def switch(tree_id, keep = False):
            """Switch the tree to the given id
            """
            if keep:
                # only update the index while keeping the local changes
                GRun('read-tree', tree_id).run()

This behavior doesn't affect changes and deletions since StGIT
automatically adds them back to the index, but it completely controverts
additions.  Please provide a direct way to add files to non-topmost
patches.

One could argue that my setup is bad.  I could work around the problem
by loading updates using a separate tree holding a clean CVS checkout,
but then it is less convenient to check out additional modules.  I could
download and import the entire CVS history with git-cvsimport, but that
would take an enormous amount of time and disk space.  I'm open to
practical suggestions for a better setup, but I do hope the problem with
StGIT gets fixed.

[I am off-list; please include me in replies.]

Matt

Re: StGIT: Trouble adding files to non-topmost patch

[Karl Hasselström]

On 2008-02-07 23:30:24 -0500, Matt McCutchen wrote:

> I keep a copy of the Eclipse source code checked out from CVS, and I
> use StGIT to manage both long-term and short-term local changes to
> the source. (StGIT is so much nicer than shuffling patches by hand!)
> My StGIT patch stack is based on an empty tree; the bottom-most
> patch (named "origin") contains the original Eclipse source and the
> others contain my changes. I use "cvs up" to pull updates from
> Eclipse's repository, a custom script to load the updates into the
> git index, and "stg refresh -p origin" to load them into the patch
> stack.
>
> However, when the Eclipse developers create new files, I can't seem
> to add them to "origin" this way. After my index-updating script
> runs, "git status" shows that the new files have been added to the
> index, but ???"stg refresh -p origin" doesn't change "origin" and
> the new files show as untracked again. Some investigation revealed
> that the problem is that, whenever StGIT pops a patch (including as
> part of "stg refresh -p"), it resets the index. Here's the relevant
> code in git.py:
>
>     def switch(tree_id, keep = False):
>         """Switch the tree to the given id
>         """
>         if keep:
>             # only update the index while keeping the local changes
>             GRun('read-tree', tree_id).run()
>
> This behavior doesn't affect changes and deletions since StGIT
> automatically adds them back to the index, but it completely
> controverts additions. Please provide a direct way to add files to
> non-topmost patches.

Thanks for the detailed bug report!

Unfortunately, I don't have time to fix it immediately, so I put it in
the bug tracker: https://gna.org/bugs/index.php?11009.

> One could argue that my setup is bad. I could work around the
> problem by loading updates using a separate tree holding a clean CVS
> checkout, but then it is less convenient to check out additional
> modules. I could download and import the entire CVS history with
> git-cvsimport, but that would take an enormous amount of time and
> disk space. I'm open to practical suggestions for a better setup,
> but I do hope the problem with StGIT gets fixed.

What I'd do if I were you is to have a regular git branch just for
importing the upstream, and make a new commit there whenever I run
'cvs up'. And then rebase my local StGit patch stack on top of that
branch. Which would conveniently side-step the StGit bug ... ;-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle