Re: Stash

["Stephen J. Turnbull" <stephen@xemacs.org>]

Richard Stallman writes:

 > I think Git ought to have an 'update' facility, for simple usage
 > scenarios, that would be just as easy to use as cvs update.  In
 > more complex scenarios, it could refuse to operate.

Lack of a facility that only merges into the workspace and pays no
attention to the revision history is a deliberate design choice.  One
reason that git developers do not add such a mode is that it can and
does create future conflicts.  What can (and did) happen in CVS is
that developers who preferred to keep pending changes in their
workspaces would repeatedly cvs up and repeatedly resolve different
conflicts, which would end up all jammed together in a single commit.
In CVS, everybody worked on the mainline, and there was very little
branching or cherrypicking, so very little annoyance, since
essentially all workspaces were based on tip of trunk.

However, the resolutions would not be recorded individually in the
history.  In git, this causes headaches for third parties who were
cherrypicking or rebasing because they had only *some* of the
conflicting changes, and had to decide for themselves how to resolve
those conflicts that had resolutions but not conflicting changes.

Often they would decide differently, not knowing the history, and thus
end up reverting the original resolution.  So with git, the annoyance
to other developers became the dominant factor because of the
prevalence of multiple-branch development workflows.  I think it is
likely that a request for such a feature to the Git project would be
immediately closed WONTFIX, but you could try.

You could keep track of whether previous pulls had required conflict
resolution, and refuse to update if there would be conflicts again.  I
suspect that this would be a horrible workflow, requiring a pile of
git knowledge to reconstruct an appropriate state to commit.