abbrev-ref doe not need no revision.
$ git symbolic-ref --short HEAD
notyet
Are you trying to say that the result of 'rev-parse --abbrev-ref HEAD'
is suboptimal and that of 'symbolic-ref --short HEAD' is OK?
--
Jakub Narębski
--
To unsubscribe from this list: send the li
ld conceivably be added to the trailer
tool, the latter can be done with appropriate regexp in
"git log --grep=...".
I wonder what would break if one used 'Name , Name '
as the author...
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git&quo
On 2015-06-19 at 06:25, Jeff King wrote:
> On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:
>> Author and committer include datetime in the contents of the
>> field, which is used by Git for heuristics limiting walk. Coauthor
>> would have the same date as
ship of
> the resulting commit.
Hmmm... I didn't think about the problem of attributing authorship
for squashed commits. Though here multiple 'author' headers, or
multiline 'author' header would be a better match than 'coauthor'
header (which itself
W dniu 2015-06-19 o 19:58, Junio C Hamano pisze:
> Charles Bailey writes:
[...]
>> +if (!git_parse_ulong(arg, opt->value))
>> +return opterror(opt, "expects a numerical value",
>> flags);
>
> This used to be:
>
>> -die(_("unable to parse value '%s' f
On Fri, Jun 19, 2015 at 11:11 PM, Tuncer Ayaz wrote:
> On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote:
>> [This is sent from Thunderbird news, so it should be all right]
>
> This is fine, the other one was broken. Out of curiosity what's the
> difference betwee
lit the packfiles into 4.3G chunks".
>
> - counts, e.g. "show me the most recent 2k commits".
>
> - bandwidth, e.g. "limit the transfer to consume at most 2M bps".
>
> which is not limited to size, it is not a very good idea, either.
>
> OPT_SC
d the final conflict resolution that was recorded in the merge.
>
> Waiting for a reroll.
> ($gmane/256591).
Is it something that Atlassian uses as a differentiatior (instead
of sending patch upstream):
https://developer.atlassian.com/blog/2015/01/a-better-pull-request/
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tions for "log --count" tests that "rev-list
> --count" also doesn't have tests for.
>
> I would like to keep working on implementing "log --count", sharing
> code with rev-list where possible so they both are improved, unless
> you are saying you wo
e who use or have their own code in Gitweb?
Sent a reply to wrong (old) thread, sorry.
tl;dr - first can be applied unconditionally, others have slight
issues. Cgit implements something like this, though with limit
(only first directory path), and different UI - it looks useful
on https://git.kernel
On 2015-07-22, Tony Finch wrote:
> Jakub Narębski wrote:
>
> Thanks for the review!
>
>>> * tf/gitweb-project-listing (2015-03-19) 5 commits
>>> - gitweb: make category headings into links when they are directories
>>> - gitweb: optionally set project c
W dniu 2015-07-22 o 15:19, Tony Finch pisze:
> Jakub Narębski wrote:
>>
>> A question about implementation: why emptying $path_info in
>> evaluate_path_info()?
>
> That was for consistency with other parts of the subroutine which (mostly)
> remove items from the g
ost helpful.
One policy I can think of that may have use of checking if commit
is tagged is requiring some extra restrictions on the commit that
is being tagged, for example that the only file that it can touch
is version.h / VERSION-FILE, and no code changes at all.
--
Jakub Narębski
--
To unsubscri
On 2016-06-27, Alex Riesen wrote:
> This adds a FILENAMES environment variable, which contains the repository
> pathnames of all selected files the list.
> The variable contains the names separated by spaces.
Why not separate filenames with end-of-line character (LF)? It would still
be broken for
W dniu 2016-06-27 o 15:23, Alex Riesen pisze:
> It is very confusing that the file, diff of which is displayed and which is
> marked as selected in the file list, is not, in fact, selected. I.e. the array
> of selected files does not contain an entry for it.
>
> Fixing this also improves the use o
On 27 June 2016 at 19:53, Junio C Hamano wrote:
> Jakub Narębski writes:
>
>> On 2016-06-27, Alex Riesen wrote:
>>
>>> This adds a FILENAMES environment variable, which contains the repository
>>> pathnames of all selected files the list.
>>> The va
rences
(well, it also ensures that delta chain doesn't gets too long).
HTH
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
place to put that
information in. Nowadays we have gitcli(7) manual page, but perhaps
it would be better to create a separate manpage for issues related
to pathspec handling (of which ":/" is only one part)... but then
what should it be named?
What do you think?
--
Jakub Narębski
|||
Nowadays there is also [compressed] bitmap index (if enabled), though I am
not sure if it is yet used to speed-up reachability queries
http://githubengineering.com/counting-objects/
https://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/Scaling%20Up%20JGit%20-%20Eclips
W dniu 2016-06-29 o 21:51, Junio C Hamano pisze:
> On Wed, Jun 29, 2016 at 12:47 PM, Jakub Narębski wrote:
>> I have noticed that the magic pathspec ":/" is described only in RelNotes
>> for revision 1.7.6:
>> |I think the reason might be that there was no good plac
they could probably be made so without too much effort. You wouldn't
> have ready-made generation numbers for commits since the last full
> repack, but you can compute them incrementally based on what you do have
> at a cost linear to the unpacked commits (this is the same for bitmaps)
W dniu 2016-06-29 o 23:28, Junio C Hamano pisze:
> Jakub Narębski writes:
>
>> But I think it is not the best place to keep this documentation.
>
> All true. In case it was not obvious, I didn't mean to say "Here
> you find the information, shut up." It wa
W dniu 2016-06-30 o 00:00, Jeff King pisze:
> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>
>>> So this is the ideal case for generation numbers (the worst cases are
>>> when the things you are looking for are in branchy, close history where
>>
simply use "git cherry-pick -x", which will
> write the sha1 of the original commit into the cherry-picked commit
> message. You can then use that to correlate directly.
"git log --grep=" would help there (or even match the specific
message that "git cherry-pick
W dniu 2016-06-30 o 20:12, Linus Torvalds pisze:
> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
>>
>> P.S. Having Git ensure that committerdate (as an epoch) is greater
>> than committerdates of its parents at the commit creation time (with
>> providing warni
it
> your repository (though again, it is unclear in such a case if the
> commit is broken or the clock of the checker).
Well, one heuristics is that if commits in the future, and/or commits
with committerdate out of order have all the same committer, then
probably commits are broken. Another "heur
W dniu 2016-07-01 o 08:54, Jeff King pisze:
> On Thu, Jun 30, 2016 at 12:30:31PM +0200, Jakub Narębski wrote:
>
>>> This is one of the open questions. My older patches turned them off when
>>> replacements and grafts are in effect.
>>
>> Well, if you store th
obal-apropos"
example and search sources... but then we would need to follow inclusions
at least for it to be useful. We could search HTML version of manpages...
but then we would have to strip formatting codes before performing a search.
> I don't think those are problems that _git_ should necessarily be
> solving, though. It's a general problem for manpages. And there may be
> better "man" implementations than I'm used to (or even options or
> configuration I don't know about).
I wonder what other version control systems do, like Mercurial, or
Subversion, or Veracity with providing access to their reference docs...
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
for forced non-fast-forward updates).
It would be nice to have documented here also other formats,
like "[new branch]", and/or mention that if the is not usable
for `git log` it is put in brackets [].
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe
== 0x5D /* ']' */){
>>> || ci > name += advance();
>>> || ci >name += advance();
>>> | c >}
>
> Likewise, this is showing that a "non-human not knowing } is a closing
> and { is an opening token".
If not encoding heuristic that [,{,( are opening token, and ],},) are
closing token into heuristics, perhaps length of the line could be
a consideration about where to start a diff chunk?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 2016-07-04 o 17:17, Duy Nguyen pisze:
> On Mon, Jul 4, 2016 at 4:07 PM, Jakub Narębski wrote:
>> W dniu 2016-06-26 o 07:58, Nguyễn Thái Ngọc Duy pisze:
>>> +summary::
>>> + For a successfully fetched ref, the summary shows the old and new
>>> +
or in reachability of one of ancestors of B?) and in finding merge
bases (intersection of reachabilities of A and B, or their ancestors...
or something like that, I think, probably more complicated).
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
ve_cache[pos]))
This has an additional improvement (not mentioned in the commit
message, but probably not worth it) in that it shows which file
was not found, not only that there was some bug, isn't it?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "u
hind the scene, GitHub would fork a repository, edit file and create
a commit, then create a pull request. Very easy for one-off fixes, assuming
that you have a GitHub account.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
obody noticed this (callee just don't care how the
parameter is named).
Instead of nebulous "fairness" (i.e., be unfair in other direction),
in my opinion it would be better to simply fix the issue, be consistent
and use common terminology.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o they
use and which tools (maybe there is some great unknown tool there?),
where they go to find help about Git.
What types of questions should there be in this year survey?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
Hello Johannes,
On 8 July 2016 at 09:17, Johannes Schindelin wrote:
> Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
> almost 11 years already, we used a male form to describe "the other
> tree".
>
> While most likely unintended, this gave the erroneous impression as if
e) a single commit range, only revision.
It is actually
^! == ( --not ^@ )
that is, reachable from but not from any of its parents.
Parentheses here denote that `--not` does not affect the rest of
rev-like parameters.
Hope that helps
--
Jakub Narębski
--
To unsubscribe from this list: send the l
W dniu 2016-06-30 o 00:00, Jeff King pisze:
> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still
>> limited to object counting?
>
> At GitHub we are using them for --contains analysis, al
s -- as you can find on the
bottom of the page... though it is not obvious.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ting _filename_ to 32GB is a reasonable
assumption, for forever...
>> > Git writes --> 4 byte content length
>> > Git writes --> content string
...while limiting file _content_ to 32GB might not be
future-proof enough.
;-)
--
Jakub Narębski
--
To unsubscribe from this li
the loop.
done
Then pass the output to some histogramming or statistics tool... or use
a spreadsheet. Note the results are in seconds.
HTH (not checked much)
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
out
that for technical implementation reasons it is not possible to have
"(initial) (detached)".
Just something I was wondering about, no need for any change...
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
?? dir1/\n" >>expected &&
> + printf "?? expected\n" >>expected &&
> + printf "?? file_x\n" >>expected &&
> + printf "?? file_y\n" >>expected &&
> + printf "?? file_z\n" >>expected
On 20 July 2016 at 17:42, Jeff Hostetler wrote:
> On 07/20/2016 11:29 AM, Jakub Narębski wrote:
>> W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
>>
>>> +Porcelain Format Version 2
>>> +~~
>>> +
>>> +
>>> +I
On 20 July 2016 at 17:47, Jeff Hostetler wrote:
> On 07/20/2016 11:30 AM, Jakub Narębski wrote:
>> W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
>>>
>>> +test_expect_success pre_initial_commit_0 '
>>> + printf "## branch: (initial) master\n
have a way to check where the value didn't came from,
because for example error in the include condition?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 2016-07-20 o 15:56, Jakub Narębski pisze:
> W dniu 2016-07-20 o 10:05, Ernesto Maserati pisze:
>
>> I assume that feature branches are not frequently enough merged into
>> master. Because of that we discover bugs later than we could with a more
>> continuous code i
le present in revision
given by the 'hb' parameter?
See e.g. http://repo.or.cz/?p=git/zerocommit.git;a=tree;hb=master;f=t
> Are these arguments documented somewhere? What is the recommended way to
> construct a URL like I need?
Well, they are not described in the documentation
On 20 July 2016 at 23:35, CLOSE Dave wrote:
> Thanks, Jakub, for the quick response.
>
> On 07/20/16 02:20 PM, Jakub Narębski wrote:
>
>>> If I replace the hb=SHA argument with hb=HEAD, the URL still works. But
>>> I have no idea what I can use to replace the h=SHA
simple
merging of topic branches into mainline), the shortest time from
creating a branch to merging it in git.git is 7 seconds (probably
it was a bugfix-type of a topic branch), the longest if I did it
correctly is slightly less than 4 years (???): 641830c.
--
Jakub Narębski
--
To unsubscribe
ooks are a thing!
Or you can use third-party tools with support for such cases, such
as Gitolite. VREFs allow to restrict pushes by the filename, see
http://gitolite.com/gitolite/vref.html#NAME (though I am not sure
if it checks only the end state, or if it checks every commit
that was pushed)
die "not enough to read";
I know it's only a test script (well, a part of one), but we would probably
want to have more information in the case of a real filter.
> +}
> +print $debug " [OK] -- ";
> +}
> +
> +if (
W dniu 2016-07-22 o 21:51, Jeff King pisze:
> The "raw" format shows a Unix epoch timestamp, but with a
> timezone tacked on. The timestamp is not _in_ that zone, but
> it is extra information about the time (by default, the zone
> the author was in).
I would say that "Unix time" (name according
W dniu 2016-07-20 o 21:24, CLOSE Dave pisze:
> I'm trying to create a URL that will always refer to the latest version
> of a file stored under Gerrit. gitweb access is available. The man page
> specification doesn't seem to work for me. Instead, I seem to need to
> put most of the information
says that it is Pro Git Reedited?
Have you tried submitting changes upstream?
Best,
--
Jakub Narębski
author of "Mastering Git"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ed and automated.
Do you use bitmap indices for speeding up fetches?
BTW. IMVHO the problem with dumb HTTP is the latency, not extra
bandwidth needed...
Best,
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
Re-added git mailing list
On 24 July 2016 at 17:57, Jon Forrest wrote:
> On 7/24/2016 2:00 AM, Jakub Narębski wrote:
>
>> I have not checked the book itself; it would be nice if it were
>> hosted somewhere, even if using GitHub Pages (per-project or
>> per-user).
>
&
W dniu 2016-07-24 o 19:34, Jon Forrest pisze:
> On 7/24/2016 10:19 AM, Jakub Narębski wrote:
>
>> As far as I can see you cannot view it online (without downloading).
>
> True. I changed the way the HTML file is generated so that it
> contains all the images downloading it
gt;
> Is such a thing to ridiculous to even consider? Is there a better way
> to achieve the same result
IMVHO it would require heavy surgery of Git for little benefit
(see the beginning of reply for alternate solutions).
--
Jakub Narębski
--
To unsubscribe from this list: send
W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
> On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
>> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
>>> From: Lars Schneider
>>
>> Nb. this line is only needed if you want author name and/or date
>>
W dniu 2016-07-24 o 21:20, Jon Forrest pisze:
> On 7/24/2016 11:46 AM, Jakub Narębski wrote:
>>
>> Another possibility is to set authordate and committerdate to some
>> specified time by the way of appropriate environment variables.
>
> That sounds like a great idea.
W dniu 2016-07-24 o 22:14, Jakub Narębski pisze:
> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>> I agree that the name is not ideal. "UseProtocol" as it is would be a
>> boolean.
>> I thought about "persistent" but this name wouldn't convey
W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:
> On 24/07/16 18:16, Lars Schneider wrote:
>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
>>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
[...]
This patch adds the filter..useProtocol option which, if enabled,
keeps the external fil
W dniu 2016-07-25 o 09:33, Johannes Schindelin pisze:
> Therefore "%s%n%+b" *might* do what you intended (I would not
> know, because that information was missing from the report).
Shouldn't it be "%s%n%n%-b" or "%s%n%-b"?
--
Jakub Narębski
--
To
t checkout".
All this is the information for end user, not scripts.
$ git branch -v -v
* gitweb-docs 4ebf58d [origin/master: ahead 1] gitweb(1): Document query
parameters
master08bb350 [origin/master] Sixth batch of topics for 2.10
$ git checkout
Your branch is ahead of &#
_PORCELAIN;
> + else if (!strcmp(arg, "v1"))
> + *value = STATUS_FORMAT_PORCELAIN;
> + else
> + die("unsupported porcelain version");
> +
> + return 0;
> +}
Presumably it is not something hard to find, but perhaps it
would be bet
W dniu 2016-07-25 o 21:25, Jeff Hostetler pisze:
> +Porcelain Format Version 2
> +~~
> +
> +Version 2 format adds more detailed information about the state of
> +the worktree and the changed items.
I think it should be "and changed items", but I am not a native speaker.
>
e, that is that if branch is not
new it prevents push (e.g. when is HEAD), or is it
covered by other tests?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 2016-07-25 o 22:32, Lars Schneider pisze:
> On 25 Jul 2016, at 01:22, Jakub Narębski wrote:
>> W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:
>>> On 24/07/16 18:16, Lars Schneider wrote:
>>>> It was a conscious decision to have the `filter` tal
W dniu 2016-07-25 o 22:16, Lars Schneider pisze:
>
> On 24 Jul 2016, at 23:30, Jakub Narębski wrote:
>
>> W dniu 2016-07-24 o 22:14, Jakub Narębski pisze:
>>> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>>
>>>> I agree that the name is no
W dniu 2016-07-25 o 22:09, Lars Schneider pisze:
> On 24 Jul 2016, at 22:14, Jakub Narębski wrote:
>> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>>> On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
>>>> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pis
W dniu 2016-07-26 o 20:47, Jeff King pisze:
> On Sat, Jul 23, 2016 at 12:15:37PM +0200, Jakub Narębski wrote:
>
>>> diff --git a/Documentation/rev-list-options.txt
>>> b/Documentation/rev-list-options.txt
>>> index 5d1de06..3ec75d4 100644
>>> --- a/Do
to easily test
if the supermodule works with and without its submodules present.
[...]
> If you switch a branch (or to any sha1), the submodule currently stays
> "as-is" and may be updated using "submodule update", which goes through
> the list of existing (checked out) submodules and checks them out to the
> sha1 pointed to by the superprojects gitlink.
Which might be simply a problem that submodule UI is not mature enough.
I would like to see automatic switch of submodule contents, if
configured so.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nd if anybody uses it,
but one might want to use different repositories (different
forks) for different branches, and thus different worktrees.
For example the 'next' branch might want to switch to X.Org,
because XFree86 is moribund, but keep the old repo for 'maint',
or something like that ;-)
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> Hi,
>
> thanks a lot for the extensive reviews. I tried to address all mentioned
> concerns and summarized them below. The most prominent changes since v1 are
> the following:
> * Git offers a number of filter
s easy to understand, though,
so the commit message style is not that important.
Perhaps "Git filter driver command with spaces"?
Well, nevermind; if you have a better idea, good. If not, it is
good enough, IMHO.
--
Jakub Narębski
--
To unsubscribe from this list: send the line &quo
W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> 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 be
W dniu 2016-07-28 o 09:16, Lars Schneider pisze:
>> On 27 Jul 2016, at 21:08, Jakub Narębski wrote:
>> W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
>>>
>>> thanks a lot for the extensive reviews. I tried to address all mentioned
>>> conce
W dniu 2016-07-28 o 20:22, Eric Sunshine pisze:
> On Thu, Jul 28, 2016 at 1:47 PM, Johannes Sixt wrote:
>> Interactive rebase uses 'wc -l' to write the current patch number
>> in a progress report. Some implementations of 'wc -l' produce spaces
>> before the number, leading to ugly output such as
W dniu 2016-07-28 o 18:56, Øyvind A. Holm pisze:
> On 28 July 2016 at 18:37, Junio C Hamano wrote:
>> Øyvind A. Holm writes:
>>> This is a script I created some weeks ago, and I've found it to be
>>> immensely useful. Here is a snippet from git-testadd --help:
>>>
>>> If you have lots of unrel
W dniu 2016-07-28 o 15:29, Jeff King pisze:
> On Thu, Jul 28, 2016 at 09:16:18AM +0200, Lars Schneider wrote:
>
>> But Peff ($gmane/299902), Duy, and Eric, seemed to prefer the pkt-line
>> solution (gmane is down - otherwise I would have given you the links).
>
> FWIW, I think there are arguments
W dniu 2016-07-28 o 18:27, Brian Henderson pisze:
> Hi, I've been working with Jeff King on this patch, but he encouraged me to
> email the list.
>
> I recently learned about the diff-highlight tool and find it very helpful,
> however, I frequently use the --graph option to git log which breaks th
style... convert.c is already big and gets only bigger
> with this patch (1720 lines). Would it make sense to add a new file
> "convert-pipe-protocol.c"
> or something for my additions?
I wonder if it would be possible to enhance existing functions, instead
of redoing them (a
W dniu 2016-07-29 o 19:35, Junio C Hamano pisze:
> Lars Schneider writes:
>
>> I think sending it upfront is nice for buffer allocations of big files
>> and it doesn't cost us anything to do it.
>
> While I do NOT think "total size upfront" MUST BE avoided at all costs,
> I do not think the abov
W dniu 2016-07-30 o 01:44, Lars Schneider pisze:
> On 30 Jul 2016, at 01:11, Jakub Narębski wrote:
>> I think the protocol should be either: + , or
>> + + , that is do not use flush
>> packet if size is known upfront -- it would be a second point
>> of truth
W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> set_packet_header() converts an integer to a 4 byte hex string. Make
> this function locally available so that other pkt-line functions can
> use it.
This description is not that clear that set_packet_header()
W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> Sometimes pkt-line data is already available in a buffer and it would
> be a waste of resources to write the packet using packet_write() which
> would copy the existing buffer into a strbuf before writing it.
>
W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> packet_flush() would die in case of a write error even though for some callers
> an error would be acceptable. Add packet_flush_gentle() which writes a
> pkt-line
> flush packet and returns `0` for success and
W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> The packet_trace() call is not ideal in format_packet() as we would print
Style; I think the following is more readable:
The packet_trace() call in format_packet() is not ideal, as we would...
> a trace whe
W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> According to LARGE_PACKET_MAX in pkt-line.h the maximal lenght of a
> pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and
> therefore the pkt-line data component must not exceed 65516 bytes.
s
W dniu 26.07.2016 o 23:11, Jeff Hostetler pisze:
> +Porcelain Format Version 2
> +~~
> +
> +Version 2 format adds more detailed information about the state of
> +the worktree and changed items.
> +
> +If `--branch` is given, a series of header lines are printed with
> +info
unnecessary in the commit
message).
I guess that "1.0.0&0.0.1" tags are something encountered in real
repositories, while "12" would be just something evil...
>
> Signed-off-by: Andreas Brauchli
Good catch!
Acked-by: Jakub Narębski
> ---
> gitweb/gitweb.p
"reject" or "error" packet.
packet: git< "" (flush packet)
packet: git< reject\n
Should there be a place for an error message, or would standard error
(stderr) be used for this?
> +
> +After the filter has processed a blob it is expected to wait for
> +the next command. A demo implementation can be found in
> +`t/t0021/rot13-filter.pl` located in the Git core repository.
It is actually in Git sources. Is it the best way to refer to
such files?
> +
> +If the filter supports the "shutdown" capability then Git will
> +send the "shutdown" command and wait until the filter answers
> +with "done". This gives the filter the opportunity to perform
> +cleanup tasks. Afterwards the filter is expected to exit.
> +
> +packet: git> shutdown\n
> +packet: git< done\n
> +
> +
> +If a filter..clean or filter..smudge command
> +is configured then these commands always take precedence over
> +a configured filter..process command.
All right; this is quite clear.
> +
> +Please note that you cannot use an existing filter..clean
> +or filter..smudge command as filter..process
> +command. As soon as Git would detect a file that needs to be
> +processed by this filter, it would stop responding.
This isn't.
P.S. I will comment about the implementation part in the next email.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
sn't `--reachable-commits` the same as existing `--ancestry-path`
option to `git log` and friends (I wonder if passing log options to
bisect, that is: `git bisect --ancestry-path ...` would work)?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git&
[Excuse me replying to myself, but there are a few things I forgot,
or realized only later]
W dniu 31.07.2016 o 00:05, Jakub Narębski pisze:
> W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes
W dniu 31.07.2016 o 16:32, Sylvain Garrigues pisze:
> Hello,
>
> It seems now with 2.9 you cannot use git subtree split —rejoin
> without —onto otherwise you get:
>fatal: refusing to merge unrelated histories
>
> I wish I could pass --allow-unrelated-histories but that doesn’t
> work.
>
> Ad
W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze:
[...]
> +Please note that you cannot use an existing filter..clean
> +or filter..smudge command as filter..process
> +command.
I think it would be more readable and easier to understand to write:
... you cannot use an existing ... comma
W dniu 31.07.2016 o 21:49, Lars Schneider pisze:
> On 31 Jul 2016, at 11:42, Jakub Narębski wrote:
>> W dniu 31.07.2016 o 00:05, Jakub Narębski pisze:
>>> W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze:
[...]
>>> I think it would be nice to have here at leas
t's only split on spaces right now. While I don't think
> there's any current case where spaces would be useful/desirable;
> I suppose a 3rd patch in this series could add support for using
> split_cmdline (from alias.c)...
Is there any pager that needs spaces in options-set en
1 - 100 of 501 matches
Mail list logo
