Felipe Contreras writes:
> Junio C Hamano wrote:
>
>> * The remote-helper interface to fast-import/fast-export via the
>>transport-helper has been tightened to avoid leaving the import
>>marks file from a failed/crashed run, as such a file that is out-of-
>>sync with reality confuses
Good day.
I am Elizabeth Sakura, a staff of Lloyds TSB Group Plc.here in Hong
Kong. I will need you to assist me in executing a business project
from Hong Kong to your country.Contact me Email address(
tseselizabeth...@yahoo.com ) for more information.Regards,Mrs.Sukura
Elizabeth tse
--
To unsub
On Tue, May 20, 2014 at 10:10:46AM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> > AFAIU, Junio already applied my patches (existance of a branch
> > as/pretty-truncate tells us that). So, we can only send other patches that
> > fix errors brought with former patches.
>
> No, NO, NOO
Added option that allows a signature file to be used with format-patch
so that signatures with newlines and other special characters can be
easily included.
$ git format-patch --signature-file ~/.signature -1
The config variable format.signaturefile is also provided so that it
can be added by d
v6 of patch to add format-patch --signature-file option.
This revision includes more suggestions from Jeff King and Junio C Hamano:
- Adding #define DEFAULT_SIGNATURE was a good idea but it could be
used in a way that nullifies the pointer comparison used to see if
the default has chan
Ronnie Sahlberg wrote:
> No external callers reference lock_ref_sha1 any more so lets declare it
> static.
>
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 2 +-
> refs.h | 3 ---
> 2 files changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this lis
Ronnie Sahlberg wrote:
> No external users call write_ref_sha1 any more so lets declare it static.
Yay!
[...]
> +++ b/refs.c
> @@ -251,6 +251,8 @@ struct ref_entry {
[...]
> static void read_loose_refs(const char *dirname, struct ref_dir *dir);
> +static int write_ref_sha1(struct ref_lock *lock
Junio C Hamano wrote:
> * The remote-helper interface to fast-import/fast-export via the
>transport-helper has been tightened to avoid leaving the import
>marks file from a failed/crashed run, as such a file that is out-of-
>sync with reality confuses a later invocation of itself.
Re
Ronnie Sahlberg wrote:
> This changes the locking slightly for walker_fetch. Previously the code would
> lock all refs before writing them but now we do not lock the refs until the
> commit stage. There is thus a very short window where changes could be done
> locally during the fetch which would
On Tue, May 20, 2014 at 08:06:50AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > You could do:
> >
> > #define DEFAULT_SIGNATURE git_version_string
> > static const char *signature = DEFAULT_SIGNATURE;
> >
> > ...
> >
> > if (signature == DEFAULT_SIGNATURE)
> > ...
> >
> > b
On Tue, May 20, 2014 at 04:27:40AM -0400, Jeff King wrote:
> On Tue, May 20, 2014 at 01:00:06AM -0700, Jeremiah Mahler wrote:
>
...
> > +test_expect_success 'format-patch --signature-file=file' '
> > + git format-patch --stdout --signature-file=expect -1 >output &&
> > + check_patch output &&
A release candidate Git v2.0.0-rc4, hopefully the final one before
the real thing, is now available for testing at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc4'
tag and t
Surely. I am on a bus with terrible WiFi that does not let me use the
usual terminal,
but you would find a code in revision.c that sets revs->topo_order = 1
when it parses
"--graph" option. If you disable it, that would stop "--graph" from
wanting to compute
the whole history before starting to emi
On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano wrote:
> Mitchel Humpherys writes:
>
>> I've noticed that --max-count doesn't seem to speed up `git log --graph'
>> computation time.
>
> AFAIK, --graph wants to compute the whole history and the max-count
> only affects the output phase after --
On 20/05/14 23:44, Jonathan Nieder wrote:
> Hi,
>
> Ramsay Jones wrote:
>> On 20/05/14 22:40, Jonathan Nieder wrote:
>
>>> What should happen if I have set GIT_SKIP_TESTS explicitly to run
>>> only some of the tests in t-basic?
>>
>> A quick test (with the above patch applied) shows that
>> i
When an explicit '--git-dir' option points to a directory inside
the work tree, git treats it as if it were any other directory.
In particular, 'git status' lists it as untracked, while 'git add -A'
stages the metadata directory entirely
Add GIT_DIR to the list of excludes in setup_standard_exclud
On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> I'm not sure what would be the usefulness of using things like
>> 'xx/topic~4'.
>
> As a notation it is not very pretty ;-).
>
> Imagine that xx/topic is about a multistep introduction of a
> backward incompati
Mitchel Humpherys writes:
> I've noticed that --max-count doesn't seem to speed up `git log --graph'
> computation time.
AFAIK, --graph wants to compute the whole history and the max-count
only affects the output phase after --graph does its computation.
Besides, "log --max-count=n" and "log HE
Felipe Contreras writes:
> I'm not sure what would be the usefulness of using things like
> 'xx/topic~4'.
As a notation it is not very pretty ;-).
Imagine that xx/topic is about a multistep introduction of a
backward incompatible feature. The beginning part of the series up
to xx/topic~4 are t
Hi,
Ramsay Jones wrote:
> On 20/05/14 22:40, Jonathan Nieder wrote:
>> What should happen if I have set GIT_SKIP_TESTS explicitly to run
>> only some of the tests in t-basic?
>
> A quick test (with the above patch applied) shows that
> it works as I would expect:
>
> $ GIT_SKIP_TESTS=t
On 20/05/14 22:40, Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/t/t-basic.sh
>> +++ b/t/t-basic.sh
>> @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' '
>> '
>>
>> test_expect_success 'GIT_SKIP_TESTS' "
>> -GIT_SKIP_TESTS='git.2' \
>> -run_sub_te
I've noticed that --max-count doesn't seem to speed up `git log --graph'
computation time. Here are some numbers using the linux kernel
repository:
| command | time* |
|--+---|
| git log --graph --max-count=5000 | 4.11s |
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Or have an option to specify a dynamic instruction sheet, so you can cat
> > the instructions of 'match-next' and replace the base. However, I don't
> > see the point of re-applying the branches for 'next' if you already know
> > that 'next'
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>> ...
>> > So to make it clear, I now request that you do:
>> >
>> > 1) Remove all the code.
>> ...
>> I'll do that, but just one thing to make sure---do you want the
>> helper to exit with status 0?
>
> It doesn't ma
Johan Herland wrote:
> On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty
> wrote:
> > On 05/19/2014 11:31 PM, Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >>> Where is git-imerge packaged?
> >>
> >> I didn't see it on the archive the said Ubuntu box slurps from, but
> >> I did not check
Ramsay Jones wrote:
> --- a/t/t-basic.sh
> +++ b/t/t-basic.sh
> @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' '
> '
>
> test_expect_success 'GIT_SKIP_TESTS' "
> - GIT_SKIP_TESTS='git.2' \
> - run_sub_test_lib_test git-skip-tests-basic \
> + GIT_SKIP_
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> >> Let's try this in a different way, as I sense there is a
> >> misunderstanding somewhere about your "wish".
> >> ...
> > No, I already said I do not want the code removed from v2.0, that's why
> > I sent patches that simply added a warning,
Ramsay Jones writes:
> This patch is an RFC, because I take a different approach to the
> above solution, only because the diff is much smaller and easier
> to read! Is it a better solution?
>
> ATB,
> Ramsay Jones
>
> t/t-basic.sh | 15 +--
> 1 file changed, 9 insertions(+), 6 d
Felipe Contreras writes:
> Or have an option to specify a dynamic instruction sheet, so you can cat
> the instructions of 'match-next' and replace the base. However, I don't
> see the point of re-applying the branches for 'next' if you already know
> that 'next' and 'match-next' are the same.
Th
Signed-off-by: Ramsay Jones
---
The test suite has been failing for me on the pu branch for
a while now. I finally found a few minutes to take a look.
This failure is specific to the dash shell (/bin/sh) on my
system (ie it may well affect other shells, but I haven't
tested them all ... :). Thi
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > ...
> > Which will generate the integration instructions for you:
> >
> > % git reintegrate --cat
> > base master
> > merge jl/submodule-mv
> >
> > Moving a regular file in a repository with a .gitmodules file was
> > producing
Felipe Contreras writes:
>> Let's try this in a different way, as I sense there is a
>> misunderstanding somewhere about your "wish".
>> ...
> No, I already said I do not want the code removed from v2.0, that's why
> I sent patches that simply added a warning, and I specifically said
> those were
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >>
> >> After looking at the reverse-depends list of packages, my faith is
> >> strengthened in that the Git ecosystem is truly maturing and useful
> >> third-party plug-ins will be picked up by distro packagers.
> >
On Tue, May 20, 2014 at 1:38 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> [Subject: fast-import.c: use a ref transaction when dumping tags]
>
> This seems like an odd thing to do: either it would make sense to have
> a single transaction for all imported refs so all fail or succeed
> t
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> 2. add warning that is given every time the scripts are run and
> >> give the same instruction as in README.
> >>
> >> 3. (optional) cripple the script to make them always fail after
> >> showing
Ronnie Sahlberg wrote:
> [Subject: fast-import.c: use a ref transaction when dumping tags]
This seems like an odd thing to do: either it would make sense to have
a single transaction for all imported refs so all fail or succeed
together, or there would be separate transactions for each ref.
That
On Tue, May 20, 2014 at 12:42 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Wrap all the ref updates inside a transaction to make the update atomic.
>
> Interesting.
>
> [...]
>> --- a/builtin/receive-pack.c
>> +++ b/builtin/receive-pack.c
>> @@ -46,6 +46,8 @@ static void *head_name_to_
Junio C Hamano writes:
> A bit safer way to organize might be to first create a list of the
> refs to be removed in-core, update packed-refs without these refs to
> be removed, and then finally remove the loose ones, but I haven't
> thought things through.
Perhaps a removal of remote can go in t
Ronnie Sahlberg wrote:
> Wrap all the ref updates inside a transaction to make the update atomic.
Interesting.
[...]
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -46,6 +46,8 @@ static void *head_name_to_free;
> static int sent_capabilities;
> static int shallow_update;
>
Stepan Kasal writes:
> Hello,
>
> On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote:
>> It would be nice if somebody in the S-o-b chain can double-check
>> that the "combined" version is sane. [...]
>
> "Combined" was an unfortunate word. There was a pair of successive
> commits in
Jens Lindström writes:
> When 'git remote rm' or 'git remote prune' were used in a repository
> with many refs, and needed to delete many refs, a lot of time was spent
> deleting those refs since for each deleted ref, repack_without_refs()
> was called to rewrite packed-refs without just that del
Hello,
On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote:
> It would be nice if somebody in the S-o-b chain can double-check
> that the "combined" version is sane. [...]
"Combined" was an unfortunate word. There was a pair of successive
commits in msysgit all the time. I just deci
Add trace_performance and trace_performance_since macros that print file
name, line number, time and an optional printf-formatted text to the file
specified in environment variable GIT_TRACE_PERFORMANCE.
Unless enabled via GIT_TRACE_PERFORMANCE, these macros have no noticeable
impact on performanc
Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
unsigned 64-bit integer (i.e. overflows in july 2554). This is easier to
work with than e.g. struct timeval or struct timespec.
The implementation uses gettimeofday() by default; supports high precision
time sources on the f
Add performance tracing to identify which git commands are called and how
long they execute. This is particularly useful to debug performance issues
of scripted commands.
Usage example: > GIT_TRACE_PERFORMANCE=~/git-trace.log git stash list
Creates a log file like this:
performance: at trace.c:31
This is the POSIX port of the patches I typically use to track down msysgit
performance issues (thus v4, the latest windows-only version is here [1]).
Sebastian and Dscho thought this might be useful in core git, so here it is.
[1] https://github.com/msysgit/git/pull/46
Karsten Blees (3):
add h
On Tue, 20 May 2014 18:18:08 +
"Stewart, Louis (IS)" wrote:
> From you response then there is a method to only obtain the Project,
> Directory and Files (which could hold 80 GBs of data) and not the
> rest of the Repository that contained the full overall Projects?
Please google the phrase "
Stepan Kasal writes:
> From: Cezary Zawadka
> Date: Tue, 13 Jul 2010 16:17:43 +0200
>
> [efl: moved MinGW-specific part to compat/]
> [jes: fixed compilation on non-Windows]
>
> Eric Sunshine fixed mingw_offset_1st_component() to return consistently "foo"
> for UNC "//machine/share/foo", cf
> ht
Junio C Hamano writes:
> As I already said, I think "better known" is much less of an issue
> than that "-a/-o" is "more error prone", and that is the reason why
> we may want to do this rewrite.
>
> I do not know offhand how busy the tree would be when we can apply
> these patches post-release w
Jeff King writes:
> If it were just "--signature", I'd agree. After all, nobody is even
> complaining. But this is also in preparation for --signature-file.
> Should the user create a file without a trailing newline?
Ahh, I missed that part.
I am fine with processing it with stripspace().
By t
On 5/20/2014 12:40 PM, Arup Rakshit wrote:
On Tuesday, May 20, 2014 11:24:11 AM you wrote:
Arup Rakshit writes:
Untracked files and modifications to files in your working directory
do not belong to your current branch. This is to allow you, after
starting to work on one branch then realizing
On Tuesday, May 20, 2014 11:24:11 AM you wrote:
> Arup Rakshit writes:
>
> Untracked files and modifications to files in your working directory
> do not belong to your current branch. This is to allow you, after
> starting to work on one branch then realizing that the changes and
> additions you
Richard Hansen writes:
> Not all shells subject the prompt string to parameter expansion. Test
> whether the shell will expand the value of PS1, and use the result to
> control whether raw ref names are included directly in PS1.
>
> This fixes a regression introduced in commit 8976500 ("git-prom
Matthieu Moy writes:
> Signed-off-by: Matthieu Moy
> ---
> Eric Sunshine writes:
>
>> Simpler (replace above two lines):
>>
>> test_set_editor "$(pwd)/abort-editor.sh" &&
>
> Indeed.
>
> And I had debug statements left.
>
> Hopefully, this after-coffee-v2 will be clear enough and correct ;-
On 5/20/2014 12:20 PM, Arup Rakshit wrote:
On Tuesday, May 20, 2014 12:06:49 PM you wrote:
It never "came to the new branch", as it was never version controlled,
it was an untracked file left behind when you switched branches.
Once you added it to the new branch, change_class, it became a ver
Am Dienstag, den 20.05.2014, 17:24 + schrieb Stewart, Louis (IS):
> Thanks for the reply. I just read the intro to GIT and I am concerned
> about the part that it will copy the whole repository to the developers
> work area. They really just need the one directory and files under
> that one d
On Tue, May 20, 2014 at 10:53:11AM -0700, Junio C Hamano wrote:
> I actually think these "supress extra LFs" trying to be overly smart
> and inviting unnecessary surprises. Unlike log messages people type
> (in which we do squash runs of blank lines and other prettifying),
> mail-signature string
Arup Rakshit writes:
> On Tuesday, May 20, 2014 12:06:49 PM you wrote:
>
>>
>> It never "came to the new branch", as it was never version controlled,
>> it was an untracked file left behind when you switched branches.
>>
>> Once you added it to the new branch, change_class, it became a version
Hi,
Elia Pinto wrote:
> These patch series convert test -a/-o to && and ||.
Should this come with a new check in t/check-non-portable-shell.pl so
we don't regress in the future?
> Elia Pinto (19):
[...]
> check_bindir|2 +-
> contrib/examples/git-clone.sh |2 +-
>
On Tuesday, May 20, 2014 12:06:49 PM you wrote:
>
> It never "came to the new branch", as it was never version controlled,
> it was an untracked file left behind when you switched branches.
>
> Once you added it to the new branch, change_class, it became a version
> controlled file,
This is st
>From you response then there is a method to only obtain the Project, Directory
>and Files (which could hold 80 GBs of data) and not the rest of the Repository
>that contained the full overall Projects?
-Original Message-
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Tuesday, Ma
"Stewart, Louis (IS)" writes:
> Thanks for the reply. I just read the intro to GIT and I am
> concerned about the part that it will copy the whole repository to
> the developers work area. They really just need the one directory
> and files under that one directory. The history has TBs of data.
Elia Pinto writes:
> The interaction with unary operators and operator precedence
> for && and || are better known than -a and -o, and for that
> reason we prefer them. Replace all existing instances
> of -a and -o to save readers from the burden of thinking
> about such things.
>
> Signed-off-by
Elia Pinto writes:
> These patch series convert test -a/-o to && and ||.
>
> This is the second version.
Perhaps slightly off-topic, but has the remainder of the previous $(...)
series been perfected and ready to apply?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
Jeff King writes:
> But one could easily specify a longer, multi-line signature,
> like:
>
> git format-patch --signature='
> this is my long signature
>
> it has multiple lines
> ' ...
>
> We should notice that it already has its own trailing
> newline, and suppress one of ours.
>
> Sign
Jeff King writes:
> On Mon, May 19, 2014 at 10:35:56PM +0300, Michael S. Tsirkin wrote:
>
>> I tried to fump the whole history of qemu with format-patch.
>> It crashes both with v2.0.0-rc2-21-g6087111
>> and with git 1.8.3.1:
>>
>> ~/opt/libexec/git-core/git-format-patch --follow -o patches/all
Matthieu Moy writes:
> [ Cc-ing Ramkumar ]
>
> Karen Etheridge writes:
>
>> scenario:
>> - edit some tracked files; do not add them to the index
>> - "git config rebase.autostash true"
>> - "git rebase -i HEAD~3" (an autostash will be created)
>> - delete the entire buffer and save/exit the edi
Anders Kaseorg writes:
>> How bad does the documentation look with the patch applied (I know how
>> bad it looks without source-highlight installed)? If it is not too bad,
>> then it sounds like a sensible solution to drop the highlight markup
>> unconditionally like the patch that started th
Thanks for the reply. I just read the intro to GIT and I am concerned about
the part that it will copy the whole repository to the developers work area.
They really just need the one directory and files under that one directory. The
history has TBs of data.
Lou
-Original Message-
Fro
"Stewart, Louis (IS)" writes:
> Can GIT handle versioning of large 20+ GB files in a directory?
I think you can "git add" such files, push/fetch histories that
contains such files over the wire, and "git checkout" such files,
but naturally reading, processing and writing 20+GB would take some
ti
Alexey Shumkin writes:
> AFAIU, Junio already applied my patches (existance of a branch
> as/pretty-truncate tells us that). So, we can only send other patches that
> fix errors brought with former patches.
No, NO, NO
The existence of a branch merely means that I saw the patches, and
th
On 5/20/2014 10:37 AM, Stewart, Louis (IS) wrote:
Can GIT handle versioning of large 20+ GB files in a directory?
Maybe you're looking for git-annex?
https://git-annex.branchable.com/
--
.marius
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
On 5/20/2014 11:03 AM, Arup Rakshit wrote:
On Tuesday, May 20, 2014 11:56:57 AM you wrote:
On 5/20/2014 10:38 AM, Arup Rakshit wrote:
I was following some tutorial (http://gitref.org/branching/#merge) - and
doing it in my console :
Because you never committed the original file to the master
> -Original Message-
> From: Stewart, Louis (IS)
> Sent: Tuesday, May 20, 2014 11:38
>
> Can GIT handle versioning of large 20+ GB files in a directory?
Are you asking 20 files of a GB each or files 20GB each?
A what and why may help with the underlying questions.
v/r,
Jason Pyeron
--
On Tuesday, May 20, 2014 11:56:57 AM you wrote:
> On 5/20/2014 10:38 AM, Arup Rakshit wrote:
> > I was following some tutorial (http://gitref.org/branching/#merge) - and
> > doing it in my console :
>
> Because you never committed the original file to the master branch
> before you created and sw
On 5/20/2014 10:38 AM, Arup Rakshit wrote:
I was following some tutorial (http://gitref.org/branching/#merge) - and doing
it in my console :
Arup-iMac:arup_git shreyas$ git status
# On branch master
nothing to commit, working directory clean
Arup-iMac:arup_git shreyas$ touch test.rb
Arup-iMac:ar
The files in question would be in directory containing many files some small
other huge (example: text files, docs,and jpgs are Mbs, but executables and ova
images are GBs, etc).
Lou
From: Gary Fixler [mailto:gfix...@gmail.com]
Sent: Tuesday, May 20, 2014 12:09 PM
To: Stewart, Louis (IS)
Cc: g
On 20/05/14 17:02, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote:
>> On 20/05/14 15:19, Alexey Shumkin wrote:
>>> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Alexey,
If yo
I was following some tutorial (http://gitref.org/branching/#merge) - and doing
it in my console :
Arup-iMac:arup_git shreyas$ git status
# On branch master
nothing to commit, working directory clean
Arup-iMac:arup_git shreyas$ touch test.rb
Arup-iMac:arup_git shreyas$ ls
git_1.txttest.rb
Arup-iMa
On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote:
> On 20/05/14 15:19, Alexey Shumkin wrote:
> > On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
> >>
> >> Signed-off-by: Ramsay Jones
> >> ---
> >>
> >> Hi Alexey,
> >>
> >> If you need to re-roll your 'as/pretty-truncate'
Can GIT handle versioning of large 20+ GB files in a directory?
Lou Stewart
AOCWS Software Configuration Management
757-269-2388
--
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/m
On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty wrote:
> On 05/19/2014 11:31 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>> Where is git-imerge packaged?
>>
>> I didn't see it on the archive the said Ubuntu box slurps from, but
>> I did not check all the other distros.
>>
>> Michael,
"Michael S. Tsirkin" writes:
> Just to clarify I can post v2 of 4/4 without reposting 1-3 since they
> are queued?
If you need to update anything queued only on 'pu' but not yet in
'next', it is customary to resend the whole for everybody to see
(what is already in 'next' should only be built up
Jeff King writes:
> You could do:
>
> #define DEFAULT_SIGNATURE git_version_string
> static const char *signature = DEFAULT_SIGNATURE;
>
> ...
>
> if (signature == DEFAULT_SIGNATURE)
> ...
>
> but maybe that is getting a little unwieldy, considering the scope of
> the original proble
On 20/05/14 15:48, Alexey Shumkin wrote:
> Added in 0a144b3 (t4205, t6006: add failing tests for the case when
> i18n.logOutputEncoding is set, 2014-05-19) tests give no error
> (somehow) with Bash as /bin/sh but fail for some other shells.
>
> Quote format strings to avoid errors.
>
> Signed-off
On 20/05/14 15:19, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
>>
>> Signed-off-by: Ramsay Jones
>> ---
>>
>> Hi Alexey,
>>
>> If you need to re-roll your 'as/pretty-truncate' branch, could
>> you please squash the relevant parts of this patch into the
>>
On 05/19/2014 11:31 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Junio C Hamano wrote:
>>>
>>> After looking at the reverse-depends list of packages, my faith is
>>> strengthened in that the Git ecosystem is truly maturing and useful
>>> third-party plug-ins will be picked up by dist
Added in 0a144b3 (t4205, t6006: add failing tests for the case when
i18n.logOutputEncoding is set, 2014-05-19) tests give no error
(somehow) with Bash as /bin/sh but fail for some other shells.
Quote format strings to avoid errors.
Signed-off-by: Alexey Shumkin
Suggested-by: Ramsay Jones
---
t
On Mon, May 19, 2014 at 02:34:26PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > test ack! handling
> >
> > Signed-off-by: Michael S. Tsirkin
>
> Will queue with this squashed in.
>
> 4/4 seems to have some style issues as well, but I didn't look very
> closely.
>
> Thanks
Am 5/20/2014 15:50, schrieb Elia Pinto:
> # If we don't already have a -f flag and the submodule
> has never been checked out
> - if test -z "$subsha1" -a -z "$force"
> + if test -z "$subsha1" || test -z "$force"
Should not be ||, but
On Tue, May 20, 2014 at 06:19:36PM +0400, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
> >
> > Signed-off-by: Ramsay Jones
> > ---
> >
> > Hi Alexey,
> >
> > If you need to re-roll your 'as/pretty-truncate' branch, could
> > you please squash the relevan
On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Alexey,
>
> If you need to re-roll your 'as/pretty-truncate' branch, could
> you please squash the relevant parts of this patch into the
> corresponding patches of your patch series. (ie t
Elia Pinto writes:
> Elia Pinto (19):
I went through the series (not very thoroughly) and it sounds good to
me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
Elia Pinto writes:
> - test $status = D -o $status = T && echo "$sm_path" &&
> continue
> + {
> + test "$status" = D ||
> + test "$status" = T
> + } &&
> + echo "$sm_path"
> +
Signed-off-by: Ramsay Jones
---
Hi Alexey,
If you need to re-roll your 'as/pretty-truncate' branch, could
you please squash the relevant parts of this patch into the
corresponding patches of your patch series. (ie this is a patch
against the head of the current pu branch ...).
Without this pat
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
t/t5537-fetch-s
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
contrib/example
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
t/t5403-post-ch
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
t/t0025-crlf-au
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
t/t5000-tar-tre
1 - 100 of 125 matches
Mail list logo
