git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Haberman <stephen@exigencecorp.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: marceloribeiro <marcelo@sonnay.com>, git@vger.kernel.org
Subject: Re: Numeric Revision Names?
Date: Fri, 3 Oct 2008 11:55:57 -0500	[thread overview]
Message-ID: <20081003115557.08d80c2f.stephen@exigencecorp.com> (raw)
In-Reply-To: <m3d4ihr7as.fsf@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]


> Second, in my opinion revision numbers are not that useful for
> projects with large number of commits (where revision number might be
> something like r4321), and nonlinear history (you don't know how r4555
> relates to r4556: they might be on different branches).

For projects that do have a central authority (e.g. internal corporate
projects), revision numbers make more sense.

Granted, they are on separate branches (like svn), but the nice thing
about them is that they are monotonically increasing. E.g. our qa
people love numbers--the bug fix ticket says dev just put in
r100...qa/production box says it is on r95. Doesn't matter the
branch/whatever, they know the box doesn't have r100. Now, right, if
its r105, it is trickier, although we also throw in branch name (e.g.
topica-r100) which means no false positives but can lead to false
negatives.

Per Robin's response and then a thread on the list a year+ ago, a
hook+tags can be used to fake this, and we're doing that now. I've been
meaning to put our hooks repo up somewhere, as we've got several fun
hooks that are focused on an internal/centralized workflow, but I
haven't gotten to it yet. For now I've just attached the commit
numbers script.

For our team, lack of monotonic version numbers was a big deal--as in
can't use git sort of big deal. I wouldn't be surprised if it is a
contributing factor that keeps other people, especially internal teams,
from git. I understand all of the reasons it can't be in git proper,
but an FAQ entry about the hook/tag hack or link to a contrib script
might be useful (not necessarily the one attached, given its
functions/etc. baggage).

- Stephen


[-- Attachment #2: functions --]
[-- Type: application/octet-stream, Size: 6725 bytes --]

#!/bin/sh

# Sets: new_commits
# Assumes: $oldrev $newrev $refname
#
# This is for use in post receive hooks, as it assumes the refname has moved and
# is now newrev, we need to discard it. This is down with bash string replace,
# as it will replace only the first match, compared to the canonical "grep -v"
# approach which will throw out multiple matches if the same commit is referred
# to by multiple branches.
#
# Excellent, excellent docs from Andy Parkin's email script
#
##################################################
#
# Consider this:
#   1 --- 2 --- O --- X --- 3 --- 4 --- N
#
# O is $oldrev for $refname
# N is $newrev for $refname
# X is a revision pointed to by some other ref, for which we may
#   assume that an email has already been generated.
# In this case we want to issue an email containing only revisions
# 3, 4, and N.  Given (almost) by
#
#  git rev-list N ^O --not --all
#
# The reason for the "almost", is that the "--not --all" will take
# precedence over the "N", and effectively will translate to
#
#  git rev-list N ^O ^X ^N
#
# So, we need to build up the list more carefully.  git rev-parse
# will generate a list of revs that may be fed into git rev-list.
# We can get it to make the "--not --all" part and then filter out
# the "^N" with:
#
#  git rev-parse --not --all | grep -v N
#
# Then, using the --stdin switch to git rev-list we have effectively
# manufactured
#
#  git rev-list N ^O ^X
#
# This leaves a problem when someone else updates the repository
# while this script is running.  Their new value of the ref we're
# working on would be included in the "--not --all" output; and as
# our $newrev would be an ancestor of that commit, it would exclude
# all of our commits.  What we really want is to exclude the current
# value of $refname from the --not list, rather than N itself.  So:
#
#  git rev-parse --not --all | grep -v $(git rev-parse $refname)
#
# Get's us to something pretty safe (apart from the small time
# between refname being read, and git rev-parse running - for that,
# I give up)
#
#
# Next problem, consider this:
#   * --- B --- * --- O ($oldrev)
#          \
#           * --- X --- * --- N ($newrev)
#
# That is to say, there is no guarantee that oldrev is a strict
# subset of newrev (it would have required a --force, but that's
# allowed).  So, we can't simply say rev-list $oldrev..$newrev.
# Instead we find the common base of the two revs and list from
# there.
#
# As above, we need to take into account the presence of X; if
# another branch is already in the repository and points at some of
# the revisions that we are about to output - we don't want them.
# The solution is as before: git rev-parse output filtered.
#
# Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N
#
# Tags pushed into the repository generate nice shortlog emails that
# summarise the commits between them and the previous tag.  However,
# those emails don't include the full commit messages that we output
# for a branch update.  Therefore we still want to output revisions
# that have been output on a tag email.
#
# Luckily, git rev-parse includes just the tool.  Instead of using
# "--all" we use "--branches"; this has the added benefit that
# "remotes/" will be ignored as well.
#
##################################################
function set_new_commits() {
	nl=$'\n'

	# Get all the current branches, not'd as we want only new ones
	new_commits=$(git rev-parse --not --branches)

	# Strip off the not current branch
	new_hash=$(git rev-parse $refname)
	new_commits=${new_commits/^$new_hash/}

	# Put back newrev without the not
	new_commits=${new_commits}${nl}${newrev}

	# Put in ^oldrev if it's not a new branch
	if [ "$oldrev" != "0000000000000000000000000000000000000000" ] ; then
		new_commits=${new_commits}${nl}^${oldrev}
	fi

	new_commits=${new_commits/$nl$nl/$nl}
	new_commits=${new_commits/#$nl/}
}

# Sets: $change_type
# Assumes: $oldrev $newrev
#
# --- Interpret
# 0000->1234 (create)
# 1234->2345 (update)
# 2345->0000 (delete)
function set_change_type() {
	if [ "$oldrev" == "0000000000000000000000000000000000000000" ] ; then
		change_type="create"
	else
		if [ "$newrev" == "0000000000000000000000000000000000000000" ] ; then
			change_type="delete"
		else
			change_type="update"
		fi
	fi
}

# Sets: $newrev_type $oldrev_type $rev $rev_type
# Assumes: $newrev $oldrev
# --- Get the revision types
function set_rev_types() {
	newrev_type=$(git cat-file -t "$newrev" 2> /dev/null)
	oldrev_type=$(git cat-file -t "$oldrev" 2> /dev/null)
	if [ "$newrev" == "0000000000000000000000000000000000000000" ] ; then
		rev_type="$oldrev_type"
		rev="$oldrev"
	else
		rev_type="$newrev_type"
		rev="$newrev"
	fi
}

# Sets: $describe
# Assumes: $rev
#
# The email subject will contain the best description of the ref that we can build from the parameters
function set_describe() {
	rev_to_describe="$rev"
	if [ "$1" != "" ] ; then
		rev_to_describe="$1"
	fi

	describe=$(git describe $rev_to_describe 2>/dev/null)
	if [ -z "$describe" ]; then
		describe=$rev_to_describe
	fi
}

# Sets: $describe_tags
# Assumes: $rev
#
# The email subject will contain the best description of the ref that we can build from the parameters
function set_describe_tags() {
	rev_to_describe="$rev"
	if [ "$1" != "" ] ; then
		rev_to_describe="$1"
	fi

	describe_tags=$(git describe --tags $rev_to_describe 2>/dev/null)
	if [ -z "$describe_tags" ]; then
		describe_tags=$rev_to_describe
	fi
}

# Takes a lockfile path and command to execute once the lock is acquired.
#
# Retries every second for 5 minutes.
#
# with_lock "foo.lock" "echo a"             # Works
# with_lock "foo.lock" "echo b1 ; echo b2"  # Work
# function several() {
# echo several1 ; echo several2
# }
# with_lock "foo.lock" several              # Works
#
function with_lock() {
	lockfile="$1"
	block="$2"
	with_lock_has_lock=1

	trap with_lock_unlock_if_held INT TERM EXIT
	lockfile -1 -r 300 "$lockfile"
	with_lock_has_lock=$?
	if [ $with_lock_has_lock -ne 0 ] ; then
		exit $?
	fi
	eval "$block"
	rm -f "$lockfile"
	with_lock_has_lock=1
}

function with_lock_unlock_if_held() {
	if [[ "$with_lock_has_lock" -eq 0 ]] ; then
		rm -f "$lockfile"
	fi
}

function display_error_message() {
	echo "----------------------------------------------------" >&2
	echo ""                                                     >&2
	echo ""                                                     >&2
	for ((i=1;i<=$#;i+=1)); do
	eval message="$"$i
	echo "$message"                                             >&2
	done
	echo ""                                                     >&2
	echo ""                                                     >&2
	echo "----------------------------------------------------" >&2
}


[-- Attachment #3: post-receive-assign-commit-numbers --]
[-- Type: application/octet-stream, Size: 502 bytes --]

#!/bin/sh

. $(dirname $0)/functions

while read oldrev newrev refname ; do
	set_new_commits
	echo "$new_commits" | git rev-list --reverse --stdin | while read commit ; do
		if [[ $(grep "$commit" "$GIT_DIR/commitnumbers" 2>/dev/null) == "" ]] ; then
			with_lock "$GIT_DIR/commitnumbers.lock" 'echo "$commit $refname" >> "$GIT_DIR/commitnumbers"'
			number=$(grep --max-count=1 --line-number "$commit" "$GIT_DIR/commitnumbers" | grep -oP "^\d+(?=:)")
			git tag "r/$number" "$commit"
		fi
	done
done


  reply	other threads:[~2008-10-03 16:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 12:37 Numeric Revision Names? marceloribeiro
2008-10-03 12:41 ` Robin Burchell
2008-10-03 12:44 ` Bruce Stephens
2008-10-03 16:07 ` Jakub Narebski
2008-10-03 16:55   ` Stephen Haberman [this message]
2008-10-03 17:13     ` Thomas Rast
2008-10-03 17:42       ` Stephen Haberman
2008-10-05  3:13         ` André Goddard Rosa
2008-10-05  9:19           ` Alex Riesen
2008-10-03 17:14     ` Jeff King
2008-10-03 17:37       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081003115557.08d80c2f.stephen@exigencecorp.com \
    --to=stephen@exigencecorp.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=marcelo@sonnay.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).