Hi Johannes,
thank you very much for this reply.
| Sent: Wednesday, October 5, 2016 11:04:17 PM
|
| 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
Change the documentation for push.tracking=* to re-include a mention
of what "tracking" does.
The "tracking" option was renamed to "upstream" back in
53c4031 ("push.default: Rename 'tracking' to 'upstream'", 2011-02-16),
this section was then subsequently rewritten in 87a70e4 ("config doc:
rewrite
Signed-off-by: Dimitriy Ryazantcev
---
po/git-gui.pot | 2203 +++-
1 file changed, 1205 insertions(+), 998 deletions(-)
diff --git a/po/git-gui.pot b/po/git-gui.pot
index 0c94f9c..634af68 100644
--- a/po/git-gui.pot
+++ b/po/git-gui.pot
@@ -8,4
This is v2 of patches I sent on September 21st starting at
<20160921114428.28664-1-ava...@gmail.com>. Jakub Narębski had a lot of
feedback for that series (thanks!). Which as far as I can tell I've
incorporated entirely in this re-roll.
Ævar Arnfjörð Bjarmason (3):
gitweb: Fix a typo in a commen
Change the minimum length of an abbreviated object identifier in the
commit message gitweb tries to turn into link from 8 hexchars to 7.
This arbitrary minimum length of 8 was introduced in bfe2191 ("gitweb:
SHA-1 in commit log message links to "object" view", 2006-12-10), but
the default abbrevia
Change a typo'd MIME type in a comment. The Content-Type is
application/xhtml+xml, not application/xhtm+xml.
Fixes up code originally added in 53c4031 ("gitweb: Strip
non-printable characters from syntax highlighter output", 2011-09-16).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
gitweb/gitweb.
Change the log formatting function to know about "git describe" output
such as "v2.8.0-4-g867ad08", in addition to just plain "867ad08".
There are still many valid refnames that we don't link to
e.g. v2.10.0-rc1~2^2~1 is also a valid way to refer to
v2.8.0-4-g867ad08, but I'm not supporting that w
Hi,
please also keep the mailinglist in the CC so everyone can read this.
On Thu, Oct 06, 2016 at 09:11:05AM +0200, Thomas Bétous wrote:
> On Wed, Oct 5, 2016 at 3:36 PM, Heiko Voigt wrote:
>
> >
> > My initial reaction is that this might be a problem with line endings. Did
> > you
> > check wh
On Wed, Oct 05, 2016 at 03:53:25PM +0200, Heiko Voigt wrote:
> 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 thou
The log --format="%d" includes preceding space:
$ git log -n1 --format="XX%dXX" HEAD
XX (HEAD -> master)XX
I know of no other % that is output in this way.
Is there a way of removing this preceding space through the format
string, or will it need to be a code change?
--
Tom Hale
> On 06 Oct 2016, at 11:32, Johannes Schindelin
> wrote:
>
> Hi Junio & Lars,
>
> On Wed, 5 Oct 2016, Junio C Hamano wrote:
>
>> Lars Schneider writes:
>>
>>> OK. Something like the patch below would work nicely.
>>
>> Yeah, something along that line; it would eliminate the need to
>> worr
Hi Junio & Lars,
On Wed, 5 Oct 2016, Junio C Hamano wrote:
> 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" ;-)
Not only a need to worry. Git for Windows
git ships with a compat/regex tree containing a recent regex
release, presumably with the intention of allowing systems with
either no regex or an old regex installed to use the newer compat
version.
With the release of git-2.10.1, the use of a recent regex
is now specifically checked in git-comp
On Thu, Oct 6, 2016 at 10:49 AM, Ævar Arnfjörð Bjarmason
wrote:
> Change the documentation for push.tracking=* to re-include a mention
> of what "tracking" does.
>
> The "tracking" option was renamed to "upstream" back in
> 53c4031 ("push.default: Rename 'tracking' to 'upstream'", 2011-02-16),
> t
Hi,
On Thu, 6 Oct 2016, Torsten Bögershausen wrote:
> >I am not suggesting that you apply this exact patch (stdin_ is not a good
> choice
>
> How about fd_stdin ?
Better: stdin_fd. Why? Prior art:
$ git grep -c stdin_fd
builtin/remote-ext.c:3
$ git grep -c fd_stdin
Ci
Hi Kuba,
On Wed, 5 Oct 2016, Jakub Narębski wrote:
> 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.
Yeah, I figured that it is
Hi James,
On Wed, 5 Oct 2016, James B wrote:
> On Wed, 5 Oct 2016 12:41:50 +0200 (CEST)
> Johannes Schindelin wrote:
>
> It's a very sad day for a tool that was developed originally to maintain
> Linux kernel, by the Linux kernel author, now is restricted to avoid
> use/optimise on Linux/POSIX
Throwing something at the mailing list to see if anybody is
interested.
Current '!' aliases move cwd to $GIT_WORK_TREE first, which could make
handling path arguments hard because they are relative to the original
cwd. We set GIT_PREFIX to work around it, but I still think it's more
natural to kee
Dearest Chosen One
With Due Respect And Humanity,I was compelled to write to you under a
humanitarian ground. My name is Mrs Amina Mohammed, My Husband was a director
in a trading company here in Cote D Ivoire.We were married for 36 years without
a child. He died after Cardiac Arteries operati
Ævar Arnfjörð Bjarmason writes:
> That's bad, either we shouldn't support it at all, or we should
> document what it does. This patch does the latter.
I vaguely remember a similar discussion and probably even a patch in the
past (maybe by you actually). I think the proposal was to add a mention
Junio C Hamano writes:
> 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
>>> "n
Junio C Hamano writes:
> 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
>
Hi Junio,
On Mon, 12 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I do not offhand see why we want to be lenient here,
> >> especially only to the left.
> >
> > Postel's Law.
>
> How would that compare/relate to yagni, though?
I did need it, though. Blame it on being o
This is the second of two variant for request to add option to change
suffix of name of temporary files generated by git mergetool. This
change is requested for cases, when is git mergetool used for local
comparison between two version of same package during package rebase.
Signed-off-by: Josef Ri
> On 04 Oct 2016, at 21:04, Jakub Narębski wrote:
>
> W dniu 03.10.2016 o 19:13, Lars Schneider pisze:
>>> On 01 Oct 2016, at 22:48, Jakub Narębski wrote:
>>> W dniu 01.10.2016 o 20:59, Lars Schneider pisze:
On 29 Sep 2016, at 23:27, Junio C Hamano wrote:
> Lars Schneider writes:
>
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
> On 04 Oct 2016, at 22:50, Jakub Narębski wrote:
>
> [Some of answers may get invalidated by v9]
>
> W dniu 30.09.2016 o 20:56, Lars Schneider pisze:
>>> On 27 Sep 2016, at 00:41, Jakub Narębski wrote:
>>>
+
+After the filter has processed a blob it is expected to wait for
+th
This is the first of two variant for request to add option to change
suffix of name of temporary files generated by git mergetool. This
change is requested for cases, when is git mergetool used for local
comparision between two version of same package during package rebase.
Signed-off-by: Josef Ri
Hi Junio,
On Sun, 11 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This makes the code consistent by fixing quite a couple of error messages.
>
> Looks OK. While at it, we may want another one to downcase the
> first word, perhaps?
>
> These may not be messages added by
When starting Git Bash, I receive the following errors:
0 [main] bash 18088 fork: child 14072 - died waiting for dll loading, errno 11
bash: fork: retry: No child processes
1190419 [main] bash 18088 fork: child 8744 - died waiting for dll loading,
errno 11
bash: fork: retry: No child processes
334
Hi Junio,
On Sun, 11 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > When translating error messages, we need to be careful *not* to translate
> > the todo commands such as "pick", "reword", etc because they are commands,
> > and Git would not understand translated versions
On Thu, 6 Oct 2016 14:02:09 +
"Vacha, Brian [USA]" wrote:
> When starting Git Bash, I receive the following errors:
> 0 [main] bash 18088 fork: child 14072 - died waiting for dll loading,
> errno 11 bash: fork: retry: No child processes
> 1190419 [main] bash 18088 fork: child 8744 - died wait
Johannes Schindelin writes:
> Hi Junio & Lars,
>
> On Wed, 5 Oct 2016, Junio C Hamano wrote:
>
>> 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" ;-)
Johannes Sixt writes:
> Therefore, I think that your patch as written does not help to reduce
> the confusion. It may be a building block for further improvement, but
> if you stop here, it is pointless.
Yup, you're right.
On Thu, Oct 06, 2016 at 03:13:19PM +0200, Lars Schneider wrote:
> >>> Well, it would be good to tell users _why_ Git is hanging, see below.
> >>
> >> Agreed. Do you think it is OK to write the message to stderr?
> >
> > On the other hand, this is why GIT_TRACE (and GIT_TRACE_PERFORMANCE)
> > was
Hello,
Sorry again for the mailing list...
On Thu, Oct 6, 2016 at 11:20 AM, Heiko Voigt wrote:
> So I guess the same applies to 'git status'?
No, it is the strange thing.
As told in my very first message here what happens after git diff and
git status:
$ git clone https://github.com/githubtrai
On Thu, Oct 6, 2016 at 2:13 PM, Matthieu Moy
wrote:
> Ęvar Arnfjörš Bjarmason writes:
>
>> That's bad, either we shouldn't support it at all, or we should
>> document what it does. This patch does the latter.
>
> I vaguely remember a similar discussion and probably even a patch in the
> past (may
Am 06.10.2016 um 15:08 schrieb Johannes Schindelin:
> Hi Junio,
>
> On Mon, 12 Sep 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
I do not offhand see why we want to be lenient here,
especially only to the left.
>>>
>>> Postel's Law.
>>
>> How would that compare/relate
Ævar Arnfjörð Bjarmason writes:
> Junio, looks like from the 2013 discussion that you preferred just
> having that mention in parenthesis instead of its own item, how about
> just re-applying your fa23348 (with conflicts resolved)?
(fa23348 did this:
--- a/Documentation/config.txt
+++ b/Document
This fixes an infinite loop bug dating back to the v1.8.x era.
Triggering it requires creating a broken symbolic link in the .git
directory, so I don't think it's security-interesting. It should apply
cleanly on "maint".
[1/2]: files_read_raw_ref: avoid infinite loop on broken symlinks
[2/2]:
Limit the number of retries to 3. That should be adequate to
prevent any races, while preventing the possibility of
infinite loops if the logic fails to handle any other
possible error modes correctly.
After the fix in the previous commit, there's no known way
to trigger an infinite loop, but I di
Our ref resolution first runs lstat() on any path we try to
look up, because we want to treat symlinks specially (by
resolving them manually and considering them symrefs). But
if the results of `readlink` do _not_ look like a ref, we
fall through to treating it like a normal file, and just
read the
Josef Ridky writes:
> I agree, that this patch is written as general as possible and can
> possibly bring more confusion than benefits.
I am not sure about that. Other people would have similar but
different workflow needs where they compare local new one with local
old one that would be helped
web1_re...@theadagio.com.tw
（凭此邮件优惠1000元/公司，需回信专用接收邮箱“12809...@qq.com”报名参展）
JEC world Composites Show & Conferences 2017
2017第52届JEC世界复合材料展览及会议
—— 参加JEC展会是一个复合材料及新材料企业走向国际化的标志和途径
【中文名称】 2017第52届世界JEC复合材料展览及会议（法国巴黎）
【英文名称】 The 52th JEC Composites Show & Conferences 2017 in Paris France （
Josef Ridky writes:
> + --local=*)
> + temp_name=${1#--local=}
> + if [ "$temp_name" != "" ] && [ "$temp_name" != "$REMOTE_NAME" ]
> && [ "$temp_name" != "$BASE_NAME" ] && [ "$temp_name" != "$BACKUP_NAME" ]
> + then
> + LOCAL_NAME=$temp
Jeff King writes:
> I am not sure if I have followed all of this discussion, but I am of the
> opinion that Git should not be doing any timeouts at all.
> ...
> If this is debugging output of the form "now I am calling wait() on all
> of the filters", without respect to any timeout, that sounds r
On Thu, Oct 6, 2016 at 2:23 AM, Heiko Voigt wrote:
> On Wed, Oct 05, 2016 at 03:53:25PM +0200, Heiko Voigt wrote:
>> 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 qu
Lars Schneider writes:
> You are right. Would the solution below be acceptable?
> I would like to keep the `packet_size` variable as it eases the rest
> of the function.
>
>
> const size_t packet_size = size + 4;
>
> - if (packet_size > sizeof(packet_write_buffer))
> + if (size
Sergey Organov writes:
>>> Last, if "reference" is not good enough and we get to internals anyway,
>>> why not say SHA1 then?
>>
>> Because that is still colloquial? I think s/name/object name/ is a
>> sensible change, but not s/name/reference/.
>
> No, "reference" is more sensible here than any
Sergey Organov writes:
> Ah, I now see. I tried to keep the text intact as much as possible, and
> only split it into description and a note. Well, how about this then:
Much better than your earlier patch, but I am not sure if the
updated one is that much better compared to the original.
The pr
Matthieu Moy writes:
> Ævar Arnfjörð Bjarmason writes:
>
>> Junio, looks like from the 2013 discussion that you preferred just
>> having that mention in parenthesis instead of its own item, how about
>> just re-applying your fa23348 (with conflicts resolved)?
>
> (fa23348 did this:
> --- a/Docum
Richard Lloyd writes:
> git ships with a compat/regex tree containing a recent regex
> release, presumably with the intention of allowing systems with
> either no regex or an old regex installed to use the newer compat
> version.
Quick question. Does NO_REGEX help? cf. Makefile
# Define NO_RE
Johannes Sixt writes:
> Let me take the opportunity to say
>
>Thank You Very Much!
>
> for the new implementation of rebase -i. I'm using your branch
> rebase-i-extra, and it is such a pleasure to work with on Windows
> compared to the old fully scripted version.
Thanks for testing.
Havin
Nguyễn Thái Ngọc Duy writes:
> Throwing something at the mailing list to see if anybody is
> interested.
>
> Current '!' aliases move cwd to $GIT_WORK_TREE first, which could make
> handling path arguments hard because they are relative to the original
> cwd. We set GIT_PREFIX to work around it,
"Ravi (Tom) Hale" writes:
> The log --format="%d" includes preceding space:
>
> $ git log -n1 --format="XX%dXX" HEAD
> XX (HEAD -> master)XX
>
> I know of no other % that is output in this way.
That is primarily because %d predates %[-+ ] mechanism,
I think. It is too late to redefine what "%d"
On Thu, Oct 06, 2016 at 06:41:24PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Throwing something at the mailing list to see if anybody is
> interested.
>
> Current '!' aliases move cwd to $GIT_WORK_TREE first, which could make
> handling path arguments hard because they are relative to the original
> c
On Thu, Oct 06, 2016 at 03:00:14PM -0400, Jeff King wrote:
> PS I think your "!!" syntax conflicts with something like:
>
> git -c alias.has-changes='!! git diff --quiet' has-changes
>
>I don't know if that is worth worrying about or not. I also notice
>that using "!!git diff" with n
On Thu, Oct 06, 2016 at 10:15:49AM +0100, Richard Lloyd wrote:
> Unfortunately, on systems with an older regex shipped as
> standard (e.g. HP-UX 11), the include path picks up
> /usr/include/regex.h first, which doesn't define REG_STARTEND
> and the git-compat-util.h check fails.
>
> The fix I ap
Duy Nguyen writes:
> On Tue, Oct 4, 2016 at 11:15 PM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> We don't use it internally _yet_. I need to go through all the
>>> external diff code and see --shift-ita should be there. The end goal
>>> is still changing the default behavior and getting
On Tue, Oct 4, 2016 at 6:08 PM, Johannes Schindelin
wrote:
> As to making NO_REGEX conditional on REG_STARTEND: you are talking about
> apples and oranges here. NO_REGEX is a Makefile flag, while REG_STARTEND
> is a C preprocessor macro.
>
> Unless you can convince the rest of the Git developers (
Johannes Schindelin writes:
> If you prefer to accept such sloppy work, I will change it of course,
> feeling dirty that it has my name on it.
I do want neither leaks nor sloppyness, and I thought that was
understood by everybody, hence I thought the last round made it
clear that _entrust() must
On Thu, Oct 06, 2016 at 09:18:29PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Oct 4, 2016 at 6:08 PM, Johannes Schindelin
> wrote:
> > As to making NO_REGEX conditional on REG_STARTEND: you are talking about
> > apples and oranges here. NO_REGEX is a Makefile flag, while REG_STARTEND
> > is
On Thu, Oct 06, 2016 at 03:23:40PM -0400, Jeff King wrote:
> On Thu, Oct 06, 2016 at 09:18:29PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > On Tue, Oct 4, 2016 at 6:08 PM, Johannes Schindelin
> > wrote:
> > > As to making NO_REGEX conditional on REG_STARTEND: you are talking about
> > > apples an
Jonathan Tan writes:
> How important is this feature? It doesn't seem too difficult to add,
> although it does break compatibility (in particular, "--signoff" must
> now be documented as "after the last trailer" instead of "at the end
> of the commit message").
The sign-off has always been meant
On Thu, Oct 06, 2016 at 03:25:00PM -0400, Rich Felker wrote:
> > No, I think that is the exact purpose of configure.ac and autoconf.
> >
> > It would be neat if we could auto-fallback during the build. Rich
> > suggested always compiling compat/regex.c, and just having it be a noop
> > at the pre
Am 06.10.2016 um 18:48 schrieb Jeff King:
+test_expect_success SYMLINKS 'ref resolution not confused by broken symlinks' '
+ ln -s does-not-exist .git/broken &&
+ test_must_fail git rev-parse --verify broken
Hm, lower-case named refs directly in .git are frowned upon, no? If we
eve
This is a reroll of
http://public-inbox.org/git/20161004210359.15266-1-sbel...@google.com/
([PATCHv3 1/2] push: change submodule default to check when submodules exist)
but with a test.
As we only have a heuristic, the test failed initially as these tests don't
have any configuration at all nor do
Currently the force flag in `git submodule add` takes care of possibly
ignored files or when a name collision occurs.
However there is another situation where submodule add comes in handy:
When you already have a gitlink recorded, but no configuration was
done (i.e. no .gitmodules file nor any ent
When working with submodules, it is easy to forget to push the submodules.
The setting 'check', which checks if any existing submodule is present on
at least one remote of the submodule remotes, is designed to prevent this
mistake.
Flipping the default to check for submodules is safer than the cur
On Thu, Oct 06, 2016 at 09:31:22PM +0200, Johannes Sixt wrote:
> Am 06.10.2016 um 18:48 schrieb Jeff King:
> > +test_expect_success SYMLINKS 'ref resolution not confused by broken
> > symlinks' '
> > + ln -s does-not-exist .git/broken &&
> > + test_must_fail git rev-parse --verify broken
>
>
Ævar Arnfjörð Bjarmason writes:
> Change the minimum length of an abbreviated object identifier in the
> commit message gitweb tries to turn into link from 8 hexchars to 7.
>
> This arbitrary minimum length of 8 was introduced in bfe2191 ("gitweb:
> SHA-1 in commit log message links to "object"
Ævar Arnfjörð Bjarmason writes:
> Change the log formatting function to know about "git describe" output
> such as "v2.8.0-4-g867ad08", in addition to just plain "867ad08".
>
> There are still many valid refnames that we don't link to
> e.g. v2.10.0-rc1~2^2~1 is also a valid way to refer to
> v2
Stefan Beller writes:
> Currently the force flag in `git submodule add` takes care of possibly
> ignored files or when a name collision occurs.
>
> However there is another situation where submodule add comes in handy:
> When you already have a gitlink recorded, but no configuration was
> done (i
Hi,
At GitLab, we are annoyed by the fact that `git log` doesn't seem to
work well when using it with both --follow and --skip.
For example:
> git log --oneline -6 README.md
a299e3a README.md: format CLI commands with code syntax
c9a014e README.md: don't take 'commandname' literally
a217f07 READ
Stefan Beller writes:
> When working with submodules, it is easy to forget to push the submodules.
> The setting 'check', which checks if any existing submodule is present on
> at least one remote of the submodule remotes, is designed to prevent this
> mistake.
>
> Flipping the default to check f
> On 04 Oct 2016, at 23:00, Jakub Narębski wrote:
>
> [Some of answers and comments may got invalidated by v9]
>
> W dniu 30.09.2016 o 21:38, Lars Schneider pisze:
>>> On 27 Sep 2016, at 17:37, Jakub Narębski wrote:
>>>
>>> Part second of the review of 11/11.
> [...]
+
+ if (start_
On Thu, Oct 6, 2016 at 1:25 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When working with submodules, it is easy to forget to push the submodules.
>> The setting 'check', which checks if any existing submodule is present on
>> at least one remote of the submodule remotes, is designed t
Junio C Hamano writes:
> Michael J Gruber writes:
>
>> Also, I'm open to using another letter for EXPKEYSIG but couldn't decide
>> between 'Y', 'Z', 'K'. 'K' could be confused with REVKEYSIG, I'm afraid.
>> 'Y' is next to 'X' and contained in 'KEY', it would be my first choice.
>
> Sounds good e
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.
A handful of topics have been merg
W dniu 06.10.2016 o 21:23, Junio C Hamano pisze:
> Johannes Schindelin writes:
>
>> If you prefer to accept such sloppy work, I will change it of course,
>> feeling dirty that it has my name on it.
>
> I do want neither leaks nor sloppyness, and I thought that was
> understood by everybody, henc
On 06/10/16 20:18, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Oct 4, 2016 at 6:08 PM, Johannes Schindelin
> wrote:
>> As to making NO_REGEX conditional on REG_STARTEND: you are talking about
>> apples and oranges here. NO_REGEX is a Makefile flag, while REG_STARTEND
>> is a C preprocessor macro.
>
Jakub Narębski writes:
>> We manage lifetime of a field in a structure in one of three ways in
>> our codebase [*1*].
>>
>> ...
>> * A field can sometimes own and sometimes borrow the memory, and it
>>is accompanied by another field to tell which case it is, so that
>>cleaning-up can t
When working with submodules, it is easy to forget to push the submodules.
The setting 'check', which checks if any existing submodule is present on
at least one remote of the submodule remotes, is designed to prevent this
mistake.
Flipping the default to check for submodules is safer than the cur
Signed-off-by: David Aguilar
---
git-mergetool.sh | 180 ---
1 file changed, 93 insertions(+), 87 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 300ce7f..b2cd0a4 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -366,
Signed-off-by: David Aguilar
---
git-mergetool.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index bf86270..300ce7f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -3,6 +3,7 @@
# This program resolves merge conflicts in git
#
# Copyright (c)
Teach mergetool to get the list of files to edit via `diff` so that we
gain support for diff.orderFile.
Suggested-by: Luis Gutierrez
Helped-by: Johannes Sixt
Signed-off-by: David Aguilar
---
Documentation/git-mergetool.txt | 5 +
git-mergetool.sh| 30 +++---
Teach mergetool to pass "-O" down to `git diff` when
specified on the command-line.
Signed-off-by: David Aguilar
---
Documentation/git-mergetool.txt | 10 ++
git-mergetool.sh| 14 --
t/t7610-mergetool.sh| 27 +++
3 files cha
Signed-off-by: Stefan Beller
---
This was raised in the discussion of
https://public-inbox.org/git/20161006193725.31553-1-sbel...@google.com/raw
However this can go as a separate patch instead of adding it to the series.
Thanks,
Stefan
Documentation/config.txt | 15 +++
1 file ch
On Tue, Sep 27, 2016 at 09:11:58PM +0200, René Scharfe wrote:
> Call strbuf_add_unique_abbrev() to add abbreviated hashes to strbufs
> instead of taking detours through find_unique_abbrev() and its static
> buffer. This is shorter and a bit more efficient.
> [...]
> diff --git a/diff.c b/diff.c
>
Teach mergetool to pass "-O" down to `git diff` when
specified on the command-line.
Signed-off-by: David Aguilar
---
This is a replacement patch for 4/4 from the original series.
The changes are stylistic -- the "order_file" variable name and
"-O" in the usage were changed to "orderfile" and
"-O
On Thu, Oct 06, 2016 at 03:24:17PM -0700, Junio C Hamano wrote:
> 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 branche
Am 07.10.2016 um 01:47 schrieb David Aguilar:
Signed-off-by: David Aguilar
---
An answer to "why?" is missing here. I guess it is just so that
everything happens in functions, and that there is only the invocation
of main at the top-level of the script. I am unsure whether this is
sufficien
Make it easier to follow the program's flow by isolating all
logic into functions. Isolate the main execution code path into
a single unit instead of having prompt_after_failed_merge()
interrupt it partyway through.
The use of a main() function is borrowing a convention from C,
Python, Perl, and
93 matches
Mail list logo
