I've seen the questions here and there and they don't have any real answer. While those graphs might be "topologically identical", I would really like my trees to show commits in order they actually happened.
There isn't such a tool to my knowledge, but you're wrong that the questions you link to "don't have any real answer". As explained in two answers to the second question you link to, you can get the behavior you want by cloning your repository in such a way that the changesets are recorded in chronological order. This answer (by myself) shows how to do it automatically. It's a clone, not history editing, so you can use it with shared repositories.
It's not as simple as using a different GUI, but consider that a hypothetical tool with the behavior you want would probably have other shortcomings. Stick to your favorite GUI and adjust the repo instead.
SourceTree (Git/Hg Ui tool) has both modes of graph display: date order and more rigorous ancestral order.
To use date ordering, you must be absoultely sure all committers have their ntp sync on and date/time zone set correctly.
Сhronological display breaks when trying to show commits from hosts with unsynchronised or invalid date/time, displaying those on their own line out of nowhere.
Related
I want to create a product/project documentation in R that is going to be reviewed and discussed by a group of reviews. There are plenty of examples of how to create book-like documents using Rmarkdown (e.g. https://bookdown.org/) or interactive data visualizations using R-shiny. However, I could not find any solution for user comments similar to LibreOffice Writer, MS Word, or Google Docs. I could also imagine having a split-pane where one side is dedicated to the content presentation (e.g. text, graphs, code), while the other side is left for comments.
I am aware that such a solution requires a server-side solution for storing comments.
Any hints on existing solutions, workarounds, and implementations are welcome.
If I correctly understood, your question isn't very R specific. R is just code, R files are just text and they don't allow comments (beside the raw hashtag comments) and reviews. Your question is more about version control environments, that allow reviews on code stuff. The most used version control system is git, and git has an integrated panel in RStudio.
Git allows you to split your developpements in branches, which are the different ideas you and your coworkers can work on independentely. Once an idea is finalised, after some consecutive modifications known as commits, it is to be asked for merge in the "main branch". It is a "pull request".
That is where the different platform using git, like GitHub or GitLab, allow some review systems. Basically, when a branch is done, you ask "is that ok ?". Your reviewer can see the changes, can try you things, and tell if that is actually ok.
The other advantage of these is the continuous integration, that is : elaborating tests (in R with testthat) that will be tested on some events merge, like "on each merge to master". It is meant to ensure that the software is going forward : if a merge breaks some earlier test, you'll know it.
For beginners, in order to avoid being lost in bash commands, GitHub Desktop is a fine GUI above Git.
Note : You can also rely on the package usethis which has a few helper functions like use_git, use_gitlab_ci, use_github_action... It's not specific to reviews and comments but to the gitlab and github integration
I am currently writing a text with R bookdown and asked two friends to read my text and give comments, corrections and general feedback. My source files for the text are stored on GitHub and I would like my collaborators to make changes in the files (one for each chapter) with the help of git. However, none of us are really experts on git. This makes it hard to figure out what a suitable workflow is.
For now, we decided that each one of them creates himself a branch so that he does not directly push into the master branch. After I have read their changes I would like to decide what I merge into the master branch and what not. So far, it looks like each change needs to be in a separate commit because I am not able to merge single lines from a specific commit (not sure if that is at all possible). However, this seems like a lot of annoying and unnecessary commits to create. So, I guess I am looking for a way to avoid that and/or general pointers towards a good workflow for such kind of projects.
A useful command will be git cherry-pick, it allows you to select specific commits from a branch.
A general good practice is that commits should be self contained (if applied alone they make sense) and they target a specific feature (in the use case mentioned, that could be a paragraph or a section or a chapter).
In the end, if you would like to apply only specific changes of a commit, that would have to happen manually, someone has to decide which parts to apply and which not. A commit can be edited using git rebase -i <branch name> before being merged. This question might also be useful.
I finally found what worked for me in here. Basically, on my master branch I had to use
git merge --no-commit --no-ff branch-to-merge
This will merge all changes into my master branch but does not immediatly commit the changes so that they can still be staged/unstaged. Then, I can decide what line change to include by staging the line changes I want to keep and discard all other line changes. Finally, I commit all staged line changes et voilà, that's what I wanted to get.
Sidenote: I am using gitkraken and as a beginner with git I enjoy using the GUI but the merge part with the options "no-commit" and "no-fast-forwarding" had to be done via the git console (at least I could not find a way to to that using the GUI). Choosing which lines to stage and which to discard is then an easy task via the GUI.
When working with git, I'm in the habit of reviewing all of my changes before pushing. I'd like to be able to do the same for Paw. I just can't seem to find any information on making this or other comparisons. I'd also like to see what others have pushed to their branches before merging into master.
I'm building an application that parses text files that contain information about specific nodes with incoming ports and outgoing ports that are interconnected. Doing some research there are some libraries but none of them support the exact characteristics needed.
this is what I'm trying to build and any language will do: Python, Perl, .net, etc.
One of the libraries I have found is GoDiagaram Node Classes
http://www.nwoods.com/components/dotnet/features-nodes.htm
The idea is to have boxes like so, interconnected and I should be able to click on one of them and link it to a new sub-diagram with more boxes contained in the one clicked.
Is there a counter part of these kind of charts that is opensource? and do these diagrams have a specific kind of name?
I don't know any specific details, since I never looked into this too closely, but here are some potential directions:
The data structure used for representing something like this is usually a graph (probably a directed graph). You could also try searching for graphical (or visual) programming languages. I seem to remember Pure Data as one that was relevant, but I never looked at it in detail.
Blender and VirtualDub both have a mode that's similar to this (the node editor and audio filters, respectively) and I believe both are open source, although I think neither has the option of having the nodes contain other nodes internally.
You could just use LabVIEW, which gives you the ability to create and edit LV code programmatically (search for "VI scripting"), but the code for that might not be very pretty and it's certainly not open source.
I'm looking at requiring my team to document their code more thoroughly for some major upcoming projects and to make life a little less painful, I am steering towards XML documentation generators such as Sandcastle, Doxygen or Box Live Documenter.
What are the key considerations I should keep in mind when evaluating the best option and what experiences have led you to a particular decision?
For me the key considerations would be:
Fully automated: Can it be set up in such a way so that pretty much
no outside work is required to
create or edit the documentation.
Fully styled: Can the documentation be fully styled so
that it looks great in a wiki or pdf
after it’s generated. I should be
able to change colors, font sizes,
layouts, etc.
Good Filtering: Can I select only the items I want to be
generated. I should be able to
filter the namespaces, file types,
classes, etc.
Customization: Can I include headers, footers, custom elements,
etc.
I found Doxygen could do all of this. Our workflow is as follows:
Developer makes a change to the code
They update the documentation tags right above the code they just changed
We click a generate button
Doxygen will then extract all the XML documentation from the code, filter it to only include the classes and methods we want, and apply the CSS styling we’ve pre-made for it. Our end result is an internal wiki that looks the way we want, and doesn’t require editing.
Extra: We have all our projects in various git repositories. We pull all these down to one root folder and generate the docs form this root folder..
Would be interested to know how others are automating even further..?
Who is paying for the documentation and why? (is the system stable enough, does it add enough value)
Who is going to read it, and why is she not using a more effective communication channel?
(if correct mostly distance in time/place)
Who is going to keep it up to date.
When are you going to destroy it? (Automatically if it hasn't been read or updated in the past three months?)
I mostly prefer better code to make my life less painful, over more documentation, but I like scenario & unit tests and a high level architecture description.
[edit] Documentation costs time and money to write and keep up to date. JavaDoc style documentation has a serious detrimental effect on the amount of code simultaneously visible and might be a good idea for the developers using the code, but not for those writing it.