To be honest, I use git add -p and, sometimes, it happens to have in the same hunk with date fields, some changes that I want to commit, so I have to edit that hunk and to manually revert the date changes. Hope my use case is more clear now.
On Thu, Jul 28, 2016 at 12:14 AM, Sergiu Dumitriu <[email protected]> wrote: > git add --interactive > > On 07/27/2016 03:59 AM, Alexandru Cotiuga wrote: > > I'm +1 for not committing date changes and it would be helpful to ignore > > them at some point, since I need all the time to edit files to commit in > > order to revert date changes. > > > > Thanks, > > Alex > > > > On Mon, Jul 25, 2016 at 10:40 PM, Thomas Mortagne < > [email protected] > >> wrote: > > > >> Le 25 juil. 2016 18:31, "Vincent Massol" <[email protected]> a écrit : > >>> > >>> > >>>> On 25 Jul 2016, at 18:20, Eduard Moraru <[email protected]> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol <[email protected]> > >> wrote: > >>>> > >>>>> I think I’d be in favor of: > >>>>> * Have our xar:format remove the dates > >>>>> * Have xar:verify fail if the dates are in the XML (thus our quality > >> build > >>>>> will fail if that’s the case) > >>>>> * Have the import set the current date if no dates are defined > (that’s > >>>>> probably the case already, would need to be checked) > >>>>> > >>>> > >>>> A side-effect of this is that, when you upgrade and extension, all the > >>>> pages of the extension will be changed and set to the update date as > >> their > >>>> last modification dates, right? (i.e. it affects both fresh installs > >> and > >>>> upgrades) > >>> > >>> Isn’t this what happens now already, i.e. when an existing page is > >> imported the current date is set (unless it’s a backup pack)? > >> > >> Yes EM does not take into account plumbing stuff like date and version. > >> > >>> > >>> If the issue is about the diff, I guess we could have a diff that > doesn’t > >> take into account the dates (or a better algorithm could be to not > update a > >> page that only has the date metadata modified). > >> > >> It's already the case... > >> > >>> > >>>> Thinking more about it, it could be problematic for all the pages of > an > >>>> extension that you upgrade to appear as being modified, even if > nothing > >>>> changed in them in that particular version. > >>> > >>> We should definitely not update pages with no changes. > >>> > >>>> Another minor negative side-effect would also be searching or listing > >>>> documents and sorting them by the last update time. Of course, this > >> would > >>>> mostly affect admins or users with "show hidden documents" enabled. > >>> > >>> I we don’t update pages that haven’t been changed we won’t have this > >> problem, right? > >>> > >>>> However, if you happen to also manage some content pages in your build > >>>> (that are not supposed to be hidden), this becomes a nuissance. > >>>> > >>>> WDYT about the 2 problems? I guess we could always accept them and say > >> that > >>>> installs/upgrades are relatively rare and that the impact is minimal > >> (and > >>>> similar to an empty save in a document - something that can already be > >>>> observed in practice in a document's history - so we don`t introduce > >>>> anything new). > >>>> > >>>> Thanks, > >>>> Eduard > >>>> > >>>> P.S.: Here`s an existing issue more or less related to this topic > >>>> http://jira.xwiki.org/browse/XWIKI-7058. Caty reminded me about it. > >>> > >>> And http://jira.xwiki.org/browse/XWIKI-11764 > >>> > >>> Thanks > >>> -Vincent > >>> > >>>> * Have AS and Watchlist exclude import / new wiki (already the case) > >>>>> > >>>>> Thanks > >>>>> -Vincent > >>>>> > >>>>>> On 25 Jul 2016, at 14:08, Eduard Moraru <[email protected]> > >> wrote: > >>>>>> > >>>>>> Hi, devs, > >>>>>> > >>>>>> This interesting discussion [1] came up recently on a github commit > >> that > >>>>>> lead us to realise that a practice which we have been doing since > >> forever > >>>>>> is not documented in our best practices guides and that we also seem > >> to > >>>>>> lack consensus on it. > >>>>>> > >>>>>> It`s about the practice of skipping date field changes from document > >> XML > >>>>>> pages when committing them to source control. This includes doc date > >>>>>> and contentUpdateDate > >>>>>> fields, but also attachment dates. > >>>>>> > >>>>>> You can see some arguments on the discussion[1], but I also wanted > to > >>>>>> mention that this practice goes in line with what we do for document > >>>>>> versions (which is handled by the xar:format maven plugin goal which > >> we > >>>>>> execute every time, before committing XML pages). If we are to > update > >> doc > >>>>>> dates, then we should also increment doc versions, otherwise it does > >> not > >>>>>> make any sense. > >>>>>> > >>>>>> The idea was, AFAIR, that XWIki`s code pages should not generate any > >>>>>> updates in the user`s wiki content, in any way, and that and update > >> of > >>>>> the > >>>>>> code of a "system"/XWiki page should not show up as an update of > *the > >>>>>> user's content*, since it would otherwise confuse him. > >>>>>> > >>>>>> What we are currently missing from xar:format is exactly this: the > >> reset > >>>>> of > >>>>>> XML page dates to have a clearer and more consistent date for > XWiki`s > >>>>> code > >>>>>> pages. > >>>>>> > >>>>>> Your input is appreciated and the result of this discussion would be > >> the > >>>>>> update of our Development Practices [2] and Application Development > >> Best > >>>>>> Practices [3] pages. > >>>>>> > >>>>>> Thanks, > >>>>>> Eduard > >>>>>> > >>>>>> ---------- > >>>>>> [1] > >>>>>> > >>>>> > >> > >> > https://github.com/xwiki/xwiki-platform/commit/1938dd18e1d25b8c03e4cb22286273bffdea5530#commitcomment-18375907 > >>>>>> [2] > >> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices > >>>>>> [3] > >>>>>> > >>>>> > >> > >> > http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices > >>>>>> _______________________________________________ > >>>>>> devs mailing list > >>>>>> [email protected] > >>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >>>>> > >>>>> _______________________________________________ > >>>>> devs mailing list > >>>>> [email protected] > >>>>> http://lists.xwiki.org/mailman/listinfo/devs > >>>>> > >>>> _______________________________________________ > >>>> devs mailing list > >>>> [email protected] > >>>> http://lists.xwiki.org/mailman/listinfo/devs > >>> > >>> _______________________________________________ > >>> devs mailing list > >>> [email protected] > >>> http://lists.xwiki.org/mailman/listinfo/devs > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
