On Sat, Jan 30, 2016 at 02:21:26AM -0500, Jeff King wrote:
> Even the commit porting rsync over to C from shell (cd547b4)
> lists it as deprecated! So between the 10 years of informal
> warnings, and the fact that it has been severely broken
> since 2007, it's probably safe to simply remove it wit
On Sat, Jan 30, 2016 at 01:30:36AM -0500, Jeff King wrote:
> I guess that doesn't handle subsequent fetches. But
> really...git-over-rsync is just an awful protocol. Nobody should be
> using it. Having looked at it in more detail, I'm more in favor than
> ever of removing it.
So here it is. I thi
On Sat, Jan 30, 2016 at 12:41:41AM -0500, Jeff King wrote:
> It looks like this has been broken since cd547b4 (fetch/push: readd
> rsync support, 2007-10-01). The fix is just to ignore packed-refs
> entries which duplicate loose ones. But given the length of time this
> has been broken with nobody
On Sat, Jan 30, 2016 at 05:11:33AM +, Eric Wong wrote:
> I have not used rsync remotes in ages, but I was working on the
> patch for -4/-6 support and decided to test it against rsync.kernel.org
>
> Cloning git.git takes forever and failed with:
No kidding. There are over 95,000 unreachable
On Fri, Jan 29, 2016 at 09:28:44AM -0500, Stefan Monnier wrote:
> > The primary goal of fast-import is to write that packfile. It kind of
> > sounds like you are using the wrong tool for the job.
>
> Yes, I realize that. But in some cases it's the best tool available.
> `fast-import' is very cl
I have not used rsync remotes in ages, but I was working on the
patch for -4/-6 support and decided to test it against rsync.kernel.org
Cloning git.git takes forever and failed with:
$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git
Checking connectivity... fatal: bad object
ecdc6d8612df8
Привет.
Ищите качественный сервис поиска клиентов?
Заказать и узнать тарифы можно по тел 8 961 136 35 21
E-mail lady.lachina1...@mail.ru
--
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.
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref sta
On Fri, Jan 29, 2016 at 06:24:07PM +, Anatoly Borodin wrote:
> > You're expecting git to notice a tree change, even though it never even
> > examined the tree in the first place (because you didn't give it a tree
> > or index filter).
>
> When git-filter-branch(1) says "If you have any grafts
> These all look OK (I am not sure about message i18n, though).
>
> Do we not test a case where --force-with-lease push is rejected due
> to REF_STATUS_REJECT_STALE?
Good idea, new patch on the way.
-andrew
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messag
Hi Junio,
I've tested it with many older versions of git, as well as with the recent
v2.7.0 - it seems like this feature has been never working properly.
The script https://gist.github.com/anatolyborodin/9c581b50c584534fff28
#!/bin/sh
set -e
# a
# b
# c
# D/a
# D/b
# D/c
# E/F/a
# E/F/b
# E/F
Signed-off-by: Jean-Noel Avila
---
po/fr.po | 761 +++
1 file changed, 373 insertions(+), 388 deletions(-)
diff --git a/po/fr.po b/po/fr.po
index 80f72fb..2e55c89 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -3,14 +3,14 @@
# This file is di
Signed-off-by: Jean-Noel Avila
---
po/fr.po | 96 +++-
1 file changed, 46 insertions(+), 50 deletions(-)
diff --git a/po/fr.po b/po/fr.po
index 2e55c89..c44f994 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -9,7 +9,7 @@ msgstr ""
"Project-Id
Matthias Aßhauer writes:
[administrivia: please wrap your lines to reasonable lengths]
>> Honestly, I had high hopes after seeing the "we are rewriting it
>> in C" but I am not enthused after seeing this. I was hoping that
>> the rewritten version would do this all in-core, by calling these
>>
>>> Yes, I did. It definitly makes things easier if you are not used to mailing
>>> lists, but it was also a bit of a kerfuffle. I tried to start working on
>>> coverletter support, but I couldn't get it to accept the amazon SES
>>> credentials I provided. I ended up manually submiting the cover
> Hmph, why not have everything inside builtin/stash--helper.c? I do not quite
> see a point of having the other two "library-ish" looking files.
>
> Also I personally feel that it would be easier to review when these two
> patches are squashed into one. I had to go back and forth while readin
Jeff King writes:
> The end result is roughly the same, but it's a lot less churn, and it's
> more likely for new callers to get it right, because they have to go the
> extra mile to ignore the error. I say "roughly" because it treats cases
> we missed as "die", whereas yours leaves them as "igno
> On 29 Jan 2016, at 19:20, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> If the clean/smudge command of a Git filter driver (filter..smudge
>> and
>> filter..clean) is set to an empty string ("") and the filter driver
>> is
>> not required (fil
Junio C Hamano writes:
> Instead, teach apply_filter() to treat an empty string given as a
> filter means the input must be returned as-is without conversion,
> and the operation must always succeed.
Ugh, that was a non-sentence.
Instead, teach apply_filter() to treat an empty string as a n
Dickson Wong writes:
> When invoking default (g)vimdiff three-way merge, the merged file is
> loaded as the first buffer but moved to the bottom as the fourth window.
> This causes a disconnect between vim commands that operate on window
> positions (e.g. CTRL-W_w) and those that operate on buffe
Thomas Gummerer writes:
> Matthias, feel free to squash the following (or something similar) in
> when you re-roll.
>
> diff --git a/t/perf/p3000-stash.sh b/t/perf/p3000-stash.sh
> new file mode 100755
> index 000..e6e1153
> --- /dev/null
> +++ b/t/perf/p3000-stash.sh
> @@ -0,0 +1,20 @@
> +#!
Assen Totin writes:
> I'm not sure if the described issue is a bug or a feature; if it is the
> latter, please, excuse the report.
>
> I'm dealing with git 1.7.12.4. If this has been addressed in the later
> issue, please, point me so.
That is a bit too ancient version, so I am not sure how it b
Hi Jeff,
I've created a gist with the script
https://gist.github.com/anatolyborodin/6505a364a68584f13846
I've added some changes and a second test (will be discussed in the
comments).
Jeff King wrote:
> I'm not sure if this is a bug or not. The "empty commit" check works by
> checking the tre
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> If the clean/smudge command of a Git filter driver (filter..smudge and
> filter..clean) is set to an empty string ("") and the filter driver is
> not required (filter..required=false) then Git will run successfully.
> However, Git will p
On Fri, Jan 29, 2016 at 09:34:27AM -0800, Junio C Hamano wrote:
> Yeah, after re-reading the messages in this thread, I realize that I
> missed the fact that you do consider these CONNECT_VERBOSE messages
> as debugging aid and from that point of view "fetch -v" that shows
> these messagse in addi
Jeff King writes:
> On Thu, Jan 28, 2016 at 07:19:30PM -0800, Junio C Hamano wrote:
>
>> I just reviewed the output that are protected by CONNECT_VERBOSE;
>> they look somewhere between pure debugging aid (like the protocol
>> dump that are shown by "fetch -vv") and progress display, and at
>> le
Hi,
I'm not sure if the described issue is a bug or a feature; if it is the
latter, please, excuse the report.
I'm dealing with git 1.7.12.4. If this has been addressed in the later
issue, please, point me so.
The problem: I have a directory tree with lots of files and dirs, of which
I only trac
On 29/01/16 05:31, Eric Sunshine wrote:
> On Thu, Jan 28, 2016 at 06:56:16PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> diff --git a/test-regex.c b/test-regex.c
>> @@ -1,19 +1,63 @@
>> int main(int argc, char **argv)
>> {
>> -char *pat = "[^={} \t]+
>> I recently discovered that "git fast-import" signals an error if used in
>> a tree to which we do not have write-access, because it tries to create
>> a "objects/pack/tmp_pack_XXX" file even before starting to process
>> the commands.
> The primary goal of fast-import is to write that packfile.
你的老朋友邀你来Q群:343257759
On 01/28, Stefan Beller wrote:
> On Thu, Jan 28, 2016 at 12:36 PM, Matthias Asshauer wrote:
> > From: Matthias Aßhauer
> >
> > Use the new "git stash--helper" builtin. It should be faster than the old
> > shell code and is a first step to move
> > more shell code to C.
>
> You had some good meas
From: Lars Schneider
diff to v1:
* improve commit message (Thanks Junio & Torsten)
* check for empty filter strings in apply_filter to catch all use cases (Thanks
Peff)
* use more idiomatic style to check for an empty string (Thanks Eric)
* use test_config/test_config_global to set configs (Than
From: Lars Schneider
If the clean/smudge command of a Git filter driver (filter..smudge and
filter..clean) is set to an empty string ("") and the filter driver is
not required (filter..required=false) then Git will run successfully.
However, Git will print an error for every file that is affected
On Thu, Jan 28, 2016 at 10:00:28AM +0100, Patrick Steinhardt wrote:
> I've finally got around to producing version two of my previous
> patch to handle errors when setting configs. Back in September
> I've posted a single patch to handle errors when
> `install_branch_config` fails due to configura
34 matches
Mail list logo
