FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

On May 19, 2012, at 7:57 AM, Frediano Ziglio wrote:

> 2012/5/18 James K. Lowden <jklowden AT freetds.org>:
>> For anyone interested in the git repository, I just pushed my first
>> commit with
>> 
>>        git push ssh://git AT gitorious.org/freetds/freetds.git
>> 
>> It seemed work.  I'm still getting the hang of git.
>> 
> 
> Yes, confirmed !!
> 
> I think that "git push" is enough.


It's usually enough, unless someone else has pushed since your last push.  In 
that case you'll want to do "git pull --rebase" first in order to avoid 
spurious empty merge commits.  They don't actually do much harm but they do 
create stupid-looking singularities in the commit history.

I also think ChangeLog is now redundant and could be phased out.  It even 
creates a genuine problem when trying to cherry-pick changes from master onto 
a maint branch when the ChangeLog was modified in the same commit as 
something else.  Here's an example:

% git checkout Branch-0_91
Switched to branch 'Branch-0_91'
% git cherry-pick e6305b655e590c2
error: could not apply e6305b6... Build more of the newer tests we weren't 
building on VMS.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
% git status
# On branch Branch-0_91
# Changes to be committed:
#
#       modified:   vms/descrip_mms.template
#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      ChangeLog
#

There is a merge conflict because ChangeLog is too different between the two 
branches to be merged even though the actual bits of code that I want merge 
just fine.  Now, if I wanted *all* of the changes to a particular file in 
master, I could (instead of the above) do

% git checkout Branch-0_91
Switched to branch 'Branch-0_91'
% git checkout master vms/descrip_mms.template
% git status
# On branch Branch-0_91
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   vms/descrip_mms.template
#

Which apparently (I just learned this today) grabs the entire file currently 
in the master branch and pulls it into whatever branch I'm on. But 
unfortunately in this case, that brings changes to the file that should not 
be pulled into the maint branch as well as those that should.

So instead I have to do something like:

% git checkout master
% git diff e6305b655e590c2^ e6305b655e590c2 vms/descrip_mms.template > 
e6305b655e590c2.patch
% git checkout Branch-0_91
% git apply e6305b655e590c2.patch

And then commit as if it were an entirely new patch and I weren't working on 
two related branches of a repository in a modern version control system, 
which it isn't and I am.  But since I have just gone through this exercise, 
there two more steps to preparing this change, one of which is:

% git format-patch HEAD~1
0001-VMS-build-help-from-e6305b655e590c2.patch

and the other of which is attaching that patch here and requesting that it be 
applied (with "git am" or "git apply-patch") to the 0.91 branch.  Without 
this patch, 0.91 doesn't build on VMS.  If someone would apply it I'd be 
grateful.

  
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Attachment: 0001-VMS-build-help-from-e6305b655e590c2.patch
Description: Binary data