FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2012/5/22 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:
>

Yes, now we don't change ChangeLog every time, git log is enough, but
at the time you did the patch we was still in cvs -> git transition

> % 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

Applied.

Frediano