[LyX/master] Fix an on-screen representation glitch.

[Enrico Forestieri]

commit 95787a0a4c3f6c037b22cb4ba8c98f2e8fa988de
Date: Fri May 16 15:11:08 2014 +0200
Fix an on-screen representation glitch.
If a layout has NextNoIndent set to true, the following paragraph
is not indented on screen. LyX checks the previous layout for that
style parameter to decide whether to indent or not. Of course,
what matters is the latex output and the on-screen representation
should match this output. Now, when a layout has NextNoIndent==true,
the latex output is correctly not indented, while the on-screen
representation may fail to match this output. This can occur when,
for example, a standard paragraph is nested in the previous layout,
because LyX would check the property of the nested layout instead
of the container layout. Thus, LyX should check the property of a
previous layout at the same depth for correctly deciding whether
a paragraph has to be indented or not.
See also http://www.lyx.org/trac/ticket/9055#comment:12 for an
example document where the previous scenario actually occurs.

Richard, this could go to branch. It's only cosmetic, though.

diff --git a/src/TextMetrics.cpp b/src/TextMetrics.cpp
index 790d706..0be9058 100644
--- a/src/TextMetrics.cpp
+++ b/src/TextMetrics.cpp
@@ -1907,12 +1907,13 @@ int TextMetrics::leftMargin(int max_width,
}
}
- // This happens after sections in standard classes. The 1.3.x
- // code compared depths too, but it does not seem necessary
- // (JMarc)
- if (tclass.isDefaultLayout(par.layout())
- && pit > 0 && pars[pit - 1].layout().nextnoindent)
- parindent.erase();
+ // This happens after sections or environments in standard classes.
+ // We have to check the previous layout at same depth.
+ if (tclass.isDefaultLayout(par.layout()) && pit > 0) {
+ pit_type prev = text_->depthHook(pit, par.getDepth());
+ if (pars[prev < pit ? prev : pit - 1].layout().nextnoindent)
+ parindent.erase();
+ }
FontInfo const labelfont = text_->labelFont(par);
FontMetrics const & labelfont_metrics = theFontMetrics(labelfont);

[Richard Heck]

Post by Enrico Forestieri

commit 95787a0a4c3f6c037b22cb4ba8c98f2e8fa988de
Date: Fri May 16 15:11:08 2014 +0200
Fix an on-screen representation glitch.
If a layout has NextNoIndent set to true, the following paragraph
is not indented on screen. LyX checks the previous layout for that
style parameter to decide whether to indent or not. Of course,
what matters is the latex output and the on-screen representation
should match this output. Now, when a layout has NextNoIndent==true,
the latex output is correctly not indented, while the on-screen
representation may fail to match this output. This can occur when,
for example, a standard paragraph is nested in the previous layout,
because LyX would check the property of the nested layout instead
of the container layout. Thus, LyX should check the property of a
previous layout at the same depth for correctly deciding whether
a paragraph has to be indented or not.
See also http://www.lyx.org/trac/ticket/9055#comment:12 for an
example document where the previous scenario actually occurs.

Richard, this could go to branch. It's only cosmetic, though.

As you think best.

Richard

[Enrico Forestieri]

Post by Richard Heck

Post by Enrico Forestieri
Richard, this could go to branch. It's only cosmetic, though.

As you think best.

I pushed it. However, git told me bad things:

$ git push
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.07 KiB, done.
Total 5 (delta 4), reused 0 (delta 0)
To ***@git.lyx.org:lyx
b17802b..f5a246b 2.1.x -> 2.1.x
! [rejected] 2.0.x -> 2.0.x (non-fast-forward)
error: failed to push some refs to '***@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.


I think it is still trying to do something with the 2.0.x branch behind
my back. What are the magic words I have to use to stop it from doing that?

[Enrico Forestieri]

Post by Enrico Forestieri

Post by Richard Heck

Post by Enrico Forestieri
Richard, this could go to branch. It's only cosmetic, though.

As you think best.

$ git push
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.07 KiB, done.
Total 5 (delta 4), reused 0 (delta 0)
b17802b..f5a246b 2.1.x -> 2.1.x
! [rejected] 2.0.x -> 2.0.x (non-fast-forward)
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
I think it is still trying to do something with the 2.0.x branch behind
my back. What are the magic words I have to use to stop it from doing that?

After some googling I think I need to issue the following commands:

$ git branch -d -r origin/2.0.x
$ git config --unset branch.2.0.x.remote
$ git config --unset branch.2.0.x.merge

Is that correct?

[Scott Kostyshak]

Post by Enrico Forestieri
Merge the remote changes (e.g. 'git pull') before pushing again. See the

When I get this error, doing a
git pull --rebase
is usually what I want. Git will not let you push if you do not have
the latest version. Even if you edited a file that does not conflict
with the updates you don't have. The "--rebase" just tells git to put
your patch on top of the commits that you're going to pull in.

Scott

[Enrico Forestieri]

Post by Scott Kostyshak

Post by Enrico Forestieri
Merge the remote changes (e.g. 'git pull') before pushing again. See the

When I get this error, doing a
git pull --rebase
is usually what I want. Git will not let you push if you do not have
the latest version. Even if you edited a file that does not conflict
with the updates you don't have. The "--rebase" just tells git to put
your patch on top of the commits that you're going to pull in.

No, this cannot be the reason. My procedure for pushing is the following:

$ git commit -a
$ git pull --rebase
$ git push

so, I had just issued that command. It has something to do with the fact
that previously I had 2.0.x as a checked out branch and then I switched
to 2.1.x. Now git is still someway trying to also push 2.0.x and I would
like to tell it not to do that, but I don't know neither why it still
insists on 2.0.x nor what I can do. Maybe it is simpler to start afresh
and clone again the repository. I like very much git branches.

[Scott Kostyshak]

Post by Enrico Forestieri
Now git is still someway trying to also push 2.0.x and I would
like to tell it not to do that, but I don't know neither why it still
insists on 2.0.x nor what I can do.
From what I understand, when you do a "git push" you only want to push

the branch that you have checked out. If that's right, then putting
the following should do that:

git config --global push.default current

Note the "global". I assume you want this for all Git-related projects.

Scott

[Enrico Forestieri]

Post by Enrico Forestieri

Post by Enrico Forestieri
Now git is still someway trying to also push 2.0.x and I would
like to tell it not to do that, but I don't know neither why it still
insists on 2.0.x nor what I can do.

From what I understand, when you do a "git push" you only want to push
the branch that you have checked out.

Exactly.

Post by Enrico Forestieri
If that's right, then putting
git config --global push.default current
Note the "global". I assume you want this for all Git-related projects.

Maybe you are right. But I have now found .git/config whose content is:

$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ***@git.lyx.org:lyx
[branch "2.0.x"]
remote = origin
merge = refs/heads/2.0.x
[merge]
defaultToUpstream = true
[gui]
wmstate = normal
geometry = 1031x427+46+46 282 192
[branch "2.1.x"]
remote = origin
merge = refs/heads/2.1.x


and I simply plan removing the [branch "2.0.x"] stanza.

[Scott Kostyshak]

Post by Enrico Forestieri
and I simply plan removing the [branch "2.0.x"] stanza.

Ah, now I see what you meant above. I am still not used to 2.0.x as
being "old". I was reading it as I should read 2.1.x. I still put the
date as 2013 also :)

Scott

[Enrico Forestieri]

Post by Scott Kostyshak

Post by Enrico Forestieri
and I simply plan removing the [branch "2.0.x"] stanza.

Ah, now I see what you meant above. I am still not used to 2.0.x as
being "old". I was reading it as I should read 2.1.x. I still put the
date as 2013 also :)

I now tried my luck and issued the commands I found googling:
$ git branch -d -r origin/2.0.x
$ git config --unset branch.2.0.x.remote
$ git config --unset branch.2.0.x.merge

then I looked again at .git/config
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ***@git.lyx.org:lyx
[branch "2.0.x"]
[merge]
defaultToUpstream = true
[gui]
wmstate = normal
geometry = 1031x427+46+46 282 192
[branch "2.1.x"]
remote = origin
merge = refs/heads/2.1.x

and it actually almost got rid of the [branch "2.0.x"] stanza, leaving
only the header. I would like to get rid of that too, but I don't know
what of the git options of the type --reset --hard --really --please
I have to use. Perhaps I will simply use an editor and be done with it.

[Richard Heck]

Post by Enrico Forestieri

Post by Scott Kostyshak

Post by Enrico Forestieri
and I simply plan removing the [branch "2.0.x"] stanza.

Ah, now I see what you meant above. I am still not used to 2.0.x as
being "old". I was reading it as I should read 2.1.x. I still put the
date as 2013 also :)

$ git branch -d -r origin/2.0.x
$ git config --unset branch.2.0.x.remote
$ git config --unset branch.2.0.x.merge
then I looked again at .git/config
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "2.0.x"]
[merge]
defaultToUpstream = true
[gui]
wmstate = normal
geometry = 1031x427+46+46 282 192
[branch "2.1.x"]
remote = origin
merge = refs/heads/2.1.x
and it actually almost got rid of the [branch "2.0.x"] stanza, leaving
only the header. I would like to get rid of that too, but I don't know
what of the git options of the type --reset --hard --really --please
I have to use. Perhaps I will simply use an editor and be done with it.

It's a text file and can perfectly well be edited by hand.

Your original problem was due to the fact that you had changes on the
2.0.x branch that had not yet been pushed. The command "git push", with
no options, pushes everything that needs pushing unless you have set the
config option Scott mentioned before. So git is trying to push to 2.0.x,
but that branch is not up to date, so it is refusing to do so.

Here's an example:

../lyx/lyx-devel/ [2.1.x] > git push -n
To ***@git.lyx.org:lyx
f5a246b..66c96ce 2.1.x -> 2.1.x
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '***@git.lyx.org:lyx'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you did not intend to push that branch, you may
want to
hint: specify branches to push or set the 'push.default' configuration
hint: variable to 'current' or 'upstream' to push only the current branch.

Here, master was also dirty, so git tried to push it, even though I'm on
2.1.x.

You can set it only to push your current branch by doing:
git config --global push.default current
See http://stackoverflow.com/questions/948354/git-push-default-behavior
for more info.

Richard

[Enrico Forestieri]

Post by Richard Heck
Your original problem was due to the fact that you had changes on
the 2.0.x branch that had not yet been pushed. The command "git
push", with no options, pushes everything that needs pushing unless
you have set the config option Scott mentioned before. So git is
trying to push to 2.0.x, but that branch is not up to date, so it is
refusing to do so.

I am sure I had no changes in 2.0.x. I remember I had to fight hard
against "git gui" before convincing it that I would have liked to
drop 2.0.x and activate 2.1.x. Eventually I won, but it was still
not tamed, apparently.

Post by Richard Heck
../lyx/lyx-devel/ [2.1.x] > git push -n
f5a246b..66c96ce 2.1.x -> 2.1.x
! [rejected] master -> master (non-fast-forward)
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you did not intend to push that branch, you
may want to
hint: specify branches to push or set the 'push.default' configuration
hint: variable to 'current' or 'upstream' to push only the current branch.

I was not given that hint, but a seemingly unrelated error that initially
confused me before I noticed that it was also trying to push 2.0.x:
To ***@git.lyx.org:lyx
b17802b..f5a246b 2.1.x -> 2.1.x
! [rejected] 2.0.x -> 2.0.x (non-fast-forward)
error: failed to push some refs to '***@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.

Post by Richard Heck
git config --global push.default current

Thanks. I will also do this for good measure. However, I see that
the 2.0.x branch is still around (maybe it's a zombie...):
$ git br
2.0.x
* 2.1.x

Most probably, I have also to issue a "git -d 2.0.x" to completely
get rid of the thing. For good measure, I will also perform some
propitiatory rite...

[Enrico Forestieri]

Post by Enrico Forestieri
Most probably, I have also to issue a "git -d 2.0.x" to completely
get rid of the thing. For good measure, I will also perform some
propitiatory rite...

Argh! Wrong rite, apparently:

$ git br -d 2.0.x
error: The branch '2.0.x' is not fully merged.
If you are sure you want to delete it, run 'git branch -D 2.0.x'.

May I really issue "git br -D 2.0.x" and not be involved in solving
a next problem?

[Richard Heck]

Post by Enrico Forestieri

Post by Enrico Forestieri
Most probably, I have also to issue a "git -d 2.0.x" to completely
get rid of the thing. For good measure, I will also perform some
propitiatory rite...

$ git br -d 2.0.x
error: The branch '2.0.x' is not fully merged.
If you are sure you want to delete it, run 'git branch -D 2.0.x'.
May I really issue "git br -D 2.0.x" and not be involved in solving
a next problem?

It's safe to do that, if there's nothing in 2.0.x that you want. Which,
I take it, there is not.

Richard

[Enrico Forestieri]

Post by Richard Heck

Post by Enrico Forestieri

Post by Enrico Forestieri
Most probably, I have also to issue a "git -d 2.0.x" to completely
get rid of the thing. For good measure, I will also perform some
propitiatory rite...

$ git br -d 2.0.x
error: The branch '2.0.x' is not fully merged.
If you are sure you want to delete it, run 'git branch -D 2.0.x'.
May I really issue "git br -D 2.0.x" and not be involved in solving
a next problem?

It's safe to do that, if there's nothing in 2.0.x that you want.
Which, I take it, there is not.

I don't understand why it was claiming that the branch was not fully
merged, because I am sure I didn't touch it after the last pull.

That command worked. I only had a hiccup after pulling again, because of:
From git.lyx.org:lyx
* [new branch] 2.0.x -> origin/2.0.x
936773c..4bd0941 master -> origin/master
Current branch 2.1.x is up to date.

but "git br" showed no trace of 2.0.x, and the following push worked
as I was expecting. Thanks for the assistance to everyone.

[Richard Heck]

Post by Enrico Forestieri
From git.lyx.org:lyx
* [new branch] 2.0.x -> origin/2.0.x
936773c..4bd0941 master -> origin/master
Current branch 2.1.x is up to date.
but "git br" showed no trace of 2.0.x, and the following push worked
as I was expecting.

I think somehow the origin/2.0.x branch got deleted locally, and you
will see it now if you
look at the output of "git br -a". I sometimes run into these naming
conflicts, where I've got
a local branch bugs/whatever and I've pushed it (for backup, basically)
to my developers
repo, which would be at rgheck/bugs/whatever, locally. I haven't figured
out why this
happens.

Richard

[Scott Kostyshak]

Post by Scott Kostyshak
git config --global push.default current
See http://stackoverflow.com/questions/948354/git-push-default-behavior for
more info.

Just a note that I believe this is the default in Git 2.0:
http://lkml.iu.edu/hypermail/linux/kernel/1405.3/02592.html

Scott