Re: [lmi] Did I resolve this git issue correctly?

[Greg Chicares]

On 2016-12-07 14:09, Vadim Zeitlin wrote:
> On Wed, 7 Dec 2016 10:23:49 +0000 Greg Chicares <address@hidden> wrote:

[...'git push' rejected; I resolved that by doing 'git pull' first...]

> GC> I don't see where this did any harm, but did I handle it in the best way?
> 
>  You indeed didn't do any harm, but many people, me included, think that
> this is not the best way to do things.

[...instead: 'git pull --rebase', then 'git push'...]

>  But I strongly suspect that you actually want to understand why is this
> preferable instead of just being told what to do, so let me explain: the

Yes, thanks for the detailed explanations, including the parts that I've
elided here.

> important thing is that this will avoid a meaningless merge commit and the
> history will remain linear, which is not the case now:
> 
>       % git log --oneline --graph -8 master
>       *   8f40291 Merge branch 'master' of git.sv.gnu.org:/srv/git/lmi
>       |\
>       | * 0778129 Disable clang warnings about mismatched struct/class
>       | * c1c9c1a Fix linking of mc_enum unit test when using autotools
>       * | fd65f39 Improve rate-table accuracy
>       * | 7721853 Test for CR and VT separately
>       * | 4f35f0c Use extension '.rates' for rate tables; enforce coding 
> rules for them
>       * | eb8fbb6 Revert "Allow empty comments in rate tables"
>       |/
>       * 802eb23 Refactor for simplicity

Yick. I did so want to maintain universal linearity. But rewriting the
history now is probably much worse than living with this departure from
one-dimensional purity.

>  Of course, there is nothing wrong with having merges in git, but it's
> better if they're intentional and have semantic meaning, i.e. correspond to
> the integration of some feature (or series of bug fixes) into master. Here
> it is not the case and the merge just makes the history unnecessarily
> confusing.

Indeed.

>  To finish on a somewhat philosophical note, initially I thought that it
> was pretty important to have a nice linear history (as do all the people
> coming from svn or cvs, of course, because dealing with branches in these
> systems is such a pain). However the more I work with git, more I start to
> appreciate having each change done in its own independent branch.

Thanks, but I want to remain in my linear world--not because branching
was mechanically difficult with svn, but because it's conceptually
simpler with any vcs. Two dimensions good--one dimension better; at
least for a project like this that is inherently one-dimensional.