# Is there a clean way to create offset branches in gitdags?

Julien Cretel created the elegant gitdags package for easily generating educational git graphs, which I'm currently using to create educational and reference materials for my team.

When discussing branching in some context, I like to add a “kink” to the graph to visually reinforce the idea that a branch represents a line of development and that other work might continue concurrently

Is there a clean way to tell gitdags/TikZ to offset a node vertically like this?

-
Perhaps add a tag for gitdags? If it doesn't exist, it'd be great to create one for it :) – cmhughes Feb 14 at 14:12
@cmhuges I tried but I don't have the reputation :} – Daniel Rocco Feb 15 at 14:29
No problem :) done! your question is the first to be tagged with gitdags :) :) :) – cmhughes Feb 17 at 14:04

## 2 Answers

I don't know if this counts as "cleaner" (and I also don't know the gitdags package) but anyway:

\documentclass[tikz,border=5]{standalone}
\usepackage{gitdags}
\tikzgraphsset{%
nudge/.style={/tikz/shift={#1}},
nudge down/.style={nudge=(270:#1)},
nudge down/.default=1
}
\begin{document}
\begin{tikzpicture}
\gitDAG[grow right sep = 2em]{
{[nodes=placeholder commits] "..."}  -- A -- B -- C --
{[nudge down]
D -- E;
}
};
\end{tikzpicture}
\end{document}


-
This is great! Yes, your solution is cleaner than mine: it lets us express our actual intent, rather than tricking TikZ with an invisible node hack. Thanks! :) – Daniel Rocco Feb 17 at 14:34

My current solution, used to generate the graph in the question, is to create an invisible node along the master branch, which forces the node D to the next row:

\gitDAG[grow right sep = 2em]{
{[nodes=placeholder commits] "..." } -- A -- B -- C -- {
"" [placeholder];
D [>opacity=0.75] -- E;
}
};


The "" [placeholder]; bit creates the invisible node after C along the master branch; D represents a parallel line of development and therefore is vertically aligned with the invisible node.

This trick gets the job done but feels very hackish, especially since we have to reset the edge opacity when we are done ([>opacity=0.75]). Without this reset, nodes D and E will be rendered but their edges will not.

-