Re: Harmonious collaboration - reverting commit process

Nicholas Rishel via Bf-committers <[email protected]>
Newsgroups gmane.comp.video.blender.devel
Message-ID <CA+OttGai8+5myDZymjJAYS7Nb_sSLj0=im7FxcmgwO=a_bvWag@mail.gmail.com>
Howard,

I'd recommend using git gui over terminal for commit staging. It's easier
to jump between staging at line/hunk/bulk file granularity so you rarely
make overcommitting mistakes.


On Wed, Jun 9, 2021 at 9:35 AM Sergey Sharybin via Bf-committers <
[email protected]> wrote:

> Hi,
>
> Currently I do not believe submodules change is important enough to grant a
> revertal. Some reasoning:
>
> - It is often harmless
> - It is easy to recover from
> - It is hard to avoid by mistake (even happens for me when committing from
> a non-main PC!)
>
> I do believe the situation with submodules is to be changed, to make it
> easier to do the right thing, but this is a separate topic.
>
> ---
>
> Some thoughts on the matter. Doing it in this thread because I do not have
> a concrete proposal yet to grant a useful conversation. Although,
> bringing some points on the table will help to understand the
> situation better.
>
> Part of the issue is that we don't use submodules and configuration
> correctly. When we did an initial transition from Subversion to Git the
> `ignore = all` meant that the submodule is ignored for both DIFF and STAGE
> family of Git commands. But! This is how code worked, not how it was
> documented. After some time the Git code got fixed to follow documentation.
> That's why we now have lots of submodule changes committed.
>
> The current state is very confusing: git status/diff will not show changes
> in the submodules, but git add and git commit will make it so changes are
> very easy to land to the official repository.
>
> One thing we can/should do is to remove the `ignore = all` setting, so that
> it is at least visible what is in the commit.
> Maybe add a post-receive check about submodules on the server?
>
> But how to make it so it's easy to commit still? Ask everyone to never
> stage submodules? Don't think this is a good solution.
> Maybe make an easy-to-install local hook which will do some unstage magic
> for the submodules?
>
> Anyway, so for the topic of commit revertal I do not think submodules
> change should be reverted simply because our current setup feels messy and
> unfriendly.
> If someone feels like looking into a solution, I suggest moving this matter
> to a separate ML thread, to keep discussions more focused.
>
> Best regards,
> - Sergey -
> --------------------------------------------------------------------
> Sergey Sharybin - [email protected] - www.blender.org
> Principal Software Engineer, Blender
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On Wed, Jun 9, 2021 at 6:20 PM Howard Trickey via Bf-committers <
> [email protected]> wrote:
>
> > Speaking of that error -- submodules changed by mistake -- what is the
> best
> > practice to avoid that? My GSoC mentee was asking about that, and I told
> > him
> > what I do, but it seems clunky and there is probably a better way.
> >
> > What I do:
> > 1) make sure I've used "make update" or something similar to ensure that
> > the
> > submodules are up to date
> > 2) when I "git add" files, I always add explicitly, one by one, only
> those
> > files
> > that "git status" shows I've changed. In other
> >
> > Is there something easier than (2)?
> >
> > On Wed, Jun 9, 2021 at 7:46 AM Jeroen Bakker via Bf-committers <
> > [email protected]> wrote:
> >
> > > A common reason why I revert commits is that submodules were changed by
> > > mistake. Is reverting a good solution? Perhaps worth mentioning.
> > >
> > > Jeroen
> > >
> > >
> > > On Wed, Jun 9, 2021 at 12:55 PM Sergey Sharybin via Bf-committers <
> > > [email protected]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Today I continued to update the development process guidelines and
> > > policies
> > > > on the Wiki. This is based on previous discussions with the other
> > > > bf-admins, and I'm working with Dalai on the final text adjustments.
> So
> > > > today we handled the "polemic" topic of reverting commits:
> > > > https://wiki.blender.org/wiki/Process/Revert_Commit
> > > >
> > > > Feedback and suggestions are welcome.
> > > >
> > > > Please note that we do read the feedback you are giving. Currently we
> > are
> > > > focusing on finishing the first pass of the process update. We will
> > then
> > > > look into addressing your feedback to make the development process
> fun
> > > and
> > > > smooth!
> > > >
> > > > Best regards,
> > > > - Sergey -
> > > > --------------------------------------------------------------------
> > > > Sergey Sharybin - [email protected] - www.blender.org
> > > > Principal Software Engineer, Blender
> > > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> > > > _______________________________________________
> > > > Bf-committers mailing list
> > > > [email protected]
> > > > https://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > _______________________________________________
> > > Bf-committers mailing list
> > > [email protected]
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > [email protected]
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> [email protected]
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
[email protected]
https://lists.blender.org/mailman/listinfo/bf-committers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.