<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Jan 2016, at 18:52, Nicholas Sauter &lt;<a href="mailto:nksauter@lbl.gov" class="">nksauter@lbl.gov</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: LucidaSans; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If a feature is broken today, but I know for a fact that it worked sometime in the past, I simply do a svn update -r "[datestamp]" to narrow down the exact date when the feature became broken, then I isolate the exact commit and look at the code.&nbsp; Can this be done with git or does it even make sense if there is no concept of linear change?</div></div></blockquote><br class=""></div><div>You can do that with git, and more: git bisect can automatically find for you which commit introduced the bug you are hunting down. Moreover git ships with a graphical viewer, gitk, which displays all the branches. But that means you would be forced to use git and this is enough of a paradigm shift compared to svn that you may not want to invest the time to learn it because svn just works fine for you. I respect that and this is the crux of the point I raised. I think it’s important we all think about those issues before diving in.</div><div><br class=""></div><div>Best wishes,</div><div><br class=""></div><div>Luc</div><div><br class=""></div></body></html>