Re: [Emacs-diffs] master 4e23cd0 4/5: * mail/rmail.el (rmail-show-message-1): When displaying a mime message,

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

Alan Mackenzie writes:

 > Since that time, whenever I have files in the staging area ready to
 > commit, and do a git pull, those files end up no longer being in the
 > staging area.

I don't understand.  I did

cd /tmp
git clone ~/src/Twitter
cd Twitter
git reset --hard HEAD^
echo foo > foo
git add foo

I expect that if I now pull I will get an up-to-date git repo with foo
ready for commit.  Try it:

Twitter 18:19$ git pull
Updating 64cb97f..f079094
Fast-forward
 stream.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Twitter 18:19$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

  new file:   foo

Twitter 18:19$

How do I reproduce your experience?

 > > ...., but the problems Richard and Alan are encountering are
 > > soon solved by those who study a little bit, and establish some
 > > discipline in performing what they've learned.
 > 
 > Excuse me, but that is disparagingly patronising.

Nonsense.  I don't know what you and Richard are doing differently,
but it is a fact that millions of people have learned to use git,
reasonably quickly, at the level needed to contribute to some project.

I don't know why you and Richard encounter the issues you do.  That
doesn't mean I think you're somehow less of a developer for that.  I
would like to know why; if I did, I might be able to see a way to do
things your way.  But all I hear from you and Richard is that git
requires tens of hours to learn to the level required for contributing
to Emacs, which is manifestly false from my own experience and that of
many many others, and that it is a "screw", which is purely
pejorative.  Neither contains content useful to developing an
"unscrewed" workflow.

 > Again you're muddying the waters, insinuating that we're both stuck
 > in the antediluvian CVS past.

You want workflows that (for Richard) involves avoiding branches and
(for both) leaving some changes uncommitted for long periods while
updating your workspace with new code from upstream.  Those are
typical of workflows developed for and adapted to CVS.

"Antediluvian" is your word, not mine.  Feel free to retract it, I
won't mind.

 > > There's nothing wrong with wanting your tools to be adapted to
 > > you, of course, but if you want to cooperate with others,
 > > sometimes you need to compromise with the shared tools.
 > 
 > More insinuations.

Only if you make the effort to read them that way.  That was not my
intent, and it's in not the words you quoted.

 > Although I have criticised git's many shortcomings, I have never
 > requested or suggested that other people adapt it to my liking.

In fact, Richard has done so, in particular suggesting to seek out
somebody who "resents" git sufficiently to do it for him.  But I did
not say that in the text you quoted.

 > And nobody could fairly accuse me of not compromising with git.

"Fair" is a matter of opinion, of course.  But what anyone can observe
is that you complain about the need to compromise with git, and
disparage the tool itself.  I think that's hardly helpful in
developing a workflow.