* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-28 23:53 ` Alan Mackenzie
@ 2015-10-29 0:17 ` Dmitry Gutov
2015-10-29 0:28 ` Michael Heerdegen
` (4 subsequent siblings)
5 siblings, 0 replies; 90+ messages in thread
From: Dmitry Gutov @ 2015-10-29 0:17 UTC (permalink / raw)
To: Alan Mackenzie, Óscar Fuentes; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-28 23:53 ` Alan Mackenzie
2015-10-29 0:17 ` Dmitry Gutov
@ 2015-10-29 0:28 ` Michael Heerdegen
2015-10-29 0:49 ` Michael Heerdegen
2015-10-29 2:25 ` Yuri Khan
` (3 subsequent siblings)
5 siblings, 1 reply; 90+ messages in thread
From: Michael Heerdegen @ 2015-10-29 0:28 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-28 23:53 ` Alan Mackenzie
2015-10-29 0:17 ` Dmitry Gutov
2015-10-29 0:28 ` Michael Heerdegen
@ 2015-10-29 2:25 ` Yuri Khan
2015-10-29 8:21 ` David Kastrup
` (2 subsequent siblings)
5 siblings, 0 replies; 90+ messages in thread
From: Yuri Khan @ 2015-10-29 2:25 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Óscar Fuentes, Emacs developers
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).
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-28 23:53 ` Alan Mackenzie
` (2 preceding siblings ...)
2015-10-29 2:25 ` Yuri Khan
@ 2015-10-29 8:21 ` David Kastrup
2015-10-29 12:35 ` Alan Mackenzie
2015-10-29 16:16 ` Eli Zaretskii
2015-10-29 17:45 ` Davis Herring
5 siblings, 1 reply; 90+ messages in thread
From: David Kastrup @ 2015-10-29 8:21 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Óscar Fuentes, emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-29 8:21 ` David Kastrup
@ 2015-10-29 12:35 ` Alan Mackenzie
2015-10-29 13:21 ` David Kastrup
2015-10-29 16:31 ` Git question: when using branches, how does git treat working files when changing branches? Eli Zaretskii
0 siblings, 2 replies; 90+ messages in thread
From: Alan Mackenzie @ 2015-10-29 12:35 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-29 12:35 ` Alan Mackenzie
@ 2015-10-29 13:21 ` David Kastrup
2015-10-29 17:02 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Alan Mackenzie
2015-10-29 16:31 ` Git question: when using branches, how does git treat working files when changing branches? Eli Zaretskii
1 sibling, 1 reply; 90+ messages in thread
From: David Kastrup @ 2015-10-29 13:21 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-29 13:21 ` David Kastrup
@ 2015-10-29 17:02 ` Alan Mackenzie
2015-10-29 17:22 ` David Kastrup
` (4 more replies)
0 siblings, 5 replies; 90+ messages in thread
From: Alan Mackenzie @ 2015-10-29 17:02 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-29 17:02 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Alan Mackenzie
@ 2015-10-29 17:22 ` David Kastrup
2015-10-29 18:08 ` John Wiegley
` (3 subsequent siblings)
4 siblings, 0 replies; 90+ messages in thread
From: David Kastrup @ 2015-10-29 17:22 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-29 17:02 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Alan Mackenzie
2015-10-29 17:22 ` David Kastrup
@ 2015-10-29 18:08 ` John Wiegley
2015-10-30 7:48 ` Paul Eggert
` (2 subsequent siblings)
4 siblings, 0 replies; 90+ messages in thread
From: John Wiegley @ 2015-10-29 18:08 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: David Kastrup, emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-29 17:02 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Alan Mackenzie
2015-10-29 17:22 ` David Kastrup
2015-10-29 18:08 ` John Wiegley
@ 2015-10-30 7:48 ` Paul Eggert
2015-10-30 9:27 ` Alan Mackenzie
2015-10-30 9:09 ` joakim
2015-10-30 12:50 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Juanma Barranquero
4 siblings, 1 reply; 90+ messages in thread
From: Paul Eggert @ 2015-10-30 7:48 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 7:48 ` Paul Eggert
@ 2015-10-30 9:27 ` Alan Mackenzie
2015-10-30 9:48 ` David Kastrup
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: Alan Mackenzie @ 2015-10-30 9:27 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 9:27 ` Alan Mackenzie
@ 2015-10-30 9:48 ` David Kastrup
2015-10-30 10:34 ` Eli Zaretskii
2015-10-30 21:44 ` Paul Eggert
2 siblings, 0 replies; 90+ messages in thread
From: David Kastrup @ 2015-10-30 9:48 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Paul Eggert, emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 9:27 ` Alan Mackenzie
2015-10-30 9:48 ` David Kastrup
@ 2015-10-30 10:34 ` Eli Zaretskii
2015-10-30 21:44 ` Paul Eggert
2 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2015-10-30 10:34 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: eggert, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 9:27 ` Alan Mackenzie
2015-10-30 9:48 ` David Kastrup
2015-10-30 10:34 ` Eli Zaretskii
@ 2015-10-30 21:44 ` Paul Eggert
2 siblings, 0 replies; 90+ messages in thread
From: Paul Eggert @ 2015-10-30 21:44 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-29 17:02 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Alan Mackenzie
` (2 preceding siblings ...)
2015-10-30 7:48 ` Paul Eggert
@ 2015-10-30 9:09 ` joakim
2015-10-30 10:49 ` Yuri Khan
2015-10-30 12:50 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Juanma Barranquero
4 siblings, 1 reply; 90+ messages in thread
From: joakim @ 2015-10-30 9:09 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: David Kastrup, emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 9:09 ` joakim
@ 2015-10-30 10:49 ` Yuri Khan
2015-10-31 3:16 ` Stephen J. Turnbull
0 siblings, 1 reply; 90+ messages in thread
From: Yuri Khan @ 2015-10-30 10:49 UTC (permalink / raw)
To: joakim; +Cc: Alan Mackenzie, David Kastrup, Emacs developers
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 10:49 ` Yuri Khan
@ 2015-10-31 3:16 ` Stephen J. Turnbull
2015-10-31 8:24 ` Eli Zaretskii
2015-10-31 16:50 ` Alan Mackenzie
0 siblings, 2 replies; 90+ messages in thread
From: Stephen J. Turnbull @ 2015-10-31 3:16 UTC (permalink / raw)
To: Yuri Khan; +Cc: Alan Mackenzie, David Kastrup, joakim, Emacs developers
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-31 3:16 ` Stephen J. Turnbull
@ 2015-10-31 8:24 ` Eli Zaretskii
2015-10-31 8:32 ` Andreas Schwab
` (3 more replies)
2015-10-31 16:50 ` Alan Mackenzie
1 sibling, 4 replies; 90+ messages in thread
From: Eli Zaretskii @ 2015-10-31 8:24 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: emacs-devel
> 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!
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-31 8:24 ` Eli Zaretskii
@ 2015-10-31 8:32 ` Andreas Schwab
2015-10-31 11:35 ` Oleh Krehel
` (2 subsequent siblings)
3 siblings, 0 replies; 90+ messages in thread
From: Andreas Schwab @ 2015-10-31 8:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen J. Turnbull, emacs-devel
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."
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-31 8:24 ` Eli Zaretskii
2015-10-31 8:32 ` Andreas Schwab
@ 2015-10-31 11:35 ` Oleh Krehel
2015-10-31 12:19 ` David Kastrup
2015-10-31 16:02 ` On the popularity of git Stephen J. Turnbull
3 siblings, 0 replies; 90+ messages in thread
From: Oleh Krehel @ 2015-10-31 11:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen J. Turnbull, emacs-devel
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-31 8:24 ` Eli Zaretskii
2015-10-31 8:32 ` Andreas Schwab
2015-10-31 11:35 ` Oleh Krehel
@ 2015-10-31 12:19 ` David Kastrup
2015-11-02 22:01 ` Nikolaus Rath
2015-10-31 16:02 ` On the popularity of git Stephen J. Turnbull
3 siblings, 1 reply; 90+ messages in thread
From: David Kastrup @ 2015-10-31 12:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen J. Turnbull, emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-31 12:19 ` David Kastrup
@ 2015-11-02 22:01 ` Nikolaus Rath
2015-11-03 8:42 ` David Kastrup
0 siblings, 1 reply; 90+ messages in thread
From: Nikolaus Rath @ 2015-11-02 22:01 UTC (permalink / raw)
To: emacs-devel
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.«
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-11-02 22:01 ` Nikolaus Rath
@ 2015-11-03 8:42 ` David Kastrup
2015-11-03 17:38 ` Nikolaus Rath
0 siblings, 1 reply; 90+ messages in thread
From: David Kastrup @ 2015-11-03 8:42 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-11-03 8:42 ` David Kastrup
@ 2015-11-03 17:38 ` Nikolaus Rath
0 siblings, 0 replies; 90+ messages in thread
From: Nikolaus Rath @ 2015-11-03 17:38 UTC (permalink / raw)
To: emacs-devel
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.«
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 8:24 ` Eli Zaretskii
` (2 preceding siblings ...)
2015-10-31 12:19 ` David Kastrup
@ 2015-10-31 16:02 ` Stephen J. Turnbull
2015-11-01 8:08 ` Uwe Brauer
3 siblings, 1 reply; 90+ messages in thread
From: Stephen J. Turnbull @ 2015-10-31 16:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git
2015-10-31 16:02 ` On the popularity of git Stephen J. Turnbull
@ 2015-11-01 8:08 ` Uwe Brauer
0 siblings, 0 replies; 90+ messages in thread
From: Uwe Brauer @ 2015-11-01 8:08 UTC (permalink / raw)
To: emacs-devel
>>> "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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 3:16 ` Stephen J. Turnbull
2015-10-31 8:24 ` Eli Zaretskii
@ 2015-10-31 16:50 ` Alan Mackenzie
2015-10-31 16:58 ` Dmitry Gutov
` (2 more replies)
1 sibling, 3 replies; 90+ messages in thread
From: Alan Mackenzie @ 2015-10-31 16:50 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: David Kastrup, Emacs developers, joakim, Yuri Khan
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).
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git
2015-10-31 16:50 ` Alan Mackenzie
@ 2015-10-31 16:58 ` Dmitry Gutov
2015-11-02 22:05 ` Nikolaus Rath
2015-10-31 19:24 ` Stephen J. Turnbull
2015-10-31 21:08 ` Steinar Bang
2 siblings, 1 reply; 90+ messages in thread
From: Dmitry Gutov @ 2015-10-31 16:58 UTC (permalink / raw)
To: Alan Mackenzie, Stephen J. Turnbull
Cc: Yuri Khan, David Kastrup, joakim, Emacs developers
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 16:58 ` Dmitry Gutov
@ 2015-11-02 22:05 ` Nikolaus Rath
2015-11-03 8:39 ` David Kastrup
0 siblings, 1 reply; 90+ messages in thread
From: Nikolaus Rath @ 2015-11-02 22:05 UTC (permalink / raw)
To: emacs-devel
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.«
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git
2015-11-02 22:05 ` Nikolaus Rath
@ 2015-11-03 8:39 ` David Kastrup
0 siblings, 0 replies; 90+ messages in thread
From: David Kastrup @ 2015-11-03 8:39 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 16:50 ` Alan Mackenzie
2015-10-31 16:58 ` Dmitry Gutov
@ 2015-10-31 19:24 ` Stephen J. Turnbull
2015-10-31 20:13 ` David Kastrup
2015-10-31 21:08 ` Steinar Bang
2 siblings, 1 reply; 90+ messages in thread
From: Stephen J. Turnbull @ 2015-10-31 19:24 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git
2015-10-31 19:24 ` Stephen J. Turnbull
@ 2015-10-31 20:13 ` David Kastrup
0 siblings, 0 replies; 90+ messages in thread
From: David Kastrup @ 2015-10-31 20:13 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: Alan Mackenzie, Emacs developers
"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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 16:50 ` Alan Mackenzie
2015-10-31 16:58 ` Dmitry Gutov
2015-10-31 19:24 ` Stephen J. Turnbull
@ 2015-10-31 21:08 ` Steinar Bang
2015-10-31 21:15 ` David Kastrup
2015-10-31 21:48 ` Alan Mackenzie
2 siblings, 2 replies; 90+ messages in thread
From: Steinar Bang @ 2015-10-31 21:08 UTC (permalink / raw)
To: emacs-devel
>>>>> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 21:08 ` Steinar Bang
@ 2015-10-31 21:15 ` David Kastrup
2015-10-31 21:48 ` Alan Mackenzie
1 sibling, 0 replies; 90+ messages in thread
From: David Kastrup @ 2015-10-31 21:15 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 21:08 ` Steinar Bang
2015-10-31 21:15 ` David Kastrup
@ 2015-10-31 21:48 ` Alan Mackenzie
2015-11-01 8:17 ` Steinar Bang
1 sibling, 1 reply; 90+ messages in thread
From: Alan Mackenzie @ 2015-10-31 21:48 UTC (permalink / raw)
To: emacs-devel
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).
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-10-31 21:48 ` Alan Mackenzie
@ 2015-11-01 8:17 ` Steinar Bang
2015-11-01 8:54 ` David Kastrup
0 siblings, 1 reply; 90+ messages in thread
From: Steinar Bang @ 2015-11-01 8:17 UTC (permalink / raw)
To: emacs-devel
>>>>> 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...)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-01 8:17 ` Steinar Bang
@ 2015-11-01 8:54 ` David Kastrup
2015-11-01 10:17 ` Steinar Bang
0 siblings, 1 reply; 90+ messages in thread
From: David Kastrup @ 2015-11-01 8:54 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-01 8:54 ` David Kastrup
@ 2015-11-01 10:17 ` Steinar Bang
2015-11-01 11:15 ` Juanma Barranquero
0 siblings, 1 reply; 90+ messages in thread
From: Steinar Bang @ 2015-11-01 10:17 UTC (permalink / raw)
To: emacs-devel
>>>>> 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)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-01 10:17 ` Steinar Bang
@ 2015-11-01 11:15 ` Juanma Barranquero
2015-11-02 20:11 ` John Wiegley
0 siblings, 1 reply; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-01 11:15 UTC (permalink / raw)
To: Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-01 11:15 ` Juanma Barranquero
@ 2015-11-02 20:11 ` John Wiegley
2015-11-03 7:00 ` Oleh Krehel
0 siblings, 1 reply; 90+ messages in thread
From: John Wiegley @ 2015-11-02 20:11 UTC (permalink / raw)
To: Emacs developers
>>>>> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-02 20:11 ` John Wiegley
@ 2015-11-03 7:00 ` Oleh Krehel
2015-11-03 10:07 ` Dmitry Gutov
0 siblings, 1 reply; 90+ messages in thread
From: Oleh Krehel @ 2015-11-03 7:00 UTC (permalink / raw)
To: Emacs developers
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 7:00 ` Oleh Krehel
@ 2015-11-03 10:07 ` Dmitry Gutov
2015-11-03 11:58 ` Juanma Barranquero
2015-11-03 13:49 ` Andreas Schwab
0 siblings, 2 replies; 90+ messages in thread
From: Dmitry Gutov @ 2015-11-03 10:07 UTC (permalink / raw)
To: Oleh Krehel, Emacs developers
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 10:07 ` Dmitry Gutov
@ 2015-11-03 11:58 ` Juanma Barranquero
2015-11-03 13:08 ` John Wiegley
2015-11-03 13:49 ` Andreas Schwab
1 sibling, 1 reply; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-03 11:58 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Oleh Krehel, Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 11:58 ` Juanma Barranquero
@ 2015-11-03 13:08 ` John Wiegley
2015-11-03 13:30 ` Juanma Barranquero
0 siblings, 1 reply; 90+ messages in thread
From: John Wiegley @ 2015-11-03 13:08 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs developers, Oleh Krehel, Dmitry Gutov
>>>>> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:08 ` John Wiegley
@ 2015-11-03 13:30 ` Juanma Barranquero
2015-11-03 13:38 ` Dmitry Gutov
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-03 13:30 UTC (permalink / raw)
To: Juanma Barranquero, Dmitry Gutov, Oleh Krehel, Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git
2015-11-03 13:30 ` Juanma Barranquero
@ 2015-11-03 13:38 ` Dmitry Gutov
2015-11-03 13:43 ` Juanma Barranquero
2015-11-03 13:43 ` Oleh Krehel
2015-11-03 20:53 ` Richard Stallman
2 siblings, 1 reply; 90+ messages in thread
From: Dmitry Gutov @ 2015-11-03 13:38 UTC (permalink / raw)
To: Juanma Barranquero, Oleh Krehel, Emacs developers
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:38 ` Dmitry Gutov
@ 2015-11-03 13:43 ` Juanma Barranquero
2015-11-03 13:49 ` Dmitry Gutov
0 siblings, 1 reply; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-03 13:43 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Oleh Krehel, Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:43 ` Juanma Barranquero
@ 2015-11-03 13:49 ` Dmitry Gutov
2015-11-03 13:58 ` Juanma Barranquero
0 siblings, 1 reply; 90+ messages in thread
From: Dmitry Gutov @ 2015-11-03 13:49 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Oleh Krehel, Emacs developers
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:49 ` Dmitry Gutov
@ 2015-11-03 13:58 ` Juanma Barranquero
2015-11-03 14:14 ` Alan Mackenzie
0 siblings, 1 reply; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-03 13:58 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Oleh Krehel, Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:58 ` Juanma Barranquero
@ 2015-11-03 14:14 ` Alan Mackenzie
2015-11-03 14:25 ` Juanma Barranquero
0 siblings, 1 reply; 90+ messages in thread
From: Alan Mackenzie @ 2015-11-03 14:14 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs developers, Oleh Krehel, Dmitry Gutov
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).
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 14:14 ` Alan Mackenzie
@ 2015-11-03 14:25 ` Juanma Barranquero
0 siblings, 0 replies; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-03 14:25 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Emacs developers, Oleh Krehel, Dmitry Gutov
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:30 ` Juanma Barranquero
2015-11-03 13:38 ` Dmitry Gutov
@ 2015-11-03 13:43 ` Oleh Krehel
2015-11-03 14:35 ` Óscar Fuentes
2015-11-04 7:52 ` On the popularity of git Stephen J. Turnbull
2015-11-03 20:53 ` Richard Stallman
2 siblings, 2 replies; 90+ messages in thread
From: Oleh Krehel @ 2015-11-03 13:43 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs developers, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:43 ` Oleh Krehel
@ 2015-11-03 14:35 ` Óscar Fuentes
2015-11-03 14:52 ` Juanma Barranquero
` (2 more replies)
2015-11-04 7:52 ` On the popularity of git Stephen J. Turnbull
1 sibling, 3 replies; 90+ messages in thread
From: Óscar Fuentes @ 2015-11-03 14:35 UTC (permalink / raw)
To: emacs-devel
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]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git
2015-11-03 14:35 ` Óscar Fuentes
@ 2015-11-03 14:52 ` Juanma Barranquero
2015-11-03 15:58 ` Eli Zaretskii
2015-11-03 19:40 ` Jay Belanger
2 siblings, 0 replies; 90+ messages in thread
From: Juanma Barranquero @ 2015-11-03 14:52 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 14:35 ` Óscar Fuentes
2015-11-03 14:52 ` Juanma Barranquero
@ 2015-11-03 15:58 ` Eli Zaretskii
2015-11-03 16:04 ` Dmitry Gutov
2015-11-03 19:40 ` Jay Belanger
2 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2015-11-03 15:58 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 14:35 ` Óscar Fuentes
2015-11-03 14:52 ` Juanma Barranquero
2015-11-03 15:58 ` Eli Zaretskii
@ 2015-11-03 19:40 ` Jay Belanger
2015-11-03 20:15 ` John Wiegley
2 siblings, 1 reply; 90+ messages in thread
From: Jay Belanger @ 2015-11-03 19:40 UTC (permalink / raw)
To: emacs-devel; +Cc: jay.p.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?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 19:40 ` Jay Belanger
@ 2015-11-03 20:15 ` John Wiegley
2015-11-03 20:24 ` Drew Adams
` (3 more replies)
0 siblings, 4 replies; 90+ messages in thread
From: John Wiegley @ 2015-11-03 20:15 UTC (permalink / raw)
To: Jay Belanger; +Cc: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 90+ messages in thread* RE: On the popularity of git
2015-11-03 20:15 ` John Wiegley
@ 2015-11-03 20:24 ` Drew Adams
2015-11-03 20:35 ` Changing the tone of emacs-devel (Was: On the popularity of git) John Wiegley
2015-11-03 21:47 ` Changing the subject (was: " David Kastrup
` (2 subsequent siblings)
3 siblings, 1 reply; 90+ messages in thread
From: Drew Adams @ 2015-11-03 20:24 UTC (permalink / raw)
To: John Wiegley, Jay Belanger; +Cc: johnw, emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread* Changing the tone of emacs-devel (Was: On the popularity of git)
2015-11-03 20:24 ` Drew Adams
@ 2015-11-03 20:35 ` John Wiegley
2015-11-03 22:05 ` Artur Malabarba
0 siblings, 1 reply; 90+ messages in thread
From: John Wiegley @ 2015-11-03 20:35 UTC (permalink / raw)
To: Drew Adams; +Cc: Jay Belanger, emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Changing the tone of emacs-devel (Was: On the popularity of git)
2015-11-03 20:35 ` Changing the tone of emacs-devel (Was: On the popularity of git) John Wiegley
@ 2015-11-03 22:05 ` Artur Malabarba
2015-11-04 7:54 ` Nicolas Petton
0 siblings, 1 reply; 90+ messages in thread
From: Artur Malabarba @ 2015-11-03 22:05 UTC (permalink / raw)
To: Drew Adams, Jay Belanger, emacs-devel
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!
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Changing the tone of emacs-devel (Was: On the popularity of git)
2015-11-03 22:05 ` Artur Malabarba
@ 2015-11-04 7:54 ` Nicolas Petton
0 siblings, 0 replies; 90+ messages in thread
From: Nicolas Petton @ 2015-11-04 7:54 UTC (permalink / raw)
To: bruce.connor.am, Drew Adams, Jay Belanger, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Changing the subject (was: On the popularity of git)
2015-11-03 20:15 ` John Wiegley
2015-11-03 20:24 ` Drew Adams
@ 2015-11-03 21:47 ` David Kastrup
2015-11-03 23:37 ` Marcin Borkowski
2015-11-04 1:40 ` Changing the subject Yann Hodique
2015-11-03 22:11 ` emacs-devel etiquette (was: Re: On the popularity of git) Stephen Leake
2015-11-04 11:12 ` Future emacs mailing lists. [Was: On the popularity of git] Alan Mackenzie
3 siblings, 2 replies; 90+ messages in thread
From: David Kastrup @ 2015-11-03 21:47 UTC (permalink / raw)
To: Jay Belanger; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Changing the subject (was: On the popularity of git)
2015-11-03 21:47 ` Changing the subject (was: " David Kastrup
@ 2015-11-03 23:37 ` Marcin Borkowski
2015-11-04 0:27 ` John Yates
2015-11-04 1:40 ` Changing the subject Yann Hodique
1 sibling, 1 reply; 90+ messages in thread
From: Marcin Borkowski @ 2015-11-03 23:37 UTC (permalink / raw)
To: David Kastrup; +Cc: Jay Belanger, emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Changing the subject (was: On the popularity of git)
2015-11-03 23:37 ` Marcin Borkowski
@ 2015-11-04 0:27 ` John Yates
0 siblings, 0 replies; 90+ messages in thread
From: John Yates @ 2015-11-04 0:27 UTC (permalink / raw)
To: Marcin Borkowski; +Cc: Jay Belanger, David Kastrup, Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Changing the subject
2015-11-03 21:47 ` Changing the subject (was: " David Kastrup
2015-11-03 23:37 ` Marcin Borkowski
@ 2015-11-04 1:40 ` Yann Hodique
2015-11-04 15:37 ` John Wiegley
1 sibling, 1 reply; 90+ messages in thread
From: Yann Hodique @ 2015-11-04 1:40 UTC (permalink / raw)
To: emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: Changing the subject
2015-11-04 1:40 ` Changing the subject Yann Hodique
@ 2015-11-04 15:37 ` John Wiegley
0 siblings, 0 replies; 90+ messages in thread
From: John Wiegley @ 2015-11-04 15:37 UTC (permalink / raw)
To: Yann Hodique; +Cc: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* emacs-devel etiquette (was: Re: On the popularity of git)
2015-11-03 20:15 ` John Wiegley
2015-11-03 20:24 ` Drew Adams
2015-11-03 21:47 ` Changing the subject (was: " David Kastrup
@ 2015-11-03 22:11 ` Stephen Leake
2015-11-04 11:12 ` Future emacs mailing lists. [Was: On the popularity of git] Alan Mackenzie
3 siblings, 0 replies; 90+ messages in thread
From: Stephen Leake @ 2015-11-03 22:11 UTC (permalink / raw)
To: Jay Belanger; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Future emacs mailing lists. [Was: On the popularity of git]
2015-11-03 20:15 ` John Wiegley
` (2 preceding siblings ...)
2015-11-03 22:11 ` emacs-devel etiquette (was: Re: On the popularity of git) Stephen Leake
@ 2015-11-04 11:12 ` Alan Mackenzie
3 siblings, 0 replies; 90+ messages in thread
From: Alan Mackenzie @ 2015-11-04 11:12 UTC (permalink / raw)
To: emacs-devel
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).
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:43 ` Oleh Krehel
2015-11-03 14:35 ` Óscar Fuentes
@ 2015-11-04 7:52 ` Stephen J. Turnbull
1 sibling, 0 replies; 90+ messages in thread
From: Stephen J. Turnbull @ 2015-11-04 7:52 UTC (permalink / raw)
To: Oleh Krehel; +Cc: Juanma Barranquero, Emacs developers
Oleh Krehel writes:
> > I disagree.
>
> Seconded.
Unsubscribed.
-and-good-riddance-too-I'm-sure-ly y'rs :-),
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 13:30 ` Juanma Barranquero
2015-11-03 13:38 ` Dmitry Gutov
2015-11-03 13:43 ` Oleh Krehel
@ 2015-11-03 20:53 ` Richard Stallman
2 siblings, 0 replies; 90+ messages in thread
From: Richard Stallman @ 2015-11-03 20:53 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: lekktu, emacs-devel, ohwoeowho, dgutov
[[[ 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git
2015-11-03 10:07 ` Dmitry Gutov
2015-11-03 11:58 ` Juanma Barranquero
@ 2015-11-03 13:49 ` Andreas Schwab
1 sibling, 0 replies; 90+ messages in thread
From: Andreas Schwab @ 2015-11-03 13:49 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Oleh Krehel, Emacs developers
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."
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-29 17:02 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Alan Mackenzie
` (3 preceding siblings ...)
2015-10-30 9:09 ` joakim
@ 2015-10-30 12:50 ` Juanma Barranquero
2015-10-30 14:15 ` David Kastrup
4 siblings, 1 reply; 90+ messages in thread
From: Juanma Barranquero @ 2015-10-30 12:50 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 12:50 ` On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?] Juanma Barranquero
@ 2015-10-30 14:15 ` David Kastrup
2015-10-30 16:54 ` Juanma Barranquero
0 siblings, 1 reply; 90+ messages in thread
From: David Kastrup @ 2015-10-30 14:15 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Alan Mackenzie, Emacs developers
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 14:15 ` David Kastrup
@ 2015-10-30 16:54 ` Juanma Barranquero
2015-10-30 17:31 ` David Kastrup
0 siblings, 1 reply; 90+ messages in thread
From: Juanma Barranquero @ 2015-10-30 16:54 UTC (permalink / raw)
To: David Kastrup; +Cc: Alan Mackenzie, Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
2015-10-30 16:54 ` Juanma Barranquero
@ 2015-10-30 17:31 ` David Kastrup
0 siblings, 0 replies; 90+ messages in thread
From: David Kastrup @ 2015-10-30 17:31 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Alan Mackenzie, Emacs developers
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-29 12:35 ` Alan Mackenzie
2015-10-29 13:21 ` David Kastrup
@ 2015-10-29 16:31 ` Eli Zaretskii
1 sibling, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2015-10-29 16:31 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: dak, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-28 23:53 ` Alan Mackenzie
` (3 preceding siblings ...)
2015-10-29 8:21 ` David Kastrup
@ 2015-10-29 16:16 ` Eli Zaretskii
2015-10-29 17:45 ` Davis Herring
5 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2015-10-29 16:16 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: ofv, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: Git question: when using branches, how does git treat working files when changing branches?
2015-10-28 23:53 ` Alan Mackenzie
` (4 preceding siblings ...)
2015-10-29 16:16 ` Eli Zaretskii
@ 2015-10-29 17:45 ` Davis Herring
5 siblings, 0 replies; 90+ messages in thread
From: Davis Herring @ 2015-10-29 17:45 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Óscar Fuentes, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread