Hi Junio,
On Thu, 13 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> > On Thu, 13 Nov 2014, Johannes Schindelin wrote:
> >
> >> Due to that experience, the documentation also states pretty clearly that
> >> `updateInstead` succeeds only in updating the current branch if the
> >> working directory is clean.
> >
> > To clarify why `updateInstead` is stricter than the `merge` scenario: when
> > pushing into a remote repository with attached working directory, we
> > cannot simply clean up merge conflicts or other problems introduced by a
> > merge. Indeed, it is even possible to push without having any option to
> > fix files in the working directory afterwards. Therefore, the
> > `updateInstead` feature really needs to be adamant about the working
> > directory being clean.
>
> As the stricter check (which I think is unnecessarily strict and
> which you don't) can be loosened later without making something the
> user used to be able to do in an early version unable to do later,
> I am OK to accept the design as-is.
Thanks for mentioning this. I would like to ask not to loosen this later.
Let me try to explain in more detail than before why I think it would make
*my* life hard if it ever were loosened.
Let's start with a hypothetical change to notes.c, a change, say, that
uses part of the diff machinery. So I am doing that in my working
directory, happily testing stuff, but not quite happy with the result just
yet, staging a couple of things after a debug run so I can "git stash -k"
away the debugging statements.
Please note that while the scenario I just illustrated is purely
hypothetical, made up from thin air, the workflow and the technique is
very much my daily bread, though. I do use "git stash -k" quite frequently
to stash away stuff that I do not want, after staging what I want to keep
first.
Now let's continue by saying that I get interrupted with that notes.c work
and only come back to it much, much later, say, a couple of months,
because I have been working on a different computer in the meantime,
say, fixing Git for Windows bugs like mad.
Okay, so now I am back and I "git pull" your 'master'. Now, for the sake
of the argument, let's say that the pull does not introduce any changes to
notes.c, but instead that there has been an improvement in the diff
machinery, one that required a change of the diff machinery's API and all
of a sudden, my code does not compile anymore. It merged cleanly,
Git is completely groovy, but the code just does not compile any more. Not
a big deal: I can inspect the changes via "git diff
junio/master@{1}..junio/master" and find out very easily what went wrong
and fix my code, compile, stage, and maybe even commit because the code
now works.
Splendid.
But it would be different if the working directory was on another computer
than the one I am operating from. I could not easily access the working
directory, let alone the Git history, if all I did was a "git push".
Now let's modify the scenario a little bit further, still. Let's not talk
about git.git, but about a project implementing a web application. And
let's say that I did not dabble with notes.c but I had to work on the
production setup for a really, really urgent hotfix where the speed of a
fix was more important than not touching the production setup at all.
Please note that this is *not* a hypothetical scenario, but a true account
of what I had to go through a couple of times (don't try this at home, it
causes a lot of gray hair).
Now let's assume that I forgot to commit and push, and that nobody noticed
– and let's just draw the curtain of charity over the reasons why. Also,
let's assume that a couple of months later, I am asked to implement a new
feature for the very same web application, this time without frantic "You.
Have. To. Fix. This. ASAP!" stuff going on. So I develop this on a test
machine, test thoroughly, everything's groovy, and then I push, using the
'updateInstead' feature introduced by the patch in question (and which was
applied to that machine's Git at that time, before some joker updated it
with the official Git).
And now when I try to push, Git complains that the working directory is
not clean, which is *just* fine by me, because after further inspection it
turns out that the uncommitted changes – which are in a different file
than the changes introducing my new feature – would have borked the
production system rather thoroughly.
Please note again that I am talking about something that really happened.
So I would really like to have 'updateInstead', but only in the safe
version, i.e. refusing to update anything but a clean working directory,
and it would be a major regression for me, affecting my workflow rather
negatively, if those strict checks were loosened.
In my mind, when (and if!) a less strict version is desired, it should be
added as another denyCurrentBranch value and 'updateInstead' should be
unaffected, otherwise, speaking for me personally, all my work in this
patch series would be for naught.
Ciao,
Johannes