Hi Junio,
thank you very much for the tips. I'll make new patch with a simpler code.
Josef
| Sent: Wednesday, October 5, 2016 6:05:59 PM
| Josef Ridky writes:
|
| > Hi,
| >
| > I have just realize, that my attachment has been cut off from my previous
| > message.
| > Below you can find patch w
On Thu, Oct 6, 2016 at 7:40 AM, Jacob Keller wrote:
> On Wed, Oct 5, 2016 at 3:15 PM, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>>> Gut feeling tells me that I should take this as a subtle
>>> encouragement to look into adding 'versionsort.postreleasesuffix',
>>> shouldn't I ;)
>>
>> It i
>I am not suggesting that you apply this exact patch (stdin_ is not a good
choice
How about fd_stdin ?
On Thu, Oct 06, 2016 at 10:55:11AM +0700, Tom Hale wrote:
> On 2016-10-03 00:00, Anatoly Borodin wrote:
> > I've reported this one bug recently:
> >
> > https://public-inbox.org/git/nrmbrl$hsk$1...@blaine.gmane.org/
> >
> > The developers know about it, but it will require some deeper refactoring
On 2016-10-03 00:00, Anatoly Borodin wrote:
I've reported this one bug recently:
https://public-inbox.org/git/nrmbrl$hsk$1...@blaine.gmane.org/
The developers know about it, but it will require some deeper refactoring.
Thanks Anatoly for reporting this.
[Meta] All: For updates, is there an i
On Wed, Oct 5, 2016 at 3:15 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> Gut feeling tells me that I should take this as a subtle
>> encouragement to look into adding 'versionsort.postreleasesuffix',
>> shouldn't I ;)
>
> It is more like "this made me realize that these are merely 'suffi
Vasco Almeida writes:
> @@ -70,6 +72,8 @@ Git::I18N - Perl interface to Git's Gettext localizations
>
> printf __("The following error occurred: %s\n"), $error;
>
> + printf __n("commited %d file", "commited %d files", $files), $files;
> +
A micronit: the existing example above pri
W dniu 04.10.2016 o 14:59, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> The goal of this series is to avoid launching a new clean/smudge filter
> process for each file that is filtered.
>
> A short summary about v1 to v5 can be found here:
> https://git.github.io/rev_news/2016/08/1
Vasco Almeida writes:
> if (!defined $bottom) {
> - error_msg "Huh ($choice)?\n";
> + error_msg sprintf(__("Huh (%s)?\n"),
> $choice);
> next TOPLOOP;
>
SZEDER Gábor writes:
> Gut feeling tells me that I should take this as a subtle
> encouragement to look into adding 'versionsort.postreleasesuffix',
> shouldn't I ;)
It is more like "this made me realize that these are merely 'suffix'
after the real release name, no pre- or post- about them", al
Stefan Beller writes:
> I think so, instead of resending the documentation, maybe the header
> file shows that we're on the same page, I converted everything except
> attr.c to follow this header attr.h:
OK. The function signature of git_check_attr() looks suspect (it
does not match the "typica
W dniu 05.10.2016 o 19:20, Vasco Almeida pisze:
> Mark messages in some perl scripts for translation.
>
> Thanks for the reviews of Junio Hamano and Jakub Narębski. Although I think
> Jakub Narębski's suggestions are overall good, I am not willing to go that
> path
> because I cannot see huge be
Sergey Organov writes:
> So I believe this change is inline with the rest of the patch. The
> reference to git-pull (if it remains) should be a side-note, not part of
> explanation of operation.
Not really. The thing is, "This is the most common" needs to be
close to "Often...". "git merge" di
Sergey Organov writes:
> OK, I see. So, what is the best way to handle this? Immediately follow
> content change patch with another patch that only re-flows?
Or no reflowing at all.
>> the parents". I do not know if the updated phrasing is better. The
>> "name" in the original was meant to be
Junio C Hamano writes:
> sorga...@gmail.com writes:
[...]
>> @@ -138,14 +133,15 @@ will exit early with the message "Already up-to-date."
>> FAST-FORWARD MERGE
>> --
>>
>> -Often the current branch head is an ancestor of the named commit.
>> +Often the current branch head is
Quoting Junio C Hamano :
SZEDER Gábor writes:
And a final sidenote: sorting based on the longest matching suffix
also allows us to (ab)use version sort with prerelease suffixes to
sort postrelease tags as we please, too:
$ ~/src/git/git -c versionsort.prereleasesuffix=-alpha \
Jakub Narębski writes:
> W dniu 05.10.2016 o 16:46, sorga...@gmail.com pisze:
>> From: Sergey Organov
>>
>> Old description had a few problems:
>>
>> - sounded as if commits have changes
>>
>> - stated that changes are taken since some "divergence point"
>> that was not defined.
>>
>> New
Junio C Hamano writes:
> sorga...@gmail.com writes:
>
>> From: Sergey Organov
>>
>> Old description had a few problems:
>>
>> - sounded as if commits have changes
>>
>> - stated that changes are taken since some "divergence point"
>> that was not defined.
>>
>> New description rather uses "com
Lars Schneider writes:
> OK. Something like the patch below would work nicely.
Yeah, something along that line; it would eliminate the need to
worry about a field named "stdin" ;-)
But ...
> while (children_to_clean) {
> struct child_to_clean *p = children_to_clean;
>
Am 05.10.2016 um 09:47 schrieb Josef Ridky:
Add support for user defined suffix part of name of temporary files
created by git mergetool
Do I understand correctly that your users have problems to identify
which of the "_BASE_", "_LOCAL_", "_REMOTE_" and "_BACKUP_" files they
must edit? I agre
Junio C Hamano writes:
> sorga...@gmail.com writes:
>
>> From: Sergey Organov
>>
>> This partial list of option is confusing as it lacks a lot of
>> available options. It also clutters the SYNOPSIS making differences
>> between forms of invocation less clear.
>>
>> Signed-off-by: Sergey Organov
Junio C Hamano writes:
> sorga...@gmail.com writes:
>
>> From: Sergey Organov
>>
>> Old description not only raised the question of why the tool is called
>> git-merge rather than git-join, but "join histories" also sounds like
>> very simple operation, something like what "git-merge -s ours" do
> On 04 Oct 2016, at 21:30, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> The flag 'clean_on_exit' kills child processes spawned by Git on exit.
>> A hard kill like this might not be desired in all cases.
>>
>> Add 'wait_on_exit' which closes the
Jeff King writes:
> On Wed, Oct 05, 2016 at 05:46:22PM +0300, sorga...@gmail.com wrote:
>
>> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
>> index 216d2f4..cc0329d 100644
>> --- a/Documentation/git-merge.txt
>> +++ b/Documentation/git-merge.txt
>> @@ -3,7 +3,8 @@ git-mer
Junio C Hamano writes:
> sorga...@gmail.com writes:
>
>> From: Sergey Organov
>>
>> "-m " is one of essential distinctions between obsolete
>> invocation form and the recent one. Add it to the "usage" returned by
>> 'git merge -h' for more clarity.
>>
>> Signed-off-by: Sergey Organov
>> ---
>>
Jonathan Tan writes:
> Sounds reasonable to me. Would the "[" be a bit of overspecification,
> though, since Git doesn't produce it? Also, identifying it as a
> garbage line probably wouldn't change any behavior - in the Linux
> kernel examples, it is used to show what happened in between
> sign-
Signed-off-by: Ramsay Jones
---
Hi Lars,
Commit 6007c69e ("run-command: add wait_on_exit", 04-10-2016), which
is part of your 'ls/filter-process' branch, causes the build to fail
on cygwin, since 'stdin' is defined as a macro thus:
#define stdin (_REENT->_stdin)
(you can probably guess
Jakub Narębski writes:
>> +
>> +This command is used by 'git pull' to incorporate changes from another
>> +repository, and can be used by hand to merge changes from one branch
>> +into another.
>
> Rather "can be used by 'git pull'", or "is used by 'git pull' (unless
> configured otherwise)"...
On 10/04/2016 11:28 AM, Junio C Hamano wrote:
An addendum. We may also want to be prepared to accept an input
that has some garbage lines _after_ the trailer block, if we can
clearly identify them as such. For example, we could change the
definition of "the last paragraph" as "the block of line
On 10/04/2016 10:25 AM, Junio C Hamano wrote:
So I would say it is perfectly OK if your update works only for
cases we can clearly define the semantics for. For example, we can
even start with something simple like:
* A RFC822-header like line, together with any number of whitespace
indente
Jacob Keller writes:
>> The cost of fill function having to do the same thing repeatedly is
>> negligible, so I am OK with the result, but for fairness, this was
>> not "make the callers do this extra thing", but was "the caller can
>> prepare these unchanging parts just once, and the fill functi
W dniu 04.10.2016 o 15:06, Johannes Schindelin pisze:
> The previous code still followed the old git-pull.sh code which did not
> adhere to our new convention.
Good to know why it used its own convention.
> Signed-off-by: Johannes Schindelin
> ---
> builtin/pull.c | 2 +-
> wt-status.c| 6
W dniu 04.10.2016 o 15:05, Johannes Schindelin pisze:
> Subject: Export also the has_un{staged,committed}_changed() functions
s/changed/changes/ that is d -> s
Those are has_unstaged_changes() and has_uncommitted_changes().
Though I wonder if "other has_un*_changes() functions" would be
mor
On Wed, Oct 05, 2016 at 09:01:57PM +0200, Jakub Narębski wrote:
> > diff --git a/connected.h b/connected.h
> > index afa48cc..4ca325f 100644
> > --- a/connected.h
> > +++ b/connected.h
> > @@ -33,6 +33,11 @@ struct check_connected_options {
> >
> > /* If non-zero, show progress as we travers
> On 04 Oct 2016, at 21:33, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>>
>> +static int packet_write_gently(const int fd_out, const char *buf, size_t
>> size)
>> +{
>> +static char packet_write_buffer[LARGE_PACKET_MAX];
>> +const size_t
On Wed, Oct 05, 2016 at 08:47:29PM +0200, René Scharfe wrote:
> > Instead, let's provide a strbuf helper that does an in-place
> > normalize, but restores the original contents on error. This
> > uses a second buffer under the hood, which is slightly less
> > efficient, but this is not a performan
W dniu 03.10.2016 o 22:49, Jeff King pisze:
> diff --git a/connected.h b/connected.h
> index afa48cc..4ca325f 100644
> --- a/connected.h
> +++ b/connected.h
> @@ -33,6 +33,11 @@ struct check_connected_options {
>
> /* If non-zero, show progress as we traverse the objects. */
> int pr
sorga...@gmail.com writes:
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index 351b8fc..ba5fb0a 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -23,10 +23,6 @@ named commits and the current branch, called "merge base",
> is
> calcu
Am 03.10.2016 um 22:33 schrieb Jeff King:
This series is the result of René nerd-sniping me with the claim that we
could "easily" teach count-objects to print out the list of alternates
in:
http://public-inbox.org/git/c27dc1a4-3c7a-2866-d9d8-f5d3eb161...@web.de/
1. Send crappy patch
2.
Am 03.10.2016 um 22:34 schrieb Jeff King:
When we add a new alternate to the list, we try to normalize
out any redundant "..", etc. However, we do not look at the
return value of normalize_path_copy(), and will happily
continue with a path that could not be normalized. Worse,
the normalizing proc
Am 03.10.2016 um 22:36 schrieb Jeff King:
There's no way to get the list of alternates that git
computes internally; our tests only infer it based on which
objects are available. In addition to testing, knowing this
list may be helpful for somebody debugging their alternates
setup.
Let's add it
On Wed, Oct 05, 2016 at 09:13:53AM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> >> It IS a hack, but having this information in .git would
> >> mean that it can be forced to be in machine readable form, unlike a
> >> mention in README. I do not know if the .gitmodules/.gitignore
> >> c
sorga...@gmail.com writes:
> From: Sergey Organov
>
> Old description had a few problems:
>
> - sounded as if commits have changes
>
> - stated that changes are taken since some "divergence point"
> that was not defined.
>
> New description rather uses "common ancestor" and "merge base",
> defi
On Wed, Oct 05, 2016 at 05:46:22PM +0300, sorga...@gmail.com wrote:
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index 216d2f4..cc0329d 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -3,7 +3,8 @@ git-merge(1)
>
> NAME
>
>
sorga...@gmail.com writes:
> From: Sergey Organov
>
> Old description not only raised the question of why the tool is called
> git-merge rather than git-join, but "join histories" also sounds like
> very simple operation, something like what "git-merge -s ours" does.
>
> Signed-off-by: Sergey Org
sorga...@gmail.com writes:
> From: Sergey Organov
>
> This partial list of option is confusing as it lacks a lot of
> available options. It also clutters the SYNOPSIS making differences
> between forms of invocation less clear.
>
> Signed-off-by: Sergey Organov
> ---
> Documentation/git-merge.t
sorga...@gmail.com writes:
> From: Sergey Organov
>
> "-m " is one of essential distinctions between obsolete
> invocation form and the recent one. Add it to the "usage" returned by
> 'git merge -h' for more clarity.
>
> Signed-off-by: Sergey Organov
> ---
> builtin/merge.c | 2 +-
> 1 file cha
Johannes Schindelin writes:
> Actually, come to think of it, I will change the patch, as it is too
> confusing. What I want is to preserve a positive return value in case of
> merge conflicts, and that is exactly what I should do instead of playing
> games with the Boolean OR operator.
That woul
Johannes Schindelin writes:
> I briefly considered consolidating them and using .git/rebase-merge/ as
> state directory also for cherry-pick/revert, but that would cause
> problems: I am surely not the only user who cherry-picks commits manually
> while running interactive rebases.
Good thinking
> On 04 Oct 2016, at 21:53, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>
>> +int write_packetized_from_buf(const char *src_in, size_t len, int fd_out)
>> +{
>> +static char buf[LARGE_PACKET_DATA_MAX];
>> +int err = 0;
>> +size_t bytes_
Mark warnings, errors and other messages that are interpolated for
translation.
We call sprintf() before calling die() and in few other circumstances in
order to replace the values on the placeholders.
Signed-off-by: Vasco Almeida
---
I changed (y|N) to [y|N] around line 1750 to match with the
Remove unnecessary entries from %patch_modes. After the i18n conversion,
these entries are not used anymore.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 21 -
1 file changed, 21 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
Mark warnings, errors and other messages for translation.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 78eb59b..982c6c0 100755
--- a/gi
Mark words 'nothing', 'unchanged' and 'binary' used to display what has
been staged or not, in "git add -i" status command.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-add--interactive.perl b/git-
Mark strings often displayed to the user for translation.
Signed-off-by: Vasco Almeida
---
git-send-email.perl | 52 ++--
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index da81be4..78eb5
Signed-off-by: Vasco Almeida
---
git-difftool.perl | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index a5790d0..8d3632e 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -22,6 +22,7 @@ use File::Path qw(m
Since at this point Git::I18N.perl lacks support for Perl i18n
placeholder substitution, use of sprintf following die or error_msg is
necessary for placeholder substitution take place.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 23 ---
1 file changed, 12 ins
Mark prompt message assembled in place for translation, unfolding each
use case for each entry in the %patch_modes hash table.
Previously, this script relied on whether $patch_mode was set to run the
command patch_update_cmd() or show status and loop the main loop. Now,
it uses $cmd to indicate we
Mark simple strings (without interpolation) for translation.
Brackets around first parameter of ternary operator is necessary because
otherwise xgettext fails to extract strings marked for translation from
the rest of the file.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 74 +++
Change strings for help to match the ones in git-add--interactive.perl.
The strings now represent one entry to translate each rather then two
entries each different only by an ending newline character.
Signed-off-by: Vasco Almeida
---
builtin/clean.c | 10 +-
1 file changed, 5 insertions
Mark help message of help_patch_cmd for translation. The message must
be unfolded to be free of variables so we can have high quality
translations.
Signed-off-by: Vasco Almeida
---
git-add--interactive.perl | 54 ---
1 file changed, 46 insertions(+),
Mark plural strings for translation. Unfold each action case in one
entire sentence.
Pass new keyword for xgettext to extract.
Update test to include new subroutine __n() for plural strings handling.
Update documentation to include a description of the new __n() subroutine.
Signed-off-by: Vasc
Mark message of edit_hunk_manually displayed in the editing file when
user chooses 'e' option. The message had to be unfolded to allow
translation of the $participle verb.
Some messages end up being exactly the same for some uses cases, but
left it for easier change in the future, e.g., wanting t
Mark messages in here-document without interpolation for translation.
The here-document delimiter \EOF, which is the same as 'EOF', indicate
that the text is to be treated literally without interpolation of its
content. Unfortunately xgettext is not able to extract here documents
with delimiter \
Mark messages in some perl scripts for translation.
Thanks for the reviews of Junio Hamano and Jakub Narębski. Although I think
Jakub Narębski's suggestions are overall good, I am not willing to go that path
because I cannot see huge benefits from them given what we already have and
also I lack P
Duy Nguyen writes:
>> At the least I think we should clarify this in the document.
>
> How about something like this? Would it help?
>
> -- 8< --
> Subject: [PATCH] git-commit.txt: clarify --patch mode with pathspec
>
> How pathspec is used, with and without --interactive/--patch, is
> different.
On Wed, Oct 5, 2016 at 10:00 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I thought about that, but as I concluded that the get_all_attrs doesn't need
>> conversion to a threading environment, we can keep it as is.
>
> I agree that it is OK for get_all_attrs() to use its own way to ask
SZEDER Gábor writes:
> And a final sidenote: sorting based on the longest matching suffix
> also allows us to (ab)use version sort with prerelease suffixes to
> sort postrelease tags as we please, too:
>
> $ ~/src/git/git -c versionsort.prereleasesuffix=-alpha \
> -c versionso
Stefan Beller writes:
> I thought about that, but as I concluded that the get_all_attrs doesn't need
> conversion to a threading environment, we can keep it as is.
I agree that it is OK for get_all_attrs() to use its own way to ask
a question and receive an answer to it, that is different from h
W dniu 05.10.2016 o 16:46, sorga...@gmail.com pisze:
> From: Sergey Organov
>
> Old description had a few problems:
>
> - sounded as if commits have changes
>
> - stated that changes are taken since some "divergence point"
> that was not defined.
>
> New description rather uses "common ances
On Wed, Oct 5, 2016 at 7:29 AM, Jeff King wrote:
> When we are copying the alternates from the source
> repository, if we find a relative path that is too deep for
> the source (e.g., "../../../objects" from "/repo.git/objects"),
> then normalize_path_copy will report an error and leave
> trash in
On Wed, Oct 5, 2016 at 7:40 AM, Jeff King wrote:
> On Wed, Oct 05, 2016 at 03:58:53PM +0200, Jakub Narębski wrote:
>
>> I would prefer the following:
>>
>> # A --> B --> C --> D --> E --> F --> G --> H
>> # 0 1 2 3 4 5 6
>
> Yeah, that is also more visually pleasing.
Hi Johannes,
>
>
> Original Message
> Subject: RE: [musl] Re: Regression: git no longer works with musl libc's
> regex impl
> From: Johannes Schindelin
> Date: Wed, October 05, 2016 3:49 am
> To: writeo...@midipix.org
> Cc: m...@lists.openwall.com, git@vger.kernel.org, Jeff Ki
On Wed, Oct 05, 2016 at 12:11:58PM -0400, Jeff King wrote:
> On Wed, Oct 05, 2016 at 10:59:34PM +1100, James B wrote:
>
> > Number downloads does not make first-tier platform. You know that as
> > well as everyone else.
> >
> > First-tier support is the decision made by the maintainers that the
>
Johannes Schindelin writes:
>> The function "git pull" uses to stop the user when the working
>> tree has changes is useful in other places.
>
> I stumbled over this sentence. How about
>
> The function used by "git pull" to stop [...]
>
> instead?
Perfect. Thanks.
Hello,
I want to deploy a hook script to control format of commit message. For this I
use the prepare-commit-msg script.
I want to check if the commit message starts with a number of 3 digits. If this
is the case, the script returns 0, otherwise 1.
It works fine for an utilisation with the git
On Wed, Oct 05, 2016 at 03:11:05PM +0200, Jakub Narębski wrote:
> W dniu 05.10.2016 o 00:33, Rich Felker pisze:
> > On Wed, Oct 05, 2016 at 09:06:25AM +1100, James B wrote:
> >> On Tue, 4 Oct 2016 18:08:33 +0200 (CEST)
> >> Johannes Schindelin wrote:
> >>>
> >>> No, it is not. You quote POSIX, but
On 04/10/2016 23:31, René Scharfe wrote:
So let's summarize; here's the effect of a raw qsort(3) call:
array == NULL nmemb bug QSORT following NULL check
- - --- -
0 0 no qsort is skipped
0 >0 no qsort is
Jeff King writes:
> On Wed, Oct 05, 2016 at 03:58:53PM +0200, Jakub Narębski wrote:
>
>> I would prefer the following:
>>
>> # A --> B --> C --> D --> E --> F --> G --> H
>> # 0 1 2 3 4 5 6
>
> Yeah, that is also more visually pleasing.
>
> Here's a squashable upda
Heiko Voigt writes:
>> It IS a hack, but having this information in .git would
>> mean that it can be forced to be in machine readable form, unlike a
>> mention in README. I do not know if the .gitmodules/.gitignore
>> combination is a sensible thing to use, but it does smell like a
>> potential
On Wed, Oct 05, 2016 at 10:59:34PM +1100, James B wrote:
> Number downloads does not make first-tier platform. You know that as
> well as everyone else.
>
> First-tier support is the decision made by the maintainers that the
> entire features of the software must be available on those first tier
Josef Ridky writes:
> Hi,
>
> I have just realize, that my attachment has been cut off from my previous
> message.
> Below you can find patch with requested change.
>
> Add support for user defined suffix part of name of temporary files
> created by git mergetool
> ---
The first two paragraphs
On Wed, Oct 5, 2016 at 8:47 AM, Jeff King wrote:
> On Tue, Oct 04, 2016 at 02:03:58PM -0700, Stefan Beller wrote:
>
>> thanks for the suggestions, both git_path(..) as well as checking the config,
>> this seems quite readable to me:
>>
>> builtin/push.c | 14 +-
>> 1 file changed, 13
On Tue, Oct 04, 2016 at 02:03:58PM -0700, Stefan Beller wrote:
> thanks for the suggestions, both git_path(..) as well as checking the config,
> this seems quite readable to me:
>
> builtin/push.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
Yeah, this seems like a goo
On Wed, Oct 05, 2016 at 03:58:53PM +0200, Jakub Narębski wrote:
> I would prefer the following:
>
> # A --> B --> C --> D --> E --> F --> G --> H
> # 0 1 2 3 4 5 6
Yeah, that is also more visually pleasing.
Here's a squashable update that uses that and clarifies t
From: Sergey Organov
Sergey Organov (6):
git-merge: clarify "usage" by adding "-m "
Documentation/git-merge.txt: remove list of options from SYNOPSIS
Documentation/git-merge.txt: fix SYNOPSIS of obsolete form to include
options
Documentation/git-merge.txt: improve short description in
From: Sergey Organov
This partial list of option is confusing as it lacks a lot of
available options. It also clutters the SYNOPSIS making differences
between forms of invocation less clear.
Signed-off-by: Sergey Organov
---
Documentation/git-merge.txt | 5 +
1 file changed, 1 insertion(+)
From: Sergey Organov
"-m " is one of essential distinctions between obsolete
invocation form and the recent one. Add it to the "usage" returned by
'git merge -h' for more clarity.
Signed-off-by: Sergey Organov
---
builtin/merge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
From: Sergey Organov
Old description not only raised the question of why the tool is called
git-merge rather than git-join, but "join histories" also sounds like
very simple operation, something like what "git-merge -s ours" does.
Signed-off-by: Sergey Organov
---
Documentation/git-merge.txt |
From: Sergey Organov
No awareness of git-pull is required to understand git-merge operation,
so leave reference to git-pull only where it actually makes sense, in
the description of fast-forward merges, and only as clarification of
when this merging behaviour is mostly useful.
Other references t
From: Sergey Organov
Old description had a few problems:
- sounded as if commits have changes
- stated that changes are taken since some "divergence point"
that was not defined.
New description rather uses "common ancestor" and "merge base",
definitions of which are easily discoverable in th
From: Sergey Organov
Signed-off-by: Sergey Organov
---
Documentation/git-merge.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 90342eb..216d2f4 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/gi
When we are copying the alternates from the source
repository, if we find a relative path that is too deep for
the source (e.g., "../../../objects" from "/repo.git/objects"),
then normalize_path_copy will report an error and leave
trash in the buffer, which we will add to our new alternates
file. I
W dniu 03.10.2016 o 22:36, Jeff King pisze:
> +test_expect_success 'count-objects shows the alternates' '
> + cat >expect <<-EOF &&
> + alternate: $(pwd)/B/.git/objects
> + alternate: $(pwd)/A/.git/objects
> + EOF
> + git -C C count-objects -v >actual &&
> + grep ^alternate
On Tue, Oct 04, 2016 at 12:01:13PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Stefan Beller writes:
> >
> >> I wonder if we could make that convenient for users by not tracking
> >> the submodule,
> >> i.e.
> >> * we have the information in the .gitmodules file
> >> * the path i
W dniu 04.10.2016 o 22:58, Stefan Beller pisze:
> On Tue, Oct 4, 2016 at 1:55 PM, Jeff King wrote:
>> On Tue, Oct 04, 2016 at 01:52:19PM -0700, Jacob Keller wrote:
>>
+# Note: These tests depend on the hard-coded value of 5 as "too
deep". We start
+# the depth at 0 and
Hi,
please do not top-post the conversation will otherwise get hard to
follow. Thank you.
On Tue, Oct 04, 2016 at 05:46:45PM +0200, Thomas Bétous wrote:
> Thank you for your answer and sorry for the delay (I was on vacation...).
>
> I am using git 2.9.0.windows.1 (run on Windows 7 via git bash).
On Tue, Oct 04, 2016 at 02:03:58PM -0700, Stefan Beller wrote:
> Jeff,
> thanks for the suggestions, both git_path(..) as well as checking the config,
> this seems quite readable to me:
When reading the discussion I thought the same: What about the
"old-style" repositories. I like this one. Checki
On Wed, Oct 05, 2016 at 01:17:49PM +0200, Johannes Schindelin wrote:
> Hi Rich,
>
> On Tue, 4 Oct 2016, Rich Felker wrote:
>
> > On Tue, Oct 04, 2016 at 06:08:33PM +0200, Johannes Schindelin wrote:
> >
> > > And lastly, the best alternative would be to teach musl about
> > > REG_STARTEND, as it i
W dniu 05.10.2016 o 00:33, Rich Felker pisze:
> On Wed, Oct 05, 2016 at 09:06:25AM +1100, James B wrote:
>> On Tue, 4 Oct 2016 18:08:33 +0200 (CEST)
>> Johannes Schindelin wrote:
>>>
>>> No, it is not. You quote POSIX, but the matter of the fact is that we use
>>> a subset of POSIX in order to be
1 - 100 of 120 matches
Mail list logo
