Am 6/17/2013 11:18, schrieb Thomas Rast:
> +match_pattern_list () {
> + arg="$1"
> + shift
> + test -z "$*" && return 1
> + for pat
> + do
> + case "$arg" in
> + $pat)
> + return 0
> + esac
> + done
> + return 1
> +
Phil Hord wrote:
> I share your disdain for the bare '40's in the code. But I think this
> code is less clear than the previous version with the magic number.
Please read the cover-letter: I was just toying around to see if this
was a good idea, and Junio points out that it's not.
--
To unsubscri
Junio C Hamano wrote:
>> Will replace what has been queued on 'pu'.
>
> ... after fixing an indentation error, that is.
Where did the error occur? I thought I taught my Emacs to always
indent properly.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to m
Philip Oakley wrote:
> A sentence, in the Documentation/config.txt, is needed to clarify the
> Central workflow and any distinction with the non-central workflow(s). We
> cannot assume the new reader has the same world view of that concept (they
> may be thinking it means we do a centralised VCS,
On ma, 2013-06-17 at 13:09 -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Dennis Kaarsemaker writes:
> >
> >> I'm doing daily builds of git, using many workers and a shared git.git,
> >> with per-worker checkouts
> >
> > OK, so GIT_DIR is explicitly specified in these "workers".
[I don't seem to have received a copy of the original mail, so I can
only guess...]
Jeff King writes:
> On Sat, Jun 15, 2013 at 04:01:04PM +0200, Mark Abraham wrote:
>
>> Controlled by new configuration option
>> "color.word-diff-in-interactive-add". There is no existing support for
>> "git add"
From: Johannes Sixt
The recently introduced tests used uppercase letters to denote
cherry-picks of commits having the corresponding lowercase letter names.
The helper functions also set up tags with the names of the commits.
But this constellation fails on case-insensitive file systems because
t
Junio C Hamano wrote:
> I do no think the remainder (snipped) belongs to the log message.
Oh, it was never intended to be a proper commit message. I'll write a
proper one when I send it in with the implementation.
> - To understand "if central, works as upstream, otherwise works as
>current
Junio C Hamano writes:
> After I re-read the one, I found that "override" somewhat a strange
> expression. There is nothing that overrides or to be overriden.
Right, I actually meant "overwrite".
> How about putting it like this?
I'm not sure "push out refs other than the current branch" is
Matthieu Moy wrote:
> I'd put it the other way around: the intuitive explanation first, and
> the technical one after. For people not totally familiar with Git, the
> first part does not make much sense (and when I learn a new tool, I
> really don't like when the doc assumes I already know too much
>
> I don't understand. Do you mean that you want to change the rules
> that generate user-manual.xml? Would generating different XML files
> for the PDF and for other purposes (with different names) work as a
> way to achieve that without losing the printable manual?
>
This would be even wors
Johannes Sixt writes:
> Am 6/17/2013 11:18, schrieb Thomas Rast:
>> +match_pattern_list () {
>> +arg="$1"
>> +shift
>> +test -z "$*" && return 1
>> +for pat
>> +do
>> +case "$arg" in
>> +$pat)
>> +return 0
>> +esac
>> +
Commit 35d2fffd introduced 'git merge --abort' as a synonym to 'git reset
--merge', and added some failing tests in t7611-merge-abort.sh (search
'###' in this file) showing that 'git merge --abort' could not always
recover the pre-merge state.
Still, in many cases, 'git merge --abort' just works,
Jeff King writes:
> On Mon, Jun 17, 2013 at 11:18:48AM +0200, Thomas Rast wrote:
>
>> As suggested by Jeff King, this takes care to wrap the entire test_expect_*
>> block, but nothing else, in the verbose toggling. To that end we use
>> a new pair of hook functions. The placement is a bit weird
Matthieu Moy wrote:
> Weaken the warning by discouraging only merge with /non-trivial/
> uncommited changes.
>
> I don't think documenting all the failure cases in the doc would be a
> good idea, so I've left the "in some cases" part.
It's already documented in the pre-merge checks section, as Jon
Junio C Hamano wrote:
>> + test $# == 1 ||
>
> This is broken under POSIX shells. No need to resend (will locally
> patch up).
Ugh, my C habit. Thanks for catching it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
Ramkumar Ramachandra writes:
> Matthieu Moy wrote:
>> Weaken the warning by discouraging only merge with /non-trivial/
>> uncommited changes.
>>
>> I don't think documenting all the failure cases in the doc would be a
>> good idea, so I've left the "in some cases" part.
>
> It's already documente
On 17 June 2013 09:12, Matthieu Moy wrote:
>>> Also, it seems to be only part of the solution. With your change, from
>>> contrib/mw-to-git/ and after running only "make",
>>>
>>> ./git-mw takes the installed version of GitMediawiki.pm in priority
>>>
>>> ../../bin-wrappers/git takes the installed
Junio C Hamano wrote:
> I actually tried to reorder the patches and they seem to work OK as
> expected. And I think it makes sense to order them the way I've
> been suggesting, so I'll tentatively queue the result of reordering
> on 'rr/rebase-checkout-reflog' and push it out as a part of 'pu'.
>
On Tue, Jun 18, 2013 at 02:05:35AM -0400, Jeff King wrote:
> On Tue, Jun 18, 2013 at 04:17:03AM +0200, SZEDER Gábor wrote:
>
> > The whole series speeds up the bash prompt on Windows/MSysGit
> > considerably. Here are some timing results in two scenarios, repeated
> > 10 times:
> >
> > At the to
From: Jorge Juan Garcia Garcia
Make it so that we can use a list of email in flags
instead of having to use one flag per email address.
The format of email list handled is pretty basic for now:
$ git send-email --to='Foo , b...@example.com'
We thought it would be nice to have a "first-st
Ramkumar Ramachandra wrote:
> Thanks for the reorder and commit message tweaks. I'm working on the
> series you put up on `pu` now.
That said, I do not agree with one of your commit message updates:
checkout: respect GIT_REFLOG_ACTION
GIT_REFLOG_ACTION is an environment variable specify
From: SZEDER Gábor
---
On Tue, Jun 18, 2013 at 11:49:31AM +0200, SZEDER Gábor wrote:
> (Hmm, speaking of which, the
> patch reading HEAD might break setups using $PROMPT_COMMAND, because
> it might do a simple return without updating $PS1...)
Indeed. Here's the fixup.
contrib/completion/git-p
Benoît Person writes:
>>From my point of view, this could definitely be improved from:
>> - perlcritic -2 *.perl
>> + perlcritic -2 *.perl
>> \ No newline at end of file
> to something like that:
>> - perlcritic -2 *.perl
>> + perlcritic -2 *.perl
>> \ removed newline at end of fi
Le 2013-06-17 20:37, Junio C Hamano a écrit :
Mathieu Lienard--Mayor
writes:
When in the middle of a rebase, it can be annoying to go in .git
in order to find the SHA1 of the commit where the rebase stopped.
git-status now includes this information in its default output.
With this new informa
jorge-juan.garcia-gar...@ensimag.imag.fr wrote:
> The format of email list handled is pretty basic for now:
> $ git send-email --to='Foo , b...@example.com'
> We thought it would be nice to have a "first-step" version which works
> before handling more complex ones such as:
> $ git
Le 2013-06-18 12:12, Ramkumar Ramachandra a écrit :
jorge-juan.garcia-gar...@ensimag.imag.fr wrote:
The format of email list handled is pretty basic for now:
$ git send-email --to='Foo ,
b...@example.com'
We thought it would be nice to have a "first-step" version which
works
before ha
Mathieu Liénard--Mayor wrote:
>> Is this a regression? I can't send emails to a recipient whose name
>> contains a comma?
>
> It is not. Previously the input would be considered incorrect:
Right. It dies with
Comma in --to entry: ...
This artificial limitation is imposed by 79ee555b (Check a
> +sub split_email_list {
> +my(@list) = @_;
> +my @tmp;
> +my @emails;
> + for (my $i = 0; $i <= $#list; $i++) {
> + if ($list[$i] =~ /,/) {
> + @emails = split(/,/, $list[$i]);
> + } else {
> + @emails = $list[$i];
> + }
Junio C Hamano wrote:
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index a58406d..c175ef1 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -934,6 +934,21 @@ test_expect_success 'rebase --edit-todo can be used to
> modify todo
jorge-juan.garcia-gar...@ensimag.imag.fr wrote:
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index 9f46f22..87641bc 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -1349,4 +1349,39 @@ test_expect_success $PREREQ
> 'sendemail.aliasfile=~/.mailrc' '
>
Le 2013-06-18 12:47, Ramkumar Ramachandra a écrit :
jorge-juan.garcia-gar...@ensimag.imag.fr wrote:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 9f46f22..87641bc 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1349,4 +1349,39 @@ test_expect_success $PREREQ
Benoît Person writes:
> On 17 June 2013 09:12, Matthieu Moy wrote:
Also, it seems to be only part of the solution. With your change, from
contrib/mw-to-git/ and after running only "make",
./git-mw takes the installed version of GitMediawiki.pm in priority
../../bin-
jorge-juan.garcia-gar...@ensimag.imag.fr wrote:
> +sub split_email_list {
> +my(@list) = @_;
> +my @tmp;
> +my @emails;
> + for (my $i = 0; $i <= $#list; $i++) {
> + if ($list[$i] =~ /,/) {
> + @emails = split(/,/, $list[$i]);
> + } else {
> +
Mathieu Liénard--Mayor wrote:
> Shouldn't
>
> $ git send-email --cc 'f...@example.com' --cc 'b...@example.com'
>
> and
>
> $ git send-email --cc 'f...@example.com, b...@example.com'
>
> have the exact same effect ?
Ah. Perhaps it would be clearer to check the headers directly like in
the other te
Ramkumar Ramachandra writes:
> Mathieu Liénard--Mayor wrote:
>> Shouldn't
>>
>> $ git send-email --cc 'f...@example.com' --cc 'b...@example.com'
>>
>> and
>>
>> $ git send-email --cc 'f...@example.com, b...@example.com'
>>
>> have the exact same effect ?
>
> Ah. Perhaps it would be clearer to ch
Hi,
'git send-email' recently started to add redundant From: lines to my
messages, see e.g.
http://article.gmane.org/gmane.comp.version-control.git/228132
Bisect points to:
commit da18759e86bb1a7ee718c79a0c6cb15fbcbdf3c2
Author: Michael S. Tsirkin
Date: 2013-06-05 21:11:00 +0300
send-
No message body: areatrain...@iberotelmakadibeach.com
Original message follows.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 18, 2013 at 01:09:04PM +0200, SZEDER Gábor wrote:
> Hi,
>
> 'git send-email' recently started to add redundant From: lines to my
> messages, see e.g.
>
> http://article.gmane.org/gmane.comp.version-control.git/228132
Can you please show what do commits point to?
E.g. push to some p
On Tue, Jun 18, 2013 at 02:42:07PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 18, 2013 at 01:09:04PM +0200, SZEDER Gábor wrote:
> > Hi,
> >
> > 'git send-email' recently started to add redundant From: lines to my
> > messages, see e.g.
> >
> > http://article.gmane.org/gmane.comp.version-con
Hi Junio,
2013-06-18 AM 12:27, Junio C Hamano wrote:
Namhyung Kim writes:
In its current form, when an user wants to filter specific ref using
--refs option, she needs to give something like --refs=refs/tags/v1.*.
This is not intuitive as users might think it's enough to give just
actual tag
This is a re-roll for rr/rebase-checkout-reflog, which is queued in
`pu`.
I've reviewed the changes carefully, and I believe that they are all
correct. I've added a [6/8], because I think it is the correct way to
unset GIT_REFLOG_ACTION.
Junio: there is no need to re-export GIT_REFLOG_ACTION eve
b397ea4 (status: show more info than "currently not on any branch",
2013-03-13) attempted to make the output of 'git status' richer in
the case of a detached HEAD. Before this patch, with a detached
HEAD, we saw:
$ git status
# Not currently on any branch.
But after the patch, we see:
$ g
$ git checkout -
does not work as expected after a rebase. This is because the
reflog records "checkout" made by "rebase" as its implementation
detail the same way as end-user initiated "checkout", and makes it
count as the branch that was previously checked out.
Add four failing tests documen
From: Junio C Hamano
b397ea (status: show more info than "currently not on any branch",
2013-03-13) wanted to make sure that after a checkout to detach HEAD,
the user can see where the HEAD was originally detached from. The last
test added by that commit to t/status-help shows one example,
immed
Now that the "checkout" invoked internally from "rebase" knows to honor
GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when "rebase anotherbranch", "rebase --onto branch",
etc. internally checks out the new fork point. We will write:
rebase: checkout master
instead
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Several other commands
including merge, reset, and commit respect it.
Fix the failing tests in t/checkout-last by making checkout respect it
too. You can now expect
$ git checkout
The struct grab_1st_switch_cbdata has the field "found", which is
set in grab_1st_switch() when a match is found. This information is
redundant and unused by any code. The return value of the function
serves to communicate this information anyway.
Remove the field.
Signed-off-by: Ramkumar Ramac
Now that the "checkout" invoked internally from "rebase -i" knows to
honor GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when "rebase -i anotherbranch", "rebase -i --onto branch",
etc. internally checks out the new fork point. We will write:
rebase -i (start): check
Several callers set GIT_REFLOG_ACTION via set_reflog_action(), but
nobody unsets it, leaving a potentially stray variable in the
environment. Fix this by making die_with_status() unset it.
Signed-off-by: Ramkumar Ramachandra
---
git-sh-setup.sh | 1 +
1 file changed, 1 insertion(+)
diff --git
2013-06-18 AM 12:53, Junio C Hamano wrote:
Junio C Hamano writes:
Wouldn't it make more sense to see if the given pattern matches a
tail substring of the ref, instead of using the hardcoded "strip
refs/heads/, refs/tags or refs/, and then match once" logic? That
way, --refs=origin/* can find
It's already used twice, and we will have more of the same kind of
matching in a minute.
Helped-by: Johannes Sixt
Signed-off-by: Thomas Rast
---
t/test-lib.sh | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/t/test-lib.sh b/t/test-l
This moves
* the early setup part from test_skip to a new function test_start_
* the final common parts of test_expect_* to a new function
test_finish_
to make the next commit more obvious.
Signed-off-by: Thomas Rast
---
t/test-lib-functions.sh | 6 --
t/test-lib.sh | 9 ++
Changes from v2:
- $pat renamed to $pattern_ to avoid collisions (thanks j6t)
- New patch 3 that tests --verbose operation, and additions to patch
(now) 4 that test --verbose-only. (Adding similar tests for
--valgrind[-only] and associated options would be nice, but is much
harder because
t contains some light self-tests of test-lib.sh, but --verbose was
not covered. Add a test.
The only catch is that the presence of a test harness influences the
output (specifically, the presence of some empty lines). The easiest
fix is to unset TEST_HARNESS for the sub-test scripts. This m
With the new --verbose-only= option, one can enable --verbose
at a per-test granularity. The pattern is matched against the test
number, e.g.
./t-basic.sh --verbose-only='2[0-2]'
to see only the full output of test 20-22, while showing the rest in the
one-liner format.
As suggested by Jef
With the new --valgrind-parallel= option, we support running the
tests in a single test script under valgrind in parallel using 'n'
processes.
This really follows the dumbest approach possible, as follows:
* We spawn the test script 'n' times, using a throw-away
TEST_OUTPUT_DIRECTORY. Each of
With the new --valgrind-only= option, one can enable
--valgrind at a per-test granularity, exactly analogous to
--verbose-only from the previous commit.
The options are wired such that --valgrind implies --verbose (as
before), but --valgrind-only= implies
--verbose-only= unless --verbose is also i
1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the
MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit
their effect to only the test runs. However, they were actually
enabled only during test cleanup. Call setup/teardown_malloc_check
also around the evaluation of
This is not really meant for external use, and thus not documented. It
allows the next commit to neatly distinguish between sub-tests and the
main run.
The format is intentionally not valid TAP. The use in the next commit
would not result in anything valid either way, and it seems better to
make
From: Namhyung Kim
In its current form, when an user wants to filter specific ref using
--refs option, she needs to give something like --refs=refs/tags/v1.*.
It'd be convenient providing a way to specify a subpath of ref pattern.
For example, --refs=origin/* can find refs/remotes/origin/master
On Tue, Jun 18, 2013 at 01:48:00PM +0200, SZEDER Gábor wrote:
> On Tue, Jun 18, 2013 at 02:42:07PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 18, 2013 at 01:09:04PM +0200, SZEDER Gábor wrote:
> > > Hi,
> > >
> > > 'git send-email' recently started to add redundant From: lines to my
> > > mes
Ramkumar Ramachandra:
+ on_what = _("rebase in progress; onto ");
Could you please add a
/* TRANSLATORS: Followed by branch name. */
or something similar here (and possibly to the other "on_what"s in the
function)?
Ideally, the "%s" for the branch name shou
Verify that author name is not duplicated if it matches
sender, even if it is in utf8.
Signed-off-by: Michael S. Tsirkin
---
t/t9001-send-email.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 9f46f22..cef884f 100755
--- a/
On Tue, Jun 18, 2013 at 01:48:00PM +0200, SZEDER Gábor wrote:
> On Tue, Jun 18, 2013 at 02:42:07PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 18, 2013 at 01:09:04PM +0200, SZEDER Gábor wrote:
> > > Hi,
> > >
> > > 'git send-email' recently started to add redundant From: lines to my
> > > mes
sender is now sanitized, but we didn't sanitize
author when checking whether From: line is needed
in the message body.
As a result git started writing duplicate From lines
when author matched sender and has utf8 characters.
Reported-by: SZEDER Gábor
Signed-off-by: Michael S. Tsirkin
---
git-sen
Recently I had to write some automation scripts and I found
that git reset --hard actually restores each file's permissions.
That is causing both the created and the last-modified dates
of the file to get changed to the time of the git reset.
This behavior is easy to demonstrate:
echo "test" > m
Alexander Nestorov writes:
> echo "test" > myfile
> chmod 777 myfile
> git add myfile && git commit -m "Test" && git push
> chmod 775 myfile
> git reset --hard origin/master
This doesn't tell what the permissions are in origin/master.
If the last line was "git reset --hard HEAD", then it wouldn
bca...@nvidia.com wrote on Mon, 17 Jun 2013 18:40 -0700:
> From: Brandon Casey
>
> Prior to commit fa83a33b, the 'git checkout' DWIMery would create a
> new local branch if the specified branch name did not exist and it
> matched exactly one ref in the "remotes" namespace. It searched
> the "rem
Git does preserve file permissions, that is, git is aware of the
permissions you can set with chmod.
I'm not trying to ignore the x bit, what I'm trying to do is make
"git reset" checkout only the files that actually changed instead
of checking out all the files with different permissions than the
Thanks!
By the way, where can I find this kind of specification? I couldn't
find the spec of tree objects here:
https://github.com/git/git/tree/master/Documentation
--
Chico Sokol
On Wed, Jun 12, 2013 at 11:06 AM, Jakub Narebski wrote:
> Junio C Hamano pobox.com> writes:
>> Chico Sokol gmai
Hi Michael,
thanks for the quick turnaround.
On Tue, Jun 18, 2013 at 03:49:29PM +0300, Michael S. Tsirkin wrote:
> Verify that author name is not duplicated if it matches
> sender, even if it is in utf8.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> t/t9001-send-email.sh | 13 +
>
On Tue, Jun 18, 2013 at 03:25:22PM +0200, Alexander Nestorov wrote:
> Recently I had to write some automation scripts and I found
> that git reset --hard actually restores each file's permissions.
>
> That is causing both the created and the last-modified dates
> of the file to get changed to the
Alexander Nestorov writes:
> I'm not trying to ignore the x bit, what I'm trying to do is make
> "git reset" checkout only the files that actually changed instead
> of checking out all the files with different permissions than the
> ones git thinks they should have.
Ah, OK, you want "git reset -
Git reset --keep is not an option as it will abort the operation if
there are local changes,
which is exactly what I want to do: replace files with local changes
but leave file
permissions as they are.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
Indeed, "git update-index --refresh" before "git reset" did the trick :)
Anyways, what about the proposal? Should it be implemented?
Thank you
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger
Ramkumar Ramachandra writes:
> Phil Hord wrote:
>> I share your disdain for the bare '40's in the code. But I think this
>> code is less clear than the previous version with the magic number.
>
> Please read the cover-letter:
Which was...
>> [1/2] is important. [2/2] is a minor prettificatio
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> Will replace what has been queued on 'pu'.
>>
>> ... after fixing an indentation error, that is.
>
> Where did the error occur?
I think you can compare what is in 'pu' and what you sent out
without asking.
--
To unsubscribe from this list
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> + test $# == 1 ||
>>
>> This is broken under POSIX shells. No need to resend (will locally
>> patch up).
>
> Ugh, my C habit. Thanks for catching it.
You're welcome---that is what the reviews are for.
--
To unsubscribe from this list
[ The rule here is to keep everyone Cced, not just git@vger ]
Alexander Nestorov writes:
> Indeed, "git update-index --refresh" before "git reset" did the trick :)
> Anyways, what about the proposal? Should it be implemented?
I'd say the current behavior is OK by default (it's not so common to
Matthieu Moy writes:
> Junio C Hamano writes:
>
>
>> After I re-read the one, I found that "override" somewhat a strange
>> expression. There is nothing that overrides or to be overriden.
>
> Right, I actually meant "overwrite".
>
>> How about putting it like this?
>
> I'm not sure "push out re
Dennis Kaarsemaker writes:
> On ma, 2013-06-17 at 13:09 -0700, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> > Dennis Kaarsemaker writes:
>> >
>> >> I'm doing daily builds of git, using many workers and a shared git.git,
>> >> with per-worker checkouts
>> >
>> > OK, so GIT_DIR is exp
Sorry for not keeping everyone Cced, I wasn't aware of the rules.
Yes, writing about that in the docs seems more reasonable than patching reset,
as as you said, that'd just run update-index before the reset.
Let me get at home and I'll try to push a change :)
Regards
--
To unsubscribe from this l
Junio C Hamano wrote:
>> Where did the error occur?
>
> I think you can compare what is in 'pu' and what you sent out
> without asking.
Ah, I sent out the series before I taught Emacs to indent properly.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> Matthieu Moy wrote:
>>> Weaken the warning by discouraging only merge with /non-trivial/
>>> uncommited changes.
>>>
>>> I don't think documenting all the failure cases in the doc would be a
>>> good idea, so I've left the "in some cases"
jorge-juan.garcia-gar...@ensimag.imag.fr writes:
> From: Jorge Juan Garcia Garcia
>
> Make it so that we can use a list of email in flags
> instead of having to use one flag per email address.
>
> The format of email list handled is pretty basic for now:
> $ git send-email --to='Foo , b...@
Ramkumar Ramachandra writes:
> Several callers set GIT_REFLOG_ACTION via set_reflog_action(), but
> nobody unsets it, leaving a potentially stray variable in the
> environment. Fix this by making die_with_status() unset it.
I am totally lost.
- You can set your own environment variables, and
Junio C Hamano writes:
> Doesn't
>
> git send-email --to='Foo ' --to='b...@example.com'
>
> work? If it does, I do not see much point of this change. If you
> are starting from two pieces of information, why combine it into
> one, only have the program to split it again, risking to be bit
The section describing "git diff " had been placed in a
position that disrupted the statement "This is synonymous to the
previous form".
Reorder to place this form after all the -using forms, and the
note applying to them. Also mention this form in the initial description
paragraph.
Signed-off-b
What is the encoding of the filename?
--
Chico Sokol
On Tue, Jun 11, 2013 at 3:26 PM, Ilari Liusvaara
wrote:
> On Tue, Jun 11, 2013 at 01:25:14PM -0300, Chico Sokol wrote:
>> Is there any official documentation of tree objets format? Are tree
>> objects encoded specially in some way? How can I
Namhyung Kim writes:
> From: Namhyung Kim
>
> In its current form, when an user wants to filter specific ref using
> --refs option, she needs to give something like --refs=refs/tags/v1.*.
Will queue. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
Daniel Stenberg writes:
> On Tue, 18 Jun 2013, Jeff King wrote:
>
> TL;DR: I'm just confirming what's said here! =)
Thanks. We are very fortunate to have you as the cURL guru who
gives prompt responses and sanity checks to us.
--
To unsubscribe from this list: send the line "unsubscribe git" in
Johannes Sixt writes:
> From: Johannes Sixt
>
> The recently introduced tests used uppercase letters to denote
> cherry-picks of commits having the corresponding lowercase letter names.
> The helper functions also set up tags with the names of the commits.
>
> But this constellation fails on cas
Hi!
I have a question about gitignore.
There is a git extension called git ftp, written by René:
https://github.com/resmo in bash. This extension uses git to push only
the changed files to the ftp server. Currently this extension uses
grep to decide which file is ignored by upload. It uses a conf
Junio C Hamano wrote:
> - There is no mechanism for you to affect environment of your
>parent process.
Please excuse my stupidity and drop this patch. I got mislead by your
SQUASH??? patch which took care to set the environment variable and
call checkout in a subshell.
--
To unsubscribe from
I'm home,
https://github.com/alexandernst/git/commit/61f0a7d558e3cbae308fabdff66bd87569d6aa18
Is that good? Should I PR?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt wrote:
>
> The recently introduced tests used uppercase letters to denote
> cherry-picks of commits having the corresponding lowercase letter names.
> The helper functions also set up tags with the names of the commits.
>
> But this constellation fai
Alexander Nestorov writes:
> I'm home,
> https://github.com/alexandernst/git/commit/61f0a7d558e3cbae308fabdff66bd87569d6aa18
> Is that good?
Please, post your patches inline, it eases review. More generally, read
Documentation/SubmittingPatches.
+Ignore file permissions::
It's not only about
Documentation and some comments still refer to files in builtin/
as 'builtin-*.[cho]'. Update these to show the correct location.
Signed-off-by: Phil Hord
---
Documentation/git-log.txt | 4 ++--
Documentation/technical/api-builtin.txt | 2 +-
Documentation/technical/
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
>> index a58406d..c175ef1 100755
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -934,6 +934,21 @@ test_expect_success 'rebase --e
1 - 100 of 194 matches
Mail list logo
