David Aguilar writes:
> This is a replacement patch for (previously) 3/3 that includes Junio's
> suggestions to fix the alignment for continuation lines and case bodies.
>
> The subsequent patch addresses the function definitions.
Looks good; thanks.
--
To unsubscribe from this list: send the li
Junio C Hamano writes:
> I am not yet sure if it makes sense to mix both the regular output
> and an error into the same buffer for the callers to process (your
> "reason 1)" above), and this looks like a wrong way to allow a
> caller that wants no output (your "reason 2)" above). A caller that
We prefer a space between the function name and the parentheses, and no
space inside the parentheses.
The opening "{" should also be on the same line.
Suggested-by: Junio C Hamano
Signed-off-by: David Aguilar
---
This says "v3" but this is actually a branch new patch that wasn't included
in the
Prefer "test" over "[ ... ]", use double-quotes around variables, break
long lines, and properly indent "case" statements.
Helped-by: Johannes Sixt
Helped-by: Junio C Hamano
Signed-off-by: David Aguilar
---
This is a replacement patch for (previously) 3/3 that includes Junio's
suggestions to fi
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
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
Vasco Almeida writes:
> + default:
> + error_msg = xstrfmt(_("bad config line %d in %s"),
> + cf->linenr, cf->name);
> + }
> +
> if (cf->die_on_error)
> - die(_("bad config line %d in %s %s"), cf->linenr,
> cf->origin_type,
Johannes Schindelin writes:
> Let's make sure that the same holds true when outputting the commit
> title: previously, we used several printf() statements to stdout and
> speculated that stdout's buffer is large enough to hold the entire
> commit title.
s/speculate/assume/; other than that looks
Johannes Schindelin writes:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index a16b150..66e93e0 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -2069,6 +2069,7 @@ int merge_recursive(struct merge_options *o,
> o->ancestor = "merged common ancestors";
> clean
Johannes Schindelin writes:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 311cfa4..a16b150 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -2078,6 +2078,8 @@ int merge_recursive(struct merge_options *o,
> commit_list_insert(h2, &(*result)->parents->nex
Johannes Schindelin writes:
> Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14),
> we already accumulate the output in a buffer. The idea was to avoid
> interfering with the progress output that goes to stderr, which is
> unbuffered, when we write to stdout, which is buffere
On Wed, Jul 27, 2016 at 02:28:32PM -0700, Junio C Hamano wrote:
> On Wed, Jul 27, 2016 at 2:13 PM, Jeff King wrote:
> > ... But two is that I've
> > wondered if we can do even better with a most-recently-used cache
> > instead of the last_pack_found hack. So I'm trying to implement and
> > measur
On Wed, Jul 27, 2016 at 2:37 PM, Junio C Hamano wrote:
>
>> + strbuf_vaddf(&o->obuf, err, params);
>> + error("%s", o->obuf.buf);
>> + strbuf_reset(&o->obuf);
>
> Sneaky ;-)
Just to avoid confusion, I am _fine_ with this "we happen to have
a strbuf that we know to be empty at this poi
Johannes Schindelin writes:
> The data structure passed to the recursive merge machinery has a feature
> where the caller can ask for the output to be buffered into a strbuf, by
> setting the field 'buffer_output'.
>
> Previously, we simply swallowed the buffered output when showing error
> messa
On Wed, Jul 27, 2016 at 2:13 PM, Jeff King wrote:
> ... But two is that I've
> wondered if we can do even better with a most-recently-used cache
> instead of the last_pack_found hack. So I'm trying to implement and
> measure that (both for this loop, and to see if it does better in
> find_pack_ent
On Tue, Jul 26, 2016 at 02:38:28PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I got side-tracked by adding a t/perf test to show off the improvement.
> > It's rather tricky to get right and takes a long time to run. I _think_
> > I have it now, but am waiting for results. :)
>
> Wel
Kirill Smelkov writes:
> > From: Kirill Smelkov
> Subject: [PATCH 1/2] pack-objects: Make sure use_bitmap_index is not active
> under
> --local or --honor-pack-keep
>
> Since 6b8fda2d (pack-objects: use bitmaps when packing objects) there
> are two codepaths in pack-objects: with & without usi
Jeff King writes:
> I do find this by itself a little hard to parse. Maybe:
>
> `--date=raw` shows the date as seconds since the epoch (1970-01-01
> 00:00:00 UTC), followed by a space, and then the timezone as an offset
> from UTC (a `+` or `-` with four digits; the first two are hours, and
On Wed, Jul 27, 2016 at 01:11:34PM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] date: clarify --date=raw description
>
> "... in the internal raw Git format `%s %z` format." was clunky in
> repeating "format" twice, and would not have helped those who do not
> know that these are st
On Mon, Jul 25, 2016 at 02:40:25PM -0400, Jeff King wrote:
> On Wed, Jul 13, 2016 at 01:52:17PM +0300, Kirill Smelkov wrote:
>
> > > So I think if you were to repeatedly "git repack -adb" over time, you
> > > would get worse and worse ordering as objects are added to the
> > > repository.
> >
> >
Jeff King writes:
> The second option you've shown here is much better, and I think this is
> worth fixing (and it should be in a new patch, and can go on top of the
> others).
>
> I'm not sure if it's worth calling out more clearly what the timezone
> means, since the epoch seconds are in UTC, a
W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
> Git filter with spaces (e.g. `filter.sh foo`) are hard to read in
> error messages. Quote them to improve the readability.
This is not something very important, but the above commit message
feels a bit clunky to me. The change is easy
Vasco Almeida writes:
> +
> + switch (cf->origin_type) {
> + case CONFIG_ORIGIN_BLOB:
> + error_msg = xstrfmt(_("bad config line %d in blob %s"),
> + cf->linenr, cf->name);
> + break;
> + case CONFIG_ORIGIN_FILE:
> +
On Wed, Jul 27, 2016 at 12:49:40PM -0700, Junio C Hamano wrote:
> > @@ -746,7 +746,10 @@ format, often found in email messages.
> > +
> > `--date=short` shows only the date, but not the time, in `-MM-DD`
> > format.
> > +
> > -`--date=raw` shows the date in the internal raw Git format `%s
On Wed, Jul 27, 2016 at 12:28:14PM -0700, Junio C Hamano wrote:
> > Some of the tests actually care quite a bit about
> > whitespace, but none of them do so at the beginning of the
> > line (because they things like qz_to_tab_space to avoid
>
> I'll do s/they things/they use things/ here while qu
Jeff King writes:
> +e.g. ``2 hours ago''. The `-local` option has no effect for
> +`--date=relative`.
Good.
> @@ -746,7 +746,10 @@ format, often found in email messages.
> +
> `--date=short` shows only the date, but not the time, in `-MM-DD` format.
> +
> -`--date=raw` shows the date in
Vasco Almeida writes:
> A Ter, 26-07-2016 às 09:57 -0700, Junio C Hamano escreveu:
>> Vasco Almeida writes:
>>
>> >
>> > + strbuf_add_commented_lines(&buf, "\n",
>> > strlen("\n"));
>> > + strbuf_add_commented_lines(&buf, _(note_template),
>> > strlen(_(note_template)));
>> >
Jeff King writes:
> Our usual style in the test scripts is to indent here
> documents with tabs, and use "<<-" to strip the tabs. The
> result is easier to read.
>
> This old test script did not do so in its inception, and
> further tests added onto it followed the local style. Let's
> bring it i
On Wed, Jul 27, 2016 at 06:41:41PM +, Phil Pennock wrote:
> On 2016-07-27 at 14:32 -0400, Jeff King wrote:
> > Yeah, I agree the "!" test for "did it work" is counter-intuitive if you're
> > coming from other languages, but it's pretty normal for C code bases
> > (especially ours).
>
> For st
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
On 2016-07-27 at 14:32 -0400, Jeff King wrote:
> Yeah, I agree the "!" test for "did it work" is counter-intuitive if you're
> coming from other languages, but it's pretty normal for C code bases
> (especially ours).
For stuff returning pointers, sure.
> Ah. Yeah, those are wrong and bad. We shou
Our usual style in the test scripts is to indent here
documents with tabs, and use "<<-" to strip the tabs. The
result is easier to read.
This old test script did not do so in its inception, and
further tests added onto it followed the local style. Let's
bring it in line with our usual style.
Som
The test currently does something like:
do_one() &&
do_two() &&
test_expect_success ...
We generally avoid performing actions at the top-level of
the script (outside of a test_expect block) for two reasons:
1. The test harness is not checking and reporting if they
fail.
2. Their
On Wed, Jul 27, 2016 at 02:32:03PM -0400, Jeff King wrote:
> > This however was matching existing style for `head1` and `head2` a
> > little above. I was somewhat surprised.
>
> Ah. Yeah, those are wrong and bad. We should fix that.
So here's that fix, along with a style cleanup for the here-do
On Wed, Jul 27, 2016 at 06:13:34PM +, Phil Pennock wrote:
> > Our usual error-return is "0 is success", "-1 is error".
>
> The idea was "boolean function" and adding more negations elsewhere just
> made things ugly. I can change if you really want, as consistency wins,
> but I'll be holding
On Wed, Jul 27, 2016 at 07:31:26PM +0200, Lars Schneider wrote:
> >> + strbuf_grow(sb, size + 1); // we need one extra byte for the
> >> packet flush
> >
> > What happens if size is the maximum for size_t here (i.e., 4GB-1 on a
> > 32-bit system)?
>
> Would that be an acceptable solution?
On 2016-07-27 at 13:56 -0400, Jeff King wrote:
> On Wed, Jul 27, 2016 at 04:14:14AM -0400, Phil Pennock wrote:
> > +*/
> > + case 'T':
> > + if (get_reflog_timeinfo(×tamp, &tz,
> > c->pretty_ctx->reflog_info)) {
> > + strbuf_addstr(
On Wed, Jul 27, 2016 at 11:09:30AM -0700, Junio C Hamano wrote:
> I am still in favor of this suggestion you earlier made:
>
> > So the final solution is more like:
> >
> > - a formatter for just the reflog time, respecting date
> >
> > - a formatter for just the reflog index (the "0" in HE
On Wed, Jul 27, 2016 at 7:50 PM, Stefan Beller wrote:
> On Wed, Jul 27, 2016 at 10:42 AM, Duy Nguyen wrote:
>> Before I start doing anything silly because I don't know it can
>> already be done without waving my C wand like a mad man...
>>
>> I often do this: find a commit of interest, the commit
Jeff King writes:
> I actually think Phil's patch from today is a little cleaner for most of
> these, as it returns the values via out-parameters, and uses the return
> value for "did we get anything?".
True. That part of the interface is indeed better done with the new
one.
I am still in favo
On Wed, Jul 27, 2016 at 8:02 PM, Stefan Beller wrote:
> On Wed, Jul 27, 2016 at 10:50 AM, Stefan Beller wrote:
>>>
>>> PS. Sometimes I wish we could optionally save cover letter in the
>>> merge commit. Sometimes the "big plan" is hard to see by reading
>>> individual commit messages.
>>> --
>
>
Introduced in 473166b ("config: add 'origin_type' to config_source
struct", 2016-02-19), Git can inform the user about the origin of a
config error, but the implementation does not allow translators to
translate the keywords 'file', 'blob, 'standard input', and
'submodule-blob'. Moreover, for the s
On Wed, Jul 27, 2016 at 10:50 AM, Stefan Beller wrote:
>>
>> PS. Sometimes I wish we could optionally save cover letter in the
>> merge commit. Sometimes the "big plan" is hard to see by reading
>> individual commit messages.
>> --
I had this wish, too. That makes a lot of sense for merge commits
On Wed, Jul 27, 2016 at 10:46:48AM -0700, Junio C Hamano wrote:
> I am not sure about the latter, i.e. the return value from the
> get_reflog_time_t() function (which I think is misnamed, in that the
> function returns "unsigned long", not "time_t", and should be
> renamed to get_reflog_time()) us
On Wed, Jul 27, 2016 at 04:14:14AM -0400, Phil Pennock wrote:
> The reflog contains timestamp information, but these were not exposed to
> `--pretty`. Four of the six author/committer format string
> second-letters were still available and copied, but `d`/`D` are taken
> for reflog selector forma
On Wed, Jul 27, 2016 at 10:42 AM, Duy Nguyen wrote:
> Before I start doing anything silly because I don't know it can
> already be done without waving my C wand like a mad man...
>
> I often do this: find a commit of interest, the commit itself is not
> enough so I need a full patch series to figu
Junio C Hamano writes:
>> Hrm. Since Ted was not cc'd, it is not clear to me whether this is
>> coincidental or in response to the thread over in
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/299201
>>
>> To summarize, I think the conclusion there was that we would go with at
>>
Before I start doing anything silly because I don't know it can
already be done without waving my C wand like a mad man...
I often do this: find a commit of interest, the commit itself is not
enough so I need a full patch series to figure out what's going, so I
fire up "git log --graph --oneline"
On Wed, Jul 27, 2016 at 10:32 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> I noticed --recurse-submodules was missing from the bash completion. This
>>> adds
>>> it. I went for '--recurse-submodules' instead of '--recursive' as I seem to
>>> recall the former being agreed upon as the
> On 27 Jul 2016, at 03:32, Jeff King wrote:
>
> On Wed, Jul 27, 2016 at 02:06:05AM +0200, larsxschnei...@gmail.com wrote:
>
>> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const
>> size_t size)
>> +{
>> +off_t bytes_read;
>> +off_t total_bytes_read = 0;
>
> I have
Junio C Hamano writes:
>> I noticed --recurse-submodules was missing from the bash completion. This
>> adds
>> it. I went for '--recurse-submodules' instead of '--recursive' as I seem to
>> recall the former being agreed upon as the better (or least ambiguous) of the
>> two terms.
>
> Yup, that
On Wed, Jul 27, 2016 at 10:18:11AM -0700, Junio C Hamano wrote:
> > Hrm. Since Ted was not cc'd, it is not clear to me whether this is
> > coincidental or in response to the thread over in
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/299201
> >
> > To summarize, I think the con
On Tue, Jul 19, 2016 at 6:12 PM, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 12:54 AM, Eric Wong wrote:
>> Oops, forgot to Cc some folks who worked on this :x
>>
>> Filesystem is ufs and it fails regardless of whether
>> soft-updates is enabled or not.
>
> Nothing stands out to my eyes, so I'm go
Chris Packham writes:
> Signed-off-by: Chris Packham
> ---
> Hi,
>
> I noticed --recurse-submodules was missing from the bash completion. This adds
> it. I went for '--recurse-submodules' instead of '--recursive' as I seem to
> recall the former being agreed upon as the better (or least ambiguou
Jeff King writes:
> On Wed, Jul 27, 2016 at 04:14:14AM -0400, Phil Pennock wrote:
>
>> The reflog contains timestamp information, but these were not exposed to
>> `--pretty`. Four of the six author/committer format string
>> second-letters were still available and copied, but `d`/`D` are taken
>
David Aguilar writes:
> Prefer "test" over "[ ... ]", use double-quotes around variables, break
> long lines, and properly indent "case" statements.
>
> Helped-by: Johannes Sixt
> Signed-off-by: David Aguilar
> ---
> This is a replacement patch that addresses the notes from Hannes' review.
Tha
Jakub wrote:
> I think the problem with `--reference` is that it does not
> setup backreferences to prevent gc removing borrowed objects;
> which is a hard problem to solve, except for limited cases...
> like git-worktree.
Right. And instead of solving the reference problem, I'd
rather solve the w
> On 27 Jul 2016, at 15:32, Jeff King wrote:
>
> On Wed, Jul 27, 2016 at 04:35:32AM +0200, Torsten Bögershausen wrote:
>
>>> + mkdir -p generated-test-data &&
>>> + for i in $(test_seq 1 $T0021_LARGE_FILE_SIZE)
>>> + do
>>> + # Generate 1MB of empty data and 100 bytes of random
On Wed, Jul 27, 2016 at 9:37 AM, Johannes Sixt wrote:
>
> How about this instead? It makes the sizes of the files different,
> which is a bit less obscure, IMHO.
> ...
> Equal file sizes are not crucial for the test cases, however.
That does sounds like a better solution.
--
To unsubscribe from t
Am 27.07.2016 um 14:39 schrieb Johannes Schindelin:
> On Windows, it is already pretty expensive to try to recreate the stat()
> data that Git assumes is cheap to obtain. To make things halfway decent
> in performance, we even have to skip emulating the inode and to
> determine the number of hard l
Lars Schneider writes:
>> On 27 Jul 2016, at 02:20, Junio C Hamano wrote:
>>
>> larsxschnei...@gmail.com writes:
>>
>>> From: Lars Schneider
>>>
>>> `set_packet_header` converts an integer to a 4 byte hex string. Make
>>> this function publicly available so that other parts of Git can easily
Christian Couder writes:
>> I finally found time to get back to finish reviewing this.
>
> Great, thanks!
No, thank _you_ for working on this.
>> The early part up to and including "apply: make some parsing
>> functions static again" looked good and we could treat them as a
>> continuation of t
Pranit Bauva writes:
> On Tue, Jul 26, 2016 at 11:02 PM, Junio C Hamano wrote:
>> Torsten Bögershausen writes:
>>
>>> On 07/25/2016 06:53 PM, Junio C Hamano wrote:
Pranit Bauva writes:
>>> >>> +enum terms_defined {
>>> >>> + TERM_BAD = 1,
>>> >>> + TERM_GOOD =
On Tue, Jul 26, 2016 at 8:15 PM, Stefan Beller wrote:
>> How to store stuff in .git is the implementation details that the user
>> does not care about.
>
> They do unfortunately. :(
Well.. i mean the structure of .git. If .git gets big, yeah many
people will get pissed.
> My sudden interest in w
On Wed, Jul 27, 2016 at 11:03 AM, Johannes Schindelin
wrote:
> Hi Stephen,
>
> On Wed, 27 Jul 2016, Stephen Morton wrote:
>
>> Here is my patch then. (Personally, I would add some capitalization and
>> punctuation, but I didn't see much of that in the existing code.) I'm
>> not a regular pull-requ
On Tue, Jul 26, 2016 at 9:28 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Introduce set_index_file() to be able to temporarily change the index file.
>>
>> It should be used like this:
>>
>> /* Save current index file */
>> old_index_file = get_index_file();
>> set_index_
Hi Stephen,
On Wed, 27 Jul 2016, Stephen Morton wrote:
> Here is my patch then. (Personally, I would add some capitalization and
> punctuation, but I didn't see much of that in the existing code.) I'm
> not a regular pull-requester, do I do that, or can somebody else handle
> that for me?
The pr
On Wed, Jul 27, 2016 at 6:10 AM, Max Kirillov wrote:
> Hi.
>
> On Wed, Jul 20, 2016 at 07:24:18PM +0200, Nguyễn Thái Ngọc Duy wrote:
>> + - `remote.*` added by submodules may be per working directory as
>> + well, unless you are sure remotes from all possible submodules in
>> + history are con
W dniu 2016-07-27 o 06:10, Max Kirillov pisze:
> Hi.
>
> On Wed, Jul 20, 2016 at 07:24:18PM +0200, Nguyễn Thái Ngọc Duy wrote:
>> + - `remote.*` added by submodules may be per working directory as
>> + well, unless you are sure remotes from all possible submodules in
>> + history are consisten
W dniu 2016-07-26 o 20:15, Stefan Beller pisze:
> On Tue, Jul 26, 2016 at 10:20 AM, Duy Nguyen wrote:
>> On Tue, Jul 26, 2016 at 1:25 AM, Stefan Beller wrote:
>>> So what is the design philosophy in worktrees? How much independence does
>>> one working tree have?
>>
>> git-worktree started out as
On Wed, Jul 27, 2016, at 09:58, Jeff King wrote:
> On Wed, Jul 27, 2016 at 04:14:14AM -0400, Phil Pennock wrote:
> > The reflog contains timestamp information, but these were not exposed to
> > `--pretty`. Four of the six author/committer format string
> > second-letters were still available and c
Here is my patch then. (Personally, I would add some capitalization
and punctuation, but I didn't see much of that in the existing code.)
I'm not a regular pull-requester, do I do that, or can somebody else
handle that for me?
diff --git a/sequencer.c b/sequencer.c
index cdfac82..ce06876 100644
-
On Wed, Jul 27, 2016 at 04:14:14AM -0400, Phil Pennock wrote:
> The reflog contains timestamp information, but these were not exposed to
> `--pretty`. Four of the six author/committer format string
> second-letters were still available and copied, but `d`/`D` are taken
> for reflog selector forma
On Wed, Jul 27, 2016 at 02:35:08PM +0200, Jakub Narębski wrote:
> > All correct. There is no --relative-local because "--relative" is a
> > historical artifact. We could support --foo for every --date=foo, but I
> > don't think there is a reason to do so (and reasons not to, like
> > avoiding clut
On Wed, Jul 27, 2016 at 04:35:32AM +0200, Torsten Bögershausen wrote:
> > + mkdir -p generated-test-data &&
> > + for i in $(test_seq 1 $T0021_LARGE_FILE_SIZE)
> > + do
> > + # Generate 1MB of empty data and 100 bytes of random characters
> > + printf "%1048576d" 1
> > +
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/Documentation/rev-list-options.txt
>>> +++ b/Doc
On Windows, it is already pretty expensive to try to recreate the stat()
data that Git assumes is cheap to obtain. To make things halfway decent
in performance, we even have to skip emulating the inode and to
determine the number of hard links.
This is not a huge problem, usually, as either the si
Hi Orgad,
On Tue, 26 Jul 2016, Orgad Shaneh wrote:
> On Tue, Jul 26, 2016 at 5:54 PM, Johannes Schindelin <
> johannes.schinde...@gmx.de> wrote:
>
> > On Tue, 26 Jul 2016, Orgad Shaneh wrote:
> >
> > > On Tue, Jul 26, 2016 at 4:02 PM, Johannes Schindelin
> > > wrote:
> > > >
> > > > On Tue, 26
On 2016-07-27 at 04:14 -0400, Phil Pennock wrote:
> pretty.c | 36
> reflog-walk.c | 16
> reflog-walk.h | 3 +++
> t/t4205-log-pretty-formats.sh | 26 ++
> 4 files c
A Ter, 26-07-2016 às 09:57 -0700, Junio C Hamano escreveu:
> Vasco Almeida writes:
>
> >
> > + strbuf_add_commented_lines(&buf, "\n",
> > strlen("\n"));
> > + strbuf_add_commented_lines(&buf, _(note_template),
> > strlen(_(note_template)));
> > + strbuf_add_commente
A Ter, 26-07-2016 às 10:05 -0700, Junio C Hamano escreveu:
> In any case, I do not understand why you want to exclude the LFs
> from the message.
As Ævar Arnfjörð Bjarmason pointed out [1], it is to assure that a
translator does not break the output by mistake, by removing a LF.
I agree because I
Hi,
Attached is a potential patch for reversing the order on which
git-mergetool presents the files to merge.
Currently, when running git-mergetool, it performs a sort of the files
to merge by alphabetical ordering. When working on C, this has the
annoying effect of presenting the merge for a .c*
larsxschnei...@gmail.com wrote:
> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const size_t
> size)
I'm no expert in C, but this might be const-correctness taken
too far. I think basing this on the read(2) prototype is less
surprising:
static ssize_t multi_packet_read(int
I have tried all of that.
A colleague looked at it and he reset xrdb with xrdb -remove -all
apparently this works and my issues has been fixed.
Regards,
On Wed, Jul 27, 2016 at 10:21 AM, Trần Ngọc Quân wrote:
> On 27/07/2016 15:05, jessie hernandez wrote:
>> Dear git,
>>
>> I have been dealing
> On 27 Jul 2016, at 02:20, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> `set_packet_header` converts an integer to a 4 byte hex string. Make
>> this function publicly available so that other parts of Git can easily
>> generate a pkt-line.
>
> I
Signed-off-by: Chris Packham
---
Hi,
I noticed --recurse-submodules was missing from the bash completion. This adds
it. I went for '--recurse-submodules' instead of '--recursive' as I seem to
recall the former being agreed upon as the better (or least ambiguous) of the
two terms.
contrib/comple
The reflog contains timestamp information, but these were not exposed to
`--pretty`. Four of the six author/committer format string
second-letters were still available and copied, but `d`/`D` are taken
for reflog selector formatting. So use `%gT` for "time" instead of
"date" mnemonic for using `-
On 27/07/2016 15:05, jessie hernandez wrote:
> Dear git,
>
> I have been dealing with an issue in gitk for a while now. I do not
> know if this is a specific gitk issue or something else. I cannot find
> any information about it online.
>
> When I start gitk in my repository gitk comes up but all t
Dear git,
I have been dealing with an issue in gitk for a while now. I do not
know if this is a specific gitk issue or something else. I cannot find
any information about it online.
When I start gitk in my repository gitk comes up but all the font and
all the menus are Extremly small. (see attach
89 matches
Mail list logo
