Skip to Content.
Sympa Menu

freetds - Re: [freetds] git push #1

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Craig A. Berry" <craigberry AT mac.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] git push #1
  • Date: Mon, 21 May 2012 21:40:58 -0500


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




Archive powered by MHonArc 2.6.24.

Top of Page