Your comments
It works, thanks.!
17.1 preview 12 #11103
I like the new carriage return diff view.
I wanted to disable this option to look "at true changes" (ignoring carriage return).
But it seems that the "built-in file compare" (separate windows) and the "changes" (quick view tab) don't use the same settings?
I expected "Ignore whitespace for line comparaison" to have effect on this, for both tools.
This is the correct theoretical thing to do, but...
Our source code was edited on 5 different platforms over more than 20 years. Many "bad" editors were used. Now every file we have has mixed line endings.
In effect, the SmartGit editor would be disabled on all our files.
In my opinion, the best thing to do would be what I described earlier.
The second best thing would be to uniformize the line endings on edition, with a warning (with a "do not show again" checkbox).
Many questions indeed, and as always with this subject, opinions differ.
Git is pretty confusing with 2 settings for this (core.eol, core.autocrlf) (+core.safecrlf and .gitattributes).
> what line separator to enter when the user presses <enter>
Most tools I know insert native carriage return. Visual Studio on Windows in particular insert CRLF (native), even in non-mixed Linux (LF) or Mac OS9 (CR) files
> How to handle text copy-pasted from some other source?
Most tools I know keep the source format (and thus can create mixed files)
The important part is seeing the change in the diff view
As far as I understand this is a flaw in Git design, not in the SmartGit interface.
With Git, a commit is not "on a branch", it is a node in a directed acyclic graph, with tags (branch names) at the top (see my previous comment).
If you want a version control system with named branches, you should use SVN (or maybe Mercurial, I don't know this one).
We don't use Git-Flow yet, our repo was imported from SVN and we have a great number of branches.
I think I have somewhat diverted the original issue intent.
In any case, I am happy with the graph obtained with "Toogle preserve parent" and a large number of "Increase rectilinearity".
Theses two options should be more visible, maybe in the same combo box or beside the branch colouring.
Thanks for your answers.
The result is much better with this option. Could "Preserve Parent Order" also "preserve parent color"?
The graph you obtained is the same I got. The graph is "correct" but difficult to read because 3 branches are shown as 2 ("shift-to-left layouting").
- On the bottom Master is green, but changes to red at the top.
- Bra-5 looks like the continuation of Master (because it is green).
- Later in the graph, the merge of Bra-31 will look like a merge of Bra-5 to Master (because of their positions and colors).
Thomas Singer mentions: "this is a rather complex algorithm to keep the width as narrow as possible even for large and complex repositories".
I would prefer wide readable graph rather than narrow difficult-to-read ones.
Maybe make this an option ("compressed graph" on/off)?
I just put this example on GitLab, tell me if you cannot access it.
(The problem is apparent when looking at all the 3 branches in the Log.)
Customer support service by UserEcho
So far my only feedback is: I like it very much!
I also use "Increase max connector length" + "Increase rectilinearity" + "Preserve parent order" to get a more linear (but very wide) graph.