Martin Langhoff wrote:
quoted
From what I understand, you'll want the StGIT infrastructure. If you
use git/cogito, there is an underlying assumption that you'll want
all the patches merged across, and a simple cg-update will bring in
all the pending stuff.
My concerns are both metodologicals and practical:
1) Method: To use the 'free patching workflow' on git is something foreseen in
git design, something coherent with the fork + develop + merge cycle that it
seems, at least to me, THE way git is meant to be used. Or it is stretching
the possibility of the tool to something technically allowed but not suggested.
2) Practical: The round trip git-format-patch + git-applymbox is the logical and
natural way to reach this goal or, also in this case, I intend to stretch some tools,
designed for one thing, for something else?
About StGIT, I agree it is the right tool, designed for this kind of problems. But,
peraphs because I don't know it very much, I still can't figure out how to integrate
StGit in a git GUI, like qgit is, so to have an unified and friendly view of a git
archive and a patches stack.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Tue, 16 Aug 2005, Marco Costalba wrote:
Martin Langhoff wrote:
quoted
quoted
From what I understand, you'll want the StGIT infrastructure. If you
use git/cogito, there is an underlying assumption that you'll want
all the patches merged across, and a simple cg-update will bring in
all the pending stuff.
My concerns are both metodologicals and practical:
1) Method: To use the 'free patching workflow' on git is something foreseen in
git design, something coherent with the fork + develop + merge cycle that it
seems, at least to me, THE way git is meant to be used. Or it is stretching
the possibility of the tool to something technically allowed but not suggested.
Patches are definitely meant to be part of how git is used; they are the
primary way of getting clean history out of messy history (that is, saving
a content change while discarding some history that isn't applicable).
There's relatively little support in git itself, but that's because the
point is to go outside the system's tracking. There have been various
discussions of more explicit support, and nobody's been able to come up
with a need.
2) Practical: The round trip git-format-patch + git-applymbox is the logical and
natural way to reach this goal or, also in this case, I intend to stretch some tools,
designed for one thing, for something else?
I'd guess that git-diff-tree + git-apply (without the rest of the
scripting) would be more effective when you're not doing anything with the
intermediate files, since it saves doing a bunch of formatting and
parsing.
-Daniel
*This .sig left intentionally blank*