Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Revert 77c1305 and 3c3b46b
>
> The core of the argument seems to be that
> __git_complete_revlist_file() is a misleading name for the completion
> done by archive and ls-tree, but __git_complete_file() is somehow a
> less misleading name
Jeff King writes:
> It may be worth looking again for other places to use this over
> commit_list, but even the caller you are introducing here justifies its
> presence.
The next candidate is paint-down-to-common, probably.
> Also, I wrote some basic tests to cover the priority queue as a unit.
Jeff King writes:
> The performance enhancement of the priority queue came from replacing
> "commit_list_insert_by_date" calls with insertion into a queue. That
> drops O(n^2) behavior on the linked-list down to O(n log n), as we have
> "n" insertions, each causing an O(log n) heapify operation.
On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
> I vaguely remember there was some way to say
> "head of the remote I am tracking" - but I could not find it.
> Where are all the tricks like foo^{} documented?
gitrevisions(7) is what you're looking for here.
In this case I thi
Jeff King writes:
> I'm not excited about introducing yet another place that parses commit
> objects (mostly not for correctness, but because we have had
> inconsistency in how malformed objects are treated). It is at least
> using split_ident_line which covers the hard bits. I wonder how much
>
Junio C Hamano wrote:
> But it turns out that in the context of these functions it refers to
> "what users consider paths in objects stored in the object database"
> (as opposed to working tree paths). That is what ls-tree would take
> (i.e. and :). And I do not offhand think
> of a better name
Once again, thanks a lot your feedback, we appreciate it a lot!
Le 2013-06-08 15:51, Ramkumar Ramachandra a écrit :
Mathieu Lienard--Mayor wrote:
@@ -170,30 +175,47 @@ static int check_local_mod(unsigned char
*head, int index_only)
* "intent to add" entry.
*/
Felipe Contreras wrote:
> git-rebase.rb | 2056
> +
> 1 file changed, 2056 insertions(+)
> create mode 100755 git-rebase.rb
I suggest putting this in contrib/ and cooking it. As usual, my
mantra is: let the patches decide what to do. I'l
"Michael S. Tsirkin" writes:
>> Not needed with recent "git format-patch -v4" option.
>
> Unless I rerun with same vX :(
> Would it make sense for it to check for vX existance and fail?
> Same without -vX, when 000X exists ...
> Could be an option.
Oh, instead of exact -v$N, trigger it with "-v
Le 2013-06-08 16:01, Ramkumar Ramachandra a écrit :
Mathieu Lienard--Mayor wrote:
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
would look like, with advice.rmHints=true:
error: 'foo.t
Mathieu Liénard--Mayor wrote:
> I'm not so sure i understand. Do you mean rmHints should deactivate addHints
> aswell, or do you mean that since we're introducing rmHints it would be
> natural to introduce addHints ?
More the latter, but I'm tilting towards addRmHints (or something)
which affects
El 2013-06-08 17:25, Ramkumar Ramachandra escribió:
Jorge Juan Garcia Garcia wrote:
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Good feature.
@@ -1112,6 +1112,15 @@ static int git_status_config(const char *k,
const char *v, voi
El 2013-06-09 21:26, Matthieu Moy escribió:
Junio C Hamano writes:
Ramkumar Ramachandra writes:
Jorge Juan Garcia Garcia wrote:
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by
default.
Good feature.
Is there a corresponding command l
Ramkumar Ramachandra writes:
> Mathieu Liénard--Mayor wrote:
>> I'm not so sure i understand. Do you mean rmHints should deactivate addHints
>> aswell, or do you mean that since we're introducing rmHints it would be
>> natural to introduce addHints ?
>
> More the latter, but I'm tilting towards a
Matthieu Moy wrote:
> I don't see why add and rm hints should be correlated, or I don't have
> the same advice as you in mind.
>
> Both have completely different meanings: the first is about .gitignore,
> and the second about not loosing data.
Right, my bad. Please continue with rmHints, and opti
Célestin Matte writes:
> A "split ' '" is turned into a "split / /", which changes its behaviour: the
> old method matched a run of whtespaces (/\s*/)
It case there's a v4: whtespaces -> whitespaces.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the li
Felipe Contreras writes:
> On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:
>
>> One example of killing the entire thread is when I see "This patch
>> will not be applied" by Felipe in a thread started with his patch.
>> I understand that it is his way to say "this patch is retracted"
>> wi
Célestin Matte writes:
> @@ -1285,8 +1285,7 @@ sub get_mw_namespace_id {
> # Look at configuration file, if the record for that namespace
> is
> # already cached. Namespaces are stored in form:
> # "Name_of_namespace:Id_namespace", ex.: "File:6".
> -
Junio C Hamano wrote:
> I am not sure what you mean by artificial.
By artificial, I mean that the precondition is absolutely unnecessary
for the code following it to work. The precondition was introduced in
a separate commit, specifically denying one usecase because the author
(you) thought that
Eric Sunshine writes:
> On Sun, Jun 9, 2013 at 6:22 PM, Célestin Matte
> wrote:
>> Changes with v2:
>> - Remove patch [02/22] about using the Readonly module
>> - Split commit [07/22] into 5 different ones
>
> This was easier to review after being split. Thanks.
>
>> - Split commit [14/22] into
On Mon, Jun 10, 2013 at 08:29:31AM +0100, John Keeping wrote:
> On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
> > I vaguely remember there was some way to say
> > "head of the remote I am tracking" - but I could not find it.
> > Where are all the tricks like foo^{} documented?
On 06/10/2013 07:15 AM, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
> wrote:
>
>> I do accuse Felipe's *attitude* to bring on and nourish such
>> unpleasantness toxicity. His technical merits and the possible
>> qualities of his patches do *nothing* to remov
First things first: Junio, please don't pick up this patch.
On Sun, Jun 09, 2013 at 05:09:54PM -0700, Jonathan Nieder wrote:
> SZEDER Gábor wrote:
>
> > Fedore 9 shipped the gvfs package with a buggy Bash completion script:
> > it removed the ':' character from COMP_WORDBREAKS, thereby breaking
Ramkumar Ramachandra writes:
> I don't understand why upstream/ simple should _not_ push to a
> different destination from the one being merged from. I'll repeat:
> push source/ destination is orthogonal to push refspec, and
> push.default modes dictate the refspec.
That is where we differ. Yo
On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
> There
> will not be a need for test_string_must_be_empty() just like there's
> no need for test_string_cmp().
Actually, if there were a test_string_cmp(), that would be the test
helper function I used most often.
--
To unsubscrib
Le 10/06/2013 02:50, Eric Sunshine a écrit :
> Given this patch's intention to use ${} within strings, should this be
> ${credential{username}}?
>
> (I don't have a preference, but it's a genuine question since it's not
> clear if this was an oversight or intentional.)
The answer is simple: I did
Le 10/06/2013 10:37, Matthieu Moy a écrit :
> Célestin Matte writes:
>
>> @@ -1285,8 +1285,7 @@ sub get_mw_namespace_id {
>> # Look at configuration file, if the record for that namespace
>> is
>> # already cached. Namespaces are stored in form:
>> # "Name_
Le 08/06/2013 10:33, Mathieu Lienard--Mayor a écrit :
> + if (files_staged.len)
> + errs = error(_("the following files have staged content "
> +"different from both the\nfileand the HEAD:%s\n"
> +"(use -f to force removal)"),
On Mon, Jun 10, 2013 at 7:48 AM, Johannes Sixt wrote:
> From: Erik Faye-Lund
>
> Returning the SIGALRM handler for SIGINT is not very useful.
>
> Signed-off-by: Erik Faye-Lund
> Signed-off-by: Johannes Sixt
> ---
> Am 6/7/2013 16:20, schrieb Erik Faye-Lund:
>> On Fri, Jun 7, 2013 at 3:07 PM, Jo
On Mon, Jun 10, 2013 at 7:30 AM, Johannes Sixt wrote:
> Am 6/9/2013 22:31, schrieb Junio C Hamano:
>> Jeff King writes:
>>
>>> I'm a little negative on handling just SIGTERM. That would make the test
>>> pass, but does it really address the overall issue? To me, the
>>> usefulness is having exit
Junio C Hamano wrote:
> The name under which the local branch is published needs a sensible
> default (when branch.$name.push is not specified), and I agree that
> you would get the name of the branch my work was forked from if you
> reuse the "upstream" code. I am saying that it does not necessar
[-CC: Duy, since he has left the community]
Junio: since Duy is no longer around to guide us, I will rely on your guidance.
Duy Nguyen wrote:
> I'm starting to think this is a half-baked solution. It hides
> problems, for example commit placeholders should produce empty string,
> not the literal
On Sun, Jun 09, 2013 at 02:47:57PM +0200, Bernhard R. Link wrote:
> * Ian Kumlien [130605 13:31]:
> > Yes, i agree, it's suboptimal but I for one would use getpwuid to get
> > the home directory of the executing user to avoid this - though i don't
> > know how portable it is (or if there is any ot
Le 07/06/2013 18:01, Sarma Tangirala a écrit :
> On Thu, Jun 6, 2013 at 6:17 PM, Junio C Hamano wrote:
>> Célestin Matte writes:
>>
>
>> But for a two-endpoint diff Porcelain (not the plumbing diff-files,
>> diff-index and diff-tree), I do not think it is particularly a bad
>> idea to add such a
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an example, the old message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force remova
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
woul
Please ignore this, manipulation error while in the git send-email
command line.
Le 2013-06-10 14:51, Mathieu Lienard--Mayor a écrit :
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current
behavior.
As an example
Please ignore this, manipulation error while in the git send-email
command line.
Le 2013-06-10 14:51, Mathieu Lienard--Mayor a écrit :
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an examp
I've tried to write down a bare minimum, without restating the obvious.
0. You do not take offense, no matter what. If someone attacks you
irrationally, you do not respond. This is a public mailing list, and
we are all rational people: the attacker has already humiliated
herself in public, and e
Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
> 0. You do not take offense, no matter what. If someone attacks you
> irrationally, you do not respond. This is a public mailing list, and
> we are all rational people: the attacker has already humiliated
> herself in public, and everyone can s
Célestin Matte writes:
> Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
>> 0. You do not take offense, no matter what. If someone attacks you
>> irrationally, you do not respond. This is a public mailing list, and
>> we are all rational people: the attacker has already humiliated
>> hersel
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
woul
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step,
which tend to indicate
The meaning of get_colorbool_found and get_diff_color_found is "the
config value if found, and -1 otherwise", but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.
Make get_color_u
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an example, the old message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force remova
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
woul
I've just been trying to use "add -p" to stage some changes which happen
to be textually entangled with other changes that I do not want to
stage.
It turns out that "git diff --patience" does a really good job
splitting this into exactly the hunks I want, but "add --interactive"
doesn't let me cha
Mathieu Lienard--Mayor writes:
> When 'git rm' fails, it now displays a single message
> with the list of files involved, instead of displaying
> a list of messages with one file each.
>
> As an example, the old message:
> error: 'foo.txt' has changes staged in the index
> (use --cach
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
Signed-off-by: Mathieu Lienard--Mayor
Signed-off-by: Matthieu Moy
---
Changes since v1:
-documentation more accurate
-removal of unappropriate
On Mon, Jun 10, 2013 at 8:44 AM, Célestin Matte
wrote:
> Since nobody answered you (publicly at least), I will try doing it myself:
> I think the best thing to do if you want a feature to be added is to
> come with a patch and request for comments on it. Then, people will
> discuss it and decide
Jorge Juan Garcia Garcia
writes:
> +test_expect_success '"Setup of environment of test"' '
Why these double quotes inside single quotes?
> +test_expect_success '"Back to environment of test by default"' '
Same.
"test environment" would sound better than "environment of test" in
english.
> +
Hi,
using gitk (git 1.8.3), the program gets stuck when checking out a new
branch if the last checked-out branch was the bottom left branch. The
error occurs consistently in this repository, but unfortunately, I
cannot reproduce the error on another repository. The message reads:
invalid command
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
Signed-off-by: Mathieu Lienard--Mayor
Signed-off-by: Matthieu Moy
---
Changes since v1:
-Documentation more accurate
-removal of unappropriate functi
Le 2013-06-10 16:38, Matthieu Moy a écrit :
Mathieu Lienard--Mayor
writes:
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an example, the old message:
error: 'foo.txt' has changes
Mathieu Liénard--Mayor writes:
> Well the current code is only using errs=error(...), using the same
> variable errs over and over, no matter how many times it loops.
> That's why i implemented it similarly.
OK, consistency is a good argument then.
--
Matthieu Moy
http://www-verimag.imag.fr/~m
From: Jorge Juan Garcia Garcia
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
Signed-off-by: Mathieu Lienard--Mayor
Signed-off-by: Matthieu Moy
---
Changes to be commented:
- Cleaning test
From: Jorge Juan Garcia Garcia
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
Signed-off-by: Mathieu Lienard--Mayor
Signed-off-by: Matthieu Moy
---
Changes to be commented:
- Cleaning test
Docum
y...@ensimag.imag.fr writes:
> To: y...@ensimag.imag.fr
Common mistake, but you're not supposed to answer "y" when you're
prompted for an email ;-).
set sendemail.from to avoid this.
> +test_expect_success '"Setup of environment of test"' '
Same problem as v2.
> +test_expect_success '"Back to
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
Signed-off-by: Mathieu Lienard--Mayor
Signed-off-by: Matthieu Moy
---
Changes since v2:
-removal of double quotes in test
Documentation/config.txt |
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
Signed-off-by: Mathieu Lienard--Mayor
Signed-off-by: Matthieu Moy
---
Changes since v2:
-removal of double quotes in test
-use of git config -
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> The name under which the local branch is published needs a sensible
>> default (when branch.$name.push is not specified), and I agree that
>> you would get the name of the branch my work was forked from if you
>> reuse the "upstream" code.
SZEDER Gábor writes:
> On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
>> There
>> will not be a need for test_string_must_be_empty() just like there's
>> no need for test_string_cmp().
>
> Actually, if there were a test_string_cmp(), that would be the test
> helper function I u
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
woul
Ramkumar Ramachandra writes:
> [-CC: Duy, since he has left the community]
>
> Junio: since Duy is no longer around to guide us, I will rely on your
> guidance.
>
> Duy Nguyen wrote:
>> I'm starting to think this is a half-baked solution. It hides
>> problems, for example commit placeholders sho
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an example, the old message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force remova
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an example, the old message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force remova
Mathieu Lienard--Mayor writes:
> +static void print_eventual_error_files(struct string_list *files_list,
Too french ;-).
Eventual (en) = final, utlime (fr).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
woul
Junio C Hamano wrote:
> Only if I want to publish the result of the work forked from your
> "triangle" as my "triangle", but that is not the case. A fork to be
> integrated by other is by definition more specialized than the
> original, and I would publish my "pushbranch" subtopic as such, not
> a
Hi,
So, this 'git checkout -' not working after a 'rebase -i' has annoyed
me to no end. This is the fix.
Unfortunately, some tests fail and I'm still tracking down what
exactly is going on.
Thanks.
Ramkumar Ramachandra (3):
t/checkout-last: checkout - doesn't work after rebase -i
checkout:
The following command
$ git checkout -
does not work as expected after a 'git rebase -i'.
Add a failing test documenting this bug.
Signed-off-by: Ramkumar Ramachandra
---
t/t2012-checkout-last.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t2012-checkout-last.sh b/t/t2012-
Invoking 'git rebase -i' writes the following line to the reflog at the
start of the operation:
rebase -i (start)
This is not very useful. Make it more informative like:
rebase -i (start): checkout master
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--interactive.sh | 2 ++
1 file c
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Other commands including
merge, reset, and commit respect it.
This incidentally fixes a bug in t/checkout-last. You can now expect
$ git checkout -
to work fine after an interact
On Mon, Jun 10, 2013 at 04:04:29PM +0200, Matthieu Moy wrote:
> Célestin Matte writes:
>
> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
> >> 0. You do not take offense, no matter what. If someone attacks you
> >> irrationally, you do not respond. This is a public mailing list, and
> >
Matthieu Moy writes:
> Célestin Matte writes:
>
>> @@ -1285,8 +1285,7 @@ sub get_mw_namespace_id {
>> # Look at configuration file, if the record for that namespace
>> is
>> # already cached. Namespaces are stored in form:
>> # "Name_of_namespace:Id_namesp
On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:
>>
>>> One example of killing the entire thread is when I see "This patch
>>> will not be applied" by Felipe in a thread started with his patch.
>>> I unde
On Mon, Jun 10, 2013 at 11:53 AM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:
>> E.g.
>> convincing people that it is not worth their time interacting with
>> you, especially when there are better things to do like tending to
>> other topics, and you lose the
Mathieu Liénard--Mayor writes:
> Please ignore this, manipulation error while in the git send-email
> command line.
Here is what my mailbox looks like (the penultimate one with 252
lines is what I am responding to).
R. [ 146: Mathieu Lienard--Mayor ] [PATCH 1/2] rm: better error messa
R.
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
wrote:
>> You need two sides to have an argument.
> I disagree. Unless you mean than, whenever a part behaves in a
> hostile and aggressive way, the other part should just silently
> knuckle under.
You are wrong. If a bum in the street starts
On Mon, Jun 10, 2013 at 10:56 AM, Junio C Hamano wrote:
> By the way, test_cmp() is a replacement for the "cmp" command and
> that is why it does not have "file" in its name.
That's an irrelevant implementation detail. But if you want to be
driven the the implementation, call it test_zero().
--
Mathieu Lienard--Mayor
writes:
> When 'git rm' fails, it now displays a single message
> with the list of files involved, instead of displaying
> a list of messages with one file each.
>
> As an example, the old message:
> error: 'foo.txt' has changes staged in the index
> (use --cach
Well, I think next step would be to replace all those calls with
Git.pm `command`, `command_oneline` and `config``which take an array
of arguments after the "command". In the preview tool we use those but
I don't know if we will find the time to clean that up too in
git-remote-mediawiki :) .
Don't
On Mon, Jun 10, 2013 at 2:48 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> git-rebase.rb | 2056
>> +
>> 1 file changed, 2056 insertions(+)
>> create mode 100755 git-rebase.rb
>
> I suggest putting this in contrib/ and cooki
Le 2013-06-10 18:57, Junio C Hamano a écrit :
Mathieu Liénard--Mayor writes:
Please ignore this, manipulation error while in the git send-email
command line.
Here is what my mailbox looks like (the penultimate one with 252
lines is what I am responding to).
R. [ 146: Mathieu Lienard--May
Mathieu Lienard--Mayor
writes:
> Introduce advice.rmHints to choose whether to display advice or not
> when git rm fails. Defaults to true, in order to preserve current behavior.
>
> As an example, the message:
> error: 'foo.txt' has changes staged in the index
> (use --cached to keep
On Mon, Jun 10, 2013 at 08:56:58AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
> >> There
> >> will not be a need for test_string_must_be_empty() just like there's
> >> no need for test_string_cmp().
> >
> > Actually,
Please, don't top-post. Quote the part of the message you're replying
to, and reply below.
Benoît Person writes:
> Well, I think next step would be to replace all those calls with
> Git.pm `command`, `command_oneline` and `config``which take an array
> of arguments after the "command". In the pr
Felipe Contreras writes:
> It is not bad behavior. It is bad behavior *in your opinion*,
And in essentially everyone else on this list, it seems.
> an opinion that wouldn't be shared by other projects, like the Linux
> kernel.
Googling your name and LKML gives me this in the first page (addres
Junio C Hamano writes:
>> +{
>> +if (files_list->nr) {
>> +struct strbuf err_msg = STRBUF_INIT;
>> +int i;
>> +strbuf_addstr(&err_msg, main_msg);
>> +for (i = 0; i < files_list->nr; i++)
>> +strbuf_addf(&err_msg,
>> +
"Robin H. Johnson" writes:
> On Mon, Jun 10, 2013 at 04:04:29PM +0200, Matthieu Moy wrote:
>> Célestin Matte writes:
>>
>> > Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
>> >> 0. You do not take offense, no matter what. If someone attacks you
>> >> irrationally, you do not respond. Th
Matthieu Moy writes:
> y...@ensimag.imag.fr writes:
>
>> To: y...@ensimag.imag.fr
>
> Common mistake, but you're not supposed to answer "y" when you're
> prompted for an email ;-).
Didn't we introduce safety against this in v1.7.12.1 and later? Is
the new release taking more than 9 months to pe
Matthieu Moy wrote:
> https://lkml.org/lkml/2012/4/12/434
> https://lkml.org/lkml/2012/4/15/112
We don't want things taken out of context now, do we? Follow up this
thread [1], if you're interested in that discussion. I did clip out
the quotes you chose on purpose, in the interest of presenting
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
> wrote:
>
>>> You need two sides to have an argument.
>
>> I disagree. Unless you mean than, whenever a part behaves in a
>> hostile and aggressive way, the other part should just silen
On Mon, Jun 10, 2013 at 12:21:00AM -0700, Junio C Hamano wrote:
> > It may be worth looking again for other places to use this over
> > commit_list, but even the caller you are introducing here justifies its
> > presence.
>
> The next candidate is paint-down-to-common, probably.
Yeah, I don't th
Jorge Juan Garcia Garcia
writes:
> Some people always run 'git status -s'.
> The configuration variable status.short allows to set it by default.
>
> Signed-off-by: Jorge Juan Garcia Garcia
>
> Signed-off-by: Mathieu Lienard--Mayor
> Signed-off-by: Matthieu Moy
> ---
>
> Changes since v2:
>
Jorge Juan Garcia Garcia
writes:
> Some people often run 'git status -b'.
> The config variable status.branch allows to set it by default.
>
> Signed-off-by: Jorge Juan Garcia Garcia
>
> Signed-off-by: Mathieu Lienard--Mayor
> Signed-off-by: Matthieu Moy
> ---
>
> Changes since v2:
> -remov
On Mon, Jun 10, 2013 at 12:27:31AM -0700, Junio C Hamano wrote:
> > Around the same time, though, René wrote the linked-list merge sort that
> > powers commit_list_sort_by_date. And topo-sort learned to do O(1)
> > insertions into the unsorted list, and then one O(n log n) sort.
>
> Yes, but that
Junio C Hamano writes:
> test_expect_success '-c status.short=true == status -s' '
> test_config status.showUntrackedFile no &&
That's an option, but having status.showUntrackedFile set in a separate
setup test makes the actual tests shorter. The setup test has no reason
to f
Ramkumar Ramachandra writes:
> The following command
>
> $ git checkout -
>
> does not work as expected after a 'git rebase -i'.
>
> Add a failing test documenting this bug.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> t/t2012-checkout-last.sh | 8
> 1 file changed, 8 insertions(+
Ramkumar Ramachandra writes:
> GIT_REFLOG_ACTION is an environment variable specifying the reflog
> message to write after an action is completed. Other commands including
> merge, reset, and commit respect it.
>
> This incidentally fixes a bug in t/checkout-last. You can now expect
>
> $ git
1 - 100 of 176 matches
Mail list logo
