Hello

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

Re: Opinions on changing add/add conflict resolution?

While I do not think it is a bad idea to add an optional way to write the contents of conflicted stages out to separate files, I do not think it is a good idea to change what happens to add/add conflict by default. Two integrators picking up a same patch that adds a file separately and allowing

[GSoC][PATCH] git-ci: use pylint to analyze the git-p4 code

Hello Mr. Schneider, Here is my link for the passed CI build I tested on my fork: https://travis-ci.org/VietHTran/git/builds/35210 In order to test .travis.yml configuration alone, I used a sample python script call "test.py" that is already successfully tested on my computer instead of

Fwd: Opinions on changing add/add conflict resolution?

[Re-sending because this computer happened to have plain-text mode turned off for some weird reason, and thus the email bounced] Hi, On Mon, Mar 12, 2018 at 3:19 PM, Ævar Arnfjörð Bjarmason wrote: > > Does this mean that e.g. in this case of merging two files, one > containing

Re: Git Merge contributor summit notes

On 03/12, Jeff King wrote: > On Sat, Mar 10, 2018 at 02:01:14PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > > - (peff) Time to deprecate the git anonymous protocol? > > [...] > > > > I think the conclusion was that nobody cares about the git:// protocol, > > but people do care about it being

Re: Opinions on changing add/add conflict resolution?

I'm worried that my attempt to extract add/add from the rest of the discussion with rename/add and rename/rename resulted in a false sense of simplification. Trying to handle all the edge and corner cases and remain consistent sometimes gets a little hairy. Anyway... On Mon, Mar 12, 2018 at

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

Hi Dscho, 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 ambiguities are we talking about? > > U1' vs U2' of course.

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

Hi Dscho, 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 it requires a moment to grasp the > > concept. > >

Re: [PATCH 0/2] Make cvs tests pass with '-x' tracing and /bin/sh

On Thu, Mar 08, 2018 at 01:38:42PM +0100, SZEDER Gábor wrote: > > I installed 'cvs' and whatnot to run t94* and t96* tests, and sure > > enough, 5 tests in 2 test scripts fail with '-x' tracing and /bin/sh. > > I think I will be able to get around to send v2 during the weekend. > > Well, I

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

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 mentioned explicit old:new merge > > > parameter mapping to a separate

Re: [PATCH 0/4] Speed up git tag --contains

On Mon, Mar 12, 2018 at 09:45:27AM -0400, Derrick Stolee wrote: > > diff --git a/builtin/branch.c b/builtin/branch.c > > index 8dcc2ed058..4d674e86d5 100644 > > --- a/builtin/branch.c > > +++ b/builtin/branch.c > > @@ -404,6 +404,7 @@ static void print_ref_list(struct ref_filter *filter, > >

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

Hi Dscho, On 12/03/2018 11:37, Johannes Schindelin wrote: > > > If we are to extract further mentioned explicit old:new merge > > parameter mapping to a separate discussion point, what we`re > > eventually left with is just replacing this: > > > > merge -R -C > > > > ... with this: > > >

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

On Mon, Mar 12, 2018 at 04:37:47PM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > We could even give it an environment variable, which would allow > > something like: > > > > tar xf maybe-evil.git.tar > > cd maybe-evil > > export GIT_TRUST_REPO=false > > git log > [...] > As an

Re: [PATCH v3 12/35] serve: introduce git-serve

On Tue, Mar 06, 2018 at 07:29:02AM +0100, Jeff King wrote: > > We want to do better (e.g. see [1]) but that's a bigger change than > > the initial protocol v2. > > > > As Brandon explained it to me, we really do want to use stateless-rpc > > semantics by default, since that's just better for

Re: Git Merge contributor summit notes

On Sat, Mar 10, 2018 at 02:01:14PM +0100, Ævar Arnfjörð Bjarmason wrote: > > - (peff) Time to deprecate the git anonymous protocol? > [...] > > I think the conclusion was that nobody cares about the git:// protocol, > but people do care about it being super easy to spin up a server, and >

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Jeff King wrote: > We could even give it an environment variable, which would allow > something like: > > tar xf maybe-evil.git.tar > cd maybe-evil > export GIT_TRUST_REPO=false > git log Interesting idea. Putting it in an envvar means it gets inherited by child processes, which if I

Re: Git Merge contributor summit notes

On Fri, Mar 09, 2018 at 04:06:18PM -0800, Alex Vandiver wrote: > It was great to meet some of you in person! Some notes from the > Contributor Summit at Git Merge are below. Taken in haste, so > my apologies if there are any mis-statements. Thanks very much for these notes! I think in future

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

On Mon, Mar 12, 2018 at 03:43:55PM -0700, Jonathan Nieder wrote: > Hi, > > Jeff King wrote: > > On Thu, Feb 22, 2018 at 01:26:34PM -0800, Jonathan Nieder wrote: > > >> Keep in mind that git upload-archive (a read-only command, just like > >> git upload-pack) also already has the same issues. >

Re: Opinions on changing add/add conflict resolution?

Hi, Hilco Wijbenga wrote: > On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder wrote: >> Interesting. I would be tempted to resolve this inconsistency the >> other way: by doing a half-hearted two-way merge (e.g. by picking one >> of the two versions of the colliding file)

Re: Opinions on changing add/add conflict resolution?

On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder wrote: > Interesting. I would be tempted to resolve this inconsistency the > other way: by doing a half-hearted two-way merge (e.g. by picking one > of the two versions of the colliding file) and marking the path as >

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Hi, Jeff King wrote: > On Thu, Feb 22, 2018 at 01:26:34PM -0800, Jonathan Nieder wrote: >> Keep in mind that git upload-archive (a read-only command, just like >> git upload-pack) also already has the same issues. > > Yuck. I don't think we've ever made a historical promise about that. But >

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

Hi Dscho, On 11/03/2018 23:04, Igor Djordjevic wrote: > > I`m yet to read (and reason about) your whole (very informative) > reply, but I just wanted to address this part first, as it might be a > clear end-game situation already, due to a mutual agreement, all the > rest being purely

Re: [PATCH v4 05/35] upload-pack: factor out processing lines

On 03/12, Brandon Williams wrote: > On 03/01, Junio C Hamano wrote: > > Brandon Williams writes: > > > > > Factor out the logic for processing shallow, deepen, deepen_since, and > > > deepen_not lines into their own functions to simplify the > > > 'receive_needs()' function in

Re: [PATCH v4 05/35] upload-pack: factor out processing lines

On 03/01, Junio C Hamano wrote: > Brandon Williams writes: > > > Factor out the logic for processing shallow, deepen, deepen_since, and > > deepen_not lines into their own functions to simplify the > > 'receive_needs()' function in addition to making it easier to reuse some >

Re: [PATCH v4 19/35] push: pass ref patterns when pushing

On 03/02, Junio C Hamano wrote: > Brandon Williams writes: > > > Construct a list of ref patterns to be passed to 'get_refs_list()' from > > the refspec to be used during the push. This list of ref patterns will > > be used to allow the server to filter the ref advertisement

Re: Opinions on changing add/add conflict resolution?

On Mon, Mar 12 2018, Elijah Newren jotted: > Hi everyone, > > I'd like to change add/add conflict resolution. Currently when such a > conflict occurs (say at ${path}), git unconditionally does a two-way > merge of the two files and sticks the result in the working tree at > ${path}. > > I would

Re: [PATCH v4 18/35] fetch: pass ref patterns when fetching

On 03/02, Junio C Hamano wrote: > Brandon Williams writes: > > > diff --git a/builtin/fetch.c b/builtin/fetch.c > > index 850382f55..695fafe06 100644 > > --- a/builtin/fetch.c > > +++ b/builtin/fetch.c > > @@ -332,11 +332,25 @@ static struct ref *get_ref_map(struct transport

Re: [PATCH v4 12/35] serve: introduce git-serve

On 03/01, Junio C Hamano wrote: > Brandon Williams writes: > > > Documentation/technical/protocol-v2.txt | 171 > > Unlike other things in Documentation/technical/, this is not listed > on TECH_DOCS list in Documentation/Makefile. Shouldn't it be? Yes it

Re: [PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

On Mon, Mar 12 2018, Junio C. Hamano jotted: > On Mon, Mar 12, 2018 at 11:56 AM, Ævar Arnfjörð Bjarmason > wrote: >> As someone who expects to use this (although hopefully in slightly >> modified form), it's very useful if we can keep the useful semantics in >> gc.* config

Re: [PATCH v4 02/35] pkt-line: allow peeking a packet line without consuming it

On 03/01, Junio C Hamano wrote: > Brandon Williams writes: > > > +enum packet_read_status packet_reader_read(struct packet_reader *reader) > > +{ > > + if (reader->line_peeked) { > > + reader->line_peeked = 0; > > + return reader->status; > > + } > > +

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

On Thu, Nov 16 2017, Luke Diamand jotted: > On 15 November 2017 at 22:08, Junio C Hamano wrote: >> Luke Diamand writes: >> >>> Quite a few of the worktrees have expired - their head revision has >>> been GC'd and no longer points to anything sensible >>>

Re: Opinions on changing add/add conflict resolution?

Hi again, Elijah Newren wrote: > On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder wrote: >> Would this behavior be configurable or unconditional? I suspect I >> would want it turned off in my own use. >> >> On the other hand, in the case of wild difference between the two

Re: Opinions on changing add/add conflict resolution?

Hi, Cool, thanks for taking a look! On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder wrote: > > My immediate reaction is that it seems inconsistent with the rest of > merge behavior. Why would add/add behave this way but edit/edit not > behave this way? Fair enough. I

Re: [PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

On Mon, Mar 12, 2018 at 11:56 AM, Ævar Arnfjörð Bjarmason wrote: > As someone who expects to use this (although hopefully in slightly > modified form), it's very useful if we can keep the useful semantics in > gc.* config values without needing some external job finding repos

Re: [PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

On Tue, Mar 06 2018, Nguyễn Thái Ngọc Duy jotted: > pack-objects could be a big memory hog especially on large repos, > everybody knows that. The suggestion to stick a .keep file on the > giant base pack to avoid this problem is also known for a long time. > > Let's do the suggestion

Re: [PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

On Wed, Mar 07 2018, Junio C. Hamano jotted: > Duy Nguyen writes: >>> But to those who say "packs larger than this value is too big" via >>> configuration, keeping only the largest of these above-threshold >>> packs would look counter-intuitive, wouldn't it, I wonder? >> >> I

Re: Opinions on changing add/add conflict resolution?

Hi, Elijah Newren wrote: > Hi everyone, > > I'd like to change add/add conflict resolution. Currently when such a > conflict occurs (say at ${path}), git unconditionally does a two-way > merge of the two files and sticks the result in the working tree at > ${path}. > > I would like to make it

Re: [PATCH v2 4/5] pack-objects: show some progress when counting kept objects

On Tue, Mar 06 2018, Nguyễn Thái Ngọc Duy jotted: > We only show progress when there are new objects to be packed. But > when --keep-pack is specified on the base pack, we will exclude most > of objects. This makes 'pack-objects' stay silent for a long time > while the counting phase is going. >

Opinions on changing add/add conflict resolution?

Hi everyone, I'd like to change add/add conflict resolution. Currently when such a conflict occurs (say at ${path}), git unconditionally does a two-way merge of the two files and sticks the result in the working tree at ${path}. I would like to make it instead first check whether the two files

Re: [RFC PATCH 0/5] Improve path collision conflict resolutions

On Mon, Mar 5, 2018 at 9:11 AM, Elijah Newren wrote: > 2) Doing content merges for a rename before looking at the path collision > between a rename and some other file. In particular (in what I most > suspect others might have an objection to from this series),

Re: [PATCH/RFC v3 02/12] pack-objects: turn type and in_pack_type to bitfields

On Fri, Mar 09, 2018 at 02:54:53PM -0800, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > > > @@ -1570,7 +1576,7 @@ static void drop_reused_delta(struct object_entry > > *entry) > > entry->depth = 0; > > > > oi.sizep = >size; > > - oi.typep = >type; > > +

Dear friend,

Dear friend, I Mr.Baari Abdul, Head of Operation at Bank of Africa. I want invite into a business overture which involves an amount of $ 22.3 million. At your acceptance, this amount will be transferred to your name as a foreign partner. I need your help to get this fund to be transfer

submodule..ignore vs git add -u

Hi, Let's say I have a fairly simple submodule setup where I do 'git checkout' inside the submodule to check out a different commit, so the outer repo 'git diff' shows a submodule update. In that case git config submodule..ignore all makes 'git diff' or 'git commit -a' ignore the

Re: [PATCH v5 04/13] csum-file: add CSUM_KEEP_OPEN flag

On 2/26/2018 9:32 PM, Derrick Stolee wrote: This patch is new to the series due to the interactions with the lockfile API and the hashfile API. I need to ensure the hashfile writes the hash value at the end of the file, but keep the file descriptor open so the lock is valid. I welcome any

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

Hi Johannes, Johannes Schindelin writes: [...] > The biggest difference is that it is easy for me to see the motivation > behind Phillip's strategy, whereas I am still puzzled why one would come > up with a complicated strategy that splits merge commits and

Re: [PATCH 0/4] Speed up git tag --contains

On 3/3/2018 12:15 AM, Jeff King wrote: On Fri, Jan 12, 2018 at 10:56:00AM -0800, csilvers wrote: This is a resubmission of Jeff King's patch series to speed up git tag --contains with some changes. It's been cooking for a while as: Replying to this 6-year-old thread: Is there any chance this

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

Hi Buga, Igor Djordjevic writes: > Hi Dscho, [...] > I think the root of misunderstanding might be coming from the fact > that Sergey was mainly describing a general concept (without a > strictly defined implementation strategy, not being restricted to a >

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

Hi Johannes, Johannes Schindelin writes: > Hi Buga, > > On Sun, 11 Mar 2018, Igor Djordjevic 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

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

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, [...] > That is misrepresenting what happened. No, it's you who are spreading misinformation, probably unintentional, but still. > First, you came up with a strategy. I pointed out shortcomings that > implied

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

Hi Johannes, Johannes Schindelin writes: > 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 --

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

Hi Buga, Igor Djordjevic writes: [...] > That said, *if* we decide we like temporary commit U1' == U2' consistency > check (especially for non-interactive rebase, maybe), we can produce > these after the fact for the sake of the check only. I don't believe

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

Hi Buga, I just have two thoughts to contribute as answer, so please excuse the heavily cut quoted text: On Sun, 11 Mar 2018, Igor Djordjevic 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 >

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

Hi Buga, On Sun, 11 Mar 2018, Igor Djordjevic 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 mentioned explicit old:new merge > parameter mapping to a separate discussion

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

Hi Buga, On Sun, 11 Mar 2018, Igor Djordjevic wrote: > On 11/03/2018 16:47, Johannes Schindelin wrote: > > > > > Having explained all this, I realized this is the same "essentially > > > merging the new tips into the original pretending that the new tips > > > were not rebased but merged into

Re: [GSoC] [PATCH] travis-ci: added clang static analysis

Hi, That looks interesting but I agree with Dscho that we should not limit this to master/maint. I assume you did run this on TravisCI already? Can you share a link? I assume you did find errors? Can we fix them or are there too many? If there are existing errors, how do we define a "successful"

Re: [GSoC][PATCH] git-ci: use pylint to analyze the git-p4 code

Hi Viet, > On 12 Mar 2018, at 03:20, Viet Hung Tran wrote: > > This is my submission as a microproject for the Google Summer of code. > I apologize for not setting the [GSoC] in my previous email > at <20180312020855.7950-1-viethtran1...@gmail.com>. > Please ignore it.

Re: [PATCH 1/1] git-p4: add format-patch subcommand

On 26 February 2018 at 23:48, Eric Sunshine wrote: > On Mon, Feb 26, 2018 at 6:48 AM, Luke Diamand wrote: >> It takes a list of P4 changelists and generates a patch for >> each one, using "p4 describe". >> [...] Just to say that I almost got this