* Re: Feature request: use relative path in worktree config files
From: Duy Nguyen @ 2016-10-09 11:37 UTC (permalink / raw)
To: Stéphane Klein; +Cc: Git Mailing List
In-Reply-To: <CADKxhpd-gDczp05Ny6wP57RXafWWCimArfA9ki2phh+-gHez4A@mail.gmail.com>
On Sun, Oct 9, 2016 at 6:22 PM, Stéphane Klein
<contact@stephane-klein.info> wrote:
> 2016-10-09 13:11 GMT+02:00 Duy Nguyen <pclouds@gmail.com>:
>
>>> * [worktree_foobar]/.git
>> This is made absolute on purpose. So that if you move worktree_foobar
>> away manually, it can still point back to
>> "[main_worktree]/.git/worktrees/[woktree_foobar]".
>
> Same problem if you move origin git repository.
We could fix up after moving the origin repository (because "gitdir"
file so far uses absolute paths, so we know where all the worktrees
are). But we have not done that.
>>> Why:
>>>
>>> 1. I configure worktree on my host
>>> 2. next I use this git working copy in Docker with volume share
>>> 3. next I've some git error in Docker because config files use absolute path
>>
>> I think the common way of dealing with this in docker is put things in
>> the same path where it actually is outside docker. If you have stuff
>> at /path/to/foo, then you create the same /path/to/foo inside docker
>> and bind the data to that path. Does that work?
>
> It's not always possible. I can't in my project.
>
> I think there are some pros and some cons for relative path and absolute path.
> Maybe append a "--relative" option with `git worktree add` ?
>
> I've converted all path to relative and all work with success.
>
> What do you think to append this --relative option.
Patches are welcome.
--
Duy
^ permalink raw reply
* Re: Feature request: use relative path in worktree config files
From: Stéphane Klein @ 2016-10-09 11:22 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8C0kyKor4gCLSJrreRCazazbexvaSdbBg+Cka=-beZU_g@mail.gmail.com>
2016-10-09 13:11 GMT+02:00 Duy Nguyen <pclouds@gmail.com>:
>> * [worktree_foobar]/.git
> This is made absolute on purpose. So that if you move worktree_foobar
> away manually, it can still point back to
> "[main_worktree]/.git/worktrees/[woktree_foobar]".
Same problem if you move origin git repository.
>
>> Why:
>>
>> 1. I configure worktree on my host
>> 2. next I use this git working copy in Docker with volume share
>> 3. next I've some git error in Docker because config files use absolute path
>
> I think the common way of dealing with this in docker is put things in
> the same path where it actually is outside docker. If you have stuff
> at /path/to/foo, then you create the same /path/to/foo inside docker
> and bind the data to that path. Does that work?
It's not always possible. I can't in my project.
I think there are some pros and some cons for relative path and absolute path.
Maybe append a "--relative" option with `git worktree add` ?
I've converted all path to relative and all work with success.
What do you think to append this --relative option.
Best regards,
Stéphane
^ permalink raw reply
* Re: [PATCH v2 3/3] gitweb: Link to "git describe"'d commits in log messages
From: Ævar Arnfjörð Bjarmason @ 2016-10-09 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jakub Narebski
In-Reply-To: <xmqqy421i7dg.fsf@gitster.mtv.corp.google.com>
On Thu, Oct 6, 2016 at 9:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Change the log formatting function to know about "git describe" output
>> such as "v2.8.0-4-g867ad08", in addition to just plain "867ad08".
>>
>> There are still many valid refnames that we don't link to
>> e.g. v2.10.0-rc1~2^2~1 is also a valid way to refer to
>> v2.8.0-4-g867ad08, but I'm not supporting that with this commit,
>> similarly it's trivially possible to create some refnames like
>> "æ/var-gf6727b0" or which won't be picked up by this regex.
>
> Not a serious counter-proposal or suggestion, and certainly not an
> objection to the patch I am responding to, but I wonder if it is so
> bad if we made the 867ad08 into link when showing v2.8.0-4-g867ad08.
>
> IOW, in addition to \b followed by [0-9a-f]+ followed by \b, if we
> allowed an optional 'g' in front of the hex, e.g.
>
> - $line =~ s{\b([0-9a-fA-F]{7,40})\b}{
> + $line =~ s{\bg?([0-9a-fA-F]{7,40})\b}{
>
> wouldn't that be much simpler, covers more cases and sufficient?
It would be more simpler, maybe that's the right approach. I have a
preference for making the entire reference a link. I think it makes
more sense for the UI.
>> There's surely room for improvement here, but I just wanted to address
>> the very common case of sticking "git describe" output into commit
>> messages without trying to link to all possible refnames, that's going
>> to be a rather futile exercise given that this is free text, and it
>> would be prohibitively expensive to look up whether the references in
>> question exist in our repository.
>>
>> There was on-list discussion about how we could do better than this
>> patch. Junio suggested to update parse_commits() to call a new
>> "gitweb--helper" command which would pass each of the revision
>> candidates through "rev-parse --verify --quiet". That would cut down
>> on our false positives (e.g. we'll link to "deadbeef"), and also allow
>> us to be more aggressive in selecting candidate revisions.
>>
>> That may be too expensive to work in practice, or it may
>> not. Investigating that would be a good follow-up to this patch.
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>> gitweb/gitweb.perl | 18 ++++++++++++++++--
>> 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 92b5e91..7cf68f0 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -2036,10 +2036,24 @@ sub format_log_line_html {
>> my $line = shift;
>>
>> $line = esc_html($line, -nbsp=>1);
>> - $line =~ s{\b([0-9a-fA-F]{7,40})\b}{
>> + $line =~ s{
>> + \b
>> + (
>> + # The output of "git describe", e.g. v2.10.0-297-gf6727b0
>> + # or hadoop-20160921-113441-20-g094fb7d
>> + (?<!-) # see strbuf_check_tag_ref(). Tags can't start with -
>> + [A-Za-z0-9.-]+
>> + (?!\.) # refs can't end with ".", see check_refname_format()
>> + -g[0-9a-fA-F]{7,40}
>> + |
>> + # Just a normal looking Git SHA1
>> + [0-9a-fA-F]{7,40}
>> + )
>> + \b
>> + }{
>> $cgi->a({-href => href(action=>"object", hash=>$1),
>> -class => "text"}, $1);
>> - }eg;
>> + }egx;
>>
>> return $line;
>> }
^ permalink raw reply
* Re: Feature request: use relative path in worktree config files
From: Duy Nguyen @ 2016-10-09 11:11 UTC (permalink / raw)
To: Stéphane Klein; +Cc: Git Mailing List
In-Reply-To: <CADKxhpe3S4L9CPV9yxh2yhrtJMa9wyZAPC45u_S=RiuzY1Xrkg@mail.gmail.com>
On Sat, Oct 8, 2016 at 4:35 PM, Stéphane Klein
<contact@stephane-klein.info> wrote:
> Hi,
>
> "git worktree add" write absolute path in ".git/gitdir"
>
> The code source is here
> https://git.kernel.org/cgit/git/git.git/tree/builtin/worktree.c?h=v2.10.1#n256
>
> Is it possible to use relative path in this config files:
>
> * [main_worktree]/.git/worktrees/[worktree_foobar]/gitdir
The problem with relative is the question "relative to where" and the
answer has to be the same when asked from any worktree. For this file,
it may be ok after we find a good anchor point (which I have avoided
because it gives me headache and absolute paths just work).
> * [worktree_foobar]/.git
This is made absolute on purpose. So that if you move worktree_foobar
away manually, it can still point back to
"[main_worktree]/.git/worktrees/[woktree_foobar]". I'm not sure if we
want relative paths here.
> Why:
>
> 1. I configure worktree on my host
> 2. next I use this git working copy in Docker with volume share
> 3. next I've some git error in Docker because config files use absolute path
I think the common way of dealing with this in docker is put things in
the same path where it actually is outside docker. If you have stuff
at /path/to/foo, then you create the same /path/to/foo inside docker
and bind the data to that path. Does that work?
--
Duy
^ permalink raw reply
* Re: Bug? git worktree fails with master on bare repo
From: Duy Nguyen @ 2016-10-09 10:52 UTC (permalink / raw)
To: Dennis Kaarsemaker; +Cc: Michael Tutty, Git Mailing List, Michael Rappazzo
In-Reply-To: <1475999513.7410.8.camel@kaarsemaker.net>
On Sun, Oct 9, 2016 at 2:51 PM, Dennis Kaarsemaker
<dennis@kaarsemaker.net> wrote:
> On Sat, 2016-10-08 at 19:30 -0500, Michael Tutty wrote:
>> Hey all,
>> I'm working on some server-side software to do a merge. By using git
>> worktree it's possible to check out a given branch for a bare repo and
>> merge another branch into it. It's very fast, even with large
>> repositories.
>>
>> The only exception seems to be merging to master. When I do git
>> worktree add /tmp/path/to/worktree master I get an error:
>>
>> [fatal: 'master' is already checked out at '/path/to/bare/repo']
>>
>> But this is clearly not true, git worktree list gives:
>>
>> [/path/to/bare/repo (bare)]
>>
>> ...and of course, there is no work tree at that path, just the bare
>> repo files you'd expect.
>
> The worktree code treats the base repo as a worktree, even if it's
> bare. For the purpose of being able to do a checkout of the main branch
> of a bare repo, this patch should do:
>
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index 4bcc335..b618d6b 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -138,6 +138,14 @@ test_expect_success 'checkout from a bare repo without "add"' '
> )
> '
>
> +test_expect_success '"add" default branch of a bare repo' '
> + (
> + git clone --bare . bare2 &&
> + cd bare2 &&
> + git worktree add ../there3 master
> + )
> +'
> +
> test_expect_success 'checkout with grafts' '
> test_when_finished rm .git/info/grafts &&
> test_commit abc &&
> diff --git a/worktree.c b/worktree.c
> index 5acfe4c..35e95b7 100644
> --- a/worktree.c
> +++ b/worktree.c
> @@ -345,6 +345,8 @@ const struct worktree *find_shared_symref(const char *symref,
>
> for (i = 0; worktrees[i]; i++) {
> struct worktree *wt = worktrees[i];
> + if(wt->is_bare)
> + continue;
>
> if (wt->is_detached && !strcmp(symref, "HEAD")) {
> if (is_worktree_being_rebased(wt, target)) {
>
>
You're fast :) I'm still studying 8d9fdd7 (worktree.c: check whether
branch is rebased in another worktree - 2016-04-22). But yeah that
should fix it.
> But I'm wondering why the worktree code does this. A bare repo isn't a
> worktree and I think it shouldn't treat it as one. A patch that rips
> out this feature and updates the tests to match would look like this:
>
>
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 5c4854d..3600530 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -382,15 +382,11 @@ static int add(int ac, const char **av, const char *prefix)
> static void show_worktree_porcelain(struct worktree *wt)
> {
> printf("worktree %s\n", wt->path);
> - if (wt->is_bare)
> - printf("bare\n");
> - else {
> - printf("HEAD %s\n", sha1_to_hex(wt->head_sha1));
> - if (wt->is_detached)
> - printf("detached\n");
> - else
> - printf("branch %s\n", wt->head_ref);
> - }
> + printf("HEAD %s\n", sha1_to_hex(wt->head_sha1));
> + if (wt->is_detached)
> + printf("detached\n");
> + else
> + printf("branch %s\n", wt->head_ref);
> printf("\n");
> }
This goes back to the first very first commit of "git worktree list":
bb9c03b (worktree: add 'list' command - 2015-10-08) and was sort of
pointed out during review [1] but nobody answered it.
A bare repo does not have an associated worktree. However only main
worktree can be bare. If we take this out, "git worktree list"'s first
line will no longer be about the main worktree (because it does not
exist). That may cause trouble since we promised in "git-worktree.txt"
that the main worktree is listed first. I don't think we have any way
else to determine if the main worktree exists. Showing "bare" may be
the way to see if we have a main worktree or not. So we probably want
to keep this function unchanged.
[1] https://public-inbox.org/git/%3CCANoM8SWeqxD2vWLQmEfxxxn8Dz4yPfjGOoOH=Azn1A3So+wz2Q@mail.gmail.com%3E/
--
Duy
^ permalink raw reply
* Re: [PATCH v2 20/25] sequencer: left-trim lines read from the script
From: Johannes Sixt @ 2016-10-09 10:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Jakub Narębski
In-Reply-To: <alpine.DEB.2.20.1610091054490.35196@virtualbox>
Am 09.10.2016 um 10:57 schrieb Johannes Schindelin:
> Good point. I decided to do it at a different level, though:
> parse_insn_line() should already receive the line without trailing
> end-of-line markers (this was already the case for LF-only todo scripts).
>
> I reused your commit message and touched it up a bit, hope you don't mind!
I don't mind at all.
Thanks,
-- Hannes
^ permalink raw reply
* Re: A head scratcher, clone results in modified files (tested linux and cygwin) - .gitattributes file?
From: Torsten Bögershausen @ 2016-10-09 10:27 UTC (permalink / raw)
To: git, jpyeron
In-Reply-To: <7E06D61EACFB462AB96DD60720930968@black7>
On 09/10/16 08:48, Jason Pyeron wrote:
The whole .gitattributes needs to be adopted, I think
Git 2.10 or higher has "git ls-files --eol":
git ls-files --eol | grep "i/crlf.*auto"
i/crlf w/crlf attr/text=auto src/site/xdoc/upgradeto2_3.xml
i/crlf w/crlf attr/text=auto
src/test/resources/org/apache/commons/io/FileUtilsTestDataCRLF.dat
i/crlf w/crlf attr/text=auto src/test/resources/test-file-gbk.bin
i/crlf w/crlf attr/text=auto
src/test/resources/test-file-iso8859-1-shortlines-win-linebr.bin
i/crlf w/crlf attr/text=auto src/test/resources/test-file-utf8-win-linebr.bin
i/crlf w/crlf attr/text=auto src/test/resources/test-file-windows-31j.bin
i/crlf w/crlf attr/text=auto src/test/resources/test-file-x-windows-949.bin
i/crlf w/crlf attr/text=auto src/test/resources/test-file-x-windows-950.bin
############
Problem:
xml file had been commited with CRLF : either normalize it or declare "-text".
The same is valid for the other files as well.
They are identified by auto as text, and commited with CRLF.
My feeling is that they should be declared as "-text".
Or, to be more compatible, with "-crlf":
Solution:
Make up your mind about the xml file and the html files.
If they are text, they need to be normalized.
Question:
What happens, if you do this:
# Auto detect text files and perform LF normalization
* crlf=auto
*.bin -crlf
*.dat -crlf
*.java crlf diff=java
*.html crlf diff=html
*.css crlf
*.js crlf
*.sql crlf
^ permalink raw reply
* Re: %C(auto) not working as expected
From: Tom Hale @ 2016-10-09 10:04 UTC (permalink / raw)
To: René Scharfe, git
In-Reply-To: <f35965e9-2901-b9b5-92e5-9bc7fe673637@web.de>
On 2016-10-09 13:47, René Scharfe wrote:
> %Cgreen emits color codes unconditionally. %C(auto,green) would respect
> the config settings.
Thanks, I've never seen the (,) syntax documented before!
What's strange is that this works:
%C(auto,green bold)
but
%C(auto,green,bold)
does not.
Also:
Given it's very rare to want only part of a string to emit colour codes,
if something like "bold" carries through until a "no-bold", why doesn't
"auto" do the same thing?
--
Tom Hale
^ permalink raw reply
* [PATCH v1 0/2] convert: stream and early out
From: tboegi @ 2016-10-09 9:56 UTC (permalink / raw)
To: git; +Cc: Torsten Bögershausen
From: Torsten Bögershausen <tboegi@web.de>
An optimization when autocrlf is used and the binary/text detection is run.
Or git ls-files --eol is run to analyze the content of files or blobs.
Torsten Bögershausen (2):
read-cache: factor out get_sha1_from_index() helper
convert.c: stream and early out
cache.h | 3 +
convert.c | 195 +++++++++++++++++++++++++++++++++++++++--------------------
read-cache.c | 29 +++++----
3 files changed, 151 insertions(+), 76 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v1 2/2] convert.c: stream and early out
From: tboegi @ 2016-10-09 9:56 UTC (permalink / raw)
To: git; +Cc: Torsten Bögershausen
From: Torsten Bögershausen <tboegi@web.de>
When statistics are done for the autocrlf handling, the search in
the content can be stopped, if e.g
- a search for binary is done, and a NUL character is found
- a search for CRLF is done, and the first CRLF is found.
Similar when statistics for binary vs non-binary are gathered:
Whenever a lone CR or NUL is found, the search can be aborted.
When checking out files in "auto" mode, any file that has a "lone CR"
or a CRLF will not be converted, so the search can be aborted early.
Add the new bit, CONVERT_STAT_BITS_ANY_CR,
which is set for either lone CR or CRLF.
Many binary files have a NUL very early (within the first few bytes,
latest within the first 1..2K).
It is often not necessary to load the whole content of a file or blob
into memory.
Use a streaming handling for blobs and files in the worktree.
---
convert.c | 195 +++++++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 130 insertions(+), 65 deletions(-)
diff --git a/convert.c b/convert.c
index 077f5e6..6a625e5 100644
--- a/convert.c
+++ b/convert.c
@@ -3,6 +3,7 @@
#include "run-command.h"
#include "quote.h"
#include "sigchain.h"
+#include "streaming.h"
/*
* convert.c - convert a file when checking it out and checking it in.
@@ -13,10 +14,10 @@
* translation when the "text" attribute or "auto_crlf" option is set.
*/
-/* Stat bits: When BIN is set, the txt bits are unset */
#define CONVERT_STAT_BITS_TXT_LF 0x1
#define CONVERT_STAT_BITS_TXT_CRLF 0x2
#define CONVERT_STAT_BITS_BIN 0x4
+#define CONVERT_STAT_BITS_ANY_CR 0x8
enum crlf_action {
CRLF_UNDEFINED,
@@ -31,30 +32,36 @@ enum crlf_action {
struct text_stat {
/* NUL, CR, LF and CRLF counts */
- unsigned nul, lonecr, lonelf, crlf;
+ unsigned stat_bits, lonecr, lonelf, crlf;
/* These are just approximations! */
unsigned printable, nonprintable;
};
-static void gather_stats(const char *buf, unsigned long size, struct text_stat *stats)
+static void gather_stats_partly(const char *buf, unsigned long len,
+ struct text_stat *stats, unsigned earlyout)
{
unsigned long i;
- memset(stats, 0, sizeof(*stats));
-
- for (i = 0; i < size; i++) {
+ if (!buf || !len)
+ return;
+ for (i = 0; i < len; i++) {
unsigned char c = buf[i];
if (c == '\r') {
- if (i+1 < size && buf[i+1] == '\n') {
+ stats->stat_bits |= CONVERT_STAT_BITS_ANY_CR;
+ if (i+1 < len && buf[i+1] == '\n') {
stats->crlf++;
i++;
- } else
+ stats->stat_bits |= CONVERT_STAT_BITS_TXT_CRLF;
+ } else {
stats->lonecr++;
+ stats->stat_bits |= CONVERT_STAT_BITS_BIN;
+ }
continue;
}
if (c == '\n') {
stats->lonelf++;
+ stats->stat_bits |= CONVERT_STAT_BITS_TXT_LF;
continue;
}
if (c == 127)
@@ -67,7 +74,7 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
stats->printable++;
break;
case 0:
- stats->nul++;
+ stats->stat_bits |= CONVERT_STAT_BITS_BIN;
/* fall through */
default:
stats->nonprintable++;
@@ -75,10 +82,12 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
}
else
stats->printable++;
+ if (stats->stat_bits & earlyout)
+ break; /* We found what we have been searching for */
}
/* If file ends with EOF then don't count this EOF as non-printable. */
- if (size >= 1 && buf[size-1] == '\032')
+ if (len >= 1 && buf[len-1] == '\032')
stats->nonprintable--;
}
@@ -86,41 +95,62 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
* The same heuristics as diff.c::mmfile_is_binary()
* We treat files with bare CR as binary
*/
-static int convert_is_binary(unsigned long size, const struct text_stat *stats)
+static void convert_nonprintable(struct text_stat *stats)
{
- if (stats->lonecr)
- return 1;
- if (stats->nul)
- return 1;
if ((stats->printable >> 7) < stats->nonprintable)
- return 1;
- return 0;
+ stats->stat_bits |= CONVERT_STAT_BITS_BIN;
}
-static unsigned int gather_convert_stats(const char *data, unsigned long size)
+static void gather_stats(const char *buf, unsigned long size,
+ struct text_stat *stats, unsigned earlyout)
{
+ memset(stats, 0, sizeof(*stats));
+ gather_stats_partly(buf, size, stats, earlyout);
+ convert_nonprintable(stats);
+}
+
+
+static unsigned get_convert_stats_sha1(unsigned const char *sha1,
+ unsigned earlyout)
+{
+ struct git_istream *st;
struct text_stat stats;
- int ret = 0;
- if (!data || !size)
- return 0;
- gather_stats(data, size, &stats);
- if (convert_is_binary(size, &stats))
- ret |= CONVERT_STAT_BITS_BIN;
- if (stats.crlf)
- ret |= CONVERT_STAT_BITS_TXT_CRLF;
- if (stats.lonelf)
- ret |= CONVERT_STAT_BITS_TXT_LF;
+ enum object_type type;
+ unsigned long sz;
- return ret;
+ if (!sha1)
+ return 0;
+ memset(&stats, 0, sizeof(stats));
+ st = open_istream(sha1, &type, &sz, NULL);
+ if (!st) {
+ return 0;
+ }
+ if (type != OBJ_BLOB)
+ goto close_and_exit_i;
+ for (;;) {
+ char buf[2*1024];
+ ssize_t readlen = read_istream(st, buf, sizeof(buf));
+ if (readlen < 0)
+ break;
+ if (!readlen)
+ break;
+ gather_stats_partly(buf, (unsigned long)readlen, &stats, earlyout);
+ if (stats.stat_bits & earlyout)
+ break; /* We found what we have been searching for */
+ }
+close_and_exit_i:
+ close_istream(st);
+ convert_nonprintable(&stats);
+ return stats.stat_bits;
}
-static const char *gather_convert_stats_ascii(const char *data, unsigned long size)
+static const char *convert_stats_ascii(unsigned convert_stats)
{
- unsigned int convert_stats = gather_convert_stats(data, size);
-
+ const unsigned mask = CONVERT_STAT_BITS_TXT_LF |
+ CONVERT_STAT_BITS_TXT_CRLF;
if (convert_stats & CONVERT_STAT_BITS_BIN)
return "-text";
- switch (convert_stats) {
+ switch (convert_stats & mask) {
case CONVERT_STAT_BITS_TXT_LF:
return "lf";
case CONVERT_STAT_BITS_TXT_CRLF:
@@ -132,24 +162,45 @@ static const char *gather_convert_stats_ascii(const char *data, unsigned long si
}
}
+static unsigned get_convert_stats_wt(const char *path)
+{
+ struct text_stat stats;
+ unsigned earlyout = CONVERT_STAT_BITS_BIN;
+ int fd;
+ memset(&stats, 0, sizeof(stats));
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return 0;
+ for (;;) {
+ char buf[2*1024];
+ ssize_t readlen = read(fd, buf, sizeof(buf));
+ if (readlen < 0)
+ break;
+ if (!readlen)
+ break;
+ gather_stats_partly(buf, (unsigned long)readlen, &stats, earlyout);
+ if (stats.stat_bits & earlyout)
+ break; /* We found what we have been searching for */
+ }
+ close(fd);
+ convert_nonprintable(&stats);
+ return stats.stat_bits;
+}
+
const char *get_cached_convert_stats_ascii(const char *path)
{
- const char *ret;
- unsigned long sz;
- void *data = read_blob_data_from_cache(path, &sz);
- ret = gather_convert_stats_ascii(data, sz);
- free(data);
- return ret;
+ unsigned convert_stats;
+ unsigned earlyout = CONVERT_STAT_BITS_BIN;
+ convert_stats = get_convert_stats_sha1(get_sha1_from_cache(path),
+ earlyout);
+ return convert_stats_ascii(convert_stats);
}
const char *get_wt_convert_stats_ascii(const char *path)
{
- const char *ret = "";
- struct strbuf sb = STRBUF_INIT;
- if (strbuf_read_file(&sb, path, 0) >= 0)
- ret = gather_convert_stats_ascii(sb.buf, sb.len);
- strbuf_release(&sb);
- return ret;
+ unsigned convert_stats;
+ convert_stats = get_convert_stats_wt(path);
+ return convert_stats_ascii(convert_stats);
}
static int text_eol_is_crlf(void)
@@ -213,16 +264,10 @@ static void check_safe_crlf(const char *path, enum crlf_action crlf_action,
static int has_cr_in_index(const char *path)
{
- unsigned long sz;
- void *data;
- int has_cr;
-
- data = read_blob_data_from_cache(path, &sz);
- if (!data)
- return 0;
- has_cr = memchr(data, '\r', sz) != NULL;
- free(data);
- return has_cr;
+ unsigned convert_stats;
+ convert_stats = get_convert_stats_sha1(get_sha1_from_cache(path),
+ CONVERT_STAT_BITS_ANY_CR);
+ return convert_stats & CONVERT_STAT_BITS_ANY_CR;
}
static int will_convert_lf_to_crlf(size_t len, struct text_stat *stats,
@@ -234,13 +279,13 @@ static int will_convert_lf_to_crlf(size_t len, struct text_stat *stats,
if (!stats->lonelf)
return 0;
- if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_INPUT || crlf_action == CRLF_AUTO_CRLF) {
+ if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_CRLF) {
/* If we have any CR or CRLF line endings, we do not touch it */
/* This is the new safer autocrlf-handling */
if (stats->lonecr || stats->crlf)
return 0;
- if (convert_is_binary(len, stats))
+ if (stats->stat_bits & CONVERT_STAT_BITS_BIN)
return 0;
}
return 1;
@@ -253,7 +298,8 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
{
struct text_stat stats;
char *dst;
- int convert_crlf_into_lf;
+ int has_crlf_to_convert;
+ unsigned earlyout = 0;
if (crlf_action == CRLF_BINARY ||
(src && !len))
@@ -266,12 +312,16 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
if (!buf && !src)
return 1;
- gather_stats(src, len, &stats);
+ if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_INPUT || crlf_action == CRLF_AUTO_CRLF)
+ earlyout = CONVERT_STAT_BITS_BIN;
+
+ gather_stats(src, len, &stats, earlyout);
+
/* Optimization: No CRLF? Nothing to convert, regardless. */
- convert_crlf_into_lf = !!stats.crlf;
+ has_crlf_to_convert = !!stats.crlf;
if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_INPUT || crlf_action == CRLF_AUTO_CRLF) {
- if (convert_is_binary(len, &stats))
+ if (stats.stat_bits & CONVERT_STAT_BITS_BIN)
return 0;
/*
* If the file in the index has any CR in it, do not convert.
@@ -280,24 +330,35 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
if (checksafe == SAFE_CRLF_RENORMALIZE)
checksafe = SAFE_CRLF_FALSE;
else if (has_cr_in_index(path))
- convert_crlf_into_lf = 0;
+ has_crlf_to_convert = 0;
}
if (checksafe && len) {
struct text_stat new_stats;
memcpy(&new_stats, &stats, sizeof(new_stats));
/* simulate "git add" */
- if (convert_crlf_into_lf) {
+ if (has_crlf_to_convert) {
new_stats.lonelf += new_stats.crlf;
new_stats.crlf = 0;
+ /* all crlf, if any, are gone. Update the bits */
+ new_stats.stat_bits = stats.stat_bits & CONVERT_STAT_BITS_BIN;
+ if (new_stats.lonelf)
+ new_stats.stat_bits |= CONVERT_STAT_BITS_TXT_LF;
+ if (new_stats.lonecr)
+ new_stats.stat_bits |= CONVERT_STAT_BITS_ANY_CR;
}
/* simulate "git checkout" */
if (will_convert_lf_to_crlf(len, &new_stats, crlf_action)) {
new_stats.crlf += new_stats.lonelf;
new_stats.lonelf = 0;
+ new_stats.stat_bits = stats.stat_bits & CONVERT_STAT_BITS_BIN;
+ if (new_stats.crlf)
+ new_stats.stat_bits |= CONVERT_STAT_BITS_TXT_CRLF | CONVERT_STAT_BITS_ANY_CR;
+ if (new_stats.lonecr)
+ new_stats.stat_bits |= CONVERT_STAT_BITS_ANY_CR;
}
check_safe_crlf(path, crlf_action, &stats, &new_stats, checksafe);
}
- if (!convert_crlf_into_lf)
+ if (!has_crlf_to_convert)
return 0;
/*
@@ -338,11 +399,15 @@ static int crlf_to_worktree(const char *path, const char *src, size_t len,
{
char *to_free = NULL;
struct text_stat stats;
+ unsigned earlyout = 0;
if (!len || output_eol(crlf_action) != EOL_CRLF)
return 0;
- gather_stats(src, len, &stats);
+ if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_CRLF)
+ earlyout = CONVERT_STAT_BITS_ANY_CR | CONVERT_STAT_BITS_BIN;
+
+ gather_stats(src, len, &stats, earlyout);
if (!will_convert_lf_to_crlf(len, &stats, crlf_action))
return 0;
--
2.10.0
^ permalink raw reply related
* [PATCH v1 1/2] read-cache: factor out get_sha1_from_index() helper
From: tboegi @ 2016-10-09 9:56 UTC (permalink / raw)
To: git; +Cc: Torsten Bögershausen
From: Torsten Bögershausen <tboegi@web.de>
Factor out the retrieval of the sha1 for a given path in
read_blob_data_from_index() into the function get_sha1_from_index().
This will be used in the next commit, when convert.c can do the
analyze for "text=auto" without slurping the whole blob into memory
at once.
Add a wrapper definition get_sha1_from_cache().
---
cache.h | 3 +++
read-cache.c | 29 ++++++++++++++++++-----------
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/cache.h b/cache.h
index 1604e29..04de209 100644
--- a/cache.h
+++ b/cache.h
@@ -380,6 +380,7 @@ extern void free_name_hash(struct index_state *istate);
#define unmerge_cache_entry_at(at) unmerge_index_entry_at(&the_index, at)
#define unmerge_cache(pathspec) unmerge_index(&the_index, pathspec)
#define read_blob_data_from_cache(path, sz) read_blob_data_from_index(&the_index, (path), (sz))
+#define get_sha1_from_cache(path) get_sha1_from_index (&the_index, (path))
#endif
enum object_type {
@@ -1089,6 +1090,8 @@ static inline void *read_sha1_file(const unsigned char *sha1, enum object_type *
return read_sha1_file_extended(sha1, type, size, LOOKUP_REPLACE_OBJECT);
}
+const unsigned char *get_sha1_from_index(struct index_state *istate, const char *path);
+
/*
* This internal function is only declared here for the benefit of
* lookup_replace_object(). Please do not call it directly.
diff --git a/read-cache.c b/read-cache.c
index 38d67fa..5a1df14 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2290,13 +2290,27 @@ int index_name_is_other(const struct index_state *istate, const char *name,
void *read_blob_data_from_index(struct index_state *istate, const char *path, unsigned long *size)
{
- int pos, len;
+ const unsigned char *sha1;
unsigned long sz;
enum object_type type;
void *data;
- len = strlen(path);
- pos = index_name_pos(istate, path, len);
+ sha1 = get_sha1_from_index(istate, path);
+ if (!sha1)
+ return NULL;
+ data = read_sha1_file(sha1, &type, &sz);
+ if (!data || type != OBJ_BLOB) {
+ free(data);
+ return NULL;
+ }
+ if (size)
+ *size = sz;
+ return data;
+}
+
+const unsigned char *get_sha1_from_index(struct index_state *istate, const char *path)
+{
+ int pos = index_name_pos(istate, path, strlen(path));
if (pos < 0) {
/*
* We might be in the middle of a merge, in which
@@ -2312,14 +2326,7 @@ void *read_blob_data_from_index(struct index_state *istate, const char *path, un
}
if (pos < 0)
return NULL;
- data = read_sha1_file(istate->cache[pos]->oid.hash, &type, &sz);
- if (!data || type != OBJ_BLOB) {
- free(data);
- return NULL;
- }
- if (size)
- *size = sz;
- return data;
+ return istate->cache[pos]->oid.hash;
}
void stat_validity_clear(struct stat_validity *sv)
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v2 20/25] sequencer: left-trim lines read from the script
From: Johannes Schindelin @ 2016-10-09 8:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Jakub Narębski
In-Reply-To: <5ed8aaea-9fbe-11b0-49b7-1b42567d4918@kdbg.org>
Hi Hannes,
On Thu, 6 Oct 2016, Johannes Sixt wrote:
> [PATCH] sequencer: strip CR from the end of exec insns
>
> It is not unheard of that editors on Windows write CRLF even if the file
> originally had only LF. This is particularly awkward for exec lines of a
> rebase -i todo sheet. Take for example the insn "exec echo": The shell
> script parser (either of the sequencer or of the shell that is invoked,
> I do not know) splits at the LF and leaves the CR attached to "echo",
> which leads to the unknown command "echo\r".
>
> Work it around by stripping CR before the command specified with exec is
> passed to the shell.
>
> This happens to fix t9903.14 and .15 in my environment: the insn sheet
> constructed here contains CRLF thanks to MSYS1's bash cleverness.
Good point. I decided to do it at a different level, though:
parse_insn_line() should already receive the line without trailing
end-of-line markers (this was already the case for LF-only todo scripts).
I reused your commit message and touched it up a bit, hope you don't mind!
Ciao,
Dscho
^ permalink raw reply
* Re: Bug? git worktree fails with master on bare repo
From: Dennis Kaarsemaker @ 2016-10-09 7:51 UTC (permalink / raw)
To: Michael Tutty, git, pclouds
In-Reply-To: <CAOi_75+2SG2WYHBMQhfGj96eKsZ66niJzOevVGM5eJv-qqrVNg@mail.gmail.com>
On Sat, 2016-10-08 at 19:30 -0500, Michael Tutty wrote:
> Hey all,
> I'm working on some server-side software to do a merge. By using git
> worktree it's possible to check out a given branch for a bare repo and
> merge another branch into it. It's very fast, even with large
> repositories.
>
> The only exception seems to be merging to master. When I do git
> worktree add /tmp/path/to/worktree master I get an error:
>
> [fatal: 'master' is already checked out at '/path/to/bare/repo']
>
> But this is clearly not true, git worktree list gives:
>
> [/path/to/bare/repo (bare)]
>
> ...and of course, there is no work tree at that path, just the bare
> repo files you'd expect.
The worktree code treats the base repo as a worktree, even if it's
bare. For the purpose of being able to do a checkout of the main branch
of a bare repo, this patch should do:
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 4bcc335..b618d6b 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -138,6 +138,14 @@ test_expect_success 'checkout from a bare repo without "add"' '
)
'
+test_expect_success '"add" default branch of a bare repo' '
+ (
+ git clone --bare . bare2 &&
+ cd bare2 &&
+ git worktree add ../there3 master
+ )
+'
+
test_expect_success 'checkout with grafts' '
test_when_finished rm .git/info/grafts &&
test_commit abc &&
diff --git a/worktree.c b/worktree.c
index 5acfe4c..35e95b7 100644
--- a/worktree.c
+++ b/worktree.c
@@ -345,6 +345,8 @@ const struct worktree *find_shared_symref(const char *symref,
for (i = 0; worktrees[i]; i++) {
struct worktree *wt = worktrees[i];
+ if(wt->is_bare)
+ continue;
if (wt->is_detached && !strcmp(symref, "HEAD")) {
if (is_worktree_being_rebased(wt, target)) {
But I'm wondering why the worktree code does this. A bare repo isn't a
worktree and I think it shouldn't treat it as one. A patch that rips
out this feature and updates the tests to match would look like this:
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 5c4854d..3600530 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -382,15 +382,11 @@ static int add(int ac, const char **av, const char *prefix)
static void show_worktree_porcelain(struct worktree *wt)
{
printf("worktree %s\n", wt->path);
- if (wt->is_bare)
- printf("bare\n");
- else {
- printf("HEAD %s\n", sha1_to_hex(wt->head_sha1));
- if (wt->is_detached)
- printf("detached\n");
- else
- printf("branch %s\n", wt->head_ref);
- }
+ printf("HEAD %s\n", sha1_to_hex(wt->head_sha1));
+ if (wt->is_detached)
+ printf("detached\n");
+ else
+ printf("branch %s\n", wt->head_ref);
printf("\n");
}
@@ -401,16 +397,12 @@ static void show_worktree(struct worktree *wt, int path_maxlen, int abbrev_len)
int path_adj = cur_path_len - utf8_strwidth(wt->path);
strbuf_addf(&sb, "%-*s ", 1 + path_maxlen + path_adj, wt->path);
- if (wt->is_bare)
- strbuf_addstr(&sb, "(bare)");
- else {
- strbuf_addf(&sb, "%-*s ", abbrev_len,
- find_unique_abbrev(wt->head_sha1, DEFAULT_ABBREV));
- if (!wt->is_detached)
- strbuf_addf(&sb, "[%s]", shorten_unambiguous_ref(wt->head_ref, 0));
- else
- strbuf_addstr(&sb, "(detached HEAD)");
- }
+ strbuf_addf(&sb, "%-*s ", abbrev_len,
+ find_unique_abbrev(wt->head_sha1, DEFAULT_ABBREV));
+ if (!wt->is_detached)
+ strbuf_addf(&sb, "[%s]", shorten_unambiguous_ref(wt->head_ref, 0));
+ else
+ strbuf_addstr(&sb, "(detached HEAD)");
printf("%s\n", sb.buf);
strbuf_release(&sb);
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 4bcc335..b618d6b 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -138,6 +138,14 @@ test_expect_success 'checkout from a bare repo without "add"' '
)
'
+test_expect_success '"add" default branch of a bare repo' '
+ (
+ git clone --bare . bare2 &&
+ cd bare2 &&
+ git worktree add ../there3 master
+ )
+'
+
test_expect_success 'checkout with grafts' '
test_when_finished rm .git/info/grafts &&
test_commit abc &&
diff --git a/t/t2027-worktree-list.sh b/t/t2027-worktree-list.sh
index 1b1b65a..842e9d9 100755
--- a/t/t2027-worktree-list.sh
+++ b/t/t2027-worktree-list.sh
@@ -62,9 +62,8 @@ test_expect_success 'bare repo setup' '
test_expect_success '"list" all worktrees from bare main' '
test_when_finished "rm -rf there && git -C bare1 worktree prune" &&
- git -C bare1 worktree add --detach ../there master &&
- echo "$(pwd)/bare1 (bare)" >expect &&
- echo "$(git -C there rev-parse --show-toplevel) $(git -C there rev-parse --short HEAD) (detached HEAD)" >>expect &&
+ git -C bare1 worktree add ../there master &&
+ echo "$(git -C there rev-parse --show-toplevel) $(git -C there rev-parse --short HEAD) [master]" >expect &&
git -C bare1 worktree list | sed "s/ */ /g" >actual &&
test_cmp expect actual
'
@@ -72,10 +71,7 @@ test_expect_success '"list" all worktrees from bare main' '
test_expect_success '"list" all worktrees --porcelain from bare main' '
test_when_finished "rm -rf there && git -C bare1 worktree prune" &&
git -C bare1 worktree add --detach ../there master &&
- echo "worktree $(pwd)/bare1" >expect &&
- echo "bare" >>expect &&
- echo >>expect &&
- echo "worktree $(git -C there rev-parse --show-toplevel)" >>expect &&
+ echo "worktree $(git -C there rev-parse --show-toplevel)" >expect &&
echo "HEAD $(git -C there rev-parse HEAD)" >>expect &&
echo "detached" >>expect &&
echo >>expect &&
@@ -85,9 +81,8 @@ test_expect_success '"list" all worktrees --porcelain from bare main' '
test_expect_success '"list" all worktrees from linked with a bare main' '
test_when_finished "rm -rf there && git -C bare1 worktree prune" &&
- git -C bare1 worktree add --detach ../there master &&
- echo "$(pwd)/bare1 (bare)" >expect &&
- echo "$(git -C there rev-parse --show-toplevel) $(git -C there rev-parse --short HEAD) (detached HEAD)" >>expect &&
+ git -C bare1 worktree add ../there master &&
+ echo "$(git -C there rev-parse --show-toplevel) $(git -C there rev-parse --short HEAD) [master]" >expect &&
git -C there worktree list | sed "s/ */ /g" >actual &&
test_cmp expect actual
'
diff --git a/worktree.c b/worktree.c
index 5acfe4c..d4dbaab 100644
--- a/worktree.c
+++ b/worktree.c
@@ -84,7 +84,7 @@ static struct worktree *get_main_worktree(void)
strbuf_add_absolute_path(&worktree_path, get_git_common_dir());
is_bare = !strbuf_strip_suffix(&worktree_path, "/.git");
if (is_bare)
- strbuf_strip_suffix(&worktree_path, "/.");
+ goto done;
strbuf_addf(&path, "%s/HEAD", get_git_common_dir());
@@ -94,7 +94,6 @@ static struct worktree *get_main_worktree(void)
worktree = xmalloc(sizeof(struct worktree));
worktree->path = strbuf_detach(&worktree_path, NULL);
worktree->id = NULL;
- worktree->is_bare = is_bare;
worktree->head_ref = NULL;
worktree->is_detached = is_detached;
worktree->is_current = 0;
@@ -141,7 +140,6 @@ static struct worktree *get_linked_worktree(const char *id)
worktree = xmalloc(sizeof(struct worktree));
worktree->path = strbuf_detach(&worktree_path, NULL);
worktree->id = xstrdup(id);
- worktree->is_bare = 0;
worktree->head_ref = NULL;
worktree->is_detached = is_detached;
worktree->is_current = 0;
diff --git a/worktree.h b/worktree.h
index 90e1311..04a75e8 100644
--- a/worktree.h
+++ b/worktree.h
@@ -8,7 +8,6 @@ struct worktree {
char *lock_reason; /* internal use */
unsigned char head_sha1[20];
int is_detached;
- int is_bare;
int is_current;
int lock_reason_valid;
};
^ permalink raw reply related
* Re: Bug? git worktree fails with master on bare repo
From: Kevin Daudt @ 2016-10-09 6:50 UTC (permalink / raw)
To: Michael Tutty; +Cc: git
In-Reply-To: <CAOi_75+2SG2WYHBMQhfGj96eKsZ66niJzOevVGM5eJv-qqrVNg@mail.gmail.com>
On Sat, Oct 08, 2016 at 07:30:36PM -0500, Michael Tutty wrote:
> Hey all,
> I'm working on some server-side software to do a merge. By using git
> worktree it's possible to check out a given branch for a bare repo and
> merge another branch into it. It's very fast, even with large
> repositories.
>
> The only exception seems to be merging to master. When I do git
> worktree add /tmp/path/to/worktree master I get an error:
>
> [fatal: 'master' is already checked out at '/path/to/bare/repo']
>
> But this is clearly not true, git worktree list gives:
>
> [/path/to/bare/repo (bare)]
>
> ...and of course, there is no work tree at that path, just the bare
> repo files you'd expect.
A bare repo still has a HEAD, which by default points to
refs/heads/master. That's what's it complaining about.
So the question is, should there be an exception for the branch 'checked
out' on a bare reposity.
^ permalink raw reply
* A head scratcher, clone results in modified files (tested linux and cygwin) - .gitattributes file?
From: Jason Pyeron @ 2016-10-09 6:48 UTC (permalink / raw)
To: git
Does anyone have any ideas as to why this clone resulted in modified files and how to prevent it?
There is a .gitattributes in the tree, which says:
* text=auto
*.java text diff=java
*.html text diff=html
*.css text
*.js text
*.sql text
But even then the *.bin files full of non-ascii garbage are impacted?! But I cannot find a difference:
root@YYYYYYY /projects/commons-io
$ git cat-file -p 7c9cd59c8a00e0bd3f18da42b32cd40024ad1505 | hexdump -C
00000000 a9 fa bf e9 a4 6c a8 ca 0d 0a c1 63 c5 e9 a4 a4 |.....l.....c....|
00000010 a4 e5 0d 0a |....|
00000014
root@YYYYYYY /projects/commons-io
$ git cat-file -p 7c9cd59c8a00e0bd3f18da42b32cd40024ad1505 | sha1sum.exe
d69820e1282801ccd627e35fb213e8832949c6ac *-
root@YYYYYYY /projects/commons-io
$ hexdump.exe -C src/test/resources/test-file-x-windows-950.bin
00000000 a9 fa bf e9 a4 6c a8 ca 0d 0a c1 63 c5 e9 a4 a4 |.....l.....c....|
00000010 a4 e5 0d 0a |....|
00000014
root@YYYYYYY /projects/commons-io
$ sha1sum.exe src/test/resources/test-file-x-windows-950.bin
d69820e1282801ccd627e35fb213e8832949c6ac *src/test/resources/test-file-x-windows-950.bin
Deleting the .gitattributes and the checkout -- did not help. No luck deleting the file then restoring it either.
Not even git clone git://git.apache.org/commons-io.git --config core.attributesFile=/dev/null fixed it. Details below.
-Jason
Cygwin test:
root@YYYYYYY /projects
$ git clone git://git.apache.org/commons-io.git
Cloning into 'commons-io'...
remote: Counting objects: 21203, done.
remote: Compressing objects: 100% (3454/3454), done.
remote: Total 21203 (delta 10822), reused 21129 (delta 10794)
Receiving objects: 100% (21203/21203), 2.51 MiB | 607.00 KiB/s, done.
Resolving deltas: 100% (10822/10822), done.
Checking connectivity... done.
root@YYYYYYY /projects
$ cd commons-io/
root@YYYYYYY /projects/commons-io
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: src/main/java/org/apache/commons/io/serialization/package.html
modified: src/site/xdoc/upgradeto2_3.xml
modified: src/test/resources/org/apache/commons/io/FileUtilsTestDataCRLF.dat
modified: src/test/resources/test-file-gbk.bin
modified: src/test/resources/test-file-iso8859-1-shortlines-win-linebr.bin
modified: src/test/resources/test-file-utf8-win-linebr.bin
modified: src/test/resources/test-file-windows-31j.bin
modified: src/test/resources/test-file-x-windows-949.bin
modified: src/test/resources/test-file-x-windows-950.bin
no changes added to commit (use "git add" and/or "git commit -a")
root@YYYYYYY /projects/commons-io
$ git rev-parse HEAD
c5f2e40e7a8234fe48e08d451d3152ba58a03ac6
root@YYYYYYY /projects/commons-io
$ git version
git version 2.8.3
root@YYYYYYY /projects/commons-io
$ git config --list
user.email=jpyeron@pdinc.us
user.name=Jason Pyeron
credential.helper=cache --timeout=9999999999
push.default=simple
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.url=git://git.apache.org/commons-io.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
$ uname -a
CYGWIN_NT-6.1-WOW YYYYYYY 2.5.2(0.297/5/3) 2016-06-23 14:27 i686 Cygwin
root@YYYYYYY /projects/commons-io
$
Linux test:
root@XXXXXX /tmp
# git clone git://git.apache.org/commons-io.git
Cloning into 'commons-io'...
remote: Counting objects: 21203, done.
remote: Compressing objects: 100% (3454/3454), done.
remote: Total 21203 (delta 10822), reused 21129 (delta 10794)
Receiving objects: 100% (21203/21203), 2.51 MiB | 176 KiB/s, done.
Resolving deltas: 100% (10822/10822), done.
root@XXXXXX /tmp
# cd commons-io/
root@XXXXXX /tmp/commons-io
# git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: src/main/java/org/apache/commons/io/serialization/package.html
# modified: src/site/xdoc/upgradeto2_3.xml
# modified: src/test/resources/org/apache/commons/io/FileUtilsTestDataCRLF.dat
# modified: src/test/resources/test-file-gbk.bin
# modified: src/test/resources/test-file-iso8859-1-shortlines-win-linebr.bin
# modified: src/test/resources/test-file-utf8-win-linebr.bin
# modified: src/test/resources/test-file-windows-31j.bin
# modified: src/test/resources/test-file-x-windows-949.bin
# modified: src/test/resources/test-file-x-windows-950.bin
#
no changes added to commit (use "git add" and/or "git commit -a")
root@XXXXXX /tmp/commons-io
# git rev-parse HEAD
c5f2e40e7a8234fe48e08d451d3152ba58a03ac6
root@XXXXXX /tmp/commons-io
# git version
git version 1.7.9.6
root@XXXXXX /tmp/commons-io
# git config --list
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git://git.apache.org/commons-io.git
branch.master.remote=origin
branch.master.merge=refs/heads/master
root@XXXXXX /tmp/commons-io
# uname -a
Linux XXXXXX.internal.pdinc.us 2.6.9-103.ELsmp #1 SMP Fri Dec 9 04:43:08 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
root@XXXXXX /tmp/commons-io
#
^ permalink raw reply
* Re: %C(auto) not working as expected
From: René Scharfe @ 2016-10-09 6:47 UTC (permalink / raw)
To: Tom Hale, git
In-Reply-To: <cb81631e-9623-9020-f955-ec215b493a50@hale.ee>
Am 09.10.2016 um 07:43 schrieb Tom Hale:
> $ ~/repo/git/git --version
> git version 2.10.0.GIT
>
> The `git-log` man page says:
>
> `auto` alone (i.e. %C(auto)) will turn on auto coloring on the next
> placeholders until the color is switched again.
>
> In this example:
>
> http://i.imgur.com/y3yLxk7.png
>
> I turn on auto colouring for green, but it seems that this is not being
> respected when piped through `cat`.
>
> Am I misunderstanding the manual?
So this colors the ref name decoration and the short hash:
$ git log -n1 --format="%C(auto)%d %C(auto)%Cgreen%h"
And this only colors the short hash:
$ git log -n1 --format="%C(auto)%d %C(auto)%Cgreen%h" | cat
%C(auto) respects the color-related configuration settings; that's
mentioned on the man page for git log in the section on %C(...). You
probably have color.ui=auto or color.diff=auto in your config, which
means that output to terminals is to be colored, but output to files and
pipes isn't. You could override that setting e.g. by adding the command
line option --color=always.
%Cgreen emits color codes unconditionally. %C(auto,green) would respect
the config settings.
Your second %C(auto) has no effect because it is overridden by the
immediately following %Cgreen.
You may want to add a %Creset at the end to avoid colors bleeding out
over the end of the line. You can see that happening e.g. with:
$ git log -n3 --format="normal %C(green)green" | cat
Without cat bash seems to add a reset automatically.
René
^ permalink raw reply
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
From: Jeff King @ 2016-10-09 6:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Duy Nguyen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.20.1610081034430.35196@virtualbox>
On Sat, Oct 08, 2016 at 10:36:13AM +0200, Johannes Schindelin wrote:
> > > Maybe it's time to aim for
> > >
> > > git config alias.d2u.shell \
> > > 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> > > git config alias.d2u.cdup false
> > > git d2u *.c # yada!
> >
> > That would be nice. It would also allow "alias.foo_bar.shell"; right now
> > "alias.foo_bar" is forbidden because of the config syntax, which does
> > not allow underscores outside of the "subsection" name.
>
> So what about this?
>
> [alias]
> d2u = !dos2unix
> [alias "d2u"]
> shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> exec = C:/cygwin64/bin/dos2unix.exe
>
> You introduce all kinds of ambiguities here that did not exist before...
If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
then yes, I think that's an unavoidable part of the transition. IMHO,
the new should take precedence over the old, and people will gradually
move from one to the other.
If you mean the ambiguity between alias.X.shell and alias.X.exec in your
example, the problem is that you have keys with overlapping meanings.
One solution is "don't do that" (so have a key like "cmd", and another
to select "shell or git-cmd", etc). Another is to define some rule, like
"last one wins" (so "exec" overrides "shell" in your example).
I'd prefer the "don't do that" path. The config you showed is
nonsensical, and it doesn't really matter that much how we behave. But
it is better still if we have a config scheme that makes it hard to
write nonsensical things in the first place.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
From: Jeff King @ 2016-10-09 6:08 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Duy Nguyen, Junio C Hamano, Git Mailing List
In-Reply-To: <20161009060149.voqjoiltqi6jub7g@sigill.intra.peff.net>
On Sun, Oct 09, 2016 at 02:01:49AM -0400, Jeff King wrote:
> > So what about this?
> >
> > [alias]
> > d2u = !dos2unix
> > [alias "d2u"]
> > shell = 'f() { git ls-files "$@" | xargs dos2unix; }; f'
> > exec = C:/cygwin64/bin/dos2unix.exe
> >
> > You introduce all kinds of ambiguities here that did not exist before...
>
> If you mean ambiguity between the old "alias.X" and the new "alias.X.*",
> then yes, I think that's an unavoidable part of the transition. IMHO,
> the new should take precedence over the old, and people will gradually
> move from one to the other.
>
> If you mean the ambiguity between alias.X.shell and alias.X.exec in your
> example, the problem is that you have keys with overlapping meanings.
> One solution is "don't do that" (so have a key like "cmd", and another
> to select "shell or git-cmd", etc). Another is to define some rule, like
> "last one wins" (so "exec" overrides "shell" in your example).
>
> I'd prefer the "don't do that" path. The config you showed is
> nonsensical, and it doesn't really matter that much how we behave. But
> it is better still if we have a config scheme that makes it hard to
> write nonsensical things in the first place.
Just to be clear on my "don't do that", I don't mean "the user should
not do that", but "do not design a config scheme with keys that have
overlapping meanings".
-Peff
^ permalink raw reply
* %C(auto) not working as expected
From: Tom Hale @ 2016-10-09 5:43 UTC (permalink / raw)
To: git
$ ~/repo/git/git --version
git version 2.10.0.GIT
The `git-log` man page says:
`auto` alone (i.e. %C(auto)) will turn on auto coloring on the next
placeholders until the color is switched again.
In this example:
http://i.imgur.com/y3yLxk7.png
I turn on auto colouring for green, but it seems that this is not being
respected when piped through `cat`.
Am I misunderstanding the manual?
--
Tom Hale
^ permalink raw reply
* Re: [PATCH v10 14/14] contrib/long-running-filter: add long running filter example
From: Torsten Bögershausen @ 2016-10-09 5:42 UTC (permalink / raw)
To: larsxschneider, git; +Cc: gitster, jnareb, peff
In-Reply-To: <20161008112530.15506-15-larsxschneider@gmail.com>
On 08.10.16 13:25, larsxschneider@gmail.com wrote:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> Add a simple pass-thru filter as example implementation for the Git
> filter protocol version 2. See Documentation/gitattributes.txt, section
> "Filter Protocol" for more info.
>
Nothing wrong with code in contrib.
I may have missed parts of the discussion, was there a good reason to
drop the test case completely?
>When adding a new feature, make sure that you have new tests to show
>the feature triggers the new behavior when it should, and to show the
>feature does not trigger when it shouldn't. After any code change, make
>sure that the entire test suite passes.
Or is there a plan to add them later ?
^ permalink raw reply
* Re: [PATCH v10 13/14] convert: add filter.<driver>.process option
From: Torsten Bögershausen @ 2016-10-09 5:32 UTC (permalink / raw)
To: Jakub Narębski, Lars Schneider, git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <e09a63ee-dad2-a8fb-e47f-0559d9507e1c@gmail.com>
On 09.10.16 01:06, Jakub Narębski wrote:
>> +------------------------
>> > +packet: git< status=abort
>> > +packet: git< 0000
>> > +------------------------
>> > +
>> > +After the filter has processed a blob it is expected to wait for
>> > +the next "key=value" list containing a command. Git will close
>> > +the command pipe on exit. The filter is expected to detect EOF
>> > +and exit gracefully on its own.
> Any "kill filter" solutions should probably be put here. I guess
> that filter exiting means EOF on its standard output when read
> by Git command, isn't it?
>
Isn't it that Git closes the command pipe, then filter sees EOF on it's stdin
and does a graceful exit.
^ permalink raw reply
* Bug? git worktree fails with master on bare repo
From: Michael Tutty @ 2016-10-09 0:30 UTC (permalink / raw)
To: git
Hey all,
I'm working on some server-side software to do a merge. By using git
worktree it's possible to check out a given branch for a bare repo and
merge another branch into it. It's very fast, even with large
repositories.
The only exception seems to be merging to master. When I do git
worktree add /tmp/path/to/worktree master I get an error:
[fatal: 'master' is already checked out at '/path/to/bare/repo']
But this is clearly not true, git worktree list gives:
[/path/to/bare/repo (bare)]
...and of course, there is no work tree at that path, just the bare
repo files you'd expect.
^ permalink raw reply
* Re: [PATCH v10 13/14] convert: add filter.<driver>.process option
From: Jakub Narębski @ 2016-10-08 23:06 UTC (permalink / raw)
To: Lars Schneider, git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <20161008112530.15506-14-larsxschneider@gmail.com>
Part 1 of review, starting with the protocol v2 itself.
W dniu 08.10.2016 o 13:25, larsxschneider@gmail.com pisze:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> Git's clean/smudge mechanism invokes an external filter process for
> every single blob that is affected by a filter. If Git filters a lot of
> blobs then the startup time of the external filter processes can become
> a significant part of the overall Git execution time.
>
> In a preliminary performance test this developer used a clean/smudge
> filter written in golang to filter 12,000 files. This process took 364s
> with the existing filter mechanism and 5s with the new mechanism. See
> details here: https://github.com/github/git-lfs/pull/1382
>
> This patch adds the `filter.<driver>.process` string option which, if
> used, keeps the external filter process running and processes all blobs
> with the packet format (pkt-line) based protocol over standard input and
> standard output. The full protocol is explained in detail in
> `Documentation/gitattributes.txt`.
>
> A few key decisions:
>
> * The long running filter process is referred to as filter protocol
> version 2 because the existing single shot filter invocation is
> considered version 1.
> * Git sends a welcome message and expects a response right after the
> external filter process has started. This ensures that Git will not
> hang if a version 1 filter is incorrectly used with the
> filter.<driver>.process option for version 2 filters. In addition,
> Git can detect this kind of error and warn the user.
> * The status of a filter operation (e.g. "success" or "error) is set
> before the actual response and (if necessary!) re-set after the
> response. The advantage of this two step status response is that if
> the filter detects an error early, then the filter can communicate
> this and Git does not even need to create structures to read the
> response.
> * All status responses are pkt-line lists terminated with a flush
> packet. This allows us to send other status fields with the same
> protocol in the future.
Looks good to me.
>
> Helped-by: Martin-Louis Bright <mlbright@gmail.com>
> Reviewed-by: Jakub Narebski <jnareb@gmail.com>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/gitattributes.txt | 157 +++++++++++++-
> convert.c | 297 +++++++++++++++++++++++++-
> t/t0021-conversion.sh | 447 +++++++++++++++++++++++++++++++++++++++-
> t/t0021/rot13-filter.pl | 191 +++++++++++++++++
> 4 files changed, 1082 insertions(+), 10 deletions(-)
> create mode 100755 t/t0021/rot13-filter.pl
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 7aff940..5868f00 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -293,7 +293,13 @@ checkout, when the `smudge` command is specified, the command is
> fed the blob object from its standard input, and its standard
> output is used to update the worktree file. Similarly, the
> `clean` command is used to convert the contents of worktree file
> -upon checkin.
> +upon checkin. By default these commands process only a single
> +blob and terminate. If a long running `process` filter is used
> +in place of `clean` and/or `smudge` filters, then Git can process
> +all blobs with a single filter command invocation for the entire
> +life of a single Git command, for example `git add --all`. See
> +section below for the description of the protocol used to
> +communicate with a `process` filter.
I don't remember how this part looked like in previous versions
of this patch series, but "... is used in place of `clean` ..."
does not tell explicitly about the precedence of those
configuration variables. I think it should be stated explicitly
that `process` takes precedence over any `clean` and/or `smudge`
settings for the same `filter.<driver>` (regardless of whether
the long running `process` filter support "clean" and/or "smudge"
operations or not).
>
> One use of the content filtering is to massage the content into a shape
> that is more convenient for the platform, filesystem, and the user to use.
> @@ -373,6 +379,155 @@ not exist, or may have different contents. So, smudge and clean commands
> should not try to access the file on disk, but only act as filters on the
> content provided to them on standard input.
>
> +Long Running Filter Process
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +If the filter command (a string value) is defined via
> +`filter.<driver>.process` then Git can process all blobs with a
> +single filter invocation for the entire life of a single Git
> +command. This is achieved by using a packet format (pkt-line,
> +see technical/protocol-common.txt) based protocol over standard
> +input and standard output as follows. All packets, except for the
> +"*CONTENT" packets and the "0000" flush packet, are considered
> +text and therefore are terminated by a LF.
Maybe s/standard input and output/\& of filter process,/ (that is,
add "... of filter process," to the third sentence in the above
paragraph).
I guess what LF (line-feed character, "\n") is should be obvious
for anybody who will be reading this part. All right.
> +
> +Git starts the filter when it encounters the first file
> +that needs to be cleaned or smudged. After the filter started
> +Git sends a welcome message ("git-filter-client"), a list of
> +supported protocol version numbers, and a flush packet.
I guess there is no need to be more explicit in description here,
as the exact format should be obvious from the example below.
We could add that the list of supported protocol version numbers
is send as series of "version=<integer number>" text-packet
lines.
> Git expects
> +to read a welcome response message ("git-filter-server") and exactly
> +one protocol version number from the previously sent list. All further
> +communication will be based on the selected version. The remaining
> +protocol description below documents "version=2". Please note that
> +"version=42" in the example below does not exist and is only there
> +to illustrate how the protocol would look like with more than one
> +version.
> +
> +After the version negotiation Git sends a list of all capabilities that
> +it supports and a flush packet. Git expects to read a list of desired
> +capabilities, which must be a subset of the supported capabilities list,
> +and a flush packet as response:
> +------------------------
> +packet: git> git-filter-client
> +packet: git> version=2
> +packet: git> version=42
> +packet: git> 0000
> +packet: git< git-filter-server
> +packet: git< version=2
> +packet: git> clean=true
> +packet: git> smudge=true
> +packet: git> not-yet-invented=true
> +packet: git> 0000
> +packet: git< clean=true
> +packet: git< smudge=true
> +packet: git< 0000
WARNING: This example is different from description!!!
In example you have Git sending "git-filter-client" and list of supported
protocol versions, terminated with flush packet, then filter driver
process sends "git-filter-server", exactly one version, *AND* list of
supported capabilities in "<capability>=true" format, terminated with
flush packet.
In description above the example you have 4-part handshake, not 3-part;
the filter is described to send list of supported capabilities last
(a subset of what Git command supports). Moreover in the example in
previous version at least as far as v8 of this series, the response
from filter driver was fixed length list of two lines: magic string
"git-filter-server" and exactly one line with protocol version; this
part was *not* terminated with a flush packet (complicating code of
filter driver program a bit, I think).
I think this version of protocol is *better*, just the text needs to
be updated to match. I wanted to propose something like this in v9,...
By the way, now I look at it, the argument for using the
"<capability>=true" format instead of "capability=<capability>"
(or "supported-command=<capability>") is weak. The argument for
using "<variable>=<value>" to make it easier to implement parsing
is sound, but the argument for "<capability>=true" is weak.
The argument was that with "<capability>=true" one can simply
parse metadata into hash / dictionary / hashmap, and choose
response based on that. Hash / hashmap / associative array
needs different keys, so the reasoning went for "<capability>=true"
over "capability=<capability>"... but the filter process still
needs to handle lines with repeating keys, namely "version=<N>"
lines!
So the argument doesn't hold water IMVHO, and we can choose
version which reads better / is more natural.
> +------------------------
> +Supported filter capabilities in version 2 are "clean" and
> +"smudge".
I think it would be good to have something here separating the
handshake part of protocol from the description of the working
part. The latter loops over each file to be affected by given
filter driver; handshake is done only once per filter.
Maybe subsections?
> +
> +Afterwards Git sends a list of "key=value" pairs terminated with
> +a flush packet. The list will contain at least the filter command
> +(based on the supported capabilities) and the pathname of the file
> +to filter relative to the repository root. Right after these packets
I think you meant here "right after the flush packet", isn't it?
It would be more explicit.
> +Git sends the content split in zero or more pkt-line packets and a
> +flush packet to terminate content. Please note, that the filter
> +must not send any response before it received the content and the
> +final flush packet.
That's good to have this information in the documentation.
BTW. I hope that in the future this restriction could be lifted with
"stream" capability / option, by having Git read response from filter
driver in an asynchronous process, like for one-shot v1 filters.
But that is certainly for later. Let's polish this series and have
it accepted first.
> +------------------------
> +packet: git> command=smudge
> +packet: git> pathname=path/testfile.dat
> +packet: git> 0000
> +packet: git> CONTENT
> +packet: git> 0000
> +------------------------
> +
> +The filter is expected to respond with a list of "key=value" pairs
> +terminated with a flush packet.
I wonder if we could be more explicit that it is about "status"
response. But I don't have good idea how to improve this sentence;
not that it is really needed, I don't think.
> If the filter does not experience
> +problems then the list must contain a "success" status. Right after
> +these packets the filter is expected to send the content in zero
> +or more pkt-line packets and a flush packet at the end.
Perhaps "terminating it with a flush packet"? But it is quite all
right as it is now.
> Finally, a
> +second list of "key=value" pairs terminated with a flush packet
> +is expected. The filter can change the status in the second list.
I would add here, to be more explicit:
This second list of "key=value" pairs may be empty, and usually
would be if there is nothing wrong with response or filter; the
terminating flush packet must be here regardless.
Or something like that. The above proposal could be certainly
improved.
> +------------------------
> +packet: git< status=success
> +packet: git< 0000
> +packet: git< SMUDGED_CONTENT
> +packet: git< 0000
> +packet: git< 0000 # empty list, keep "status=success" unchanged!
All right, looks good. Is this exclamation mark "!" necessary / wanted?
> +------------------------
> +
> +If the result content is empty then the filter is expected to respond
> +with a "success" status and an empty list.
Actually, it is empty content, not empty list; that is response (filter
output) composed entirely of flush packet.
Sidenote: I first thought that "empty list" here was about the post-content
information, which may be empty, and for empty contents it would almost
certainly be empty list - there is nothing I think that can change status
of filter...
> +------------------------
> +packet: git< status=success
> +packet: git< 0000
> +packet: git< 0000 # empty content!
> +packet: git< 0000 # empty list, keep "status=success" unchanged!
> +------------------------
> +
> +In case the filter cannot or does not want to process the content,
> +it is expected to respond with an "error" status. Depending on the
> +`filter.<driver>.required` flag Git will interpret that as error
> +but it will not stop or restart the filter process.
I think those two parts of last sentence: the part of 'required' flag,
and the part about restarting process would be better either split,
or their order reversed: first, tell that Git would not restart filter;
second, that it would continue with next file without 'required' flag,
and error-out if filter has 'required' flag. Though perhaps this should
be known at this point of documentation, and doesn't need repeating...
Ugh. Well, it's quite good as it is now.
> +------------------------
> +packet: git< status=error
> +packet: git< 0000
> +------------------------
> +
> +If the filter experiences an error during processing, then it can
> +send the status "error" after the content was (partially or
> +completely) sent. Depending on the `filter.<driver>.required` flag
> +Git will interpret that as error but it will not stop or restart the
> +filter process.
Errr... this is literal repetition. You need to decide whether to
put it before example, or after example. Or maybe split it.
> +------------------------
> +packet: git< status=success
> +packet: git< 0000
> +packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT
> +packet: git< 0000
> +packet: git< status=error
> +packet: git< 0000
> +------------------------
> +
> +If the filter dies during the communication or does not adhere to
> +the protocol then Git will stop the filter process and restart it
> +with the next file that needs to be processed. Depending on the
> +`filter.<driver>.required` flag Git will interpret that as error.
Uhh... until now the order was explanation, then example. From the
duplicated description above, it is now first example, then
description. Consistency would be good.
> +
> +The error handling for all cases above mimic the behavior of
> +the `filter.<driver>.clean` / `filter.<driver>.smudge` error
> +handling.
You have "error handling" repeated here.
> +
> +In case the filter cannot or does not want to process the content
> +as well as any future content for the lifetime of the Git process,
> +it is expected to respond with an "abort" status at any point in
> +the protocol. Depending on the `filter.<driver>.required` flag Git
> +will interpret that as error for the content as well as any future
> +content for the lifetime of the Git process but it will not stop or
> +restart the filter process.
Here the order, first about `required` then without, looks all right
to me: the result wrt process is the same, only the error or not
changes.
And here we have description first, example second.
> +------------------------
> +packet: git< status=abort
> +packet: git< 0000
> +------------------------
> +
> +After the filter has processed a blob it is expected to wait for
> +the next "key=value" list containing a command. Git will close
> +the command pipe on exit. The filter is expected to detect EOF
> +and exit gracefully on its own.
Any "kill filter" solutions should probably be put here. I guess
that filter exiting means EOF on its standard output when read
by Git command, isn't it?
> +
> +If you develop your own long running filter
> +process then the `GIT_TRACE_PACKET` environment variables can be
> +very helpful for debugging (see linkgit:git[1]).
s/environment variables/environment variable/ - there is only
one GIT_TRACE_PACKET. Unless you wanted to write about GIT_TRACE?
> +
> +If a `filter.<driver>.process` command is configured then it
> +always takes precedence over a configured `filter.<driver>.clean`
> +or `filter.<driver>.smudge` command.
Ah, it is here! I think it would be better to put it upfront; you
don't need information about the protocol to *use* the existing
filter, but you need this info.
Or maybe we can repeat this information.
> +
> +Please note that you cannot use an existing `filter.<driver>.clean`
> +or `filter.<driver>.smudge` command with `filter.<driver>.process`
> +because the former two use a different inter process communication
> +protocol than the latter one.
I'm not sure where this should be (but it is needed)
> +
> +
> Interaction between checkin/checkout attributes
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--
Jakub Narębski
^ permalink raw reply
* Re: Feature request: use relative path in worktree config files
From: Stéphane Klein @ 2016-10-08 19:54 UTC (permalink / raw)
To: git
In-Reply-To: <CADKxhpe3S4L9CPV9yxh2yhrtJMa9wyZAPC45u_S=RiuzY1Xrkg@mail.gmail.com>
I've write a small tool in Golang to fix this issue:
https://github.com/harobed/fix-git-worktree
2016-10-08 11:35 GMT+02:00 Stéphane Klein <contact@stephane-klein.info>:
> Hi,
>
> "git worktree add" write absolute path in ".git/gitdir"
>
> The code source is here
> https://git.kernel.org/cgit/git/git.git/tree/builtin/worktree.c?h=v2.10.1#n256
>
> Is it possible to use relative path in this config files:
>
> * [main_worktree]/.git/worktrees/[worktree_foobar]/gitdir
> * [worktree_foobar]/.git
>
> Why:
>
> 1. I configure worktree on my host
> 2. next I use this git working copy in Docker with volume share
> 3. next I've some git error in Docker because config files use absolute path
>
> Best regards,
> Stéphane
> --
> Stéphane Klein <contact@stephane-klein.info>
> blog: http://stephane-klein.info
> cv : http://cv.stephane-klein.info
> Twitter: http://twitter.com/klein_stephane
--
Stéphane Klein <contact@stephane-klein.info>
blog: http://stephane-klein.info
cv : http://cv.stephane-klein.info
Twitter: http://twitter.com/klein_stephane
^ permalink raw reply
* [PATCH] use strbuf_add_unique_abbrev() for adding short hashes, part 3
From: René Scharfe @ 2016-10-08 15:38 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano, Jeff King
Call strbuf_add_unique_abbrev() to add abbreviated hashes to strbufs
instead of taking detours through find_unique_abbrev() and its static
buffer. This is shorter in most cases and a bit more efficient.
The changes here are not easily handled by a semantic patch because
they involve removing temporary variables and deconstructing format
strings for strbuf_addf().
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
merge-recursive.c | 6 +++---
pretty.c | 12 +++++-------
submodule.c | 7 +++----
wt-status.c | 10 ++++------
4 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 5200d5c..9041c2f 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -202,9 +202,9 @@ static void output_commit_title(struct merge_options *o, struct commit *commit)
strbuf_addf(&o->obuf, "virtual %s\n",
merge_remote_util(commit)->name);
else {
- strbuf_addf(&o->obuf, "%s ",
- find_unique_abbrev(commit->object.oid.hash,
- DEFAULT_ABBREV));
+ strbuf_add_unique_abbrev(&o->obuf, commit->object.oid.hash,
+ DEFAULT_ABBREV);
+ strbuf_addch(&o->obuf, ' ');
if (parse_commit(commit) != 0)
strbuf_addstr(&o->obuf, _("(bad commit)\n"));
else {
diff --git a/pretty.c b/pretty.c
index 25efbca..0c31495 100644
--- a/pretty.c
+++ b/pretty.c
@@ -544,15 +544,13 @@ static void add_merge_info(const struct pretty_print_context *pp,
strbuf_addstr(sb, "Merge:");
while (parent) {
- struct commit *p = parent->item;
- const char *hex = NULL;
+ struct object_id *oidp = &parent->item->object.oid;
+ strbuf_addch(sb, ' ');
if (pp->abbrev)
- hex = find_unique_abbrev(p->object.oid.hash, pp->abbrev);
- if (!hex)
- hex = oid_to_hex(&p->object.oid);
+ strbuf_add_unique_abbrev(sb, oidp->hash, pp->abbrev);
+ else
+ strbuf_addstr(sb, oid_to_hex(oidp));
parent = parent->next;
-
- strbuf_addf(sb, " %s", hex);
}
strbuf_addch(sb, '\n');
}
diff --git a/submodule.c b/submodule.c
index 2de06a3..476f60b 100644
--- a/submodule.c
+++ b/submodule.c
@@ -392,10 +392,9 @@ static void show_submodule_header(FILE *f, const char *path,
}
output_header:
- strbuf_addf(&sb, "%s%sSubmodule %s %s..", line_prefix, meta, path,
- find_unique_abbrev(one->hash, DEFAULT_ABBREV));
- if (!fast_backward && !fast_forward)
- strbuf_addch(&sb, '.');
+ strbuf_addf(&sb, "%s%sSubmodule %s ", line_prefix, meta, path);
+ strbuf_add_unique_abbrev(&sb, one->hash, DEFAULT_ABBREV);
+ strbuf_addstr(&sb, (fast_backward || fast_forward) ? ".." : "...");
strbuf_add_unique_abbrev(&sb, two->hash, DEFAULT_ABBREV);
if (message)
strbuf_addf(&sb, " %s%s\n", message, reset);
diff --git a/wt-status.c b/wt-status.c
index 99d1b0a..ca5c45f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1110,7 +1110,6 @@ static void abbrev_sha1_in_line(struct strbuf *line)
split = strbuf_split_max(line, ' ', 3);
if (split[0] && split[1]) {
unsigned char sha1[20];
- const char *abbrev;
/*
* strbuf_split_max left a space. Trim it and re-add
@@ -1118,9 +1117,10 @@ static void abbrev_sha1_in_line(struct strbuf *line)
*/
strbuf_trim(split[1]);
if (!get_sha1(split[1]->buf, sha1)) {
- abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
strbuf_reset(split[1]);
- strbuf_addf(split[1], "%s ", abbrev);
+ strbuf_add_unique_abbrev(split[1], sha1,
+ DEFAULT_ABBREV);
+ strbuf_addch(split[1], ' ');
strbuf_reset(line);
for (i = 0; split[i]; i++)
strbuf_addbuf(line, split[i]);
@@ -1343,10 +1343,8 @@ static char *get_branch(const struct worktree *wt, const char *path)
else if (starts_with(sb.buf, "refs/"))
;
else if (!get_sha1_hex(sb.buf, sha1)) {
- const char *abbrev;
- abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
strbuf_reset(&sb);
- strbuf_addstr(&sb, abbrev);
+ strbuf_add_unique_abbrev(&sb, sha1, DEFAULT_ABBREV);
} else if (!strcmp(sb.buf, "detached HEAD")) /* rebase */
goto got_nothing;
else /* bisect */
--
2.10.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox