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

[Rich Freeman <r-plug@thefreemanclan.net>]

On Fri, Dec 21, 2018 at 4:31 PM Fred Stluka <fred@bristle.com> wrote:
>
> But, I'm not sure what rebase has to do with this.  When I get this
> error, I always just pull, which does a merge.  If the changes made
> were in unrelated parts of the files, the merge is automatic.  If not
> there are "merge conflicts" that I have to resolve manually because,
> for example, another developer and I made unrelated changes to
> the same line of code.  If the merge is automatic, it's fast, and so
> my next push works fine.  If not, I may take some time to manually
> resolve the conflicts, and someone may meanwhile do another
> push, so my next push fails, and I have to do another pull first.
> But I've never needed rebase in this scenario.  What am I missing?

Rebase is the same as merge as far as this issue is concerned.  The
step you're missing is confirming that your changes still work
properly after merging them in with the commits you just pulled.

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.

> For scalability, what about the workflow where folks fork (clone)
> the repo, make their change, and issue a "pull request"?  ...
> Would you expect this to also not scale?  It see it used on large
> scale FOSS projects like Django.

Indeed, this is basically the workflow used on Linux that git was
built for.  It certainly works, but requires that a minimal number of
people actually commit to the repository.  In the case of Linux that
would be one person.

-- 
Rich
___________________________________________________________________________
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