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 ag
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
> bet
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 pat
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.
>
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
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, Jon
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 i
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 tha
n the git list, 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
> dir
>> 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 documentat
this patch?"
> and people reading can follow up by reviewing that patch and
> potentially getting it applied.
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
Hi,
David Kastrup wrote:
> Javier Domingo Cansino 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 your house
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 softwa
>> 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 caution: The term "stage/staged" is already a little overloa
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.
On
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
> 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 "s
> > 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
> > add
Javier Domingo Cansino 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 house, you shoul
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 mos
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
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 br
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 Contreras 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.
>>
>> Provi
On Thu, 24 Apr 2014, Felipe Contreras wrote:
David Kastrup wrote:
Felipe Contreras 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
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 c
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
> convin
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 optimu
David Kastrup wrote:
> Felipe Contreras 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
> about them
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="), if I remember correctly, so
> > there is defi
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="), if I remember correctly, so
> there is definitely a valid (i.e. user approved) ema
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 syst
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="), if I remember correctly, so
> there is definitely a valid (i.e. user approved) ema
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="), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.
2014-04-24 17:47 GMT
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 ---
> > specifical
> 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 n
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 t
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.
Andre
Felipe Contreras writes:
> David Kastrup wrote:
>> Felipe Contreras 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
>> >> > fr
David Kastrup wrote:
> Felipe Contreras 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 use
Felipe Contreras 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 mean to
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. Howe
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
sugge
Felipe Contreras 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 chapter of The Lord
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
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.
Feli
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 i
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 th
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 m
David Kastrup wrote:
> Felipe Contreras 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"
Junio C Hamano wrote:
> Junio C Hamano 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
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 probab
Felipe Contreras 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 in most othe
Matthieu Moy writes:
> Felipe Contreras 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 alia
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 prob
Junio C Hamano 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 imagining a
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 G
Matthieu Moy wrote:
> Felipe Contreras 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 al
Felipe Contreras 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, there's no backward
compatibi
Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
> > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano 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 dif
Sebastian Schuberth writes:
> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano 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 interopera
Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
> 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
Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano 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 interoper
On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
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 shortcut.
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano 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 that that sh
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
> > act
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
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
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 use the same short comman
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
> > wrote:
> >
> > > I have these aliases as well, except br => b, and cp => pi. 'br' is
> > > probably
> > > better, but not sure as 'cp' which can b
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
> 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 re
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
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 it: cherry-pick is som
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
Sebastian Schuberth 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 as the lowest pr
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 aliases.
On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras
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
[4] http://thread.gmane.or
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 situatio
77 matches
Mail list logo
