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: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] git push #1
  • Date: Wed, 23 May 2012 09:10:33 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page