ty...@mit.edu writes:
On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems
Javier Domingo Cansino javier...@gmail.com writes:
Felipe's
===
= Reject non-fast-forward pulls by default =
Not having this introduced yet allows newbie people to use git with
just 4 commands, without bothering around with fetch and merge and so.
If you have a gun lying around your
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are
I think you are on the right track but the solution is not to shrug shoulders.
We should acknowledge there are serious problems with the interface, list
them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage $tracked_file`.
I agree. The stage
Philippe Vaucher wrote:
I think you are on the right track but the solution is not to shrug
shoulders.
We should acknowledge there are serious problems with the interface, list
them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage
On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
I agree. The stage area is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
One
On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote:
I agree, but I think it's better than index tho. That one is heavily
overloaded and easily confused with other meaning in other softwares.
There is a big difference between being used in a difference sense
than other software
Hi,
David Kastrup wrote:
Javier Domingo Cansino javier...@gmail.com writes:
= Reject non-fast-forward pulls by default =
Not having this introduced yet allows newbie people to use git with
just 4 commands, without bothering around with fetch and merge and so.
If you have a gun lying around
was commenting on a number of concrete proposals regarding
the subject line What is missing from Git v2.0 and quoted Felipe
directly. As you seem to have lost the context, let me requote the
respective portion:
From: Felipe Contreras felipe.contre...@gmail.com
Subject: What is missing
Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the overloaded argument can be easily solved
by renaming one of the overloads.
And renaming one of a term also has costs, especially if it is one
that is in use in large amounts of documentation, both
, the rule is simple. Feel free to grumble, but make
sure there is some contribution in the same message.
[...]
Uh, Javier was commenting on a number of concrete proposals regarding
the subject line What is missing from Git v2.0 and quoted Felipe
directly. As you seem to have lost the context, let
Theodore Ts'o wrote:
On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
I agree. The stage area is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the
Philippe Vaucher wrote:
Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the overloaded argument can be easily solved
by renaming one of the overloads.
And renaming one of a term also has costs, especially if it is one
that is in use in large
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
When I say literally everbody agreed to move away from the name index
(except
Junio and another guy) I mean it. I even composed a list:
http://article.gmane.org/gmane.comp.version-control.git/233469
Jeff King, Jonathan
Jeff King wrote:
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
When I say literally everbody agreed to move away from the name index
(except
Junio and another guy) I mean it. I even composed a list:
http://article.gmane.org/gmane.comp.version-control.git/233469
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
I specifically said everybody agreed to move away from the name 'index', I
didn't say everybody agreed on the staged area although the vast majority
did, and I didn't say anybody agreed on my patches, although some did.
I
Jeff King wrote:
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
I specifically said everybody agreed to move away from the name 'index', I
didn't say everybody agreed on the staged area although the vast majority
did, and I didn't say anybody agreed on my patches,
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index.
So you agree that the index is a bad name, and you agree staging area is a
better name,
Jeff King wrote:
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index.
So you agree that the index is a bad name, and you agree staging
Felipe Contreras wrote:
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users who are not
fresh-out-of-the-boat, yet not power users either.
Oh, I didn't mean to suggest a dichotomy of any kind. However these
are the two groups (I
suggest)
James Denholm wrote:
Felipe Contreras wrote:
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users who are not
fresh-out-of-the-boat, yet not power users either.
Oh, I didn't mean to suggest a dichotomy of any kind. However these
Felipe Contreras felipe.contre...@gmail.com writes:
James Denholm wrote:
Felipe Contreras wrote:
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users who are not
fresh-out-of-the-boat, yet not power users either.
Oh, I didn't
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
James Denholm wrote:
Felipe Contreras wrote:
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users who are not
fresh-out-of-the-boat, yet not power
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
James Denholm wrote:
Felipe Contreras wrote:
This is a false dichotomy; there aren't just two kinds
of Git users.
There is such a category of Git users
On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote:
...
Anyway, if you disagree change one of your frequently used passwords to a
chapter of The Lord of the Rings for a day. Let's see if you still think that.
Proving that one extreme isn't the optimum doesn't prove the other is.
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
Felipe,
It's clear that you've not been able to produce evidence that can
convince most of the people on
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to git config
--global author.email=y...@mail.here), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
Stefan Beller wrote:
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to git config
--global author.email=y...@mail.here), if I remember correctly, so
there is definitely a valid (i.e. user
tytso@ wrote:
On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
I don't even think we need to query the user to fill out all of the
fields. We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
Stefan Beller wrote:
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to git config
--global author.email=y...@mail.here), if I remember correctly, so
there is definitely a valid (i.e. user
Jonathan Nieder wrote:
Stefan Beller wrote:
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to git config
--global author.email=y...@mail.here), if I remember correctly, so
there is
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
The people having to read and understand scripts written in the
expectation of default aliases.
Which are imaginary.
And I prefer them to stay that way since then one does not need to worry
Andreas Krey wrote:
On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote:
...
Anyway, if you disagree change one of your frequently used passwords to a
chapter of The Lord of the Rings for a day. Let's see if you still think
that.
Proving that one extreme isn't the optimum doesn't
Theodore Ts'o wrote:
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
It's clear that you've not been able to produce evidence that can
convince most
On Thu, Apr 24, 2014 at 01:26:33PM -0500, Felipe Contreras wrote:
Jonathan Nieder wrote:
Stefan Beller wrote:
I may have missunderstood.
So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to git config
--global
On Thu, 24 Apr 2014, Felipe Contreras wrote:
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
The people having to read and understand scripts written in the
expectation of default aliases.
Which are imaginary.
And I prefer them to stay that
Felipe Contreras felipe.contre...@gmail.com writes:
Andreas Krey wrote:
On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote:
...
Anyway, if you disagree change one of your frequently used passwords to a
chapter of The Lord of the Rings for a day. Let's see if you still think
that.
On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote:
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
Creating a ~/.gitconfig file if one doesn't already is one I agree
with, and at least on Unix systems, telling them that the config file
lives in ~/.gitconfig, or
Felipe's
===
= The publish tracking branch =
I still have problems getting upstream branches correctly configured
as to have this introduced, anyway, I suppose it's optional, so
nothing to add on that.
By the way, remote branch managing has improved a lot, one of the
best things I see for
Javier Domingo Cansino wrote:
Felipe's
===
= The publish tracking branch =
I still have problems getting upstream branches correctly configured
as to have this introduced, anyway, I suppose it's optional, so
nothing to add on that.
I did so too, until I patch `git branch -v` to be
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Theodore Ts'o wrote:
This is especially true for commands which might not be used as often
-- e.g., rebase, and for commands where the meaning of git commit
without any argument is qualitatively different from
David Lang wrote:
agreed, of all the things that people complain about regarding learning git,
the fact that the commands are words instead of cryptic 2 letter
abberviations is not one of them.
It is when they start to use Git seriously and type them a lot.
The complaints tend to be far more
On Wed, 23 Apr 2014, Felipe Contreras wrote:
David Lang wrote:
agreed, of all the things that people complain about regarding learning git,
the fact that the commands are words instead of cryptic 2 letter
abberviations is not one of them.
It is when they start to use Git seriously and type
David Lang wrote:
On Wed, 23 Apr 2014, Felipe Contreras wrote:
David Lang wrote:
agreed, of all the things that people complain about regarding learning
git,
the fact that the commands are words instead of cryptic 2 letter
abberviations is not one of them.
It is when they start
Felipe Contreras wrote:
David Lang wrote:
agreed, of all the things that people complain
about regarding learning git,
the fact that the commands are words instead of
cryptic 2 letter
abberviations is not one of them.
It is when they start to use Git seriously and type
them a lot.
Felipe, I
James Denholm wrote:
Felipe Contreras wrote:
It is when they start to use Git seriously and type them a lot.
Felipe, I think you refute your own point here, because people _learning_ git
aren't power-users. They might be one day, but not that day. If power-users
are complaining that commit
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Life's hardness is not proportional to the number of typed characters
It is. Why do you think people set aliases? To make their life harder?
Anyway, if you disagree change one of your frequently used passwords
to a
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ (slightly), hindering interoperability.
I am afraid
On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The problem is that between git rm and git mv, if we default git
cp to mean cherry-pick there could easily be user confusion.
I'm not sure that cherry-pick is used that often it really needs a two
character
Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ (slightly), hindering
Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The problem is that between git rm and git mv, if we default git
cp to mean cherry-pick there could easily be user confusion.
I'm not sure that cherry-pick is used that often
Sebastian Schuberth sschube...@gmail.com writes:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ
Junio C Hamano wrote:
Sebastian Schuberth sschube...@gmail.com writes:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
be low-priority compared to user-defined aliases,
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
be low-priority compared to
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are probably biased in that you've used Git far
Junio C Hamano gits...@pobox.com writes:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
A few thinking points that are necessary to be worked out, even
before we start
Theodore Ts'o wrote:
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are probably biased
Matthieu Moy matthieu@grenoble-inp.fr writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
Felipe Contreras felipe.contre...@gmail.com writes:
Theodore Ts'o wrote:
This is especially true for commands which might not be used as often
-- e.g., rebase, and for commands where the meaning of git commit
without any argument is qualitatively different from what ci (for
checkin) means
On Tue, 22 Apr 2014, Theodore Ts'o wrote:
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are
On 21.04.2014 00:41, Felipe Contreras wrote:
= Default aliases =
Every single version control tool out there has default aliases (e.g.
co = checkout) except Git.
Every argument against default aliases was basically refuted, yet my
patches went nowhere. And the users still expect these
Sebastian Schuberth sschube...@gmail.com writes:
Every argument against default aliases was basically refuted, yet my
patches went nowhere. And the users still expect these aliases.
+1 about having default aliases in general, and I'd also add these:
I think it might be OK to implement them
Sebastian Schuberth wrote:
On 21.04.2014 00:41, Felipe Contreras wrote:
= Default aliases =
Every single version control tool out there has default aliases (e.g.
co = checkout) except Git.
Every argument against default aliases was basically refuted, yet my
patches went nowhere.
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I have these aliases as well, except br = b, and cp = pi. 'br' is probably
better, but not sure as 'cp' which can be confusing.
If by confusing you refer to cp to copy files, that's actually what
I like about
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I have these aliases as well, except br = b, and cp = pi. 'br' is probably
better, but not sure as 'cp' which can be confusing.
If by
Theodore Ts'o wrote:
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I have these aliases as well, except br = b, and cp = pi. 'br' is
probably
better, but not sure as 'cp'
On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
= Reject non-fast-forward pulls by default =
Many new-comers end up making merges by mistake when they pull because
they don't understand what is a non-fast-forward and what they should
actually be doing. Most people, even
brian m. carlson wrote:
On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:
BTW, in my experience people tend to stick to predefined aliases instead of
redefining them to something (completely) different. This means that having
default aliases will very likely enable one to
David Aguilar wrote:
On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
= Reject non-fast-forward pulls by default =
Many new-comers end up making merges by mistake when they pull because
they don't understand what is a non-fast-forward and what they should
actually be
Hi,
I had already given up on merging important features to Git upstream,
and then one of the features I've had in git-fc (my fork) for quite
some time suddenly got attention (the @{publish} branch), but
everybody forgot I already did the work. So maybe there's other
features in a similar
On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
[3] http://thread.gmane.org/gmane.comp.version-control.git/240030
[4] http://thread.gmane.org/gmane.comp.version-control.git/235981
Actually:
[3] http://thread.gmane.org/gmane.comp.version-control.git/233554
73 matches
Mail list logo
