Thanks for the response...much appreciated.
You're absolutely right that there are scenarios where template files would
be a good solution...from what I gather, I think those use cases mostly
expect the template files to be relatively stable.
In our specific use case, the files that we'd need to turn into templates
are (sadly) sprinkled throughout a legacy codebase and change often. In
such a scenario, we don't know how a user would get feedback when they move
HEAD to a different commit that their template file tweaks must be rebased
on a new template. If hundreds of files have changed, is there a workflow
that allows them to recognize that one or more template files are in those
hundreds of files and that action is required on their part to make the
corresponding changes in their configured copy? And what should happen to
their configured copy if the source template file is deleted or renamed?
I'm not clever enough to figure out good answers to these questions, so
right now, we're trying to mark files with the skip-work tree bit, and our
workflow for changing branches is to just attempt to use git checkout and
hope that it works. If there are any conflicts that block the user from
switching branches, we have a script that does the following:
(1) saves a list of all the files that are marked with skip-worktree.
(2) git stash save (including the untracked list from step 1)
(3) git checkout the new branch
(4) git stash pop and resolve conflicts
(5) restore the skip-worktree bit on all the files from the list from step
1, then delete the list
The only two nontrivial parts are (1) that git stash pop can require manual
intervention, so our script currently supports --continue (ala merge,
rebase, etc) to resume after resolving conflicts and (2) because the
skip-worktree bit can only be set on tracked files, the last step can be
problematic when changing branches if the configuration file has been
deleted/renamed in a different branch. It's definitely not perfect, but it
seems to be *mostly* good enough to be worth using.
Thanks for reading this far, and I'll take your advice to bring this up on
the other list. Just wanted to see if there was already a well-known
workflow that solves our problem without us having to throw code at it. :-)
Mick
-
On Feb 12, 2014 10:05 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On Sun, 9 Feb 2014 13:52:20 -0800 (PST)
Mickey Killianey mickey.killia...@gmail.com wrote:
My team is starting to use the --skip-worktree flag on files to allow
them to keep modified files in their working directories. Ideally,
they'd like an option for git-stash to apply to skip-worktree
files, just as it can (optionally) be applied to untracked files, so
that skip-worktree files could be included when saving and restored
(ideally, with the skip-worktree bit set) on a git-stash pop.
(1) I don't see an option for git-stash to support skip-worktree
files...is it there and I'm just not seeing it?
(2) Does anyone know if there's a reason why this is not
possible/unreasonable to support/philosophically discouraged?
(3) If it is reasonable, where would the right place be to
suggest/request this feature?
I'm happy to look at making such changes to git-stash.sh, but before
I do so, I'd love to know that such work would be aligned with their
designs for git-stash. (For example, if the git team would only want
such an option if it also included the ability to stash
assume-unchanged files, too, that would be useful to know before I
start making changes.)
I'm afraid you'll have to reach for the main Git list [1] which is
frequented by the Git devs.
But while the contents of your question does indicate you possess
a reasonably advanced technical level, I'm oblidged to ask: did you
consider using template files to achieve your goal? I mean, the
necessity to have locally-modified files most frequently relates to
configuration files and stuff like this, and a sensible approach to
deal with this case is to keep templates of such files in the
repository (with special filenames, like the .template extension
added to each) and force the devs to *copy* them and tweak
appropriately for their systems. Would it work for your case?
1. https://gist.github.com/tfnico/4441562
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
