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 top of the work tree, before:
$ time for i in {0..9} ; do
On Mon, Jun 17, 2013 at 06:40:49PM -0700, Brandon Casey wrote:
From: Brandon Casey draf...@gmail.com
remote_find_tracking() populates the query struct with an allocated
string in the dst member. So, we do not need to xstrdup() the string,
since we can transfer ownership from the query
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 to pass a command-line option like --word-diff=color to
git-add--interactive.perl, so a configuration option is the
On Tue, 18 Jun 2013, Jeff King wrote:
TL;DR: I'm just confirming what's said here! =)
My understanding of curl's pointer requirements are:
1. Older versions of curl (and I do not recall which version off-hand,
but it is not important) stored just the pointer. Calling code was
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
+}
Watch this
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
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
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, not
On ma, 2013-06-17 at 13:09 -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Dennis Kaarsemaker den...@kaarsemaker.net 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
[I don't seem to have received a copy of the original mail, so I can
only guess...]
Jeff King p...@peff.net 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
From: Johannes Sixt j...@kdbg.org
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
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 gits...@pobox.com 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
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 worse
Johannes Sixt j.s...@viscovery.net 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
+done
+
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 p...@peff.net 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
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 Jonathan
Ramkumar Ramachandra artag...@gmail.com 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
On 17 June 2013 09:12, Matthieu Moy matthieu@grenoble-inp.fr 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
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 top of the
From: Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
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 f...@example.com,
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
From: SZEDER Gábor sze...@ira.uka.de
---
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.
Benoît Person benoit.per...@ensimag.fr 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
Le 2013-06-17 20:37, Junio C Hamano a écrit :
Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
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
jorge-juan.garcia-gar...@ensimag.imag.fr wrote:
The format of email list handled is pretty basic for now:
$ git send-email --to='Foo f...@example.com, b...@example.com'
We thought it would be nice to have a first-step version which works
before handling more complex ones such as:
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 f...@example.com,
b...@example.com'
We thought it would be nice to have a first-step version which
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 and
+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' '
grep
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 benoit.per...@ensimag.fr writes:
On 17 June 2013 09:12, Matthieu Moy matthieu@grenoble-inp.fr 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
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 tests?
--
Ramkumar Ramachandra artag...@gmail.com 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
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 m...@redhat.com
Date: 2013-06-05 21:11:00
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 public
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.
Hi Junio,
2013-06-18 AM 12:27, Junio C Hamano wrote:
Namhyung Kim namhyung@lge.com 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
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
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:
$
$ 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 documenting
From: Junio C Hamano gits...@pobox.com
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
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 of the
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
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
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): checkout
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 artag...@gmail.com
---
git-sh-setup.sh | 1 +
1 file changed, 1
2013-06-18 AM 12:53, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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,
It's already used twice, and we will have more of the same kind of
matching in a minute.
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
t/test-lib.sh | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff
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 tr...@inf.ethz.ch
---
t/test-lib-functions.sh | 6 --
t/test-lib.sh
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
With the new --verbose-only=pattern 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
With the new --valgrind-parallel=n 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
With the new --valgrind-only=pattern 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=pattern implies
--verbose-only=pattern
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
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 namhyung@lge.com
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
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
messages, see
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_whats in the
function)?
Ideally, the %s for the branch name should be
Verify that author name is not duplicated if it matches
sender, even if it is in utf8.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
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
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
messages, see
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 sze...@ira.uka.de
Signed-off-by: Michael S.
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
Alexander Nestorov alexander...@gmail.com 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
bca...@nvidia.com wrote on Mon, 17 Jun 2013 18:40 -0700:
From: Brandon Casey draf...@gmail.com
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
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 jna...@gmail.com wrote:
Junio C Hamano gitster at pobox.com
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 m...@redhat.com
---
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 time
Alexander Nestorov alexander...@gmail.com 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
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
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
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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?
Dennis Kaarsemaker den...@kaarsemaker.net writes:
On ma, 2013-06-17 at 13:09 -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Dennis Kaarsemaker den...@kaarsemaker.net writes:
I'm doing daily builds of git, using many workers and a shared git.git,
with
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
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 message
Matthieu Moy matthieu@grenoble-inp.fr writes:
Ramkumar Ramachandra artag...@gmail.com 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
jorge-juan.garcia-gar...@ensimag.imag.fr writes:
From: Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
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:
Ramkumar Ramachandra artag...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Doesn't
git send-email --to='Foo f...@example.com' --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
The section describing git diff blob blob 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 commit-using forms, and the
note applying to them. Also mention this form in the initial description
paragraph.
What is the encoding of the filename?
--
Chico Sokol
On Tue, Jun 11, 2013 at 3:26 PM, Ilari Liusvaara
ilari.liusva...@elisanet.fi 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
Daniel Stenberg dan...@haxx.se 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
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
On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt j.s...@viscovery.net 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
Alexander Nestorov alexander...@gmail.com 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::
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 ho...@cisco.com
---
Documentation/git-log.txt | 4 ++--
Documentation/technical/api-builtin.txt | 2 +-
Ramkumar Ramachandra artag...@gmail.com 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
Pete Wyckoff p...@padd.com writes:
Thanks for finding and fixing this. Great explanation. I
tested it locally too.
Acked-by: Pete Wyckoff p...@padd.com
Thanks, both. Queued.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
1 - 100 of 179 matches
Mail list logo
