Re: [PLUG] Git: net time gain or loss?

[Fred Stluka <fred@bristle.com>]

On 12/21/18 4:44 PM, Rich Freeman wrote:
> If you're just going to blindly accept whatever git merge/rebase gives
> you then sure, it isn't a big deal as far as git itself is concerned.
> But, the remote repository could have just done that if there were no
> merge conflicts.
>
> Normally you want to check to make sure that your change doesn't
> introduce a regression.  Maybe somebody changed an API for a function
> you're using, in a file you didn't modify - git would have no way of
> detecting that, and if you just added the call to that function in the
> changes you're committing the other committer wouldn't have fixed up
> your code and caused a merge conflict in your own file.
>
> In the case of Gentoo (which was the example I was citing), maybe a
> package's dependencies changed in some way that causes a break in the
> package you're about to commit.  This can be detected with some QA
> scripts, but they can take 30-60 seconds to run and that increases the
> window for push collisions.

Right.  As much as I love Git, I've always been leery of allowing
any automated tool to merge what it thinks are unrelated changes.
I've worried about the examples you cite:
- Change to function syntax:
   - Args passed
   - Data type returned
   - etc.
- Change to dependencies

Also:
- Change to function *semantics*:
   - What it is supposed to do when called
   - What else the caller is supposed to do before/after calling it
   - What global effects it has on the world
   - etc.
- "Cross-cutting concerns" like:
   - I add logging to all functions and you add a new function
   - I change all Python string literals from ASCII to Unicode, and
     you add a new string literal
- Semantic conflicts:
   - I add code to the top of a function to fix a problem, but you
      add different code (or the same code) to the bottom of the
      function to fix the same problem

Automatic merges, in any tool, won't spot these issues.  An
extensive set of regression tests might catch some, but probably
not all.

But it's not just a problem with automatic merges.  The same
situations can occur with strictly sequential updates to a code
base by multiple people, unless the people all communicate
very well with each other about the intent of every change they
make.  So, it happens with a distributed or non-distributed VCS.

My answer, as an anal-compulsive, OCD type of guy (which I claim
is critical to me being a good programmer), has been to wrap any
VCS tool I've used for the past 30+ years with scripts that always
show me a diff of every source file modified by any other team
member.  So, effectively, I'm always playing Linus.  And I've been
automating my own versions of what today is called a "pull request".

While I'm at it, my scripts automate other steps like:
- Helping me write release notes by pulling info on resolved tickets
   from Jira, and diffing the Git log with a local copy

And things that I should probably move into a CI like Jenkins like:
- Adding a Git tag for a formal build that might be released
- Auto-generating new database "migrations"
- Running any database "migrations" not yet run
- Rsyncing files from the PROD server that an end user may have
   changed or added so that regression tests are more valid
- Running regression tests

See, for example:
- http://bristle.com/Tips/Mac/Unix/gitpullreview
- http://bristle.com/Tips/Mac/Unix/gitsync

--Fred
------------------------------------------------------------------------
Fred Stluka -- Bristle Software, Inc. -- http://bristle.com
#DontBeATrump -- Make America Honorable Again!
------------------------------------------------------------------------


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug