Git question: when using branches, how does git treat working files when changing branches?

Git question: when using branches, how does git treat working files when changing branches?

[Alan Mackenzie]

Hello, Emacs.

I want to start using git branches, so as to be able to work on several
distinct things at the same time.

My question is, how does git handle working files (which haven't been
committed) when changing from one branch to another.  I've spent the
usual two hours searching the fine manuals without turning up a clear
explanation.

One thing that worries me is that the same command "git checkout" is
used to change branches and to revert changes to a file.  So it seems
plausible that each time I swap to a different branch I'm in danger of
irrevocably losing existing changes to source files.

So, what happens to to changes in the working directory when changing
branches?
1. git refuses to change branches because there are uncommitted changes.
2. git changes branches, discarding all uncommitted changes.
3. git changes branches, leaving the changes from the previous branch in
the working directory.

What I really want to happen is
4. git maintains uncommitted changes separately in each branch.

I suspect 4. is not the way git works.  So, how do I best simulate 4.?
I would like to be able to move freely between git branches without
suffering stupid restrictions like having to worry about preserving
changes in the working directory.  Is there some variant of "git stash"
which might do what I want?

TIA!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Git question: when using branches, how does git treat working files when changing branches?

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> I want to start using git branches, so as to be able to work on several
> distinct things at the same time.
>
> My question is, how does git handle working files (which haven't been
> committed) when changing from one branch to another.  I've spent the
> usual two hours searching the fine manuals without turning up a clear
> explanation.
>
> One thing that worries me is that the same command "git checkout" is
> used to change branches and to revert changes to a file.  So it seems
> plausible that each time I swap to a different branch I'm in danger of
> irrevocably losing existing changes to source files.
>
> So, what happens to to changes in the working directory when changing
> branches?
> 1. git refuses to change branches because there are uncommitted changes.
> 2. git changes branches, discarding all uncommitted changes.
> 3. git changes branches, leaving the changes from the previous branch in
> the working directory.

Either 1 or 3, depending on whether the difference between the two
branches overlaps with the uncommitted changes or not.  When Git can
just keep the uncommitted changes without conflict, it does that.  This
comes in rather handy when you start doing some work, then figure out
that you really should have started a new branch.  You can then just
checkout/create the new branch and ultimately commit there.

> What I really want to happen is
> 4. git maintains uncommitted changes separately in each branch.

Nope.  There is only one index and one work directory.  Just commit
them.  You can also do "git stash" for saving index/work directory on a
stack and use "git stash pop" for getting them back out again later when
you switch back to your branch, but stashes are not tied to a particular
branch either.

It's usually just easier to do

git commit -m "wip" -a

and have a commit with message "wip" (work in progress) on the branch
where it belongs.  You can fix that commit up later with

git commit --amend

in order to both fix the commit message as well as adding more changes
to it.

-- 
David Kastrup

Re: Git question: when using branches, how does git treat working files when changing branches?

[Steinar Bang]

>>>>> Alan Mackenzie <acm@muc.de>:

> So, what happens to to changes in the working directory when changing
> branches?
> 1. git refuses to change branches because there are uncommitted changes.

If the branch you change to wants to modify one of the files you have
local changes in, git will abort the branch change with the message:
 error: Your local changes to the following files would be overwritten by checkout:
        filename
 Please, commit your changes or stash them before you can switch branches.
 Aborting

> 2. git changes branches, discarding all uncommitted changes.

Not by default, but using "-f" or "--force" will allow you to change
branch while overwriting local changes.

> 3. git changes branches, leaving the changes from the previous branch in
> the working directory.

If the branch change doesn't overwrite any of the files where you have
local changes, this is what will happen.

> What I really want to happen is
> 4. git maintains uncommitted changes separately in each branch.

> I suspect 4. is not the way git works.

Correct.

> So, how do I best simulate 4.?

git stash
git checkout some-branch
git stash pop

> I would like to be able to move freely between git branches without
> suffering stupid restrictions like having to worry about preserving
> changes in the working directory.  Is there some variant of "git stash"
> which might do what I want?

You mean, automatically...?

Dunno.

I mostly just try changing the branch, and revert to
 git stash
 git checkout some-branch
 git stash pop
if git complains about local changes being overwritten.

Re: Git question: when using branches, how does git treat working files when changing branches?

[Ricardo Wurmus]

Alan Mackenzie <acm@muc.de> writes:

> So, what happens to to changes in the working directory when changing
> branches?
> 1. git refuses to change branches because there are uncommitted changes.
> 2. git changes branches, discarding all uncommitted changes.
> 3. git changes branches, leaving the changes from the previous branch in
> the working directory.

It’s a mix of 1 and 3.

(A branch is just a pointer to a commit in the graph.  When creating a
branch you create a named pointer to the last commit (the one pointed to
by “HEAD”).  When you switch branches you really just tell git to travel
to the commit in the graph by following the named pointer.)

If there are new, uncommitted files in your working directory they will
remain as you switch branches.  Git refuses to switch to another branch
when the uncommitted file is created by a commit in the target branch,
so that you won’t accidentally lose the file.

For tracked files git will refuse to change branches:

~~~~~~~~
error: Your local changes to the following files would be overwritten by checkout:
	/path/to/the/modified/file.el
Please, commit your changes or stash them before you can switch branches.
Aborting
~~~~~~~

> What I really want to happen is
> 4. git maintains uncommitted changes separately in each branch.
>
> I suspect 4. is not the way git works.  So, how do I best simulate 4.?
> I would like to be able to move freely between git branches without
> suffering stupid restrictions like having to worry about preserving
> changes in the working directory.  Is there some variant of "git stash"
> which might do what I want?

Git only cares about commits and pointers to commits.  If you have
uncommitted changes and you want to make sure they are not lost as you
switch branches, the git way is to commit them, e.g.

    git add /path/to/the/modified/file.el
    git commit -m "WIP"
    git checkout the-other-branch

and then reset the last commit upon your return:

    git checkout first-branch
    git reset HEAD^
    
    # This means: reset to the parent commit of the commit that “HEAD”
    # points to.  The changes introduced by the commit remain in your
    # directory, but the commit is gone.

This is safe and you are very unlikely to ever lose your changes because
you created a commit object.  (It’s not easy to really lose commits by
accident.)

An alternative is to use “git stash” before switching and “git stash
pop” after your return.  You can have multiple stashes, but it’s easier
to get lost than it is with commits.

~~ Ricardo

Re: Git question: when using branches, how does git treat working files when changing branches?

[Alex Bennée]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> I want to start using git branches, so as to be able to work on several
> distinct things at the same time.
>
> My question is, how does git handle working files (which haven't been
> committed) when changing from one branch to another.  I've spent the
> usual two hours searching the fine manuals without turning up a clear
> explanation.
>
> One thing that worries me is that the same command "git checkout" is
> used to change branches and to revert changes to a file.  So it seems
> plausible that each time I swap to a different branch I'm in danger of
> irrevocably losing existing changes to source files.
>
> So, what happens to to changes in the working directory when changing
> branches?
> 1. git refuses to change branches because there are uncommitted
> changes.

By default git will complain if changing branches would revert
uncommitted changes.

> 2. git changes branches, discarding all uncommitted changes.

You can force it to reset everything (which you don't want)

> 3. git changes branches, leaving the changes from the previous branch in
> the working directory.
>
> What I really want to happen is
> 4. git maintains uncommitted changes separately in each branch.
>
> I suspect 4. is not the way git works.  So, how do I best simulate 4.?
> I would like to be able to move freely between git branches without
> suffering stupid restrictions like having to worry about preserving
> changes in the working directory.  Is there some variant of "git stash"
> which might do what I want?

Well I usually do a stash/rebase/stash-pop cycle in magit. However you
may want to look at the rebase.autostash option (since Git 2.6)

>
> TIA!


-- 
Alex Bennée

Re: Git question: when using branches, how does git treat working files when changing branches?

[Alan Mackenzie]

Hello, Alex.

On Wed, Oct 28, 2015 at 08:10:14PM +0000, Alex Bennée wrote:

> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Emacs.

> > I want to start using git branches, so as to be able to work on several
> > distinct things at the same time.

> > My question is, how does git handle working files (which haven't been
> > committed) when changing from one branch to another.  I've spent the
> > usual two hours searching the fine manuals without turning up a clear
> > explanation.

> > One thing that worries me is that the same command "git checkout" is
> > used to change branches and to revert changes to a file.  So it seems
> > plausible that each time I swap to a different branch I'm in danger of
> > irrevocably losing existing changes to source files.

> > So, what happens to to changes in the working directory when changing
> > branches?
> > 1. git refuses to change branches because there are uncommitted
> > changes.

> By default git will complain if changing branches would revert
> uncommitted changes.

OK, I started with a test repository, with some changes in (which I saved
in a diff file).  After listing the available branches, and chosing one
at random, I did
    $ git checkout /origin/master
, and got some message or other about a detached head.  Without doing
anything else I then switched back with
    $ git checkout master.

git status now reports that the working directory is "clean".  So one of
these two operations has discarded my changes.

> > 2. git changes branches, discarding all uncommitted changes.

This has indeed happened.

So it would seem a good idea, before switching branches, to make a
complete backup of ones changes with git diff > foo.diff.

> You can force it to reset everything (which you don't want)

> > 3. git changes branches, leaving the changes from the previous branch in
> > the working directory.

> > What I really want to happen is
> > 4. git maintains uncommitted changes separately in each branch.

> > I suspect 4. is not the way git works.  So, how do I best simulate 4.?
> > I would like to be able to move freely between git branches without
> > suffering stupid restrictions like having to worry about preserving
> > changes in the working directory.  Is there some variant of "git stash"
> > which might do what I want?

> Well I usually do a stash/rebase/stash-pop cycle in magit. However you
> may want to look at the rebase.autostash option (since Git 2.6)

The problem is that, according to David K, there's only one stash stack,
so it would be very inconvenient having to keep track of which entries in
this stack belong to which branches.

Or, maybe I would be better just keeping several distinct copies of the
repository, all cloned off of a master master, and using git push to
propagate changes from a sub-master to it.  That would mean me having to
be more selective with my backups, but it might be the best solution.

> -- 
> Alex Bennée

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Git question: when using branches, how does git treat working files when changing branches?

[Xue Fuqiao]

Hi Alan,

On Thu, Oct 29, 2015 at 6:32 AM, Alan Mackenzie <acm@muc.de> wrote:
> OK, I started with a test repository, with some changes in (which I saved
> in a diff file).  After listing the available branches, and chosing one
> at random, I did
>     $ git checkout /origin/master

It should be `git checkout origin/master' or `git checkout
refs/remotes/origin/master'.

> , and got some message or other about a detached head.  Without doing
> anything else I then switched back with
>     $ git checkout master.
>
> git status now reports that the working directory is "clean".  So one of
> these two operations has discarded my changes.

I don't think something like `/origin/master' should be in your output
of `git branch', unless you used the -r or -a option.  And one usually
shouldn't work in the 'detached HEAD' state, unless he/she would like to
discard the changes later, or want to create a new branch.

Well, this isn't really an answer to your question.  Just some
corrections/suggestions.

Re: Git question: when using branches, how does git treat working files when changing branches?

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

Joining the emacs-devel git hot line...

>> By default git will complain if changing branches would revert
>> uncommitted changes.
>
> OK, I started with a test repository, with some changes in (which I saved
> in a diff file).  After listing the available branches, and chosing one
> at random, I did
>     $ git checkout /origin/master
> , and got some message or other about a detached head.  Without doing
> anything else I then switched back with
>     $ git checkout master.
>
> git status now reports that the working directory is "clean".  So one of
> these two operations has discarded my changes.

This is hard to believe, so I tried your steps:

oscar@qcore:~/dev/emacs/emacs$ git checkout /origin/master
fatal: Could not switch to '/origin/': No such file or directory

As you can see, your first command fails to complete. I requested this
on a previous question of yours about git and I request it again: please
post the *exact* commands and its output. Otherwise, claims like what
you made above are dubious, at best.

[snip]

>> Well I usually do a stash/rebase/stash-pop cycle in magit. However you
>> may want to look at the rebase.autostash option (since Git 2.6)
>
> The problem is that, according to David K, there's only one stash stack,
> so it would be very inconvenient having to keep track of which entries in
> this stack belong to which branches.

David Kastrup also suggested to commit your changes before switching
branches, I wonder why you ignored his advice.

Over the years I used several VC systems (CVS and subversion, among
others) and git is, by far, the one that makes things easier when you
don't want to lose your changes, committed or not.

Finally, I wholeheartedly recommend to give Magit a try.

[snip]

Re: Git question: when using branches, how does git treat working files when changing branches?

[Alan Mackenzie]

Hello, Óscar.

On Wed, Oct 28, 2015 at 11:59:03PM +0100, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> Joining the emacs-devel git hot line...

> >> By default git will complain if changing branches would revert
> >> uncommitted changes.

> > OK, I started with a test repository, with some changes in (which I saved
> > in a diff file).  After listing the available branches, and chosing one
> > at random, I did
> >     $ git checkout /origin/master
> > , and got some message or other about a detached head.  Without doing
> > anything else I then switched back with
> >     $ git checkout master.

> > git status now reports that the working directory is "clean".  So one of
> > these two operations has discarded my changes.

> This is hard to believe, so I tried your steps:

> oscar@qcore:~/dev/emacs/emacs$ git checkout /origin/master
> fatal: Could not switch to '/origin/': No such file or directory

> As you can see, your first command fails to complete. I requested this
> on a previous question of yours about git and I request it again: please
> post the *exact* commands and its output. Otherwise, claims like what
> you made above are dubious, at best.

As you probably could guess, "/origin/master" was a typo, and the actual
text was "origin/master".  It's getting quite late.

Having a look at my series of commands after the first git checkout, I
in fact did a git stash list.  I don't think that list was empty when I
typed that command.  It isn't empty now.  In other words, that first git
checkout stashed my changes, it didn't discard them.  It may have told
me, it might not have.

> [snip]

> >> Well I usually do a stash/rebase/stash-pop cycle in magit. However you
> >> may want to look at the rebase.autostash option (since Git 2.6)

> > The problem is that, according to David K, there's only one stash stack,
> > so it would be very inconvenient having to keep track of which entries in
> > this stack belong to which branches.

> David Kastrup also suggested to commit your changes before switching
> branches, I wonder why you ignored his advice.

It wouldn't work well for me.  The word "commit" has a meaning,
something like "hand over on a permanent basis".  When you make a
"commitment", you are pledging your honour that you will stand behind
what you have committed.  What "commit" _doesn't_ mean is "temporarily
store because there's nowhere better".  Of course there are ways of
undoing a commit if it was done by mistake.  But routinely to commit to
something with the intention of repudiating it later is an abuse.  It is
the sort of thing politicians do.

Committed software and work in progress are two different categories of
code.  To confuse them must lead to trouble.

If I were were to commit unfinished changes just for lack of somewhere
proper to store them, inevitably some of these changes would find
themselves becoming permanent, embarassingly so.  Having continually to
remember to cancel a commit each time I change branches would be an
extra level of stress, of which there is already enough with git.

> Over the years I used several VC systems (CVS and subversion, among
> others) and git is, by far, the one that makes things easier when you
> don't want to lose your changes, committed or not.

git hid my changes, for what reason I don't know.

Right at the moment, 00:41 (which isn't a good time to make judgements),
I don't think I'm going to be using these branches, they're just to
awkward for the way I work.  Instead I'll use several distinct
repositories, minimising the potential for confusion and loss.  I'll
need a more intelligent backup strategy than I've got at the moment, but
I can manage that.

> Finally, I wholeheartedly recommend to give Magit a try.

Sometime, maybe.  Trouble is, it's all more stuff to learn, and it might
not work well for me.

> [snip]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Git question: when using branches, how does git treat working files when changing branches?

[Dmitry Gutov]

On 10/29/2015 01:53 AM, Alan Mackenzie wrote:

> In other words, that first git
> checkout stashed my changes, it didn't discard them.

That's highly implausible. I've never seen 'git checkout' do that, and 
'man git checkout' never mentions the word 'stash' either.

Re: Git question: when using branches, how does git treat working files when changing branches?

[Michael Heerdegen]

Alan Mackenzie <acm@muc.de> writes:

> Sometime, maybe.

I too think it's worth the time (now).

> Trouble is, it's all more stuff to learn, and it might not work well
> for me.

But maybe it would work very well for you.

In the case of git, you have huge man pages that explain tons of options
using terms that are defined nowhere; any command can do a variety of
quite different things that one can hardly remember.

With Magit, you don't need to remember git command options.  You don't
even have to remember lots of magit command names and key bindings,
because most stuff is called via self-explanatory popups.

So you would probably save much time in the midterm.  Once you have used
the (interactive) log where you can just hit RET on a commit and see the
diff and the commit message, or used Ediff to stash, you'll never want
to miss that.

In the case of stashing: Just hit z z RET and you have a stash
named "on [branch] [commit]" whose origin is obvious.

Mmh, it's 1:28 now...


Regards,

Michael.

Re: Git question: when using branches, how does git treat working files when changing branches?

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> diff and the commit message, or used Ediff to stash, you'll never want
                                                ^^^^^
Eh, "stage" of course, sorry.


Michael.

Re: Git question: when using branches, how does git treat working files when changing branches?

[Yuri Khan]

On Thu, Oct 29, 2015 at 5:53 AM, Alan Mackenzie <acm@muc.de> wrote:

>> David Kastrup also suggested to commit your changes before switching
>> branches, I wonder why you ignored his advice.
>
> It wouldn't work well for me.  The word "commit" has a meaning,
> something like "hand over on a permanent basis".  When you make a
> "commitment", you are pledging your honour that you will stand behind
> what you have committed.  What "commit" _doesn't_ mean is "temporarily
> store because there's nowhere better".  Of course there are ways of
> undoing a commit if it was done by mistake.  But routinely to commit to
> something with the intention of repudiating it later is an abuse.  It is
> the sort of thing politicians do.

In Git, committing is actually *the* easiest solution for the general
problem of tracking uncommitted changes per-branch.

In fact, “git stash” does just that: It creates two new commit objects
(one for the working copy state, the other for the staging area state)
on an unnamed branch starting at your current commit, and records the
hash of the second of those commits in .git/refs/stash and in
.git/logs/refs/stash.

The former file is just a pointer (reference) to the last stash made.
The latter is the list of all existing stashes, typically used in
stack discipline (but “git stash pop” accepts an optional argument
specifying which stash to pop).

A repository browser such as “gitk --all” will show you stashes at the
commits they were made from.


Your solution of making a diff file will also work. It will also be a
non-Git reimplementation of an existing Git feature (stashing), and
will have all its deficiencies (tracking difficulties) and then some
(e.g. an external diff file does not automatically state which commit
it was made from).

Re: Git question: when using branches, how does git treat working files when changing branches?

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Óscar.
>
> On Wed, Oct 28, 2015 at 11:59:03PM +0100, Óscar Fuentes wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> Joining the emacs-devel git hot line...
>
>> >> By default git will complain if changing branches would revert
>> >> uncommitted changes.
>
>> > OK, I started with a test repository, with some changes in (which I saved
>> > in a diff file).  After listing the available branches, and chosing one
>> > at random, I did
>> >     $ git checkout /origin/master
>> > , and got some message or other about a detached head.  Without doing
>> > anything else I then switched back with
>> >     $ git checkout master.
>
>> > git status now reports that the working directory is "clean".  So one of
>> > these two operations has discarded my changes.
>
>> This is hard to believe, so I tried your steps:
>
>> oscar@qcore:~/dev/emacs/emacs$ git checkout /origin/master
>> fatal: Could not switch to '/origin/': No such file or directory
>
>> As you can see, your first command fails to complete. I requested this
>> on a previous question of yours about git and I request it again: please
>> post the *exact* commands and its output. Otherwise, claims like what
>> you made above are dubious, at best.
>
> As you probably could guess, "/origin/master" was a typo, and the actual
> text was "origin/master".  It's getting quite late.
>
> Having a look at my series of commands after the first git checkout, I
> in fact did a git stash list.  I don't think that list was empty when I
> typed that command.  It isn't empty now.  In other words, that first git
> checkout stashed my changes, it didn't discard them.  It may have told
> me, it might not have.

It most certainly would not have told you since a checkout does not
magically stash things.  More likely you forget the "list" part and
typed just

git stash

or a variation thereof.

> It wouldn't work well for me.  The word "commit" has a meaning,
> something like "hand over on a permanent basis".  When you make a
> "commitment", you are pledging your honour that you will stand behind
> what you have committed.

Nope, that's what git commit -s is for (Signed-off-by: footer).

> What "commit" _doesn't_ mean is "temporarily store because there's
> nowhere better".

You are working with a distributed version control system.  It means
exactly that since you are working with your _private_ repository.
Anything non-trivial I push has actually seen a number of git commit
--amend and git rebase -i reorganizations so that what I end up pushing
is _polished_.

The most important tool of the mathematician and programmer is the
wastebasket, the most important tool of a distributed version control
system is local commits.

You are not understanding your tool if you insist on using it like CVS,
and you are making life harder for yourself (since you need to get
everything right the first try) and everybody else (since you won't get
everything right the first try).

> Of course there are ways of undoing a commit if it was done by
> mistake.  But routinely to commit to something with the intention of
> repudiating it later is an abuse.  It is the sort of thing politicians
> do.

No.  No, no, no.  Absolutely no.  The commits in a distributed version
control system are yours only.  It isn't an abuse of the creative
process to make your first written pages match the last written pages as
if you exactly knew which words you were going to write.

The sequence of commits is supposed to tell a story, not be a witness to
how you came up with the story.

Nobody wants to buy a book where the author handed in his wastebasket as
part of the manuscript.

> Committed software and work in progress are two different categories
> of code.  To confuse them must lead to trouble.

Commits are work in progress up to the point they are signed off on and
pushed to a central repository or offered to the public in some other
way.  Even then, review processes might very well change the sequence of
commits into something more sensible before they get accepted into
something less ephemeral than a review branch.

> If I were were to commit unfinished changes just for lack of somewhere
> proper to store them, inevitably some of these changes would find
> themselves becoming permanent, embarassingly so.

So read the stuff before pushing it upstream.  That's just common sense.

> Having continually to remember to cancel a commit each time I change
> branches would be an extra level of stress, of which there is already
> enough with git.

Why would you cancel a commit?  That does not make sense.

> git hid my changes, for what reason I don't know.

If your shell has a history command, I'm pretty sure that there will be
an explicit hint about why "git" "hid" your changes.

-- 
David Kastrup

Re: Git question: when using branches, how does git treat working files when changing branches?

[Alan Mackenzie]

Hello, David.

On Thu, Oct 29, 2015 at 09:21:02AM +0100, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > Having a look at my series of commands after the first git checkout, I
> > in fact did a git stash list.  I don't think that list was empty when I
> > typed that command.  It isn't empty now.  In other words, that first git
> > checkout stashed my changes, it didn't discard them.  It may have told
> > me, it might not have.

> It most certainly would not have told you since a checkout does not
> magically stash things.  More likely you forget the "list" part and
> typed just

> git stash

> or a variation thereof.

I think it's quite likely I did.  I can't remember any more.  Apologies
for stirring things up.

> > It wouldn't work well for me.  The word "commit" has a meaning,
> > something like "hand over on a permanent basis".  When you make a
> > "commitment", you are pledging your honour that you will stand behind
> > what you have committed.

> Nope, that's what git commit -s is for (Signed-off-by: footer).

I was talking about the English word, not the use git makes of it.

> > What "commit" _doesn't_ mean is "temporarily store because there's
> > nowhere better".

> You are working with a distributed version control system.  It means
> exactly that since you are working with your _private_ repository.
> Anything non-trivial I push has actually seen a number of git commit
> --amend and git rebase -i reorganizations so that what I end up pushing
> is _polished_.

It would be equally polished if you simply committed it when it was
ready.  git commit --amend, and friends, don't polish code.

> The most important tool of the mathematician and programmer is the
> wastebasket, the most important tool of a distributed version control
> system is local commits.

A commit should have a meaning.  A repository filled up with commit
messages like "Commit necessitated by git before switching branches." is
not going to make thrilling reading at a later date.

> You are not understanding your tool if you insist on using it like CVS,
> and you are making life harder for yourself (since you need to get
> everything right the first try) and everybody else (since you won't get
> everything right the first try).

Whether one commits after every single character change, or once when
work is completed, or anything in between, the quality of the work
depends only on the skill deployed in its implementation and the
conscientiousness of its testing.

> > Of course there are ways of undoing a commit if it was done by
> > mistake.  But routinely to commit to something with the intention of
> > repudiating it later is an abuse.  It is the sort of thing politicians
> > do.

> No.  No, no, no.  Absolutely no.  The commits in a distributed version
> control system are yours only.

They aren't.  If they were mine, I could chose to expunge an arbitrary
commit from the repository, clearing both file content and the log of
dross.  Commits actually belong to the repository, which imposes
stringent restrictions upon what can be done with them.

> It isn't an abuse of the creative process to make your first written
> pages match the last written pages as if you exactly knew which words
> you were going to write.

> The sequence of commits is supposed to tell a story, not be a witness to
> how you came up with the story.

> Nobody wants to buy a book where the author handed in his wastebasket as
> part of the manuscript.

Nobody wants to buy a novel where "I woke up at 6:30, had a shower, got
shaved, got dressed, had breakfast then went to work." appears three
times in every chapter.  Similarly, if I'm examining a git repository
log, I don't want to have to ignore dross like "Commit necessitated by
git ...." messages.  A commit should mean something.

> > Committed software and work in progress are two different categories
> > of code.  To confuse them must lead to trouble.

> Commits are work in progress up to the point they are signed off on and
> pushed to a central repository or offered to the public in some other
> way.  Even then, review processes might very well change the sequence of
> commits into something more sensible before they get accepted into
> something less ephemeral than a review branch.

Yes.

> > If I were were to commit unfinished changes just for lack of somewhere
> > proper to store them, inevitably some of these changes would find
> > themselves becoming permanent, embarassingly so.

> So read the stuff before pushing it upstream.  That's just common sense.

I've pushed silly commits upstream before.  Commits like merges in my own
repository.  There might be ways of avoiding these, but none of the
documentation I've read has made it obvious how.

> > Having continually to remember to cancel a commit each time I change
> > branches would be an extra level of stress, of which there is already
> > enough with git.

> Why would you cancel a commit?  That does not make sense.

I would want to cancel a "Commit necessitated by git before changing
branches" type commit so as not to fill up the repository with dross.

Like I said last night, I think I'm just going to use several
repositories, each cloned from my main master, rather than several
branches within one repository.  After all, I have a Terabyte of disk
space.

Conceptually, working files are associated with a particular branch, not
the repository as a whole, and git does not handle working files well.  I
doubt any other VCS handles them any better.  (Is this what Michael
Jackson, an author of a structured programming book, used to call a
"structure clash"?)  Committing working files in an arbitrary state in
order to swap branches is a workaround, not a feature.  The bug it works
around is the failure properly to associate working files with the
pertinent branch.

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Git question: when using branches, how does git treat working files when changing branches?

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, David.
>
> On Thu, Oct 29, 2015 at 09:21:02AM +0100, David Kastrup wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > It wouldn't work well for me.  The word "commit" has a meaning,

Slowly I am suspecting you are trying hard to make _both_ words in "git
commit" have a meaning.  Do you also try to make your mouse squeek by
removing the oil in its bearings?

>> > something like "hand over on a permanent basis".  When you make a
>> > "commitment", you are pledging your honour that you will stand behind
>> > what you have committed.
>
>> Nope, that's what git commit -s is for (Signed-off-by: footer).
>
> I was talking about the English word, not the use git makes of it.

It is a waste of time trying to teach a computer utility the meaning of
English by example.

Seriously, get a grip.  The meaning of talking to a computer lies in
what the computer does in consequence, not in how you say it.  You would
not write a program in C with array indices starting at 1 just because
the mathematical indices start at 1.

That you ascribe some particular meaning to "commit" in English common
language does not change one iota of what "git commit" does.

>> > What "commit" _doesn't_ mean is "temporarily store because there's
>> > nowhere better".
>
>> You are working with a distributed version control system.  It means
>> exactly that since you are working with your _private_ repository.
>> Anything non-trivial I push has actually seen a number of git commit
>> --amend and git rebase -i reorganizations so that what I end up
>> pushing is _polished_.
>
> It would be equally polished if you simply committed it when it was
> ready.  git commit --amend, and friends, don't polish code.

Sorry, but that's hogwash.  Unless you commit everything habitually in a
single humongous commit rather than in a sequence if individually
reviewable logical steps.  In which case you should change your habits
for the sake of reviewers and readers.

>> The most important tool of the mathematician and programmer is the
>> wastebasket, the most important tool of a distributed version control
>> system is local commits.
>
> A commit should have a meaning.  A repository filled up with commit
> messages like "Commit necessitated by git before switching branches."
> is not going to make thrilling reading at a later date.

You are _not_, I repeat _not_ listening.  I described exactly how you
later continue work.  You choose to ignore what I wrote in order to make
a point of Git using English differently from how you'd want to
interpret it.  That's nothing short of petulant.

>> You are not understanding your tool if you insist on using it like
>> CVS, and you are making life harder for yourself (since you need to
>> get everything right the first try) and everybody else (since you
>> won't get everything right the first try).
>
> Whether one commits after every single character change, or once when
> work is completed, or anything in between, the quality of the work
> depends only on the skill deployed in its implementation and the
> conscientiousness of its testing.

Part of the "implementation" is structuring your work into usefully
reviewable and understandable bits.

>> > Of course there are ways of undoing a commit if it was done by
>> > mistake.  But routinely to commit to something with the intention
>> > of repudiating it later is an abuse.  It is the sort of thing
>> > politicians do.
>
>> No.  No, no, no.  Absolutely no.  The commits in a distributed
>> version control system are yours only.
>
> They aren't.  If they were mine, I could chose to expunge an arbitrary
> commit from the repository, clearing both file content and the log of
> dross.

You certainly can do so with your own repository.  It doesn't happen
easily, but everything not reachable via branches is cleaned out after a
grace period of 3 months.  And of course you can speed this up to "right
now" in case you committed sensitive data or wagonloads of crud.

But even if you don't work with the full-steam cleanup tools, people
will have to actually know commit-ids in order to access stuff from your
repository that is no longer reachable, at least when they are working
with the standard communication channels without direct access to the
repository.

> Commits actually belong to the repository, which imposes stringent
> restrictions upon what can be done with them.

You are confused.  There is no restriction whatsoever to what you can do
to commits in _your_ repository.

>> It isn't an abuse of the creative process to make your first written
>> pages match the last written pages as if you exactly knew which words
>> you were going to write.
>
>> The sequence of commits is supposed to tell a story, not be a witness to
>> how you came up with the story.
>
>> Nobody wants to buy a book where the author handed in his wastebasket as
>> part of the manuscript.
>
> Nobody wants to buy a novel where "I woke up at 6:30, had a shower, got
> shaved, got dressed, had breakfast then went to work." appears three
> times in every chapter.

That's why you use git rebase -i and git commit --amend in order to fix
your submission before you submit it.

> Similarly, if I'm examining a git repository log, I don't want to have
> to ignore dross like "Commit necessitated by git ...." messages.  A
> commit should mean something.

Please learn to work with git rebase -i at the very least, even if you
refuse to learn about git commit --amend.

Your arguments are ridiculously wrong and based on juggling with words
rather than bothering to learn what they mean in the context of working
with Git.

Take a look at, say,
<URL:https://code.google.com/p/lilypond/issues/detail?id=4357#c33>.  Do
you want to tell me that you get a logical structure of commits like
that right at first try, without ever having to go back?

Do you think you are doing anybody a favor by dumping work like that in
a single commit, even when parts of that commit would have been
auto-generated and needed preparatory and conclusive work?

>> > If I were were to commit unfinished changes just for lack of somewhere
>> > proper to store them, inevitably some of these changes would find
>> > themselves becoming permanent, embarassingly so.
>
>> So read the stuff before pushing it upstream.  That's just common sense.
>
> I've pushed silly commits upstream before.

So you insist that once you have a silly commit, you do not want to fix
it?  But rather push it?  As a favor to whom?

> Commits like merges in my own repository.  There might be ways of
> avoiding these, but none of the documentation I've read has made it
> obvious how.

You rebase.

>> > Having continually to remember to cancel a commit each time I change
>> > branches would be an extra level of stress, of which there is already
>> > enough with git.
>
>> Why would you cancel a commit?  That does not make sense.
>
> I would want to cancel a "Commit necessitated by git before changing
> branches" type commit so as not to fill up the repository with dross.

I repeat: if you refuse to learn about git commit --amend as well as git
rebase -i, you don't have what it takes to participate in a meaningful
discussion about workflows.

> Like I said last night, I think I'm just going to use several
> repositories, each cloned from my main master, rather than several
> branches within one repository.  After all, I have a Terabyte of disk
> space.

You'll find that this comes with its own problems.  It has its place
(and you'll find the disk space impact pretty tolerable since Git
defaults to making hard links between cloned repositories on the same
drive), but it's not a one-size-fits all solution.  In particular if you
are working on several different angles to the same problem, being able
to merge, rebase, cherry-pick between approaches is useful and requires
your stuff to be in the same repository.

> Conceptually, working files are associated with a particular branch,
> not the repository as a whole, and git does not handle working files
> well.

Shrug.  man git-worktree should help you.

> I doubt any other VCS handles them any better.  (Is this what Michael
> Jackson, an author of a structured programming book, used to call a
> "structure clash"?)  Committing working files in an arbitrary state in
> order to swap branches is a workaround, not a feature.

Again, your insistence of interpreting Git's actions and related
workflows solely based on the common English meaning of parts of its
command names is plain silly.

> The bug it works around is the failure properly to associate working
> files with the pertinent branch.

At some point of time you should develop a theory as to why Git actually
managed to become the most popular version control system in spite of
the meaning of its commands not being obvious as soon as you can wave
around an English language certificate.

-- 
David Kastrup

Re: Git question: when using branches, how does git treat working files when changing branches?

[Eli Zaretskii]

> Date: Wed, 28 Oct 2015 23:53:40 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > David Kastrup also suggested to commit your changes before switching
> > branches, I wonder why you ignored his advice.
> 
> It wouldn't work well for me.  The word "commit" has a meaning,
> something like "hand over on a permanent basis".  When you make a
> "commitment", you are pledging your honour that you will stand behind
> what you have committed.  What "commit" _doesn't_ mean is "temporarily
> store because there's nowhere better".  Of course there are ways of
> undoing a commit if it was done by mistake.  But routinely to commit to
> something with the intention of repudiating it later is an abuse.  It is
> the sort of thing politicians do.
> 
> Committed software and work in progress are two different categories of
> code.  To confuse them must lead to trouble.

I suggest that you rethink this concept.  What you describe makes
sense when using centralized VCS, where "commit" goes upstream and is
immediately made public; doing this with unfinished work is unwise, of
course.

But you are using a dVCS, where commits are local until pushed.
Moreover, I understand that your entire branch is local, which means
none of what you do on that branch is visible to anyone but you.  This
makes the grave meaning you seem to assign to a commit null and void.

In a dVCS, local commits are best used for your own personal tracking
of your work, a kind of log that is automagically linked to the code
changes you make as you go.  Which means, in particular, that you and
you alone determine when it's okay to commit, and the commit log
messages don't have to make sense to anyone but you.

Given all that, committing frequently on such a branch makes a lot of
sense, because it lets you track your work with much more fine-grained
resolution.  An immediate benefit is that you no longer need to depend
on your memory to remember when and why you made some change -- you
can see it with VCS commands, and you can put into the log messages
the rationale that will explain the "why" part.  Another significant
benefit is that bisecting bugs you find later gives much more precise
results, and, with good log messages, it's easy to quickly understand
why you made the offending change, and how to test the alternative
solution to be sure it doesn't break whatever reason that led you to
that change.

It goes without saying that even with this workflow, some commits are
"more equal" than others.  Examples include commits you make after you
finish testing some of your code, commits you make after a meaningful
part of the feature is done, etc.  But it's easy to indicate the
significance of these commits in the log messages, so they are later
easily identified in the commit log.  IOW, you have all the means to
support both "meaningful" commits and the less-meaningful ones.  The
latter kinds could have a log message such as

  Finished coding FOO, but didn't test it yet.

or even

  Wrote function 'foobar', but didn't try to compile it yet.

The messages make it clear these commits are unfinished WIP, but so
what? it's your own personal log that it's nobody's business to read.

> If I were were to commit unfinished changes just for lack of somewhere
> proper to store them, inevitably some of these changes would find
> themselves becoming permanent, embarassingly so.

This issue, if it bothers you, have an easy solution: when you are
done with your feature, instead of merging it onto master, _rebase_ it
on the master branch using Git's "rebase -i" command.  That allows you
to squash all your local commits into a single commit on master.  (The
exact procedure can be found via Google and is described under
"Interactive Mode" on the "git rebase" man page; search for "squash"
in that description.)

FWIW, I'm generally not bothered to have my local commits be visible
after I merge the feature branch, so I just use "git merge".  But
that's me; I know that some people don't like to show their local
history, and prefer "rebase".

Bottom line, a dVCS gives you some useful new functionalities, and
some of that justifies rethinking your old habits, in order to make
you work more convenient.  I think this is one of them.

P.S. I see that David wrote something very similar in spirit.

Re: Git question: when using branches, how does git treat working files when changing branches?

[Eli Zaretskii]

> Date: Thu, 29 Oct 2015 12:35:54 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> A commit should have a meaning.  A repository filled up with commit
> messages like "Commit necessitated by git before switching branches." is
> not going to make thrilling reading at a later date.

It is meaningful to you.  If you don't want anyone else to see such
log messages, you can squash these commits during the final rebase.

> > No.  No, no, no.  Absolutely no.  The commits in a distributed version
> > control system are yours only.
> 
> They aren't.

The commits you make on your local branch are _only_ yours, and no one
else's.

> If they were mine, I could chose to expunge an arbitrary
> commit from the repository, clearing both file content and the log of
> dross.  Commits actually belong to the repository, which imposes
> stringent restrictions upon what can be done with them.

But "git rebase -i" and similar features allow you to rewrite history
when merging to a public branch, if you so wish.

> Like I said last night, I think I'm just going to use several
> repositories, each cloned from my main master, rather than several
> branches within one repository.  After all, I have a Terabyte of disk
> space.

That's your prerogative, of course, but you should know that by doing
so you make your life more inconvenient than it could have been.

On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Alan Mackenzie]

Hello, David.

On Thu, Oct 29, 2015 at 02:21:47PM +0100, David Kastrup wrote:
> At some point of time you should develop a theory as to why Git actually
> managed to become the most popular version control system in spite of
> the meaning of its commands not being obvious as soon as you can wave
> around an English language certificate.

I've been wondering about git's popularity for some long time.  That
git's complexity is not necessary in a powerful VCS is demonstrated by
the counterexamples of hg and (to a lesser extent) bzr.

git had (and has) Linux behind it, thus giving a lot of hackers being
forced to learn git early on.  This surely gave git a huge advantage in
numbers at the start of the competition.

But I think the real reason is that there are lots of hackers around,
possibly mainly the younger ones, who revel in their mastery of
complexity rather than attempting to sidestep and avoid it.

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, David.
>
> On Thu, Oct 29, 2015 at 02:21:47PM +0100, David Kastrup wrote:
>> At some point of time you should develop a theory as to why Git actually
>> managed to become the most popular version control system in spite of
>> the meaning of its commands not being obvious as soon as you can wave
>> around an English language certificate.
>
> I've been wondering about git's popularity for some long time.  That
> git's complexity is not necessary in a powerful VCS is demonstrated by
> the counterexamples of hg and (to a lesser extent) bzr.

Emacs finally gave up on Bzr.  XEmacs does use Hg but Stephen does not
make it sound like the project would be necessarily taking the same
choices given today's experience.

> git had (and has) Linux behind it, thus giving a lot of hackers being
> forced to learn git early on.  This surely gave git a huge advantage
> in numbers at the start of the competition.

I think you severely overestimate the number of Linux kernel hackers and
their fanout to other projects.

> But I think the real reason is that there are lots of hackers around,
> possibly mainly the younger ones, who revel in their mastery of
> complexity rather than attempting to sidestep and avoid it.

Thanks for the compliment, but I don't think it's borne out by reality.
Sites like GitHub have not become popular because they make it hard or
incomprehensible to get work done.

-- 
David Kastrup

Re: Git question: when using branches, how does git treat working files when changing branches?

[Davis Herring]

> It wouldn't work well for me.  The word "commit" has a meaning,
> something like "hand over on a permanent basis".

And, with a limited scope, that's what "git commit" does: hands over
your code (actually the "index" or "staging area") to the repository
permanently (unless/until countermanded, of course).  That the
destination is "your repository" rather than "the Emacs central
repository" does not prevent its being a commit, but it does (as has
been discussed to death elsewhere on this thread) change the social
implications of the commit drastically.

> If I were were to commit unfinished changes just for lack of somewhere
> proper to store them, inevitably some of these changes would find
> themselves becoming permanent, embarassingly so.  Having continually to
> remember to cancel a commit each time I change branches would be an
> extra level of stress, of which there is already enough with git.

If you want, maintain (local) branches named things like "eligible" and
"scratch" (perhaps such a pair per logical change you're working on).
You can then feel free to commit regardless of quality to scratch,
knowing that you would never push such a branch.  That frees your
attention to switch branches.  When you come back, you can rebase/amend
the scratch commit(s) as needed, then put them onto eligible.  It's a
separate question of when "eligible" is complete enough to be worth
pushing to a public location.

The change (for any given piece of work) from scratch to eligible is
then a question of quality, whereas from eligible to Savannah is a
question of completeness.  It's all reasonably self-explanatory once you
choose your names.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> I've been wondering about git's popularity for some long time. That git's
> complexity is not necessary in a powerful VCS is demonstrated by the
> counterexamples of hg and (to a lesser extent) bzr.

One thing to keep in mind is that Git has several distinct layers:

  - The data model
  - The plumbing
  - The porcelain

The data model is *incredibly* simple. This, I think, is Git's main
attraction. I've written about the data model in my article "Git from the
Bottom Up", and also via a Haskell library for interacting with this model,
called gitlib (http://hackage.haskell.org/package/gitlib).

The plumbing is... unintuitive to say the least. The porcelain is... fairly
bad, but slowly getting better.

The thing is, you can throw away the plumbing *and* the porcelain, and still
have access to your data. There is the C library libgit2 you can use,
completely independent from the git CLI tool. And it's *fast* for doing
large-scale manipulation (gitlib is able to optionally make use of it).

For engineers who like to dig into things, Git looks beautiful; for users who
want to use things, it often looks terrible.

John

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Paul Eggert]

Alan Mackenzie wrote:
> I think the real reason is that there are lots of hackers around,
> possibly mainly the younger ones, who revel in their mastery of
> complexity rather than attempting to sidestep and avoid it.

I prefer Git not because it's complicated, but because it's free and reliable 
and fast and used by hackers that I collaborate with and whose judgment I trust.

I doubt that Git's popularity comes from youngsters wanting to conspicuously 
display their complexity-mastering skills. My youthful colleagues generally have 
better things to do.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[joakim]

Alan Mackenzie <acm@muc.de> writes:

> Hello, David.
>
> On Thu, Oct 29, 2015 at 02:21:47PM +0100, David Kastrup wrote:
>> At some point of time you should develop a theory as to why Git actually
>> managed to become the most popular version control system in spite of
>> the meaning of its commands not being obvious as soon as you can wave
>> around an English language certificate.
>
> I've been wondering about git's popularity for some long time.  That
> git's complexity is not necessary in a powerful VCS is demonstrated by
> the counterexamples of hg and (to a lesser extent) bzr.
>
> git had (and has) Linux behind it, thus giving a lot of hackers being
> forced to learn git early on.  This surely gave git a huge advantage in
> numbers at the start of the competition.
>
> But I think the real reason is that there are lots of hackers around,
> possibly mainly the younger ones, who revel in their mastery of
> complexity rather than attempting to sidestep and avoid it.

http://xkcd.com/1597/

>
>> -- 
>> David Kastrup

-- 
Joakim Verona

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Alan Mackenzie]

Hello, Paul.

On Fri, Oct 30, 2015 at 12:48:44AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > I think the real reason is that there are lots of hackers around,
> > possibly mainly the younger ones, who revel in their mastery of
> > complexity rather than attempting to sidestep and avoid it.

> I prefer Git not because it's complicated, but because it's free and reliable 
> and fast and used by hackers that I collaborate with and whose judgment I trust.

But other systems (notably Mercurial) are also free, reliable and fast.
What you seem to be saying is you use git because "everybody" else does.

> I doubt that Git's popularity comes from youngsters wanting to conspicuously 
> display their complexity-mastering skills. My youthful colleagues generally have 
> better things to do.

Have you any theory for why git has become dominant, despite its clear
demerits?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Fri, Oct 30, 2015 at 12:48:44AM -0700, Paul Eggert wrote:
>
>> I doubt that Git's popularity comes from youngsters wanting to
>> conspicuously display their complexity-mastering skills. My youthful
>> colleagues generally have better things to do.
>
> Have you any theory for why git has become dominant, despite its clear
> demerits?

Well, I don't know about Paul's youthful colleagues, but I think that at
least this old hand has better things to do than participating in a
"discussion" with the only goal of having Alan parading his made-up mind
around.

If you have any actual question about Git's operation, feel free to ask,
preferably with a shell history in order to back up your fantastic
stories about Git's random behavior.

Running your shell from within Emacs with

M-x shell RET

would be optimal for keeping a record but would require a sensible
setting of GIT_PAGER if you don't want to go nuts (I once wrote up some
script I called emacs-pager for that purpose using auto-revert-tail-mode
but it was not all that fabulous but marginable more useful than just
using "cat").  A shell history may be enough, however.

-- 
David Kastrup

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Eli Zaretskii]

> Date: Fri, 30 Oct 2015 09:27:47 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> Have you any theory for why git has become dominant, despite its clear
> demerits?

For the same reason MS Word has become dominant: it's a de-facto
standard, so you've got to use it, whether you like it or not.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Yuri Khan]

On Fri, Oct 30, 2015 at 3:09 PM,  <joakim@verona.se> wrote:
> Alan Mackenzie <acm@muc.de> writes:
>> I've been wondering about git's popularity for some long time.  That
>> git's complexity is not necessary in a powerful VCS is demonstrated by
>> the counterexamples of hg and (to a lesser extent) bzr.
>
> http://xkcd.com/1597/

This comic actually explains it quite well. Some of us like Git
because it has a simple and elegant core, and we perceive the
particular UI surrounding that core as mildly annoying but
inconsequential in the long run.

Mercurial’s and Bazaar’s cores, on the other hand, are much more
complicated, and user-friendly UI (if any) is not sufficient to redeem
them.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Thu, Oct 29, 2015 at 6:02 PM, Alan Mackenzie <acm@muc.de> wrote:

> I've been wondering about git's popularity for some long time.  That
> git's complexity is not necessary in a powerful VCS is demonstrated by
> the counterexamples of hg and (to a lesser extent) bzr.
>
> git had (and has) Linux behind it, thus giving a lot of hackers being
> forced to learn git early on.  This surely gave git a huge advantage in
> numbers at the start of the competition.

Of course there's not a single factor that made git so popular, but there
are a few ones that surely weighted in the final situation.

In no particular order:

- Not only git has Linux behind, but it has *Linus* behind. He is revered
by a lot of hackers, who give a lot of weight to his opinions.
- It's *very* fast.
- Its foundation (its data model) is seen as elegant, even if its UI is
less than friendly.
- It's very flexible and hackable, and built from basic components, in the
"software tools" spirit.
- It was perceived as a David vs Goliath thing. BitKeeper pulls out, Linus
builds a replacement in a few days.
- It really hadn't much competition. Subversion, though good, is not
distributed. Bazaar was too slow. Mercurial had no critical mass. Other
alternatives (svk, Darcs. etc.) were even more marginal.
- It had, since the beginning, an active development community. Other dVCS
have smaller development communities (think Bazaar...) so it has progressed
at a good pace.

All of these (IMHO, of course) and others that I forget surely contributed
to its gaining momentum.

Whether git is the best tool or not is largely irrelevant now. I think even
detractors have to admit it works well enough and it's fast and responsive,
and even its more ardent evangelists won't discuss its abysmal UI (whenever
I'm starting to like it, I do "git help log" and I'm suddenly cured).

My 0.02¢

      Juanma

[-- Attachment #2: Type: text/html, Size: 3207 bytes --]

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Thu, Oct 29, 2015 at 6:02 PM, Alan Mackenzie <acm@muc.de> wrote:
>
>> I've been wondering about git's popularity for some long time.  That
>> git's complexity is not necessary in a powerful VCS is demonstrated by
>> the counterexamples of hg and (to a lesser extent) bzr.
>>
>> git had (and has) Linux behind it, thus giving a lot of hackers being
>> forced to learn git early on.  This surely gave git a huge advantage in
>> numbers at the start of the competition.
>
> Of course there's not a single factor that made git so popular, but there
> are a few ones that surely weighted in the final situation.
>
> In no particular order:
>
> - Not only git has Linux behind, but it has *Linus* behind. He is revered
> by a lot of hackers, who give a lot of weight to his opinions.
> - It's *very* fast.
> - Its foundation (its data model) is seen as elegant, even if its UI is
> less than friendly.
> - It's very flexible and hackable, and built from basic components, in the
> "software tools" spirit.
> - It was perceived as a David vs Goliath thing. BitKeeper pulls out, Linus
> builds a replacement in a few days.
> - It really hadn't much competition. Subversion, though good, is not
> distributed. Bazaar was too slow. Mercurial had no critical mass. Other
> alternatives (svk, Darcs. etc.) were even more marginal.
> - It had, since the beginning, an active development community. Other dVCS
> have smaller development communities (think Bazaar...) so it has progressed
> at a good pace.
>
> All of these (IMHO, of course) and others that I forget surely contributed
> to its gaining momentum.

When did this stop being the Emacs developer list and became fairytale
central?

The rise of Git to its current prominence did not occur while Linus was
in control of it but far, far later.

Emacs has been developed as tarballs from private directories, using
RCS, CVS, Arch (non-canonically, but every Emacs source file at least
had an Arch tag) and eventually Bazaar.  None of those choices were
unreasonable considering the respective state of the art.  Nor was the
choice of XEmacs to change from CVS (?) to Mercurial.  All of the above
cited reasons are not really in any temporal proximity to Git becoming a
mainstream entity.

What's more relevant is the rise of GitHub vs Launchpad as a major
hosting point, and a main factor for that has been that Git's C and
POSIX history and data formats and workflows made it reasonably
straightforward to map to servers, resulting in dozens of Git-based web
solutions fighting it out.

GitHub is just the most prominent survivor, and unfortunately a
proprietary one.  There never was a similar tug-o-war for web solutions
based on a particular other version control system.

> Whether git is the best tool or not is largely irrelevant now. I think
> even detractors have to admit it works well enough and it's fast and
> responsive, and even its more ardent evangelists won't discuss its
> abysmal UI (whenever I'm starting to like it, I do "git help log" and
> I'm suddenly cured).

For better or worse, the "user interface" that has won is GitHub.

-- 
David Kastrup

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On Fri, Oct 30, 2015 at 3:15 PM, David Kastrup <dak@gnu.org> wrote:

> When did this stop being the Emacs developer list and became fairytale
> central?

Quite a long time ago, I think.

> The rise of Git to its current prominence did not occur while Linus was
> in control of it but far, far later.

I wouldn't say "far, far later", but certainly, Linus passed git to Junio C
Hamano quite early on. Which doesn't mean that Linus' shadow doesn't loom
large over the whole issue.

> What's more relevant is the rise of GitHub vs Launchpad as a major
> hosting point

Oh, you're right, I forgot to mention GitHub, which obviously has had a big
influence. Though I doubt that Bazaar / Launchpad would've won the day even
if git / GitHub weren't there.

> For better or worse, the "user interface" that has won is GitHub.

As a though experiment, do you think GitHub, as a "user interface", would
be equally successful if underneath it was Bazaar?

But, really, the above was just my opinion, as I think I made clear. Fairy
tales, if you will. Not enough substance to extend this thread even further.

Thanks for your comments,

    Juanma

[-- Attachment #2: Type: text/html, Size: 1527 bytes --]

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Oct 30, 2015 at 3:15 PM, David Kastrup <dak@gnu.org> wrote:
>
>> What's more relevant is the rise of GitHub vs Launchpad as a major
>> hosting point
>
> Oh, you're right, I forgot to mention GitHub, which obviously has had a big
> influence. Though I doubt that Bazaar / Launchpad would've won the day even
> if git / GitHub weren't there.
>
>> For better or worse, the "user interface" that has won is GitHub.
>
> As a though experiment, do you think GitHub, as a "user interface",
> would be equally successful if underneath it was Bazaar?

I haven't ever used Bazaar so I'm not qualified to even deal with
hypotheticals.  From the discussion on the Emacs developer list, it has
been my impression that Bazaar's view of the repository history is to a
higher degree determined by the design underlying the actual Bazaar
tools, so a "just as GitHub" interface to Bazaar would likely feel like
a worse fit.

Again: that's pure speculation on my part, even more so than any
hypothetical is anyway.

And the amount of speculation does not actually get better by myself
never having used GitHub, either.

But I've collaborated with people who did, and their use of GitHub had
no impact on my work flows, and only marginally on theirs (as they could
not use the "Pull Request" folderol for incorporating patches of mine).

So a major point was that GitHub did not get in the way.  I'm not sure
that a "GitHub for Bazaar" would have been equally unobtrusive for
cooperating with "native" Bazaar users.

-- 
David Kastrup

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Paul Eggert]

On 10/30/2015 02:27 AM, Alan Mackenzie wrote:
> What you seem to be saying is you use git because "everybody" else does.

Not really.  The Git maintainer is a friend of mine: we worked together 
for many years building mostly-proprietary software. He's one of the 
best hackers I know.  Git in part uses implementation ideas that I was 
using before Git was a gleam in Linus Torvalds's eye. So I make no 
pretense of being impartial here. Nor do I use Git merely because 
"everybody" else does.

I partly use Emacs for the same reason I use Git. It's free and reliable 
and efficient and supported by hackers whose judgment I trust.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Stephen J. Turnbull]

Yuri Khan writes:

 > Mercurial’s and Bazaar’s cores, on the other hand, are much more
 > complicated,

+100  Both suffer badly from the Knuthian "root of all error".  The
insane complexity of Bazaar internals is half of what killed Bazaar.
(The other half, of course, is that almost all of its fans are like
Alan -- the last thing that they want to do is study their VCS, which
in combination with complexity preclude contribution -- and the rest
are "paperwork" refuseniks, so their contributions are refused.[1])

That doesn't seem to prevent Mercurial from being actively developed,
though.

 > and user-friendly UI (if any) is not sufficient to redeem them.

+1

I wouldn't go so far as to say "if any", but in my daily use, I find
that even though git starts out with a handicap (3 letters vs. 2 for
"hg"), I type fewer characters with git than with Mercurial.[2]  git is
more likely to DTRT for me without options than is Mercurial.  I
suspect that is true for enough users to make the "complexity of UI"
argument sort of miss the point.

One thing that Mercurial has that does seem like a clear advance in
usability over git is the "phase" concept.  I don't use it though, so
I don't value it and I can't say how somebody like Alan would value
it.


Footnotes: 
[1]  Granted, the Canonical CA was horrible (and probably still is):
it has an unrestricted grant of sublicense, so Canonical can include
your software in software you have to pay for and have none of the
software freedoms.

[2]  It occurs to me that one of the things I hated about both bzr and
hg was that a bare "$VCS commit" commits everything.  That is *almost
never* TRT for my workflow.  But I suspect that Alan loves that
feature, since he has a religious objection to commiting a workspace
that hasn't been polished to an optically perfect surface.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Eli Zaretskii]

> Date: Sat, 31 Oct 2015 12:16:29 +0900
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Alan Mackenzie <acm@muc.de>, David Kastrup <dak@gnu.org>, joakim@verona.se,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> [2]  It occurs to me that one of the things I hated about both bzr and
> hg was that a bare "$VCS commit" commits everything.  That is *almost
> never* TRT for my workflow.  But I suspect that Alan loves that
> feature, since he has a religious objection to commiting a workspace
> that hasn't been polished to an optically perfect surface.

It is a known psychological fact that after using some tool for a long
time, people begin liking or even loving it, no matter how horrible
that tool is.  In fact, people become fond of even the most hideous
misfeatures of that tool.  Otherwise, how to explain that people loved
DCL?

The above is an example.  The truth is that "$VCS commit" committing
all the changes _is_ TRT.  Why? because all the other VCSes before and
after Git do that, and because that's what a mere human would expect.
(I've made me an alias to do just that.)

More generally, Git's main problem is that it breaks almost every
human habit gained with the other VCSes: instead of an easily
remembered numerical version IDs you have those inhuman hashes and the
HEAD^^^^ and {m,n} thingies, instead of being able to say "commit" and
commit the entire changeset you need "git add" first, etc. etc.
_That_ is the single most important problem with Git that begets all
the other problems in usability and user-friendliness: it doesn't give
a damn about established VCS practices and mnemonics, and breaks them
all one after another.  It does that consciously and on purpose.  And
after all that, it expects me to like it.  Ha!

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> _That_ is the single most important problem with Git that begets all
> the other problems in usability and user-friendliness: it doesn't give
> a damn about established VCS practices and mnemonics, and breaks them
> all one after another.

That is also its biggest strength, because it opens up the possibility
to do new workflows that were cumbersome or impossible within the limits
of the established VCS practices.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

> It is a known psychological fact that after using some tool for a long
> time, people begin liking or even loving it, no matter how horrible
> that tool is.

I love Git. I don't think it seemed horrible when I didn't know anything
about it, coming from SVN as my first version control system.

> The above is an example.  The truth is that "$VCS commit" committing
> all the changes _is_ TRT.  Why? because all the other VCSes before and
> after Git do that, and because that's what a mere human would expect.
> (I've made me an alias to do just that.)
>
> More generally, Git's main problem is that it breaks almost every
> human habit gained with the other VCSes: instead of an easily
> remembered numerical version IDs you have those inhuman hashes and the
> HEAD^^^^ and {m,n} thingies, instead of being able to say "commit" and
> commit the entire changeset you need "git add" first, etc. etc.

I love all those things you mentioned. I have plenty of repositories in
a permanently dirty state, periodically staging and publishing only
parts of the changes, while permanently testing the rest until it's
ready. Actually, the ability to commit partial changes was the reason I
switched from SVN. All this was before I learned Magit, which made me
love Git even more.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> More generally, Git's main problem is that it breaks almost every
> human habit gained with the other VCSes: instead of an easily
> remembered numerical version IDs you have those inhuman hashes

Shrug.  In a distributed version control system, numerical version IDs
don't make sense.  Letting them make sense again requires beating some
sort of unified meaning into the distributed version graph that is not
inherently there, exactly because it is a distributed version control
system.  Git does not try to do it.  Other distributed version control
systems do, resulting in failure modes and/or merge complications that
are not obvious to people to whom linear numberings are obvious.

> and the HEAD^^^^ and {m,n} thingies, instead of being able to say
> "commit" and commit the entire changeset you need "git add" first,
> etc. etc.

CVS did not commit more than specified files.  So nothing new here.

> _That_ is the single most important problem with Git that begets all
> the other problems in usability and user-friendliness: it doesn't give
> a damn about established VCS practices and mnemonics, and breaks them
> all one after another.  It does that consciously and on purpose.  And
> after all that, it expects me to like it.  Ha!

Well, the point of Git's separate staging area is that it breaks the
established practice on _purpose_, but not out of _malice_.  The
resulting behavior is convenient as well as logical, and it is strictly
local (so does not affect the repository state or workflow at all and
consequently is orthogonal to most web interfaces).  And it is part of
the reason that people prefer Git over other "established VCS practices
and mnemonics" since those other version control systems refuse making
stuff more convenient out of principle.

Splitting operations into index operations and repository operations
means that when you look at the repository history, the additional index
stuff available for making local work more convenient does not need to
get taken into account.

So Git has an additional toolbox for preparing commits before they enter
the repository.  Web interfaces concerned with the repository might
choose to do something entirely different.  Read-only interfaces do not
even need to know anything about it and its workflow.

You can sort-of bypass it by using "git commit -a" all the time.

-- 
David Kastrup

Re: On the popularity of git

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > The truth is that "$VCS commit" committing all the changes _is_
 > TRT.  Why?

Because you're a former Department of Defense contractor used to
MIL-STD-498 processes and only commit after getting three signatures
on a paper form anyway?  Or you're Alan Mackenzie, Eli Zaretski, or
Richard Stallman, capable of effortlessly keeping a clean workspace
without ever having those embarrassing extraneous changes in it.

 > because all the other VCSes before and after Git do that,

As David points out SCCS, RCS, and CVS didn't do that.  SCCS and
RCS *could not*.  I don't recall what larch and its successors, or
Bitkeeper, did, but I don't think they did, either.

 > and because that's what a mere human would expect.

I love you too, Eli, but I'm not a genius programmer, and I'm just
disciplined enough that I can do without "git rebase -i" before
pushing -- but only because "git commit" doesn't DTWT.  I actually
have had to checkout the previous version into a new workspace and cp
the changed files over, then recommit (and delete the polluted branch)
before bzr and hg got their respective uncommit commands.  (There
probably was a better way but I was offline and impatient.  And as
much as I dislike that style, it hasn't prevented me from learning
"hg strip" and "bzr uncommit" respectively.)

 > (I've made me an alias to do just that.)
 > 
 > More generally, Git's main problem is that it breaks almost every
 > human habit gained with the other VCSes: instead of an easily
 > remembered numerical version IDs

True, for short-term memory.  Because I have to ask what revision I'm
on now and then do the relevant subtraction most of the time.  I never
have to do that with git.  I'm sure bzr and hg have shortcuts for that
now, but now I use those tools rarely enough that I needn't bother
finding a better way.

 > you have those inhuman hashes

Of course they're inhuman.  They're intended to be an approximation to
Goedel numbers.  Even Goedel didn't usually write formulas that way
(although Ramanujan may have ;-).  And SHAs are way better than those
Bizarre revids[1], which are the only stable way to refer to a Bazaar
revision.

 > and the HEAD^^^^ and {m,n} thingies,

You must detest Lisp, then, with its `cddr' and `nth'.  That's all
that HEAD~N means, you know; (nth N HEAD).  When I realized that,
that's when I fell in love with git.  The rest of the DAG traversal
algebra doesn't disturb me, I just ignore it (except for the
occasional use of @{N} and *very* rare uses of ^ other than as an
abbreviation for ~1).

 > instead of being able to say "commit" and commit the entire
 > changeset you need "git add" first, etc. etc.

Nonsense.  "git commit -a ..." has always committed all modified
files, and as far as I know there is no VCS that automatically adds
unknown files to a commit (even if they're not vcs-ignored).

 > _That_ is the single most important problem with Git that begets all
 > the other problems in usability and user-friendliness: it doesn't give
 > a damn about established VCS practices and mnemonics, and breaks them
 > all one after another.  It does that consciously and on purpose.  And
 > after all that, it expects me to like it.  Ha!

Now, now.  Don't anthropomorphize software.  The next thing you know,
you'll be opposing the GPL because "software wants to be free".

Seriously, I don't see any reason why *everybody* should like git.
But I can see lots of reasons why a whole lotta people would love it,
warts and all.  And ... I can see no good reason for Alan et al.  to
cause themselves pain repeatedly by not learning enough about git to
use it effectively.  They can learn, as you have.  They just refuse to.


Footnotes: 
[1]  Which made some sense in Arch.  But they're just weird in Bazaar.

Re: On the popularity of git

[Alan Mackenzie]

Hello, Stephen.

On Sat, Oct 31, 2015 at 12:16:29PM +0900, Stephen J. Turnbull wrote:
> Yuri Khan writes:

>  > Mercurial’s and Bazaar’s cores, on the other hand, are much more
>  > complicated,

> +100  Both suffer badly from the Knuthian "root of all error".  The
> insane complexity of Bazaar internals is half of what killed Bazaar.
> (The other half, of course, is that almost all of its fans are like
> Alan -- the last thing that they want to do is study their VCS, which
> in combination with complexity preclude contribution -- and the rest
> are "paperwork" refuseniks, so their contributions are refused.[1])

Just to clarify, I've never been a fan of bzr.  It took me some trouble
to learn, but only a reasonable amount of trouble.  The biggest
hindrance there was the vagueness of their documentation - it seemed
almost scared to say exactly what the program did.  But the trouble of
learning bzr was an order of magnitude less than that for git.

No, I don't want to become a VCS expert (or, as you put it, "study" my
VCS).  I studied hg, and it fell into place, mentally, without trouble.
I just want to be a user, as one can quite easily be a user of hg or
bzr.  Being a user of git involves learning its internal structures.
(Note the people recently emphasising the internal representation of a
git branch to me, talking about pointers to its tip, and so on.  I
really don't want to have to know about such stuff.)

It is evident that when the UI for git was "designed" nobody of any
experience (or taste) in UIs was involved in the process.  Nobody knew
when to say "stop!".  So there are _lots_ of commands, and the ones used
most often have 20, 30, 50 options to learn about, some of which do
several distinctly different things (e.g. git checkout).  A typical hg
command has, perhaps 4 or 5, or even 10.

If the git team had paid as much attention to UI as they did to elegant
internal structures, they would have had a world beater of a program.

> That doesn't seem to prevent Mercurial from being actively developed,
> though.

>  > and user-friendly UI (if any) is not sufficient to redeem them.

> +1

> I wouldn't go so far as to say "if any", but in my daily use, I find
> that even though git starts out with a handicap (3 letters vs. 2 for
> "hg"), I type fewer characters with git than with Mercurial.[2]  git is
> more likely to DTRT for me without options than is Mercurial.  I
> suspect that is true for enough users to make the "complexity of UI"
> argument sort of miss the point.

Not at all.  There are 20, 30, or 50 options which all consciously have
to be omitted.  Otherwise you are stumbling in the dark, or merely
learning sequences of commands by rote (as I have done), rather than
truly mastering them.

[ .... ]

> [2]  It occurs to me that one of the things I hated about both bzr and
> hg was that a bare "$VCS commit" commits everything.

But in both of them, the commit message template informed you which
files were being committed, giving you the opportunity to abort.

> That is *almost never* TRT for my workflow.  But I suspect that Alan
> loves that feature, since he has a religious objection to commiting a
> workspace that hasn't been polished to an optically perfect surface.

What, you mean as opposed to committing any old rubbish at the drop of a
hat?  No, that feature doesn't bother me one way or the other.  The
vagueness and uncertainty introduced by git's two stage committing, on
the other hand, is much unloved by me.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: On the popularity of git

[Dmitry Gutov]

On 10/31/2015 06:50 PM, Alan Mackenzie wrote:

> I just want to be a user, as one can quite easily be a user of hg or
> bzr.

Nobody's asking you to be a Git developer here. I know I'm not asking, 
nor am I one.

> Being a user of git involves learning its internal structures.
> (Note the people recently emphasising the internal representation of a
> git branch to me, talking about pointers to its tip, and so on.  I
> really don't want to have to know about such stuff.)

To a reasonably proficient Git user, that sounds like "I don't want to 
know what graphs are", or a C programmer saying they don't want to 
bother knowing about memory layout (that's a thing, right?).

This stuff is easy enough to learn that claims "I don't want to" don't 
sound compelling at all.

> It is evident that when the UI for git was "designed" nobody of any
> experience (or taste) in UIs was involved in the process.  Nobody knew
> when to say "stop!".  So there are _lots_ of commands, and the ones used
> most often have 20, 30, 50 options to learn about, some of which do
> several distinctly different things (e.g. git checkout).

You don't learn all commands and all options. You first figure out what 
you want to do, and then learn how to do it. Much easier.

> But in both of them, the commit message template informed you which
> files were being committed, giving you the opportunity to abort.

Guess what. Git does the same thing.

Just not in the Emacs interface provided by VC.

> The
> vagueness and uncertainty introduced by git's two stage committing,

No such thing.

Re: On the popularity of git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > No, I don't want to become a VCS expert (or, as you put it, "study" my
 > VCS).  I studied hg, and it fell into place, mentally, without trouble.

Weird.  I studied all three (in order to help write PEP 374), and they
just aren't different for any of the Python-Dev workflows that we
compared.  At the time it took 0.1 revolutions of Halley's Comet to
checkout Python with bzr; obviously that was out.  The people who just
hated git but couldn't explain why, plus the dogfooding principle (hg
is written in Python), carried the day.

 > I just want to be a user, as one can quite easily be a user of hg
 > or bzr.  Being a user of git involves learning its internal
 > structures.

No, it doesn't.  The workflows for git looked just like the workflows
for hg and bzr, *unless you want to modify a DAG at internal nodes*
(but there were no such tasks on the list for PEP 374).  Then the
workflows are very different (basically nonexistent in hg and bzr at
that time).

In any case, you already know the internal structure of git because
it's the same as a Lisp list (with a slight variation to account for
merges).  The commands for working with it have different names
(commit for cons, reset for setq), that's all.

 > (Note the people recently emphasising the internal representation
 > of a git branch to me, talking about pointers to its tip, and so
 > on.

Yeah, and a year ago I would have been posting the same stuff.  I know
now that that's like "messing around with Jim"[1], because:

 > I really don't want to have to know about such stuff.)

 > It is evident that when the UI for git was "designed" nobody of any
 > experience (or taste) in UIs was involved in the process.  Nobody
 > knew when to say "stop!".  So there are _lots_ of commands, and the
 > ones used most often have 20, 30, 50 options

Sounds just like Emacs, except that git is a whole lot more popular.

 > to learn about,

Huh?  If you don't want to learn about them, don't.  Ask a friend who
uses git how to do it.  You do have git-using friends (probably about
100,000 of them -- all them cc-mode users!)

 > some of which do several distinctly different things (e.g. git
 > checkout).

OK, you got me there.  You have a choice: learn all the variations on
checkout, or learn some internals so you can use reset.  Not attractive.

 > If the git team had paid as much attention to UI as they did to
 > elegant internal structures, they would have had a world beater of
 > a program.

Er, where have you been for the last 5 years?  They *do* have a world
beater of a program.  Compare user population with, uh, Emacs.

 > Not at all.  There are 20, 30, or 50 options which all consciously have
 > to be omitted.

Which 6 letters in the word "option" didn't you read as you typed it?
Come on, Alan, you've gone past petulant with that one.

I really don't get this; in my workflow I almost never use options in
git, except for -<digits> for log, -m and occasionally -a when
committing, --hard for reset, -l and -f for tag and branch, and -b for
checkout, all of which have important semantics and are pretty easy to
understand IMO.  What other git options do you need for your workflows?

 > > [2]  It occurs to me that one of the things I hated about both bzr and
 > > hg was that a bare "$VCS commit" commits everything.
 > 
 > But in both of them, the commit message template informed you which
 > files were being committed, giving you the opportunity to abort.

I never see that template: I use "-m" (command line) or "-F ,msg" (in
XEmacs).

 > > That is *almost never* TRT for my workflow.  But I suspect that Alan
 > > loves that feature, since he has a religious objection to commiting a
 > > workspace that hasn't been polished to an optically perfect surface.
 > 
 > What, you mean as opposed to committing any old rubbish at the drop of a
 > hat?

Yes.  Heck, I had this:

(defun sjt/git-auto-commit ()
  (let ((file (file-name-nondirectory (buffer-file-name))))
    (shell-command (format "git commit -m \"Auto-commit %s.\" %s"
			   file file))))

on after-save-hook for a while.  I admit it stopped being amusing
pretty quickly (rebase -i didn't exist back then). Instead, I just
taught myself to commit frequently enough that if I get confused about
what I'm doing I can usually reconstruct thought processes by looking
at the diffs.

BTW, although I don't care if those "interim" commits become public,
if I did care it's easy enough to "squash" the interim branch into a
single commit on trunk, and optionally delete that interim branch.

 > The vagueness and uncertainty introduced by git's two stage
 > committing,

I don't understand.  If you don't have any added or removed files for
your "polished" commit, you just do "git commit --all".  If you do,
you do "git add --all; git commit".  This isn't much different from
what you have to do with bzr or hg, except that you wouldn't need
--all on commit for the first version.  It's a bit more typing than
for hg or bzr which default to committing everything modified, but
that's always an issue when users disagree about defaults: the
minority loses.


Footnotes: 
[1]  https://www.youtube.com/watch?v=-4qUXcXuMSE

Re: On the popularity of git

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Alan Mackenzie writes:
>
>  > Not at all.  There are 20, 30, or 50 options which all consciously
>  > have to be omitted.
>
> Which 6 letters in the word "option" didn't you read as you typed it?

I must say that I am quite curious about the concept of "consciously
omitting options".  With most command line programs, I am pretty sure
that I am constantly omitting options unconsciously since "omitting"
them "consciously" would require that unconsciously calling a program
would involve typing every conceivable option in, and only consciousness
makes every unneeded option disappear from the command line.

I mean, even if my usual way of keyboard entry would be to fall asleep
on the keyboard whenever I have to type options, I am pretty sure that
I'd miss a few ones by default.

-- 
David Kastrup

Re: On the popularity of git

[Steinar Bang]

>>>>> Alan Mackenzie <acm@muc.de>:

> Not at all.  There are 20, 30, or 50 options which all consciously
> have to be omitted.  Otherwise you are stumbling in the dark, or
> merely learning sequences of commands by rote (as I have done), rather
> than truly mastering them.

Could you concretely name some of these 20 to 50 options?

If you have to omit them all the time, it shouldn't be too much work.

Re: On the popularity of git

[David Kastrup]

Steinar Bang <sb@dod.no> writes:

>>>>>> Alan Mackenzie <acm@muc.de>:
>
>> Not at all.  There are 20, 30, or 50 options which all consciously
>> have to be omitted.  Otherwise you are stumbling in the dark, or
>> merely learning sequences of commands by rote (as I have done), rather
>> than truly mastering them.
>
> Could you concretely name some of these 20 to 50 options?
>
> If you have to omit them all the time, it shouldn't be too much work.

I have to consciously omit about two dozen options whenever I call "ls".
It's so frustrating whenever you forget to omit one.

-- 
David Kastrup

Re: On the popularity of git

[Alan Mackenzie]

Hello, Steinar.

On Sat, Oct 31, 2015 at 10:08:13PM +0100, Steinar Bang wrote:
> >>>>> Alan Mackenzie <acm@muc.de>:

> > Not at all.  There are 20, 30, or 50 options which all consciously
> > have to be omitted.  Otherwise you are stumbling in the dark, or
> > merely learning sequences of commands by rote (as I have done), rather
> > than truly mastering them.

> Could you concretely name some of these 20 to 50 options?

Yes, I could, but it would be far less work for anybody interested
simply to look at a typical git man page.  For example, git-commit has
38 options, and that's not counting long and short forms of the same
option as being different.  (For comparison, hg commit has 12 options,
whose descriptions are so succinct (between three and eleven words
each), that they can be scanned in a matter of a few seconds.)

> If you have to omit them all the time, it shouldn't be too much work.

The work involved is in checking through all these options to discover
which ones aren't needed.  Given that the man pages aren't well written, 
this can be a long, tedious process.  I suspect most people just ignore
most of the options, cross their fingers, and hope.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: On the popularity of git

[Uwe Brauer]

>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>> The truth is that "$VCS commit" committing all the changes _is_
>> TRT.  Why?

>> More generally, Git's main problem is that it breaks almost every
>> human habit gained with the other VCSes: instead of an easily
>> remembered numerical version IDs

> True, for short-term memory.  Because I have to ask what revision I'm
> on now and then do the relevant subtraction most of the time.  I never
> have to do that with git.  I'm sure bzr and hg have shortcuts for that
> now, but now I use those tools rarely enough that I needn't bother
> finding a better way.

Well I think hg is a bit user friendlier here, it uses ID+changeset.

Re: On the popularity of git

[Steinar Bang]

>>>>> Alan Mackenzie <acm@muc.de>:

>> Could you concretely name some of these 20 to 50 options?

> Yes, I could, but it would be far less work for anybody interested
> simply to look at a typical git man page.  For example, git-commit has
> 38 options, and that's not counting long and short forms of the same
> option as being different.

I wanted the concrete list(s) because these are options I don't know
about and have never needed.

This is how one of my commits look like
 git commit
or maybe
 git commit -m "Some comment"

Commit without "-m" will pop up the editor in the EDITOR enviroment
variable and ask for a comment, with a template.

I don't know anything about the other 37 options and I have never looked
at the commit man page.  The above examples are all I know about commit
and all I expect to know.

(Also, the -m option was the same in CVS and SVN (and nearly the same in RCS))

(of course I rarely use even commit from the command line since I mostly
commit from the staging area of magit...)

Re: On the popularity of git

[David Kastrup]

Steinar Bang <sb@dod.no> writes:

>>>>>> Alan Mackenzie <acm@muc.de>:
>
>>> Could you concretely name some of these 20 to 50 options?
>
>> Yes, I could, but it would be far less work for anybody interested
>> simply to look at a typical git man page.  For example, git-commit has
>> 38 options, and that's not counting long and short forms of the same
>> option as being different.
>
> I wanted the concrete list(s) because these are options I don't know
> about and have never needed.
>
> This is how one of my commits look like
>  git commit
> or maybe
>  git commit -m "Some comment"
>
> Commit without "-m" will pop up the editor in the EDITOR enviroment
> variable and ask for a comment, with a template.
>
> I don't know anything about the other 37 options and I have never looked
> at the commit man page.  The above examples are all I know about commit
> and all I expect to know.

You should try looking at --amend as well.

-- 
David Kastrup

Re: On the popularity of git

[Steinar Bang]

>>>>> David Kastrup <dak@gnu.org>:

> You should try looking at --amend as well.

Ah, sorry!  There are actually *two* commit arguments I use: "-m" and "--amend".

(But mostly I just do both commit and amend from magit)

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On Sun, Nov 1, 2015 at 11:17 AM, Steinar Bang <sb@dod.no> wrote:

> Ah, sorry!  There are actually *two* commit arguments I use: "-m" and
"--amend".

I'm not a heavy user of git by any stretch of imagination, and I've used
-a, -p, -F, --author, -m, --amend and -v. Which proves nothing.

[-- Attachment #2: Type: text/html, Size: 412 bytes --]

Re: On the popularity of git

[John Wiegley]

>>>>> Juanma Barranquero <lekktu@gmail.com> writes:

> I'm not a heavy user of git by any stretch of imagination, and I've used
> -a, - p, -F, --author, -m, --amend and -v. Which proves nothing.

I understand Git is a popular topic, but I would appreciate it if this thread
were moved off of emacs-devel.

Thanks, John

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Nikolaus Rath]

On Oct 31 2015, David Kastrup <dak@gnu.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> More generally, Git's main problem is that it breaks almost every
>> human habit gained with the other VCSes: instead of an easily
>> remembered numerical version IDs you have those inhuman hashes
>
> Shrug.  In a distributed version control system, numerical version IDs
> don't make sense.

They make a lot of sense if you don't require them to be constant over
time. Mercurial solves this beautifully. It has hashes if you need to
constant identifier, but if you just want to refer to the commit that
got printed/created/referred to by the command you typed 30 seconds ago,
you can use its handy numerical id.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: On the popularity of git

[Nikolaus Rath]

On Oct 31 2015, Dmitry Gutov <dgutov@yandex.ru> wrote:
>> Being a user of git involves learning its internal structures.
>> (Note the people recently emphasising the internal representation of a
>> git branch to me, talking about pointers to its tip, and so on.  I
>> really don't want to have to know about such stuff.)
>
> To a reasonably proficient Git user, that sounds like "I don't want to
> know what graphs are"

Yes, you nailed the problem. To be a reasonably proficient git user, you
have to learn its internal representation (which isn't surprising,
because as someone else said, the internal representation is really the
git's main selling point).


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: On the popularity of git

[Oleh Krehel]

Hi John,

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> I'm not a heavy user of git by any stretch of imagination, and I've used
>> -a, - p, -F, --author, -m, --amend and -v. Which proves nothing.
>
> I understand Git is a popular topic, but I would appreciate it if this thread
> were moved off of emacs-devel.

I think this discussion is productive. It may help a lot of Emacs
developers understand Git better.

I've seen your messages like this one in several threads. My opinion is
that these messages don't add anything productive to the discussion and
I could certainly stand a lot less of them.

If you dislike long threads, there are plenty of features in Gnus to
skip them. There's no reason to tell people to shut up.

Thanks, Oleh

Re: On the popularity of git

[David Kastrup]

Nikolaus Rath <Nikolaus@rath.org> writes:

> On Oct 31 2015, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>> Being a user of git involves learning its internal structures.
>>> (Note the people recently emphasising the internal representation of a
>>> git branch to me, talking about pointers to its tip, and so on.  I
>>> really don't want to have to know about such stuff.)
>>
>> To a reasonably proficient Git user, that sounds like "I don't want to
>> know what graphs are"
>
> Yes, you nailed the problem. To be a reasonably proficient git user, you
> have to learn its internal representation

Not really.  All you need to know is that a commit is defined by a bit
of data (commit message, author, commit date, and so on), its parent
commit(s) and a snapshot of the work tree.  How those are represented in
detail is not really of much concern, and a particular implementation
might choose to use some quite different underlying database than the
standard repository does.

> (which isn't surprising, because as someone else said, the internal
> representation is really the git's main selling point).

Git changed the internal representation several times over the years,
using different packing formats and stuff.  The main selling point is
rather the simplicity (and stability) of the underlying data model.
Which is exactly the reason it's easy to plug together various pieces of
"plumbing" in order to arrive at some new porcelain like
"git-filter-branch" or similar: many Git utilities, at least initially,
were plugged together using shell scripts and it is rather few
specialized C programs (and modules) which actually need to bother with
the internal representation.

-- 
David Kastrup

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[David Kastrup]

Nikolaus Rath <Nikolaus@rath.org> writes:

> On Oct 31 2015, David Kastrup <dak@gnu.org> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> More generally, Git's main problem is that it breaks almost every
>>> human habit gained with the other VCSes: instead of an easily
>>> remembered numerical version IDs you have those inhuman hashes
>>
>> Shrug.  In a distributed version control system, numerical version IDs
>> don't make sense.
>
> They make a lot of sense if you don't require them to be constant over
> time. Mercurial solves this beautifully. It has hashes if you need to
> constant identifier, but if you just want to refer to the commit that
> got printed/created/referred to by the command you typed 30 seconds ago,
> you can use its handy numerical id.

HEAD~2 works just fine in Git.  So does "HEAD@{30 seconds ago}" though
one would rarely want to use that particular reference.  I _do_ use
something like "issue4517@{1 day ago}" as a reasonably stable reference
point occasionally.

-- 
David Kastrup

Re: On the popularity of git

[Dmitry Gutov]

On 11/03/2015 09:00 AM, Oleh Krehel wrote:

> I think this discussion is productive. It may help a lot of Emacs
> developers understand Git better.

I think it would be more on topic in e.g. gnu-emacs-help, rather than in 
emacs-devel.

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On Tue, Nov 3, 2015 at 11:07 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> I think it would be more on topic in e.g. gnu-emacs-help, rather than in
emacs-devel.

Being ontopic is overrated. This conversation sprung here and has continued
because obviously some emacs-devel denizens find it interesting and/or
useful (I do). Too many e-mails isn't an issue when it's so easy to filter
them out in the mail client.

[-- Attachment #2: Type: text/html, Size: 524 bytes --]

Re: On the popularity of git

[John Wiegley]

>>>>> Juanma Barranquero <lekktu@gmail.com> writes:

> Being ontopic is overrated. This conversation sprung here and has continued
> because obviously some emacs-devel denizens find it interesting and/or
> useful (I do). Too many e-mails isn't an issue when it's so easy to filter
> them out in the mail client.

We have valuable people leaving this mailing list due to its penchant for
straying off-topic for so long. I assure you it is not being overrated.

I again request that the members of this thread take the discussion elsewhere,
among themselves. It is not needed here in emacs-devel.

Thank you,
  John

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Tue, Nov 3, 2015 at 2:08 PM, John Wiegley <jwiegley@gmail.com> wrote:

> We have valuable people leaving this mailing list due to its penchant for
> straying off-topic for so long. I assure you it is not being overrated.

Sorry, but I find this argument less than compelling. emacs-devel has less
than 40 msg/day, which  is low. Anyone who dislikes wandering threads can
silence them. And wandering threads often come back to Emacs issues. Anyone
who's "leaving this list due to its penchant for straying off-topic for so
long" will likely leave anyway due to its penchant for long threads, even
on-topic. No one is interested in all issues.

> I again request that the members of this thread take the discussion
elsewhere,
> among themselves. It is not needed here in emacs-devel.

I disagree.

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

Re: On the popularity of git

[Dmitry Gutov]

On 11/03/2015 03:30 PM, Juanma Barranquero wrote:

> Sorry, but I find this argument less than compelling. emacs-devel has
> less than 40 msg/day, which  is low.

40 msg/day would be ridiculously high for this subscriber.

> Anyone who dislikes wandering
> threads can silence them. And wandering threads often come back to Emacs
> issues.

If you silence the threads, you miss the issues.

Seriously, using a different mailing list is not that hard. Keeping on 
topic is a good practice.

>  > I again request that the members of this thread take the discussion
> elsewhere,
>  > among themselves. It is not needed here in emacs-devel.
>
> I disagree.

I'd like to urge everyone now to recall the "looking for the new 
maintainer" thread, and the low number of volunteers.

Re: On the popularity of git

[Oleh Krehel]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Nov 3, 2015 at 2:08 PM, John Wiegley <jwiegley@gmail.com> wrote:
>
>> We have valuable people leaving this mailing list due to its penchant for
>> straying off-topic for so long. I assure you it is not being overrated.
>
> Sorry, but I find this argument less than compelling. emacs-devel has less than 40 msg/day, which is low. Anyone who dislikes wandering threads can silence them. And wandering threads often come back to Emacs issues. Anyone who's "leaving
> this list due to its penchant for straying off-topic for so long" will likely leave anyway due to its penchant for long threads, even on-topic. No one is interested in all issues.

If a person is "leaving" only because they can't stomach skipping
through ~20 messages per day, then they'd find a reason to leave anyway.
And I wouldn't call this type of people valuable, since they don't
actually contribute anything on account of "leaving" because of every
little inconvenience.

>> I again request that the members of this thread take the discussion elsewhere,
>> among themselves. It is not needed here in emacs-devel.
>
> I disagree.

Seconded.

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

On Tue, Nov 3, 2015 at 2:38 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> 40 msg/day would be ridiculously high for this subscriber.

That's messages, not threads, so a few threads to silence if they disturb
you.

> If you silence the threads, you miss the issues.

If you push them to other lists, so do you. I don't read gnu-emacs-help,
for example.

> Keeping on topic is a good practice.

It's also impossible in the long run.

> I'd like to urge everyone now to recall the "looking for the new
maintainer" thread, and the low number of volunteers.

Which is unrelated to this list's traffic, and more related to the
vagueness of the job's description and the scarcity of suitable developers.

[-- Attachment #2: Type: text/html, Size: 977 bytes --]

Re: On the popularity of git

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I think it would be more on topic in e.g. gnu-emacs-help, rather than in
> emacs-devel.

gnu-emacs-help is about using Emacs, git is off-topic there.
emacs-devel is about developing Emacs, git is on-topic here.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: On the popularity of git

[Dmitry Gutov]

On 11/03/2015 03:43 PM, Juanma Barranquero wrote:

>  > 40 msg/day would be ridiculously high for this subscriber.
>
> That's messages, not threads, so a few threads to silence if they
> disturb you.

The "silence thread" feature in my email client does not work nicely 
enough. And it's a popular one (Thunderbird).

>  > If you silence the threads, you miss the issues.
>
> If you push them to other lists, so do you. I don't read gnu-emacs-help,
> for example.

So people would have to bring these issues separately on emacs-devel, or 
file proper bug reports. Oh horror.

>  > I'd like to urge everyone now to recall the "looking for the new
> maintainer" thread, and the low number of volunteers.
>
> Which is unrelated to this list's traffic, and more related to the
> vagueness of the job's description and the scarcity of suitable developers.

It's related to your response. I wouldn't take a maintainer position 
where everyone feels free to second-guess me on trivial decisions.

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Tue, Nov 3, 2015 at 2:49 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> It's related to your response. I wouldn't take a maintainer position
where everyone feels free to second-guess me on trivial decisions.

On one hand, I don't think John's already been appointed as head
maintainer. Or did I miss some announcement?

On the other hand, someone who wouldn't take the position because some mild
disagreement over trivial issues on emacs-devel, well... let's say they
wouldn't seem to be well suited to the job. This is not, and never has
been, a quiet, happy place. Characters flare. Opinions are thrown around
with force. Egos are sometimes bruised.

[-- Attachment #2: Type: text/html, Size: 847 bytes --]

Re: On the popularity of git

[Alan Mackenzie]

Hello, Juanma.

On Tue, Nov 03, 2015 at 02:58:32PM +0100, Juanma Barranquero wrote:
> On Tue, Nov 3, 2015 at 2:49 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> > It's related to your response. I wouldn't take a maintainer position
> where everyone feels free to second-guess me on trivial decisions.

> On one hand, I don't think John's already been appointed as head
> maintainer. Or did I miss some announcement?

I don't think there's been an announcement.  We seem to be in a tacit
trial period, seeing how things work out in practice by experiment.  I
think most of us would prefer the experiment to end with John's position
as maintainer confirmed.

> On the other hand, someone who wouldn't take the position because some mild
> disagreement over trivial issues on emacs-devel, well... let's say they
> wouldn't seem to be well suited to the job. This is not, and never has
> been, a quiet, happy place. Characters flare. Opinions are thrown around
> with force. Egos are sometimes bruised.

This discussion on git is one of these marginal topics, which sort of
does, sort of doesn't belong in emacs-devel.  When such marginal threads
go on too long, people get irritated.  As one of the people to blame for
starting it, I think it is a reasonable request from our
(trial-)maintainer to stop it, though to allow the thread to carry on
would also be reasonable.

Personally, I think it would be a good thing for this thread to end,
now.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Tue, Nov 3, 2015 at 3:14 PM, Alan Mackenzie <acm@muc.de> wrote:

> I
> think most of us would prefer the experiment to end with John's position
> as maintainer confirmed.

As would I, in case there's any doubt.

> As one of the people to blame for
> starting it, I think it is a reasonable request from our
> (trial-)maintainer to stop it,

It is. It is also reasonable not to expect compliance if some people just
disagree with the request.

> Personally, I think it would be a good thing for this thread to end,
> now.

I think it is now more relevant than ever. We're now discussing not git,
but emacs-devel nettiquete and the dangers and pitfalls of the
maintainership. What could be more on-topic? ;-)

[-- Attachment #2: Type: text/html, Size: 951 bytes --]

Re: On the popularity of git

[Óscar Fuentes]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> If a person is "leaving" only because they can't stomach skipping
> through ~20 messages per day, then they'd find a reason to leave anyway.
> And I wouldn't call this type of people valuable, since they don't
> actually contribute anything on account of "leaving" because of every
> little inconvenience.

Glenn Morris is one of the most valuable Emacs hackers (contributing
solid work for very long periods of time.) He left the ml months ago
because this problem with long, wandering threads. IIRC his reasoning
was that the content of emacs-devel is too noisy and reading it achieves
no productive work.

[snip]

Re: On the popularity of git

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Tue, Nov 3, 2015 at 3:35 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> He left the ml months ago
> because this problem with long, wandering threads.

Sad to hear that.

However, our really long, long threads have been mostly on-topic (hundreds
of messages discussing Martin's new windows code, for example). Noise to
anyone not interested in these specific topics.

[-- Attachment #2: Type: text/html, Size: 526 bytes --]

Re: On the popularity of git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 03 Nov 2015 15:35:57 +0100
> 
> Glenn Morris is one of the most valuable Emacs hackers (contributing
> solid work for very long periods of time.) He left the ml months ago

He didn't:

  http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg02092.html

Re: On the popularity of git

[Dmitry Gutov]

On 11/03/2015 05:58 PM, Eli Zaretskii wrote:

> He didn't:
>
>    http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg02092.html

One can stop reading a mailing list, and still occasionally post to it.

Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]

[Nikolaus Rath]

On Nov 03 2015, David Kastrup <dak@gnu.org> wrote:
> Nikolaus Rath <Nikolaus@rath.org> writes:
>
>> On Oct 31 2015, David Kastrup <dak@gnu.org> wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> More generally, Git's main problem is that it breaks almost every
>>>> human habit gained with the other VCSes: instead of an easily
>>>> remembered numerical version IDs you have those inhuman hashes
>>>
>>> Shrug.  In a distributed version control system, numerical version IDs
>>> don't make sense.
>>
>> They make a lot of sense if you don't require them to be constant over
>> time. Mercurial solves this beautifully. It has hashes if you need to
>> constant identifier, but if you just want to refer to the commit that
>> got printed/created/referred to by the command you typed 30 seconds ago,
>> you can use its handy numerical id.
>
> HEAD~2 works just fine in Git.  So does "HEAD@{30 seconds ago}" though
[...]

Head-relative references are useful, but no substitute for short numeric
id's of *arbitrary* commits.

# Find first commit after the release following commit 372
$ hg log -r 'limit(sort(descendants(372) and tag("re:^release-"), "date"), 2)'

# ..and show what was changed:
$ hg diff -c 410


Best,s
-Nikolau

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: On the popularity of git

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11/03/2015 05:58 PM, Eli Zaretskii wrote:
>
>> He didn't:
>>
>>    http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg02092.html
>
> One can stop reading a mailing list, and still occasionally post to it.

Indeed and... wow, one message!

It's obvious that he reads the commits ml and in that case he
cross-posted to emacs-devel because here is the audience for his
message.

Eli, for convincing yourself that he no longer takes part on
emacs-devel, count his posts since a few months and compare it with how
many post he wrote on the same period one year ago.

Re: On the popularity of git

[Jay Belanger]

> Glenn Morris is one of the most valuable Emacs hackers (contributing
> solid work for very long periods of time.) He left the ml months ago
> because this problem with long, wandering threads. IIRC his reasoning
> was that the content of emacs-devel is too noisy and reading it achieves
> no productive work.

Not wanting to read all of emacs-devel would be a strange reason to
leave the list; it isn't a read-it-all or read-none-of-it type deal.
I can think of a lot of reasons why someone might write less on
emacs-devel.  Where did he give his reasons?

Re: On the popularity of git

[John Wiegley]

>>>>> Jay Belanger <jay.p.belanger@gmail.com> writes:

> Not wanting to read all of emacs-devel would be a strange reason to leave
> the list; it isn't a read-it-all or read-none-of-it type deal. I can think
> of a lot of reasons why someone might write less on emacs-devel. Where did
> he give his reasons?

I'm not sure why Glenn left, but here's an example of what some of us are
referring to: In the "IDE" discussion that took place a while back, I was
actively engaged in discussing ideas with several individuals. Meanwhile, a
sub-thread began (without changing the subject) that starting talking solely
about CEDET development. That sub-thread is still ongoing to this day.

Because of that sub-thread, it was necessary to scan every message just to
determine which messages titled "IDE" were part of the discussion I was
having, and which titled "IDE" had nothing to do with it.

At one point I was wading through 5-20 messages a day, looking for needles in
a haystack. This became tiresome enough that I stopped paying active attention
to the thread. I kept deferring my "winnowing" until later and later in the
day, and at some point told Gnus to stop showing "IDE" messages altogether --
possibly missing out on meaningful additions to the discussion.

This induces needless inertia into the medium. For those of us whose mail
readers do not easily silence threads, there is a similar inertia involved in
skipping past lots of messages that are largely irrelevant.

This sort thing happens a *lot*; maybe without the participants even realizing
it, because it has become so common-place. Multiply this many times over, plus
a need to get as much done as possible within a limited amount of time, and
perhaps you begin to see the problem.

In the future, I think it has come time to establish a Code of Conduct, along
with a transition to a passively moderated list: one where all posts are
allowed by default, but those who disregard the CoC will lose their right to
post until the end of a waiting period.

I appreciate that some do not see this as a problem or disagree with my
assessment (Hi, Juanma, thanks for your support btw :). But needless to say, I
know of several people (personally, in meat-space) who do not participate here
because of these problems, and I'm willing to make some changes to bring these
people back into the fold.

For the purposes of Emacs development (aka, emacs-devel), I would much rather
have a semi-professional atmosphere focused on improving Emacs, than an
easy-going social atmosphere focused on eloquent debates. That belongs on
another list -- and in fact, creation of just such a list is in process and
will be announced by Richard or myself shortly.

For those who've actually read to the end of this message: Richard and I met
at MIT yesterday, where I officially accepted the role as maintainer of Emacs.
An announcement is forthcoming, once we dot the i's and cross the t's. It's
also why I've switched my subscription address to johnw@gnu.org, and would
appreciate if Emacs-related issues are sent there, rather than to my other
accounts.

Toward a better future, and much happy hacking!
  John Wiegley

RE: On the popularity of git

[Drew Adams]

John: Probably should have a different Subject line...or...five. ;-)

> I'm not sure why Glenn left, but here's an example
...
> I think it has come time to establish a Code of Conduct
...
> creation of just such a list is in process and will be announced
...
> Richard and I met at MIT yesterday, where I officially accepted the role
> as maintainer of Emacs
...
> I've switched my subscription address to johnw@gnu.org, and would
> appreciate if Emacs-related issues are sent there

Changing the tone of emacs-devel (Was: On the popularity of git)

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> John: Probably should have a different Subject line...or...five. ;-)

Hah, you are so right! :) Thank you for calling me on that. Subject changed.

John

Re: On the popularity of git

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This list is for discussing the development of Emacs,
but it is not serving that purpose very well.  There are
several reasons for this, and we need to address them.

The long discussions about issues that are not directly pertinent
is one of them.  But there are others, such as a lot of arguing
and friction.

Not all mail readers understand threads, by the way.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Changing the subject (was: On the popularity of git)

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Jay Belanger <jay.p.belanger@gmail.com> writes:
>
>> Not wanting to read all of emacs-devel would be a strange reason to leave
>> the list; it isn't a read-it-all or read-none-of-it type deal. I can think
>> of a lot of reasons why someone might write less on emacs-devel. Where did
>> he give his reasons?
>
> I'm not sure why Glenn left, but here's an example of what some of us are
> referring to: In the "IDE" discussion that took place a while back, I was
> actively engaged in discussing ideas with several individuals. Meanwhile, a
> sub-thread began (without changing the subject) that starting talking solely
> about CEDET development. That sub-thread is still ongoing to this day.
>
> Because of that sub-thread, it was necessary to scan every message just to
> determine which messages titled "IDE" were part of the discussion I was
> having, and which titled "IDE" had nothing to do with it.

It's probably worth pointing out to users of Gnus to use

C-c C-f s runs the command message-change-subject (found in
message-mode-map), which is an interactive compiled Lisp function in
‘message.el’.

It is bound to C-c C-f s, <menu-bar> <Field> <Change subject...>.

(message-change-subject NEW-SUBJECT)

Ask for NEW-SUBJECT header, append (was: <Old Subject>).

[back]

when composing a reply/followup to a thread that has actually changed
subject.  And do this early enough exactly in order to keep topics
separate.  If somebody else tried changing the subject line already
(with the same overall topic), try choosing the same changed subject.

-- 
David Kastrup

Re: Changing the tone of emacs-devel (Was: On the popularity of git)

[Artur Malabarba]

2015-11-03 20:35 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
> Hah, you are so right! :) Thank you for calling me on that. Subject changed.

Now that you've brought it up, let me emphasize that a moment and
request that we all brach-off subjects _a lot_ more frequently.
I know it's easy to forget. I forget it all the time (and clearly so
does John ;-), but let's make a bit more of an effort.

Remember kids:
If you're changing the subject of a conversation, do everyone a favor
and change the subject of the message.

Then there's the matter of what do you do if the new subject is not
really about Emacs. To this matter, I quote a short snippet of what
John said on that thread, for those who might not have read it:

2015-11-03 20:15 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
> For the purposes of Emacs development (aka, emacs-devel), I would much rather
> have a semi-professional atmosphere focused on improving Emacs, than an
> easy-going social atmosphere focused on eloquent debates.

Yes, please.

> That belongs on
> another list -- and in fact, creation of just such a list is in process and
> will be announced by Richard or myself shortly.

Thank you!

emacs-devel etiquette (was: Re: On the popularity of git)

[Stephen Leake]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Jay Belanger <jay.p.belanger@gmail.com> writes:
>
>> Not wanting to read all of emacs-devel would be a strange reason to leave
>> the list; it isn't a read-it-all or read-none-of-it type deal. I can think
>> of a lot of reasons why someone might write less on emacs-devel. Where did
>> he give his reasons?
>
> I'm not sure why Glenn left, but here's an example of what some of us are
> referring to: In the "IDE" discussion that took place a while back, I was
> actively engaged in discussing ideas with several individuals. Meanwhile, a
> sub-thread began (without changing the subject) that starting talking solely
> about CEDET development. That sub-thread is still ongoing to this day.

(note that I changed the subject :)

> This induces needless inertia into the medium. For those of us whose mail
> readers do not easily silence threads, there is a similar inertia involved in
> skipping past lots of messages that are largely irrelevant.

I have stopped reading emacs-devel on occasion for similar reasons; it
was too hard to find the useful messages (I use Gnus).

> In the future, I think it has come time to establish a Code of Conduct, along
> with a transition to a passively moderated list: one where all posts are
> allowed by default, but those who disregard the CoC will lose their right to
> post until the end of a waiting period.

+1

> For those who've actually read to the end of this message: Richard and I met
> at MIT yesterday, where I officially accepted the role as maintainer of Emacs.
> An announcement is forthcoming, once we dot the i's and cross the t's. It's
> also why I've switched my subscription address to johnw@gnu.org, and would
> appreciate if Emacs-related issues are sent there, rather than to my other
> accounts.

Welcome aboard!

-- 
-- Stephe

Re: Changing the subject (was: On the popularity of git)

[Marcin Borkowski]

On 2015-11-03, at 22:47, David Kastrup <dak@gnu.org> wrote:

> It's probably worth pointing out to users of Gnus to use
>
> C-c C-f s runs the command message-change-subject (found in
> message-mode-map), which is an interactive compiled Lisp function in
> ‘message.el’.
>
> It is bound to C-c C-f s, <menu-bar> <Field> <Change subject...>.
>
> (message-change-subject NEW-SUBJECT)
>
> Ask for NEW-SUBJECT header, append (was: <Old Subject>).
>
> [back]
>
> when composing a reply/followup to a thread that has actually changed
> subject.  And do this early enough exactly in order to keep topics
> separate.  If somebody else tried changing the subject line already
> (with the same overall topic), try choosing the same changed subject.

It's probably worth pointing out to users of mu4e that it piggybacks on
Gnus' message-mode, so the above applies to mu4e as well.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Changing the subject (was: On the popularity of git)

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Tue, Nov 3, 2015 at 6:37 PM, Marcin Borkowski <mbork@mbork.pl> wrote:

> It's probably worth pointing out to users of mu4e that it piggybacks on
> Gnus' message-mode, so the above applies to mu4e as well.
>

In the same vein, I frequent have to use gmail.  Once you choose Reply or
ReplyAll there is a drop down menu to the left of the seeded To: list.
That menu includes 'Edit subject'.

/john

[-- Attachment #2: Type: text/html, Size: 750 bytes --]

Re: Changing the subject

[Yann Hodique]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

>> I'm not sure why Glenn left, but here's an example of what some of us are
>> referring to: In the "IDE" discussion that took place a while back, I was
>> actively engaged in discussing ideas with several individuals. Meanwhile, a
>> sub-thread began (without changing the subject) that starting talking solely
>> about CEDET development. That sub-thread is still ongoing to this day.
>> 
>> Because of that sub-thread, it was necessary to scan every message just to
>> determine which messages titled "IDE" were part of the discussion I was
>> having, and which titled "IDE" had nothing to do with it.

> It's probably worth pointing out to users of Gnus to use

> C-c C-f s runs the command message-change-subject (found in
> message-mode-map), which is an interactive compiled Lisp function in
> ‘message.el’.

> It is bound to C-c C-f s, <menu-bar> <Field> <Change subject...>.

> (message-change-subject NEW-SUBJECT)

> Ask for NEW-SUBJECT header, append (was: <Old Subject>).

> [back]

> when composing a reply/followup to a thread that has actually changed
> subject.  And do this early enough exactly in order to keep topics
> separate.  If somebody else tried changing the subject line already
> (with the same overall topic), try choosing the same changed subject.

It's probably also worth mentioning that Gnus users have the option to
use scores to identify (un)important messages, and that scoring on
message-id ("L i e p" for example) effectively translates into scoring
on sub-thread as long as nobody messes with the References field (which
thankfully happens to be fairly rare around here).

All this to say that while changing subject is certainly good practice,
relying on it might be a little optimistic, and there are other ways to
handle the issue that are more under the control of the person who
actually wants to filter stuff out.

Yann.

-- 
All states are abstractions.

  -- Octun Politicus, BG Archives

Re: On the popularity of git

[Stephen J. Turnbull]

Oleh Krehel writes:

 > > I disagree.
 > 
 > Seconded.

Unsubscribed.

-and-good-riddance-too-I'm-sure-ly y'rs :-),

Re: Changing the tone of emacs-devel (Was: On the popularity of git)

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-11-03 20:15 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
>> For the purposes of Emacs development (aka, emacs-devel), I would much rather
>> have a semi-professional atmosphere focused on improving Emacs, than an
>> easy-going social atmosphere focused on eloquent debates.
>
> Yes, please.

Indeed, I'd like that very much as well.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Future emacs mailing lists. [Was: On the popularity of git]

[Alan Mackenzie]

Hello, John.

Congratulations on your appointment as Emacs maintainer, and thanks for
taking it up.

On Tue, Nov 03, 2015 at 03:15:17PM -0500, John Wiegley wrote:
[ .... ]

> In the future, I think it has come time to establish a Code of Conduct, along
> with a transition to a passively moderated list: one where all posts are
> allowed by default, but those who disregard the CoC will lose their right to
> post until the end of a waiting period.

> I appreciate that some do not see this as a problem or disagree with my
> assessment (Hi, Juanma, thanks for your support btw :). But needless to say, I
> know of several people (personally, in meat-space) who do not participate here
> because of these problems, and I'm willing to make some changes to bring these
> people back into the fold.

> For the purposes of Emacs development (aka, emacs-devel), I would much rather
> have a semi-professional atmosphere focused on improving Emacs, than an
> easy-going social atmosphere focused on eloquent debates. That belongs on
> another list -- and in fact, creation of just such a list is in process and
> will be announced by Richard or myself shortly.

For that other list, the more social one, to flourish, there will need
to be a convention of switching threads from emacs-devel to
emacs-social/emacs-off-topic/emacs-whatever.  Most (?all) of the long
rambling threads that plague emacs-devel start from legitimate on-topic
discussion.  It may become part of your role as project head to call for
a switch to the other (new) group, but hopefully most people will sense
the right time themselves.

As mechanism for the switching, the Mail-followup-to: header (or
whatever it's called) should do the trick, I think.

> For those who've actually read to the end of this message: Richard and I met
> at MIT yesterday, where I officially accepted the role as maintainer of Emacs.
> An announcement is forthcoming, once we dot the i's and cross the t's. It's
> also why I've switched my subscription address to johnw@gnu.org, and would
> appreciate if Emacs-related issues are sent there, rather than to my other
> accounts.

johnw@gnu.org it is, then.

> Toward a better future, and much happy hacking!

And to yourself too, sir!

>   John Wiegley

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Changing the subject

[John Wiegley]

>>>>> Yann Hodique <yann.hodique@gmail.com> writes:

> It's probably also worth mentioning that Gnus users have the option to use
> scores to identify (un)important messages, and that scoring on message-id
> ("L i e p" for example) effectively translates into scoring on sub-thread as
> long as nobody messes with the References field (which thankfully happens to
> be fairly rare around here).

> All this to say that while changing subject is certainly good practice,
> relying on it might be a little optimistic, and there are other ways to
> handle the issue that are more under the control of the person who actually
> wants to filter stuff out.

That's a nice option for those whose mail readers have such a capability (I'll
give it a try myself, as a Gnus user). However, we can't assume everyone will
have that ability.

John