On 05.11.2014 00:12, Zieris, Franz wrote: > Hi Stefan and Arsenij, > >> as it only messes up the history > No, it doesn't -- and it would be terrible, if Git really couldn't cope with > such situations. My bad. What I meant was it is creating noise in the history log that should not be needed. Depending on your GIT Tooling it might be easy to follow the whole refactoring stuff or it might not. At least with my EGit Tooling this gives my headaches because I have to checkout the commit to follow the history to see all other affected files etc. > You could search your e-mails and find an e-mail sent from me to you two on > 2013-12-16, subject "Restrukturierung des gesamten Package Layouts" (that > thread was on exactly the same issue as this one here). > Or you keep on reading, because this is what I wrote (back then it was in > German for it was a private e-mail): > > --- Old E-Mail --- > > I just tried the rename "project" -> "session". Result: > > * The history of individual resources is shown correctly in EGit. > The diff tool (e.g. through "Compare with workspace version") does not > work. > * TortoiseGit only shows the history until the renaming (looks like an > open > issue http://code.google.com/p/tortoisegit/issues/detail?id=1600) > * On the command line, you can use "git log" with the "--follow" > parameter. > Then file renaming (including small content changes like changed > "package ..." > lines) are survived pretty well. > * Gerrit uses the same mechanism to detect renamed files. > > --- /Old E-mail --- > > Example for Gerrit in action: > http://saros-build.imp.fu-berlin.de/gerrit/#/c/1431/ > Example for GitHub in action: > https://github.com/saros-project/saros/commit/26985b547223558a46f9cb562e491fa1a6d49b0a#diff-2 > > Example to try it yourself: The first command lists 4 commits and stops at > the renaming; the second command goes back deep into the past. > > $> git log --oneline > de.fu_berlin.inf.dpp.core/src/de/fu_berlin/inf/dpp/activities/SPath.java > $> git log --oneline --follow > de.fu_berlin.inf.dpp.core/src/de/fu_berlin/inf/dpp/activities/SPath.java > > Conclusion: Git is designed in a way that makes arguments like "We don't > rename our files, even if the old names are pretty bad, because this messes > with the history" unnecessary (and many others, too), so you can completely > concentrate on the important things in life. > > Cheers, > Franz > > > PS: To answer Arsenij's original question, take a look at the history of the > core's "session" package > (https://github.com/saros-project/saros/commits/master/de.fu_berlin.inf.dpp.core/src/de/fu_berlin/inf/dpp/session). > Look at the oldest commit in that list, i.e. the commit that created that > package (https://github.com/saros-project/saros/commit/66d510e). > Read the full commit message and you'll have your explanation ("[...] changed > the package name but using session instead of the old project package.") > > > -----Original Message----- > From: Stefan Rossbach [mailto:srossb...@arcor.de] > Sent: Tuesday, November 04, 2014 10:00 PM > To: Arsenij E Solovjev; dpp-devel@lists.sourceforge.net > Subject: Re: [DPP-Devel] Difference between de.fu_berlin.inf.dpp.session and > de.fu_berlin.inf.dpp.project > > Refactor what ? The package name ? There is no need as it only messes up the > history. Mostly all those files inside the project package will be moved to > the session package (do not ask for an ETA). > > On 04.11.2014 21:52, Arsenij E Solovjev wrote: >> Hi dear devs, >> >> Is there a substantial difference between the packages .session and >> .project? >> Historically, there was only Project, back when Saros was >> project-based and you could only share one project. Afterwards Saros >> became session-based (mulitple projects can be shared). As I see it >> the session component is a generalization over project, and they >> should be united into a "session_management" >> component >> (as in Patrick Schlott's diagramm). >> >> I ask because I want to refactor them together, because it would ease >> with what I'm doing at the time, namely trying to bring the visual >> representation of the architecture and the package structure closer >> together. >> >> Any thoughts or objections? >> >> Cheers, >> Arsenij >> >> >> ---------------------------------------------------------------------- >> -------- _______________________________________________ >> DPP-Devel mailing list >> DPP-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dpp-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel
------------------------------------------------------------------------------ _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
