[freetds] git push #1

[James K. Lowden]

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.

There are two changes:

1. fix code that induces warnings in clang. All innocuous.
2. remove txt2man.

All man pages are now in -mdoc format. It was a few hours' work. The
man pages now look a little better and we lose one dependency. With a
little cleverness, we could have them in PDF format, too.

The warnings were mostly about using // as a comment, something I'm
guilty of. These became either /**/ or #if 0.

The most significant changes are to md4.c and md5.c. Each had a line

memset(ctx, 0, sizeof(ctx));
now
memset(ctx, 0, sizeof(*ctx));

The line intends to clear memory before returning to prevent sensitive
data from remaining in memory. It was clearing sizeof(void*) instead of
the whole structure.

--jkl

[Frediano Ziglio]

Post by James K. Lowden
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.

Post by James K. Lowden
1. ?fix code that induces warnings in clang. ?All innocuous.
2. ?remove txt2man.
All man pages are now in -mdoc format. ?It was a few hours' work. ?The
man pages now look a little better and we lose one dependency. ?With a
little cleverness, we could have them in PDF format, too.
The warnings were mostly about using // as a comment, something I'm
guilty of. ?These became either /**/ or #if 0.
The most significant changes are to md4.c and md5.c. ?Each had a line
? ? ? ?memset(ctx, 0, sizeof(ctx));
now
? ? ? ?memset(ctx, 0, sizeof(*ctx));
The line intends to clear memory before returning to prevent sensitive
data from remaining in memory. ?It was clearing sizeof(void*) instead of
the whole structure.

I backported the change of memset as a small security issue. Well spot!

I noted that you fixed the +1 version issue too. Good!
However I found a small issues, 0_91.46 should be 0.91.46.
Spec file is updated too. Good!

Post by James K. Lowden
--jkl

Frediano

[James K. Lowden]

On Sat, 19 May 2012 13:57:28 +0100

Post by Frediano Ziglio
I noted that you fixed the +1 version issue too. Good!
However I found a small issues, 0_91.46 should be 0.91.46.

I'm still confused because "git branch" and "git describe" say
different things:

$ pwd
/var/releng/freetds/Branch-0_91

$ git branch
* Branch-0_91
master

$ git describe --tags
branch-0_92-54-ga8789bc

$ cd ../master
$ pwd
/var/releng/freetds/master

$ git branch
* master

$ git describe --tags
branch-0_92-325-g9a1fdd5

Is that what we want?

I use the script below to generate the version. I expect "git describe
--tags" and "git branch" to both say something about "0_91" on the
release branch and "0_92" on master. If that's not a good assumption,
I'll change it.

--jkl

#! /bin/sh
set -e

VERSION=$(git describe --tags \
| sed -E 's/^[^-]*-//; s/-g[[:xdigit:]]+//')

BRANCH=$(git branch | awk '/\*/ {print $2}')

test "${BRANCH}"

if [ master = ${BRANCH} ]
then
VERSION=$(echo $VERSION | awk -F'[_-]' '{print "dev."$1"_"$2"-"$3}')
fi
VERSION=$(echo $VERSION | sed 's/[_-]/./g')
echo $VERSION

[Frediano Ziglio]

Post by James K. Lowden
On Sat, 19 May 2012 13:57:28 +0100

Post by Frediano Ziglio
I noted that you fixed the +1 version issue too. Good!
However I found a small issues, 0_91.46 should be 0.91.46.

I'm still confused because "git branch" and "git describe" say
$ pwd
/var/releng/freetds/Branch-0_91
$ git branch
* Branch-0_91
?master
$ git describe --tags
branch-0_92-54-ga8789bc
$ cd ../master
$ pwd
/var/releng/freetds/master
$ git branch
* master
$ git describe --tags
branch-0_92-325-g9a1fdd5
Is that what we want?

Quite strange. Try to fetch tags again with

git fetch --tags

Post by James K. Lowden
I use the script below to generate the version. ?I expect "git describe
--tags" and "git branch" to both say something about "0_91" on the
release branch and "0_92" on master. ?If that's not a good assumption,
I'll change it.
--jkl
#! /bin/sh
set -e
VERSION=$(git describe --tags \
? ? ? ?| sed -E 's/^[^-]*-//; s/-g[[:xdigit:]]+//')
BRANCH=$(git branch | awk '/\*/ {print $2}')
test "${BRANCH}"
if [ master = ${BRANCH} ]
then
? ?VERSION=$(echo $VERSION | awk -F'[_-]' '{print "dev."$1"_"$2"-"$3}')
fi
VERSION=$(echo $VERSION | sed 's/[_-]/./g')
echo $VERSION

Frediano

[Craig A. Berry]

Post by Frediano Ziglio

Post by James K. Lowden
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-VMS-build-help-from-e6305b655e590c2.patch
Type: application/octet-stream
Size: 12267 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20120521/7387b95f/attachment.obj

[Frediano Ziglio]

Post by Frediano Ziglio

Post by James K. Lowden
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.

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
#
# ? ? ? modified: ? vms/descrip_mms.template
#
# ? (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
# ? (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.
% git checkout master
% git diff e6305b655e590c2^ e6305b655e590c2 vms/descrip_mms.template > e6305b655e590c2.patch
% git checkout Branch-0_91
% git apply e6305b655e590c2.patch
% 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

[James K. Lowden]

On Wed, 23 May 2012 09:10:33 +0100

Post by Frediano Ziglio

Post by Craig A. Berry
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

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

How do I prepare a ChangeLog that details every commit since the
previous release?

I'd like to continue keeping ChangeLog in the distribution even if it's
not a file managed by the SCM. For a release, I derive the news and
readme files from ChangeLog.

--jkl

[Craig A. Berry]

Post by James K. Lowden
On Wed, 23 May 2012 09:10:33 +0100

Post by Frediano Ziglio

Post by Craig A. Berry
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

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

Right, it was an illustration from the past but an indication of trouble that could happen if we keep using the ChangeLog (as James has been doing). (and thanks for applying my patch)

Post by James K. Lowden
How do I prepare a ChangeLog that details every commit since the
previous release?
I'd like to continue keeping ChangeLog in the distribution even if it's
not a file managed by the SCM. For a release, I derive the news and
readme files from ChangeLog.

You might start with:

% git checkout master
Already on 'master'
% git log branch-0_91..HEAD > myChangeLog
warning: refname 'branch-0_91' is ambiguous.

and see what you want in myChangeLog that's not there. There are a *lot* of options to "git log".

I believe the ambiguous ref warning is because we have a tag name that is the same as a branch name. I don't think, going forward, that tags should really have "branch" in their names.

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

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

[James K. Lowden]

On Wed, 23 May 2012 19:12:44 -0500

Post by Craig A. Berry

Post by Frediano Ziglio

Post by Craig A. Berry
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

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

Right, it was an illustration from the past but an indication of
trouble that could happen if we keep using the ChangeLog (as James
has been doing).

I've kept this message marked for months because I knew it should make
sense and I suspected something would go missing without ChangeLog.
Now that I have a vague idea what "cherry picking" means as a term of
art, I sort of get it.

I'm OK with "git rm ChangeLog". I do think, though, that the
distribution tarballs should hold a synthesized ChangeLog, presumably
generated from the git logs. That's a little tricky ISTM because it
has to start from the point of the most recent release. That
information could be held in a little marker file in the repository, if
that helped.

Suggestions?

--jkl