On Tue, Apr 23, 2013 at 1:49 PM, Ramkumar Ramachandra
wrote:
> My point is simple: yes, it's nice to have a big user base. We
> already do. Now, what's the point of pitching to end-users who only
> use the most basic functionality? Their inputs are likely to be
> useless (arising from misunder
[off-topic; what happened/happens to your series is entirely unrelated
to the issue]
Felipe Contreras wrote:
> Nobody knows how life began, and it doesn't matter now, what matters
> is how life evolves. It doesn't matter if the chicken was first, or
> the egg, what matters is that if all the chick
Junio C Hamano writes:
>> Then the --ignore-removals option could be added using a patch like
>> the following.
>
> adding ignore-removals as a synonym (and keeping it) would be a good
> idea.
>
> We would still need to carry --all and --no-all that have been with
> us ever since we added "-A" op
Jonathan Nieder writes:
> How about something like this?
>
> warning: "git add" run on path with files removed (e.g., '%s')
> hint: use "git add --ignore-removals " to ignore removals
> hint: or "git add --no-ignore-removals " to notice them
> hint: --ignore-removals is th
> On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
>>> Junio C Hamano wrote:
You ran 'git add' with neither '-A (--all)' or '--no-all', whose
behaviour will change in Git 2.0 with respect to paths you
removed from your working tree.
* 'git ad
On Fri, Apr 19, 2013 at 4:07 PM, Phil Hord wrote:
> On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras
> wrote:
>> If something is not hypothetical, it's real, which means it actually
>> happened, but then you said you never made the claim that it did. So
>> what is it?
>
> My claim:
>
>I bis
Jeff King writes:
> On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
>
>> Jonathan Nieder writes:
>>
>> > Junio C Hamano wrote:
>> >
>> >> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
>> >> behaviour will change in Git 2.0 with respect to paths you
>>
On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Junio C Hamano wrote:
> >
> >> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
> >> behaviour will change in Git 2.0 with respect to paths you
> >> removed from your worki
On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras
wrote:
> On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord wrote:
>> On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
>
>>> Yes please. Show me one of the instances where you hit a bisect with
>>> any of the remote-hg commits mentioned above by Thomas R
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
>> behaviour will change in Git 2.0 with respect to paths you
>> removed from your working tree.
>>
>> * 'git add --no-all ', which is the current default,
>>
Junio C Hamano wrote:
> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
> behaviour will change in Git 2.0 with respect to paths you
> removed from your working tree.
>
> * 'git add --no-all ', which is the current default,
> ignores paths you removed from yo
On Thu, Apr 18, 2013 at 03:10:29PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I am expecting a reaction more like "Hmm, I never thought about it
> > before. Does that make sense to me or not? Let me think about which
> > paths it pertains to and decide".
>
> Let's step back and re-r
On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord wrote:
> On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
>> Yes please. Show me one of the instances where you hit a bisect with
>> any of the remote-hg commits mentioned above by Thomas Rast.
>
> I made no such claim. In fact, I have never bisected t
Jeff King writes:
> I am expecting a reaction more like "Hmm, I never thought about it
> before. Does that make sense to me or not? Let me think about which
> paths it pertains to and decide".
Let's step back and re-review the main text.
It currently says:
In Git 2.0, 'git add ...' will al
On Thu, Apr 18, 2013 at 02:37:53PM -0700, Junio C Hamano wrote:
> Because this is to help people who are _used_ to seeing "git add"
> not take the removals into account, I doubt that "Did I want those
> updated or not? Let me see the details of them." will be the
> question they will be asking [*
Jeff King writes:
>> But I think we are doing users a disservice by listing tons of
>> paths. Where the difference of versions matters _most_ is when the
>> user has tons of removed paths in the working tree. Either with one
>> warning per path, or a block of collected paths at the end, we are
On Thu, Apr 18, 2013 at 11:16:33AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > could work for both cases. Something like "not considering" (or another
> > synonym for "considering") might be even more accurate. It is not just
> > that we did not stage it; it is what we did not even co
On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
wrote:
> On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord wrote:
>> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
>>> If you want to waste your time, by all means, rewrite all my commit
>>> messages with essays that nobody will ever read. I'm not g
Jeff King writes:
> could work for both cases. Something like "not considering" (or another
> synonym for "considering") might be even more accurate. It is not just
> that we did not stage it; it is what we did not even consider it an item
> for staging under the current rules.
Yes, "not conside
On Thu, Apr 18, 2013 at 10:51:12AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +static const char *add_would_remove_warning = N_(
> > +/* indent for "warning: " */
> > + "In Git 2.0, 'git add ...' will also update the\n"
> > +"index for paths removed from the working tree that
Jeff King writes:
> +static const char *add_would_remove_warning = N_(
> +/* indent for "warning: " */
> + "In Git 2.0, 'git add ...' will also update the\n"
> +"index for paths removed from the working tree that match the given\n"
> +"pathspec. If you want to 'add' only changed or newly
On Wed, Apr 17, 2013 at 06:39:06PM -0700, Junio C Hamano wrote:
> Subject: [PATCH] git add: rework the logic to warn "git add ..."
> default change
>
> [...]
>
> Rework the logic to detect the case where the behaviour will be
> different in Git 2.0, and issue a warning only when it matters.
> Eve
On Thu, Apr 18, 2013 at 6:46 AM, Ramkumar Ramachandra
wrote:
> Okay, one more segment needs to be responded to.
>
> Felipe Contreras wrote:
>> If remote-hg wasn't available for users, they would be hurt; if stash
>> wasn't available, if rebase --interactive didn't exist, if there was
>> no msysgit
On Thu, Apr 18, 2013 at 6:31 AM, Ramkumar Ramachandra
wrote:
> Since you disagreed with the rest, I'll only respond to this part:
>
> Felipe Contreras wrote:
>> But I won't bother trying to convince you that no project is more
>> important than its users (in the words of Linus Torvalds), because
>
Okay, one more segment needs to be responded to.
Felipe Contreras wrote:
> If remote-hg wasn't available for users, they would be hurt; if stash
> wasn't available, if rebase --interactive didn't exist, if there was
> no msysgit, if it wasn't so fast, if the object model wasn't so simple
> and ext
Since you disagreed with the rest, I'll only respond to this part:
Felipe Contreras wrote:
> But I won't bother trying to convince you that no project is more
> important than its users (in the words of Linus Torvalds), because
> most people don't see the big picture.
I didn't say otherwise. Wha
On Thu, Apr 18, 2013 at 5:27 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Except the customers are not git developers, it's git users. Git
>> developers rejecting patches because of the commit message is akin to
>> distributors rejecting products because they don't like the
>> tran
Felipe Contreras wrote:
> Except the customers are not git developers, it's git users. Git
> developers rejecting patches because of the commit message is akin to
> distributors rejecting products because they don't like the
> transportation packages; they are only hurting themselves, by hurting
>
On Thu, Apr 18, 2013 at 4:19 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> I think the commit message is fine, you don't. So YOU go ahead and
>> write the proper one. If you don't, all you are doing is being an
>> impediment to progress.
>
> Hey Felipe. Let's get a few things strai
Felipe Contreras wrote:
> I think the commit message is fine, you don't. So YOU go ahead and
> write the proper one. If you don't, all you are doing is being an
> impediment to progress.
Hey Felipe. Let's get a few things straightened out first:
- We all act in our selfish interests, and write c
On Thu, Apr 18, 2013 at 2:44 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> * How many times have you tracked regressions in transport helper's
>> import/export functionality?
>>
>> Hint: zero.
>
> The real question to make the situation non-hypothetical would actually
> be "how many tim
Felipe Contreras writes:
> * How many times have you tracked regressions in transport helper's
> import/export functionality?
>
> Hint: zero.
The real question to make the situation non-hypothetical would actually
be "how many times did you track a regression that bisected down to
*this particul
On Wed, Apr 17, 2013 at 6:56 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> And how do you know this will be part of the 1%? You don't. How many
>> times have you tracked regressions in transport helper's import/export
>> functionality? How many times in remote-hg? How many times has
>
Jeff King writes:
> Yeah, I had the same thought, as this warning has been bugging me for
> the last day or two. The worst part about it is that I finally trained
> myself to type "git add ." to silence the _other_ warning, and now it
> triggers this one. :)
So here is the "reworked" one on top
Felipe Contreras writes:
> And how do you know this will be part of the 1%? You don't. How many
> times have you tracked regressions in transport helper's import/export
> functionality? How many times in remote-hg? How many times has
> *anybody* done so?
The last point makes it all the more impo
On Wed, Apr 17, 2013 at 11:14:42AM -0700, Junio C Hamano wrote:
> > I think it is just the warning code avoiding extra complexity and
> > overhead, if you are talking about not getting warning in the
> > pre-2.0 step that is in 'next'. Patches are very much welcomed,
> > especially the ones that
On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord wrote:
> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
> wrote:
>> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:
>>> A cursory look^W^Wreview of the messages in fc/remote-hg:
>>
>> [skipping irrelevant comments]
>>
>> I'm sorry, did you actual
Junio C Hamano writes:
> Thomas Rast writes:
>
>> I can see that problem, but along the same lines, why shouldn't I have
>> an expectation that when I say 'git add "*.py"' it removes stuff that I
>> have removed?
>
> You _should_ have that expectation.
>
> If it does not remove with the code tha
Thomas Rast writes:
> I can see that problem, but along the same lines, why shouldn't I have
> an expectation that when I say 'git add "*.py"' it removes stuff that I
> have removed?
You _should_ have that expectation.
If it does not remove with the code that has been prepared for 2.0
(that is
Junio C Hamano writes:
> Thomas Rast writes:
>
>> The warning triggers in some cases where it shouldn't, relating to
>> submodules:
>>
>> $ git submodule add gito...@git.csa.inf.ethz.ch:domjudge.git domjudge
>> Adding existing repo at 'domjudge' to the index
>> warning: In Git 2.0, 'git ad
Thomas Rast writes:
> The warning triggers in some cases where it shouldn't, relating to
> submodules:
>
> $ git submodule add gito...@git.csa.inf.ethz.ch:domjudge.git domjudge
> Adding existing repo at 'domjudge' to the index
> warning: In Git 2.0, 'git add ...' will also update
> the in
Lukas Fleischer writes:
> Not sure if you care but the commit messages of these are all wrong now
> that you squashed your API fix into the first commit. They all refer to
> read_blob_data_from_index_path()...
Ouch; thanks for noticing.
--
To unsubscribe from this list: send the line "unsubscrib
Junio C Hamano writes:
> * jc/add-2.0-delete-default (2013-03-08) 3 commits
> - git add ... defaults to "-A"
> (merged to 'next' on 2013-04-05 at 199442e)
> + git add: start preparing for "git add ..." to default to "-A"
> + builtin/add.c: simplify boolean variables
>
> In Git 2.0, "git add
On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
> [...]
> --
> [New Topics]
Phil Hord writes:
> ... Almost every time I bisect a regression
> in git.git, I find the commit message tells me exactly why the commit
> did what it did and what the expected result was. I find this to be
> amazingly useful.
> ...
> Of course, 99% of the commit messages may never be useful to
On Tue, Apr 16, 2013 at 5:34 PM, Phil Hord wrote:
> On Tue, Apr 16, 2013 at 3:48 PM, Felipe Contreras
> wrote:
>> Here it goes. The remote helper ref is going to be used to tell
>> fast-export which refs to negate (e.g. ^refs/testgit/origin/master),
>> so that extra commits are not generated, whi
On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
wrote:
> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:
>> A cursory look^W^Wreview of the messages in fc/remote-hg:
>
> [skipping irrelevant comments]
>
> I'm sorry, did you actually hit an issue that required to look at the
> commit message
On Tue, Apr 16, 2013 at 3:48 PM, Felipe Contreras
wrote:
> Here it goes. The remote helper ref is going to be used to tell
> fast-export which refs to negate (e.g. ^refs/testgit/origin/master),
> so that extra commits are not generated, which the remote helper
> should ignore anyway, because it sh
On Tue, Apr 16, 2013 at 2:19 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Sure, and where is the thinking not clear? The remote helper ref is
>> not updated, so we do update it. How is that not clear?
>
> Sure, between "leaving it untouched, keeping the stale value" and
> "updating i
Felipe Contreras writes:
> Sure, and where is the thinking not clear? The remote helper ref is
> not updated, so we do update it. How is that not clear?
Sure, between "leaving it untouched, keeping the stale value" and
"updating it to match what was pushed", everybody would know you
mean the lat
On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:
> Felipe Contreras writes:
>
>> Clearly, that's the correct behavior. Why would anybody send a change
>> that does something other than the correct behavior?
>
> Along the same lines, why would anyone write broken code? Nobody does,
> right?
Y
Jeff King writes:
> The solution is simple: now that FAILONERROR is a
> per-request setting, we move it to get_active_slot to make
> sure it is reset for each request.
>
> Signed-off-by: Jeff King
> ---
> Hmph. I have no idea how this ever passed the tests, so I can only
> assume that I screwed
Felipe Contreras writes:
> Clearly, that's the correct behavior. Why would anybody send a change
> that does something other than the correct behavior?
Along the same lines, why would anyone write broken code? Nobody does,
right?
If anyone reads that commit message in more than a few weeks, th
On Mon, Apr 15, 2013 at 11:12 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> So it should be clear now: the remote namespace refs/origin/master is
>> updated, but not the remote helper's namespace
>> refs/testgit/origin/master, which is what I already said. I don't know
>> what more do
Felipe Contreras writes:
> So it should be clear now: the remote namespace refs/origin/master is
> updated, but not the remote helper's namespace
> refs/testgit/origin/master, which is what I already said. I don't know
> what more do you expect. When you push 'refs/heads/master' to origin,
> you
n Mon, Apr 15, 2013 at 4:28 PM, Junio C Hamano wrote:
> * jn/gitweb-install-doc (2013-04-15) 1 commit
> - gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM
>
> Reword gitweb configuration instrutions.
>
> Will merge to 'next'.
While the re-worded text is easier on the eyes it fails
On Mon, Apr 15, 2013 at 8:30 PM, Jeff King wrote:
> Subject: [PATCH] http: set curl FAILONERROR each time we select a handle
>
> Until commit 6d052d7 (http: add HTTP_KEEP_ERROR option,
> 2013-04-05), setting curl's FAILONERROR option was a global
> setup; we never changed it. However, 6d052d7 intr
On Tue, Apr 16, 2013 at 01:49:13AM +0200, Øyvind A. Holm wrote:
> > [1] I know you always test master before pushing it out, but I suspect
> > you do not run the GIT_TEST_HTTPD tests. The failures are in t5541
> > and t5551.
>
> Ah, that explains why the test suite passed here, I built a
On Mon, Apr 15, 2013 at 07:25:32PM -0400, Jeff King wrote:
> On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
>
> > * jk/http-error-messages (2013-04-06) 9 commits
> [...]
> ...the tip of your current master does not currently pass the test
> suite[1]. I bisected the problem to "sh
On 16 April 2013 01:25, Jeff King wrote:
> On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
> > [Graduated to "master"]
> > [...]
> > * jk/http-error-messages (2013-04-06) 9 commits
> > (merged to 'next' on 2013-04-11 at 7a03981)
> > [...]
>
> ...the tip of your current master doe
On Mon, Apr 15, 2013 at 6:14 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> And about this:
>> http://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contre...@gmail.com
>
> What about it? Is that the one you said you are going to reroll?
At first, but then I changed my mind.
On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
> [Graduated to "master"]
> [...]
> * jk/http-error-messages (2013-04-06) 9 commits
> (merged to 'next' on 2013-04-11 at 7a03981)
> + http: drop http_error function
> + remote-curl: die directly with http error messages
> + http:
Felipe Contreras writes:
> And about this:
> http://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contre...@gmail.com
What about it? Is that the one you said you are going to reroll?
I do not recall the details of Peff's complaints, but re-reading the
log message of the patch itself, s
On Mon, Apr 15, 2013 at 3:28 PM, Junio C Hamano wrote:
> * fc/remote-hg (2013-04-11) 21 commits
> - remote-hg: activate graphlog extension for hg_log()
> - remote-hg: fix bad file paths
> - remote-hg: document location of stored hg repository
> - remote-hg: fix bad state issue
> - remote-hg:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
65 matches
Mail list logo
