Uwe Stöhr writes:
| Am 20.03.2012 09:31, schrieb Vincent van Ravesteijn:
>
>>> + if (tabular.rotate != 0)
>>> + rotateTabularAngleSB->setValue(tabular.rotate);
>>> + else
>>> + rotateTabularAngleSB->setValue(90);
>>
>> rotateTabularAngleSB->setValue(tabular.rotate == 0 ? 90 : tabular.rotate);
>
|
Pavel Sanda writes:
| Jean-Marc Lasgouttes wrote:
>> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>>> There is also a 2.0.x branch in your first clone, so you can just
>>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>>> push from there.
>>
>> But If I want to co
Vincent van Ravesteijn writes:
>>> There has to be a simple way to commit a patch to branch (please
>>> tell me there is!).
>>
>
| I forgot to mention: Ideally, if we do it the git-way completely, you
| would only have to commit a patch to the 2.0.x branch. Later, the
| 2.0.x will automatically b
Pavel Sanda writes:
| Lars Gullik Bj?nnes wrote:
>>
>> Setting up .gitignore or .git/info/excludes is something that should
>> be done. Not doing it makes it a lot harder to see actual new files
>> that should be added.
>>
>> Signed-off-by: Lars Gullik Bj?¸nnes
>> ---
>> .gitignore
Il 21/03/2012 16:44, Jean-Marc Lasgouttes ha scritto:
Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.
But If I want to compile both the
Am 20.03.2012 10:04, schrieb Vincent van Ravesteijn:
What is incomplete?
I changed it because it didn't work anymore. With Qt 4.8 things have changed
and Peter did a good
job with the script so that the former manual settings are now automatically
set.
It still worked perfectly for me. What
Am 20.03.2012 09:47, schrieb Vincent van Ravesteijn:
I would write:
bool const fixed_width_multirow = multirowCB->isChecked() && width != "0pt";
bool const inherit_column_align = !fixed_width_multirow;
if (inherit_column_align)
setHAlign(param_str);
Now it is immediately clear that we only set
Am 20.03.2012 09:31, schrieb Vincent van Ravesteijn:
+ if (tabular.rotate != 0)
+ rotateTabularAngleSB->setValue(tabular.rotate);
+ else
+ rotateTabularAngleSB->setValue(90);
rotateTabularAngleSB->setValue(tabular.rotate == 0 ? 90 : tabular.rotate);
I never understood why this form is prefer
On Wed, Mar 21, 2012 at 05:04:56PM +0100, Pavel Sanda wrote:
> Georg Baum wrote:
> > commit yet)? I guess it would look like
> >
> > git checkout -b fixfileformat
> > git commit
> > git checkout master
> > git merge fixfileformat
> > git commit
> > git branch -d fixfileformat
>
> The simplistic S
Jean-Marc Lasgouttes wrote:
> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>> There is also a 2.0.x branch in your first clone, so you can just
>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>> push from there.
>
> But If I want to compile both the master and the
Now you can push your branch to "lyx":
$ git push lyx 2.0.x
How come I have to specify "lyx 2.0.x". Isn't it possible to setup the
branch so that "git push" will do the right thing?
"git push" will by default push to the remote which is tracked by the
current branch. If the current branch
Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.
But If I want to compile both the master and the branch without doing a
full rebuild ev
On 03/21/2012 11:09 AM, Jean-Pierre Chrétien wrote:
Pavel Sanda lyx.org> writes:
No, its broken. Christian is slowly trying to recover. Pavel
Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)
Apparently, the problem is
Le 21/03/2012 16:56, Vincent van Ravesteijn a écrit :
There has to be a simple way to commit a patch to branch (please tell
me there is!).
I forgot to mention: Ideally, if we do it the git-way completely, you
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x
will autom
Georg Baum wrote:
> commit yet)? I guess it would look like
>
> git checkout -b fixfileformat
> git commit
> git checkout master
> git merge fixfileformat
> git commit
> git branch -d fixfileformat
The simplistic SVN-like scenario is just:
git pull (update from public repo)
git commit (just loca
Vincent van Ravesteijn wrote:
>>> change that was merged in by Richard was March 13.
>>>
>>> You can see this immediately if you limit the output to only Richard's
>>> commits:
>>>
>>> $ git log -p --author='Richard Heck'
>>>
>>> Vincent
>>
>> The following shows the diffs in order they got into m
There has to be a simple way to commit a patch to branch (please tell
me there is!).
I forgot to mention: Ideally, if we do it the git-way completely, you
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x
will automatically be merged into the master. This can be done,
Op 21-3-2012 16:48, Vincent van Ravesteijn schreef:
Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:
Op 21-3-2012 16:16, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Op 21-3-2012 15:00, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
all commits that are in this range). If you wan
Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:
Op 21-3-2012 16:16, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Op 21-3-2012 15:00, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code
changes
introduced by a merge you
Op 21-3-2012 16:16, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Op 21-3-2012 15:00, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:
$ git diff 9236a938 9236a938^1
This will sh
Vincent van Ravesteijn wrote:
> Op 21-3-2012 15:00, Pavel Sanda schreef:
>> Vincent van Ravesteijn wrote:
>>> all commits that are in this range). If you want to see the code changes
>>> introduced by a merge you can do:
>>>
>>> $ git diff 9236a938 9236a938^1
>>>
>>> This will show you that the mer
Op 21-3-2012 15:51, Jean-Marc Lasgouttes schreef:
Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the
following:
Assume you have a git clone in /lyx, you can clone this with
git clone -s -b 2.0.x /lyx /lyx20x
This will clone yo
Pavel Sanda lyx.org> writes:
>
> No, its broken. Christian is slowly trying to recover. Pavel
>
Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)
--
Jean-Pierre
Jean-Pierre Chrétien wrote:
> Hello,
>
> I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
> login nothing happens.
> Has the password been changed ?
No, its broken. Christian is slowly trying to recover. Pavel
Hello,
I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
login nothing happens.
Has the password been changed ?
--
Jean-Pierre
Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:
Assume you have a git clone in /lyx, you can clone this with
git clone -s -b 2.0.x /lyx /lyx20x
This will clone your repo, but it will reuse the objects. This means
t
Op 21-3-2012 15:00, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:
$ git diff 9236a938 9236a938^1
This will show you that the merge is not empty at all.
Is there a way how to obtain
Vincent van Ravesteijn wrote:
> all commits that are in this range). If you want to see the code changes
> introduced by a merge you can do:
>
> $ git diff 9236a938 9236a938^1
>
> This will show you that the merge is not empty at all.
Is there a way how to obtain full listing of diffs which went
Op 21-3-2012 13:32, Dahlmann Martin TU Ilmenau schreef:
Hello,
I am writing this to the developers list, because its more about the
development than how to possibly manually fix a special issue that I
might mention. Simply, if there is a manual fix, then I have not found
it yet, which might
On 2012-03-20, Georg Baum wrote:
> Vincent van Ravesteijn wrote:
>> I don't know what is supposed to happen to these characters.
> Basically nothing (see below).
>>> Like the other ca. 1000 out of 2751 Unicode math-related symbols without
>>> (traditional) LaTeX support, they cannot be auto-
Op 20-3-2012 20:35, Richard Heck schreef:
On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:
Op 20-3-2012 0:15, Richard Heck schreef:
This is in my private repo. I have a branch master, and another
branch bugs/7975, and another branch lyx/trunk that is tracking the
main repo, set up as yo
Lars Gullik Bj?nnes wrote:
>
> Setting up .gitignore or .git/info/excludes is something that should
> be done. Not doing it makes it a lot harder to see actual new files
> that should be added.
>
> Signed-off-by: Lars Gullik Bj?¸nnes
> ---
> .gitignore| 13 +
I
Le 21/03/2012 10:02, Lars Gullik Bjønnes a écrit :
Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.
Definitely.
JMarc
Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.
Signed-off-by: Lars Gullik Bjønnes
---
.gitignore| 13 +
boost/.gitignore |1 +
conf
Tommaso Cucinotta writes:
| Il 13/03/2012 23:32, Lars Gullik Bjønnes ha scritto:
>> On Wed, Mar 14, 2012 at 00:03, Tommaso Cucinotta wrote:
>>> Il 13/03/2012 22:38, Lars Gullik Bjønnes ha scritto:
>>>
>>> All developers login as the "git" user, then your pub key is used to
>>> authenticate you a
35 matches
Mail list logo
