On Thu, Jul 28, 2016 at 10:21 AM, Alexandru Cotiuga < [email protected]> wrote:
> 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. > You can use the "s" (split) option when you encounter such a group of changes. > > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
