Re: [PATCH v7 0/3] RUNTIME_PREFIX relocatable Git

On Mon, Mar 26 2018, Daniel Jacques wrote: > On Sun, Mar 25, 2018 at 5:15 PM Ævar Arnfjörð Bjarmason > wrote: > >> This looks good to me this time around, couple of small nits (maybe >> Junio can amend while queuing): > >> * You add a dependnecy typo in 2/3 but fix it again

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote: > On 12/03/2018 11:20, Johannes Schindelin wrote: > > > > > > [...] and cannot introduce ambiguities when rebasing the > > > > changes introduced by M (i.e. the "amendmendts" we talked about). > > > > > > Hmm, not following here, which

Cześć słodka

Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym znowu czuję się kochana ... Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka .. Proszę wybaczyć moje

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Sergey, On Wed, 14 Mar 2018, Sergey Organov wrote: > Igor Djordjevic writes: > > > On 07/03/2018 08:26, Johannes Schindelin wrote: > > [...] > > >> Second side note: if we can fast-forward, currently we prefer that, > >> and I think we should keep that

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Junio, On Tue, 13 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > If so, what tooling do you have to identify quickly what to > > cherry-pick, given merge conflicts? > > It exactly is the issue I've been trying to find ideal solution for >

[PATCH v2] test_must_be_empty: simplify file existence check

Commit 11395a3b4b (test_must_be_empty: make sure the file exists, not just empty, 2018-02-27) basically duplicated the 'test_path_is_file' helper function in 'test_must_be_empty'. Just call 'test_path_is_file' to avoid this code duplication. Signed-off-by: SZEDER Gábor ---

Re: [PATCH] test_must_be_empty: simplify file existence check

On Mon, Mar 26, 2018 at 2:48 PM, Jeff King wrote: > On Mon, Mar 26, 2018 at 01:58:15PM +0200, SZEDER Gábor wrote: > >> Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not >> just empty, 2018-02-27) basically duplicated the 'test_path_is_file' >> helper function in

Re: [RFC 0/1] Tolerate broken headers in `packed-refs` files

On 3/26/2018 8:42 AM, Michael Haggerty wrote: [...] But there might be some tools out in the wild that have been writing broken headers. In that case, users who upgrade Git might suddenly find that they can't read repositories that they could read before. In fact, a tool that we wrote and use

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote: > On 12/03/2018 11:46, Johannes Schindelin wrote: > > > > > Sometimes one just needs to read the manual, and I don`t really > > > think this is a ton complicated, but just something we didn`t really > > > have before (real merge rebasing), so

Re: [PATCH v7 0/3] RUNTIME_PREFIX relocatable Git

On Sun, Mar 25, 2018 at 5:15 PM Ævar Arnfjörð Bjarmason wrote: > This looks good to me this time around, couple of small nits (maybe > Junio can amend while queuing): > * You add a dependnecy typo in 2/3 but fix it again in 3/3. Should be > squashed. d'oh, I'll fix that

Re: [PATCH v7 0/3] RUNTIME_PREFIX relocatable Git

On Mon, Mar 26, 2018 at 2:01 AM Junio C Hamano wrote: > When testing the non-relocatable (i.e. traditional) Git, we use > GIT_EXEC_PATH and bin-wrappers/ trick to ensure that we test the > version we just have built, not a random version that happen to be > on the $PATH,

Re: [PATCH] test_must_be_empty: simplify file existence check

On Mon, Mar 26, 2018 at 01:58:15PM +0200, SZEDER Gábor wrote: > Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not > just empty, 2018-02-27) basically duplicated the 'test_path_is_file' > helper function in 'test_must_be_empty'. > > Just call 'test_path_is_file' to avoid this

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On Mon, 12 Mar 2018, Sergey Organov wrote: > Johannes Schindelin writes: > > > [...] > > > > Where "easy" meant that I had to spend 1h still to figure out why > > using the unrebased merge parents as merge bases. > > That's because you try to figure out

[RFC 1/1] packed-backend: ignore broken headers

Prior to 9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data, 2017-07-01 we silently ignored any lines in a `packed-refs` file that we didn't understand. That policy was clearly wrong. But at the time, unrecognized header lines were processed by the same code as

[RFC 0/1] Tolerate broken headers in `packed-refs` files

Prior to 9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data, 2017-07-01 we silently ignored pretty much any bogus data in a `packed-refs` file. I think that was pretty clearly a bad policy. The above commit made parsing quite a bit stricter, calling `die()` if it found

Re: [PATCH v2] branch: implement shortcut to delete last branch

Thanks for Cc-ing me, and sorry for not being very responsive these days :-\. Jeff King writes: > On Fri, Mar 23, 2018 at 10:40:34PM +, Aaron Greenberg wrote: > >> I can appreciate Matthieu's points on the use of "-" in destructive >> commands. As of this writing, git-merge supports the "-"

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote: > On 12/03/2018 13:56, Sergey Organov wrote: > > > > > > I agree with both of you that `pick ` is inflexible > > > > (not to say just plain wrong), but I never thought about it like > > > > that. > > > > > > > > If we are to extract further

[PATCH] test_must_be_empty: simplify file existence check

Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not just empty, 2018-02-27) basically duplicated the 'test_path_is_file' helper function in 'test_must_be_empty'. Just call 'test_path_is_file' to avoid this code duplication. Signed-off-by: SZEDER Gábor ---

Re: [PATCH] completion: clear cached --options when sourcing the completion script

On Fri, Mar 23, 2018 at 6:35 PM, Junio C Hamano wrote: > Junio C Hamano writes: >> I'd say we should just add !GETTEXT_POISON prereq to the problematic >> tests. > IOW, this is the minumum required. Thanks for already committing the fix, I couldn't get

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On Mon, 12 Mar 2018, Sergey Organov wrote: > Johannes Schindelin writes: > > Hi Sergey, > > [...] > > > That is misrepresenting what happened. > > No, it's you who are spreading misinformation, probably unintentional, > but still. Way to go, Sergey.

+Hey,i am Lindsey ,How's everything with you,I have interest on you after going through your profile I really want to have a good friendship with you.Beside i have something very vital to tell you

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On Mon, 12 Mar 2018, Sergey Organov wrote: > Johannes Schindelin writes: > > > > On Wed, 7 Mar 2018, Sergey Organov wrote: > > > >> Johannes Schindelin writes: > >> > >> > How can your approach -- which relies *very much* on

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On Mon, 12 Mar 2018, Sergey Organov wrote: > [...] > > Yet another consequence is that my approach will likely result in better > code reuse. This is a purely academic speculation. At least until somebody implements Phillip's method. Oh wait, I already started to implement it, and

Re: FW: Merging in Git with Branches

On Mon, Mar 26, 2018 at 10:12:04AM +, shirlin.jos...@bt.com wrote: [...] > Currently there are two main branches that we are utilizing A(master) > and B(branch of A). Branch is utilised for individual stories(as per > delivery). [...] Cross-posted to [1] as well. 1.

FW: Merging in Git with Branches

Hi Git team, I have a query. Scenario: Currently there are two main branches that we are utilizing A(master) and B(branch of A). Branch is utilised for individual stories(as per delivery). When branch is utilised since the team size is huge the number of changes/ branches created for

git shortlog --author=Me

If I have a .mailmap file containing Me brendanator And I run git log --author=Me I see all my commits However if I run git shortlog --author=Me my commits are not shown

[PATCH v3] Allow use of TLS 1.3

Add a tlsv1.3 option to http.sslVersion in addition to the existing tlsv1.[012] options. libcurl has supported this since 7.52.0. Signed-off-by: Loganaden Velvindron --- Documentation/config.txt | 1 + http.c | 3 +++ 2 files changed, 4 insertions(+) diff

Re: [PATCH v2 0/4] Teach `--default` to `git-config(1)`

On Fri, Mar 23, 2018 at 08:55:52PM -0400, Taylor Blau wrote: > Attached is 'v2' of my patch series to add a `--default` option to `git > config`. Thanks, this is looking much better. I did come up with a few suggestions/fixes. Some minor which would make v3 easy, and some that would require

Re: [PATCH v2 4/4] builtin/config: introduce `--color` type specifier

On Fri, Mar 23, 2018 at 08:55:56PM -0400, Taylor Blau wrote: > As of this commit, the canonical way to retreive an ANSI-compatible > color escape sequence from a configuration file is with the > `--get-color` action. s/retreive/retrieve/ > This is to allow Git to "fall back" on a default value

Re: [PATCH v2 2/4] Documentation: list all type specifiers in config prose

On Fri, Mar 23, 2018 at 08:55:54PM -0400, Taylor Blau wrote: > The documentation for the `git-config(1)` builtin has not been recently > updated to include new types, such as `--bool-or-int`, and > `--expiry-date`. To ensure completeness when adding a new type > specifier, let's update the

Re: [PATCH v2 1/4] builtin/config: introduce `--default`

On Fri, Mar 23, 2018 at 08:55:53PM -0400, Taylor Blau wrote: > This commit (and those following it in this series) aim to eventually > replace `--get-color` with a consistent alternative. By introducing > `--default`, we allow the `--get-color` action to be promoted to a > `--color` type

Re: [PATCH v2] branch: implement shortcut to delete last branch

On Fri, Mar 23, 2018 at 10:40:34PM +, Aaron Greenberg wrote: > I updated the commit message to include my first email's cover letter > and cleaned up the test. Thanks. This one looks good to me. > I can appreciate Matthieu's points on the use of "-" in destructive > commands. As of this

Cześć słodka

Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym znowu czuję się kochana ... Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka .. Proszę wybaczyć moje

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Mon, Mar 26, 2018 at 3:25 AM, Jeff King wrote: > OK, so here's some patches. We could do the first three now, wait a > while before the fourth, and then wait a while (or never) on the fifth. > > [1/5]: t3200: unset core.logallrefupdates when testing reflog creation > [2/5]:

Cześć słodka

Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym znowu czuję się kochana ... Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka .. Proszę wybaczyć moje

[PATCH 5/5] branch: make "-l" a synonym for "--list"

The other "mode" options of git-branch have short-option aliases that are easy to type (e.g., "-d" and "-m"). Let's give "--list" the same treatment. This also makes it consistent with the similar "git tag -l" option. We didn't do this originally because "--create-reflog" was squatting on the

[PATCH 4/5] branch: drop deprecated "-l" option

We marked the "-l" option as deprecated back in . Now that sufficient time has passed, let's follow through and get rid of it. Signed-off-by: Jeff King --- I'll need some help from the maintainer on the commit message. :) builtin/branch.c | 15 --- 1 file changed, 15

[PATCH 3/5] branch: deprecate "-l" option

The "-l" option is short for "--create-reflog". This has caused much confusion over the years. Most people expect it to work as "--list", because that would match the other "mode" options like -d/--delete and -m/--move, as well as the similar -l/--list option of git-tag. Adding to the confusion,

[PATCH 2/5] t: switch "branch -l" to "branch --create-reflog"

In preparation for deprecating "-l", let's make sure we're using the recommended option ourselves. This patch just mechanically converts "branch -l" to "branch --create-reflog". Note that with the exception of the actual "--create-reflog" test, we could actually remove "-l" entirely from most of

[PATCH 1/5] t3200: unset core.logallrefupdates when testing reflog creation

This test checks that the "-l" option creates a reflog. But in fact we'd create one even without it, since the default in a non-bare repository is to do so. Let's unset the config so we can be sure our "-l" option is kicking in. Note that we can't do this with test_config, since that would leave

[PATCH v2 1/2] perf/aggregate: add display_dir()

This new helper function will be reused in a subsequent commit. Signed-off-by: Christian Couder --- t/perf/aggregate.perl | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl index

[PATCH v2 2/2] perf/aggregate: add --sort-by=regression option

One of the most interesting thing one can be interested in when looking at performance test results is possible performance regressions. This new option makes it easy to spot such possible regressions. This new option is named '--sort-by=regression' to make it possible and easy to add other ways

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Sun, Mar 25, 2018 at 12:15:42AM -0700, Jacob Keller wrote: > > 3. Drop "-l" (probably with a deprecation period); it seems unlikely > > to me that anybody uses it for branch creation, and this would at > > least reduce the confusion (then it would just be "so why don't we > >

[PATCH v2 0/2] perf/aggregate: sort results by regression

This small patch series makes it easy to spot big performance regressions, so that they can later be investigated. For example: $ ./aggregate.perl --sort-by=regression --subsection "without libpcre" v2.14.3 v2.15.1 v2.16.2 p4220-log-grep-engines.sh +5.0% p4220-log-grep-engines.2

Re: [PATCH v2 3/6] stash: convert apply to builtin

On Mon, Mar 26, 2018 at 3:14 AM, Joel Teichroeb wrote: > Signed-off-by: Joel Teichroeb The commit message in this patch and the following ones could be a bit more verbose. It could at least tell that the end goal is to convert git-stash.sh to a C builtin.

Re: [PATCH v7 0/3] RUNTIME_PREFIX relocatable Git

Dan Jacques writes: > This patch set expands support for the RUNTIME_PREFIX configuration flag, > currently only used on Windows builds, to include Linux, Darwin, and > FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its > ancillary paths relative to the

Re: [PATCH] Remove contrib/examples/*

On Sun, Mar 25, 2018 at 08:46:53PM +, Ævar Arnfjörð Bjarmason wrote: > There were some side discussions at Git Merge this year about how we > should just update the README to tell users they can dig these up from > the history if the need them, do that. > > Looking at the "git log" for this

<    1   2