Hi Buga,
Igor Djordjevic writes:
[...]
> I don`t know, I`m thinking if we are looking at todo list from
> different perspectives - to you, it seems to be a sequence of
> commands to create something new (yes, from something that already
> exists, but that`s implementation detail). In that conte
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 relationsh
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 th
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 usi
[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 "foo" and one cont
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 sup
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 2:35
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. Th
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.
>
> If
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 wasn't
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 disc
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,
> > stru
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:
> >
>
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 in
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 main
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
> curren
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 und
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 y
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.
> >
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) and marking the path as
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
> conflicted in the index. That
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
> then
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 academic
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 addition to making
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
> > of this logic when
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 when
> > communicati
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
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
> > *transport,
> >
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 should, I'll fix that.
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 values without needing
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;
> > + }
> > +
> > + reader->stat
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
>>> (gc.worktreePruneExpire). The function o
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
>> files, skipping th
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 have two separate reaso
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 and
> creating *.keep
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 automaticall
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 think I'll just cla
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 in
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.
>
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 a
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), record
> that con
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 = &entry->size;
> > - oi.typep = &entry->type;
> > + oi.t
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 ou
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 change
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 susgge
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-merges
> them later, and why it sh
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
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
> specific one), where Phillip came up
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 mentioned explicit old:new m
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 that we cannot use it unchange
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 -- not *require* that consistency check?
>>
>> I don't under
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 interactive vs. non-interactive spl
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
> bef
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 poi
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 up
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"
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.
No worries :-)
> Add a n
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 working reasonably well, but it
gets pretty nasty
58 matches
Mail list logo
