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

[Alan Mackenzie]

Hello, Stephen.

#On Tue, Apr 14, 2015 at 08:08:12AM +0900, Stephen J. Turnbull wrote:
> 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?

I don't know.  But when it has happened to me, it has always been with
existing files in a repository directly cloned from a remote repository.
(I have no experience of other scenarios.)  I can't even say whether the
loss of staging of files is a bug or an intended feature.

>  > > ...., 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 can't speak for Richard, but for me, it might be how I learn new tools:
I first flick through tutorials to get the general gist of a tool, then
hit the reference documentation and build an internal mental map of it,
then start using the tool, using the reference doc to sort out the
problems which occur.  This usually works well, but hasn't done for git.

How do other people, such as yourself, learn these things?

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

OK.  To take an example, I was stuck a couple of months back having made
changes in my working directory and needing to revert them (from the
repository).  In many (?most) VCSs this operation is called "revert".
Not in git.  In git, you have to use "git checkout" in a particular
fashion.  Supposing one doesn't know that the command is called
"checkout", how does one find out?  How would you find this out?  In the
end, I gave up and bothered people on emacs-devel instead.  But if you
can answer this question, it would help me a great deal next time I have
a similar puzzlement.

> 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,

How, then, did you learn git?

> and that it is a "screw", which is purely pejorative.

I agree with you here.  The term is offensive, probably deliberately so.

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

Yes.  I think it more likely that CVS was developed for those workflows.
But why does git cope so badly with these workflows?  It's supposed to be
a modern flexible tool.

How do you personally deal with commits that you make not because your
development is at a suitable stage for a commit, but that you make
because git encourages/enforces it (for example, when you want to pull)?

I don't see any need for me personally to use branches.  If I was
constantly active in the development of several different things in Emacs
I might.  But then I would probably want to use several parallel
repositories rather than branches within a single one.  git's scheme of
constant branching and branch swapping doesn't scale to built objects
(such as files.o and files.elc).  I actually keep two Emacs git
repositories, one for master, the other for the Emacs-24 branch.

I foresee that both "frivolous" commits and "frivolous" branching would
create extra administrative work for me.  Somehow, they would have to be
dealt with, and effort would need to be made to prevent them accidentally
leaking to the savannah repository.

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

OK, I retract it.  There hasn't been a flood since the CVS times which
has affected me, so it's inaccurate.

[ ... ]

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

Well, maybe not.  But remaining silent about problems isn't helpful
either.

-- 
Alan Mackenzie (Nuremberg, Germany).