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.  :-)



On Feb 12, 2014 10:05 AM, "Konstantin Khomoutov" <> wrote:
> On Sun, 9 Feb 2014 13:52:20 -0800 (PST)
> Mickey Killianey <> 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
> > 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, 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.

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 
For more options, visit

Reply via email to