Re: [Development] QtQuick Call for Maintainer

[Knoll Lars]

On 05/04/16 22:56, "Development on behalf of Giuseppe D'Angelo" 
 wrote:


>Il 10/03/2016 08:37, Knoll Lars ha scritto:
>>> >
>>> >Individually or together, +1 from me.
>> Fully agree with what Alan is saying, so another +1 from me.
>
>I guess it's time to do the honours then? :)

Indeed. I've edited the wiki and settings in codereview accordingly.

Congratulations Robin and Shawn!

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QTBUG-52360: is ARMv5 still supported?

[Thiago Macieira]

If it is, can someone try a regular toolchain for that platform with Qt 5.6 
and report whether QtCore links? I'd like a second opinion with a different 
toolchain than the reporter.

The question is: if you use  functionality, do you need an extra -l 
flag?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuick Call for Maintainer

[Giuseppe D'Angelo]

Il 10/03/2016 08:37, Knoll Lars ha scritto:

>
>Individually or together, +1 from me.

Fully agree with what Alan is saying, so another +1 from me.


I guess it's time to do the honours then? :)

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] gerrit : using branches

[Jan Kundrát]

If you want to know the names of all branches which contain a given ref, 
there's also the `git branch --contains yourRef`.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] gerrit : using branches

[Matthew Woehlke]

On 2016-04-04 08:49, René J.V. Bertin wrote:
> [...] there's no way to obtain the branch from a given commit?

There is `git name-rev`, but it may or may not work or give you the
"best" answer. At least it should give you *a* branch name if a SHA is
the tip of a local branch. I'm not sure offhand what it does if multiple
branches name the same SHA¹, or how it works with tags or non-local
branches. Note that this can give answers like `master~2`, i.e. it can
in at least some cases name commits that *aren't* the tip of a branch.

(¹ You should at least get *a* name. I don't know if you'll get all
possible names, or if it will just pick one.)

You should also look at gitk, which will show you the graph, including
all names (tags as well as branches) of named SHA's. (The `--decorate`
option to `git log` does this also.)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] MSVC2012 in CI

[Frederik Gladhorn]

On Sunday, March 20, 2016 12:07:01 PM Sean Harmer wrote:
> Hi,
> 
> Can MSVC 2012 configurations be removed from the CI please? My understanding
> is that this compiler was only kept around to support Windows EC but that
> this is now removed from 5.7.

I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/
QTBUG-51934
We cannot just remove test coverage without testing some of the features on 
more modern platforms.
In this case msvc 2012 is the platform where we test "DeveloperBuild, Release, 
QtNamespace, QtLibInfix" and I'd like to keep a windows build with these 
features. It seems to consistently fail on windows 10 though.
If there's not enough information in the bug, I'm happy to provide it. As long 
as that test keeps failing, we won't get rid of msvc 2012.

Cheers,
Frederik

> In particular this compiler is a blocker to
> using a using declaration such as:
> 
> template
> using QNodeCreatedChangePtr = QSharedPointer;
> 
> Kind regards,
> 
> Sean
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?)

[Thiago Macieira]

On segunda-feira, 4 de abril de 2016 10:25:16 PDT Welbourne Edward wrote:
> $ git stash
> $ git pull -r
> $ git stash pop

Also:
$ git fetch
$ git rebase --autostash

It's exactly the same.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?)

[Welbourne Edward]

I mentioned:
>> merge-base - if you have a strict tree, this isn't a merge, so it's
>> where one was branched off the other, but nothing about the merge-base
>> or any of its ancestors contains any hint as to which branch it was on
>> when it was committed.

René J.V. Bertin replied:
> In short, there's something like a table for each branch that tells
> what commits "belong" to that branch, but there's no way to obtain the
> branch from a given commit?

There is no table.  Each commit is an object in a datastore, named by
its sha1.  The commit object contains information about the commit -
IIRC, the sha1 names of:
  * a "tree" object representing that commit's checked-out tree
  * one or (for a merge) more "parent" objects
along with the times and user info of authorship and commit; and the
commit message.  The "blob" for a commit is a simple text file packaging
this information; the sha1 that names the commit is the sha1 of the text
of this blob.

The .git/refs/heads directory contains files whose names are branches
and whose contents are sha1 IDs of commits.  When git looks at history,
it reads a branch's head file to get the current tip's sha1; it reads
the object with that sha1 to discover what the commit is; if it needs to
know history, it looks at the parent sha1(s) and finds the commit
objects named there and in the objects it thus ends up opening as it
traverses the directed graph of ancestry.  There is no database, no
table; just a filesystem [*], in which objects name other objects,
forming a directed acyclic graph of mutual references.

[*] technically, the object store ends up being a virtual filesystem, as
not all of the blobs are typically held on disk as separate files; many
of them get compressed together in a "pack file"; but this is just the
implementation of a virtual file system.  Pedagogically, git thinks it
just saves blobs as files to disk under .git/objects/: in practice, it's
usually more efficient than that.

In particular, although the refs/heads/ directory names some objects as
tips of branches, *nothing* in the git object store knows *anything*
about branches.  It only knows about commits, trees and files.  (Kinda.
It actually also knows about notes, signed tags and some other fun
meta-data - but nothing about branches.)  If you look at a commit
object, that object has no knowledge of being on any branch; it only
knows who its parents are, what tree object it describes and the user
info and times of its authorship and creation (these may be separate,
especially after cherry-picking or rebasing).  The nearest a commit gets
to knowing it's on any branch at all is the fact that it hasn't been
garbage-collected yet, so it must be an ancestor of some commit named by
some branch or (under refs/tags/) tag.  A commit doesn't even know what
other commits have it as a parent.

(When merging, the default commit message mentions the branches being
merged; so you could plausibly get some heuristics out of that.  All the
same, I can checkout -b a temp-branch from each branch, merge these,
then merge --ff-only each of the original branches to the resulting
merge point; the commit message shall name my temp-branches, yet the
result is clearly the result of merging the two branches I now have
pointing at that merge-point.  In any case, after a merge, I can git
commit --amend to change its commit message from the default.)

>> suspects (5.5, 5.6, 5.7, dev) and see which one has the closest
>> ancestor as git merge-base; or I pipe git shortlog 5.6...$branch | wc
>> -l and

> That looks like something not really trivial to capture in a script;

Indeed: git actually doesn't believe it's a meaningful question to ask.
I can move a branch name around arbitrarily, pointing it at the sha1 of
any commit in my object store, without making *any* changes to the
object store; only the file under .git/refs/heads/ changes.  You are
better off looking at your reflogs for information about what branched
off from where.

A branch is just a name that I'm temporarily giving to one commit while
preparing another, to which I'll soon move that name.  I sometimes
inadvertently make a bunch of commits on my local 5.6 (which I normally
keep shadowing a pristine origin/5.6); I could branch off a side-branch
while I'm doing that; sooner or later, I'll notice my mistake and do the

$ git branch local-changes
$ git reset --hard origin/5.6
$ git checkout local-changes

that gets my 5.6 back to where it's meant to be and gives a name to the
changes I'm working on.  If I forked off my side-branch from this set of
changes, several commits clear of where my 5.6 parted company with
origin/5.6 but before the tip at which I renamed the local development
to local-changes, do you think I branched my side-branch off from 5.6
(which might never again include the commit at which the side-branch set
off) or from local-changes (which didn't exist when I created the
side-branch) ?  From git's point of view the only thing that it's

Re: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?)

[Welbourne Edward]

> Forgot - maybe a stupid question, but can you set up a topic branch to
> track a remote branch (and would that make sense)?

$ git checkout -b topic remote/branch

will, by default, set up topic so that, while it's checked out, git pull
fetches remote/branch to merge with it (or rebase it onto) and git push
sends HEAD to remote as an update to branch.  Note, however, that if you
have a local branch tracking remote/branch and use local branch instead
of remote/branch in your checkout, it'll do none of that set-up for you;
you'll need to git branch --set-upstream-to=remote/branch if that's what
you want; and, if you want to pull from remote/branch but push to
something else (e.g. remote/topic), you'll have to juggle with git
config (and I'm not actually sure what the details are).  See the man
page for git branch for details of setting what a branch tracks.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development