Hi Junio,
On Tue, 6 Mar 2018, Junio C Hamano wrote:
> Phillip Wood writes:
>
> > I wonder if just having a predicable result rather than forcing the
> > rebase to stop if the user just squashes a fixup commit into a topic
> > branch that is the parent of a merge might be more convenient in
> >
Hi Junio,
On Wed, 7 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> OK, does this mean we want to wait before merging the "recreate
> >> merge" topic down to 'next'? For more than a few weeks, it has been
> >> slated for 'next'.
> >
> > Maybe a few more days.
> > ...
> > I
Hi Sergey,
On Wed, 7 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
> >
> > On Wed, 7 Mar 2018, Sergey Organov wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > On Tue, 6 Mar 2018, Sergey Organov wrote:
> >> >
> >> >> This is v2 of my "Rebasing merges" proposal.
> >> >
> >
Hi Sergey,
On Wed, 7 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > How can your approach -- which relies *very much* on having the
> > original parent commits -- not *require* that consistency check?
>
> I don't understand what you mean, sorry. Could you please point me t
Good day dear, i hope this mail meets you well? I know this may seem
inappropriate so
i ask for your forgiveness but i wish to get to know you better, if I may be so
bold.
I consider myself an easy-going man, adventurous, honest and fun loving person
but I
am currently looking for a relations
I can't reproduct my issue, this is my first time, but my colleague
came across this issue several weeks ago.
After I pushed my commit to git server without rejection. I run git
pull --rebase, then I got a forced update, and my last commit is
missing.
I have asked a question on StackOverflow, the
On Thu, Mar 8, 2018 at 12:30 AM, wrote:
> From: Lars Schneider
>
> Check in a case insensitive manner if one string is a prefix of another
> string.
>
> This function is used in a subsequent commit.
>
> Signed-off-by: Lars Schneider
> ---
> git-compat-util.h | 1 +
> strbuf.c | 9
Lars Schneider writes:
> I would like to advise the dashed form as this seems to be the
> canonical form and it avoids cross platform issues. My macOS
> iconv does not support the form without dashes.
Sure, that is why I said canonicalization without inserting dash
does not make much sense, henc
Am 07.03.2018 um 23:45 schrieb Junio C Hamano:
> kalle writes:
>
>> Am 06.03.2018 um 02:36 schrieb Junio C Hamano:
>>> kalle writes:
>>>
-In the explanation of the option --reference: shouldn't there be
written '' instead of 'reference repository'?
>>>
>>> "Shouldn't X be Y?" is not
> On 07 Mar 2018, at 23:57, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> At this point I thought it would make sense to make the advised
>> encoding name uppercase in both situations. OK with you?
>
> In the endgame, if upcased and properly dashed form is always used,
> that would be
> On 07 Mar 2018, at 23:52, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> I don't think HT makes too much sense. However, isspace() is nice
>> and I will use it. Being more permissive on the inputs should hurt.
>
> You are being incoherent in these three sentences. If you want to
> b
Lars Schneider writes:
> Nice catch. What do you think about this solution using is_encoding_utf8()
> from utf.c?
That helper was invented exactly for a case like this, I would
think.
Lars Schneider writes:
> In the case of has_prohibited_utf_bom() you are right as we are
> dropping the BE/LE suffix in the advise. However, look at the
> is_missing_required_utf_bom() advise. Here we *add* BE/LE.
So? Then add BE/LE like "Utf-16BE" or "utf16BE". You do not have
enough inform
> On 07 Mar 2018, at 18:54, Eric Sunshine wrote:
>
> On Wed, Mar 7, 2018 at 12:30 PM, wrote:
>> [...]
>> Add an attribute to tell Git what encoding the user has defined for a
>> given file. If the content is added to the index, then Git converts the
>> content to a canonical UTF-8 representati
Lars Schneider writes:
> Although the line is unnecessary, I felt it is safer/easier to
> understand and maintain. Since both of you tripped over it, I will
> remove it though.
I didn't actually trip over it. It made it look as if the coder
didn't understand what the code is doing to have that
> On 07 Mar 2018, at 23:32, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> I also would have liked to advise "UTF-16" instead of "UTF16" as
>> you suggested. However, that required a few more lines and I wanted
>> to keep the change to a minimum. I feel this could be added in a
>> follo
kalle writes:
> Am 06.03.2018 um 02:36 schrieb Junio C Hamano:
>> kalle writes:
>>
>>> -In the explanation of the option --reference: shouldn't there be
>>> written '' instead of 'reference repository'?
>>
>> "Shouldn't X be Y?" is not an effective way to communicate; it
>> solicits a "no, th
> On 07 Mar 2018, at 20:59, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> +static int check_roundtrip(const char* enc_name)
>
> The asterisk sticks to the variable, not type.
Argh. I need to put this check into Travis CI ;-)
>> +{
>> +/*
>> + * check_roundtrip_e
Lars Schneider writes:
> I also would have liked to advise "UTF-16" instead of "UTF16" as
> you suggested. However, that required a few more lines and I wanted
> to keep the change to a minimum. I feel this could be added in a
> follow up patch.
I'd say the whole upcase thing belongs to such a f
I wrote this, because when it is written about 'reference repository', I
consider it not totally clear, which repository is meant, as the option
'--reference ' only names one as .
For reasons of clearness, I now propose writing "reference repository
".
kalle
Am 06.03.2018 um 02:36 schrieb Junio C
> On 07 Mar 2018, at 20:49, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> +static int validate_encoding(const char *path, const char *enc,
>> + const char *data, size_t len, int die_on_error)
>> +{
>> +/* We only check for UTF here as UTF?? can be an al
hello.
1.I understood, that verbose commands are quoted in ` ' or ' '. While
the points I changed are not verbose commands. Therefore I didn't see
any sense in them. Because of the different quoting ways (e.g. `merge`),
I thought that someone didn't understand the quoting concept. But it
could also
Hi,
I was reading the email related to the "convert interactive rebase to C"
idea[1], and I have a few questions about it:
> So the first goal would be to retire git-rebase--interactive.sh. For that
> to happen, --root needs to be supported first.
Combining rebase -i and --root seems to work fin
Thanks for updating us with the status of git.el.
The last time I looked at magit, it was too heavyweight for my needs.
I like the simplicity of git.el. But perhaps it's time for me to take
another look at magit.
On Tue, Mar 6, 2018 at 3:54 AM, Alexandre Julliard wrote:
> Junio C Hamano writes
Robert Dailey writes:
> I could have gone through the effort to make this more configurable, but
> before doing that level of work I wanted to get some discussion going to
> understand first if this is a useful change and second how it should be
> configured. For example, we could allow:
>
> $ gi
I am experimenting with a version of submodule diff (using log style)
that prints the commits brought in from merges, while excluding the
merge commits themselves. This is useful in cases where a merge commit's
summary does not fully explain the changes being merged (for example,
for longer-lived b
Junio C Hamano writes:
> "Vromen, Tomer" writes:
>
>>> git stash && git checkout -b new-feature-branch && git stash pop
>>
>> This is useful when I realize that I want to open a new branch for my
>> changes (that I haven't committed yet).
>> However, I might have forgotten to save my changes in
lars.schnei...@autodesk.com writes:
> +static int check_roundtrip(const char* enc_name)
The asterisk sticks to the variable, not type.
> +{
> + /*
> + * check_roundtrip_encoding contains a string of space and/or
> + * comma separated encodings (eg. "UTF-16, ASCII, CP1125").
> +
lars.schnei...@autodesk.com writes:
> +static int validate_encoding(const char *path, const char *enc,
> + const char *data, size_t len, int die_on_error)
> +{
> + /* We only check for UTF here as UTF?? can be an alias for UTF-?? */
> + if (startscase_with(enc, "UTF")) {
lars.schnei...@autodesk.com writes:
> +static const char *git_path_check_encoding(struct attr_check_item *check)
> +{
> + const char *value = check->value;
> +
> + if (ATTR_TRUE(value) || ATTR_FALSE(value) || ATTR_UNSET(value) ||
> + !strlen(value))
> + return NULL;
Th
"Vromen, Tomer" writes:
>> git stash && git checkout -b new-feature-branch && git stash pop
>
> This is useful when I realize that I want to open a new branch for my changes
> (that I haven't committed yet).
> However, I might have forgotten to save my changes in the editor, so
> git-stash will
SZEDER Gábor writes:
> That works fine, but this would work just as well and has one less
> case arm:
OK, I missed that "obvious optimization" opportunity. I agree that
would work.
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index ab80f
Johannes Schindelin writes:
> Junio, may I ask you to put this into a SQUASH??? commit so that the
> Windows build no longer fails?
Thanks for a reminder; I also spotted it (I first thought I screwed
up in my editor while reviewing and then went back to the original
on the list) and sent out a r
Duy Nguyen writes:
>>> +Set environment variable `GIT_TRACE` in order to see the memory usage
>>> +estimation in `git gc --auto` that determines whether the base pack is
>>> +kept.
>>
>> This is somewhat a puzzling use of trace. It sounds more like a way
>> to find out "how" memory usage estimat
Johannes Schindelin writes:
>> OK, does this mean we want to wait before merging the "recreate
>> merge" topic down to 'next'? For more than a few weeks, it has been
>> slated for 'next'.
>
> Maybe a few more days.
> ...
> I want to discuss this in the other subthread, though.
If we are talking
On Wed, Mar 7, 2018 at 12:30 PM, wrote:
> Check that new content is valid with respect to the user defined
> 'working-tree-encoding' attribute.
>
> Signed-off-by: Lars Schneider
> ---
> diff --git a/convert.c b/convert.c
> @@ -266,6 +266,58 @@ static int will_convert_lf_to_crlf(size_t len, struc
Am Mr.Sare Ouedraogo.i work in one of the prime bank here in Burkina
Faso, i want the bank to transfer the money left by our late customer
is a foreigner from Korea. can you invest this money and also help the
poor' the amount value at $13,300,000.00 (Thirteen Million Three
Hundred Thousan
On Wed, Mar 7, 2018 at 12:30 PM, wrote:
> [...]
> Add an attribute to tell Git what encoding the user has defined for a
> given file. If the content is added to the index, then Git converts the
> content to a canonical UTF-8 representation. On checkout Git will
> reverse the conversion.
>
> Signe
On Tue, Mar 06, 2018 at 03:37:16PM -0800, Junio C Hamano wrote:
> Lars Schneider writes:
>
> > After thinking about it I wonder if we should barf on "utf16" without
> > dash. Your Linux iconv would handle this correctly. My macOS iconv would
> > not.
> > That means the repo would checkout correc
From: Lars Schneider
Add the GIT_TRACE_WORKING_TREE_ENCODING environment variable to enable
tracing for content that is reencoded with the 'working-tree-encoding'
attribute. This is useful to debug encoding issues.
Signed-off-by: Lars Schneider
---
convert.c| 25 +++
From: Lars Schneider
Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE
or UTF-32LE a BOM must not be used [1]. The function returns true if
this is the case.
This function is used in a subsequent commit.
[1] http://unicode.org/faq/utf_bom.html#bom10
Signed-off-by: Lars Schn
From: Lars Schneider
Git recognizes files encoded with ASCII or one of its supersets (e.g.
UTF-8 or ISO-8859-1) as text files. All other encodings are usually
interpreted as binary and consequently built-in Git text processing
tools (e.g. 'git diff') as well as most Git web front ends do not
visu
From: Lars Schneider
If the endianness is not defined in the encoding name, then let's
be strict and require a BOM to avoid any encoding confusion. The
is_missing_required_utf_bom() function returns true if a required BOM
is missing.
The Unicode standard instructs to assume big-endian if there i
From: Lars Schneider
Hi,
Patches 1-5,8 are preparation and helper functions. Patch 3 is new.
Patch 6,7,9 are the actual change.
This series depends on Torsten's 8462ff43e4 (convert_to_git():
safe_crlf/checksafe becomes int conv_flags, 2018-01-13) which is
already in master.
Changes since v9:
From: Lars Schneider
Since 3733e69464 (use xmallocz to avoid size arithmetic, 2016-02-22) we
allocate the buffer for the lower case string with xmallocz(). This
already ensures a NUL at the end of the allocated buffer.
Remove the unnecessary assignment.
Signed-off-by: Lars Schneider
---
strbu
From: Lars Schneider
Check that new content is valid with respect to the user defined
'working-tree-encoding' attribute.
Signed-off-by: Lars Schneider
---
convert.c| 55 +++
t/t0028-working-tree-encoding.sh | 56 ++
From: Lars Schneider
UTF supports lossless conversion round tripping and conversions between
UTF and other encodings are mostly round trip safe as Unicode aims to be
a superset of all other character encodings. However, certain encodings
(e.g. SHIFT-JIS) are known to have round trip issues [1].
From: Lars Schneider
Check in a case insensitive manner if one string is a prefix of another
string.
This function is used in a subsequent commit.
Signed-off-by: Lars Schneider
---
git-compat-util.h | 1 +
strbuf.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/git-co
From: Lars Schneider
Create a copy of an existing string and make all characters upper case.
Similar xstrdup_tolower().
This function is used in a subsequent commit.
Signed-off-by: Lars Schneider
---
strbuf.c | 12
strbuf.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 7 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Tue, 6 Mar 2018, Sergey Organov wrote:
>> >
>> >> This is v2 of my "Rebasing merges" proposal.
>> >
>> > Didn't we settle on Phillip's "perform success
--
I am Mr.Sheng Li Hung I have a very profitable business proposition for
you
Am 07.03.2018 um 10:36 schrieb Eric Sunshine:
> On Tue, Mar 6, 2018 at 6:05 PM, Jun Wu wrote:
>> Excerpts from Eric Sunshine's message of 2018-03-06 14:23:46 -0500:
>>> On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
+ printf "x%.0s" {1..934} >>d # pad common suffix to 1024 bytes
>>>
>>> The
Johannes Schindelin writes:
> Hi Sergey,
>
> On Wed, 7 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Tue, 6 Mar 2018, Phillip Wood wrote:
>> >
>> >> On 03/03/18 00:29, Igor Djordjevic wrote:
>> >> >
>> >> > On 02/03/2018 12:31, Phillip Wood wrote:
>> >> >>
>> >> >
Hi Jonathan,
On Mon, 5 Mar 2018, Jonathan Nieder wrote:
> BTW, thanks again for writing and submitting this document. It can't
> land soon enough. :)
It landed:
https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md
Ciao,
Dscho
Hi Sergey,
On Wed, 7 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > On Tue, 6 Mar 2018, Sergey Organov wrote:
> >
> >> This is v2 of my "Rebasing merges" proposal.
> >
> > Didn't we settle on Phillip's "perform successive three-way merges
> > between the original merge comm
We discussed partial clone today during the contributor's summit. There
were some concerns about some commands that would cause over-hydration
of blobs that need server requests to resolve.
GVFS blocks "fsck", "gc", "prune", "repack", "submodule", and "worktree"
[1]. I promised I would include
Hi Buga,
On Tue, 6 Mar 2018, Igor Djordjevic wrote:
> [...]
>
> But before elaborating, I would like to hear your opinion on whether you
> find it worth to pursue that goal here, before `--recreate-merges` hits
> the mainstream, or it might be just fine as a possible later
> improvement, too (if
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Tue, 6 Mar 2018, Sergey Organov wrote:
>
>> This is v2 of my "Rebasing merges" proposal.
>
> Didn't we settle on Phillip's "perform successive three-way merges between
> the original merge commit and the new tips with the old tips as b
Hi,
On Tue, 6 Mar 2018, Siddhartha Mishra wrote:
> Are there any other glaring issues you see in the code?
The rest looks good to me!
Ciao,
Johannes
Hi Dan,
On Tue, 6 Mar 2018, Junio C Hamano wrote:
> * dj/runtime-prefix (2017-12-05) 4 commits
> . exec_cmd: RUNTIME_PREFIX on some POSIX systems
> . Makefile: add Perl runtime prefix support
> . Makefile: add support for "perllibdir"
> . Makefile: generate Perl header from template file
>
>
Hello-
Microsoft would like to invite the contributors summit to dinner tonight;
it will take place at 8pm:
La Tagliatella (Placa Catalunya)
Ronda de la Universitat, 31
It's conveniently right around the corner from the Beers with Bitbucket
event, in case you're going to that.
Hope to see y
Hi all,
I often use this one-liner:
> git stash && git checkout -b new-feature-branch && git stash pop
This is useful when I realize that I want to open a new branch for my changes
(that I haven't committed yet).
However, I might have forgotten to save my changes in the editor, so git-stash
wi
On Wed, Mar 7, 2018 at 2:19 AM, Junio C Hamano wrote:
>> +--keep-base-pack::
>> + All packs except the base pack are consolidated into a single
>> + pack. The largest pack is considered the base pack.
>
> This makes it sound as if packs with .keep are also repacked unless
> they meet the t
Hi Duy,
On Tue, 6 Mar 2018, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 77fa720bd0..273657ddf4 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -187,7 +211,101 @@ static int too_many_packs(void)
> return gc_auto_pack_limit < cnt;
> }
>
> -static vo
On Wed, Mar 7, 2018 at 1:25 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +--keep-pack=::
>> + Ignore the given pack. This is the equivalent of having
>> + `.keep` file on the pack. Implies `--honor-pack-keep`.
>> +
>
> A few questions I am not sure how I would answer:
>
On Sat, Mar 3, 2018 at 5:05 PM, Eric Sunshine wrote:
> I can't presently think of a reason why gitdir needed/used an absolute
> or normalized path. Was it because there was some need to compare such
> paths?
No, we need to re-normalize paths before comparing anyway to be safe.
I don't think I had
On Tue, Mar 6, 2018 at 6:05 PM, Jun Wu wrote:
> Excerpts from Eric Sunshine's message of 2018-03-06 14:23:46 -0500:
>> On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
>> > + printf "x%.0s" {1..934} >>d # pad common suffix to 1024 bytes
>>
>> The expression {x..y} is not portable to non-POSIX shell
Greetings From Mr. Hamidou Kader.
I have a Mutual/Beneficial Business Project that would be beneficial to you. I
only have two questions to ask of you, if you are interested.
1. Can you handle this project?
2. Can I give you this trust?
Please note that the deal requires high level of maturity,
68 matches
Mail list logo
