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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
