[PATCH] Added an option to cvsimport to specify email domain
The authorship info in commits created by git-cvsimport-script
only contains the username of the CVS committer. This patch
adds a flag -e to git-cvsimport-script that makes it
possible to specify an email domain that is added to all email
addresses in the commit "author" and "committer" fields.
---
I have stopped using cvsimport, because cvsps seems to produce bad
output on the repository I'm using it with, but I had already prepared
this patch.
Documentation/git-cvsimport-script.txt |8 +++-
git-cvsimport-script | 18 +-
2 files changed, 20 insertions(+), 6 deletions(-)
cabbc2b5cae2dcd892d02a3c679698cdfb3b9de5
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -12,7 +12,9 @@ SYNOPSIS
'git-cvsimport-script' [ -o ] [ -h ] [ -v ]
[ -d ] [ -p ]
[ -C ] [ -i ] [ -k ]
- [ -s ] [ -m ] [ -M regex ] [ ]
+ [ -s ] [ -m ] [ -M regex ]
+ [ -e ]
+ [ ]
DESCRIPTION
@@ -86,6 +88,10 @@ OPTIONS
-s ::
Substitute the character "/" in branch names with
+-e ::
+Append '@' to the author name to use as the email
+address in commit objects.
+
OUTPUT
--
If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -29,19 +29,20 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s,$opt_m,$opt_M);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s,$opt_m,$opt_M,$opt_e);
sub usage() {
print STDERR
Re: [PATCH] Add $(LIBS) and set libiconv in tools/Makefile for Darwin
--- Junio C Hamano <[EMAIL PROTECTED]> wrote: > I'd do this slightly differently. Could you take a look at what > I have in the "proposed updates" branch, especially "Flatten > tools/ directory" commit? What I am aiming for is to have > platform specific ifeq() thing in only one place. Looks good to me, Junio. There's a very small typo in your commit though. :-) Cheers, --Mark --- diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -149,7 +149,7 @@ else MOZILLA_SHA1=1 OPENSSL_LIBSSL= endif -ifdef NEEDS_SSL_WITH_CRIPTO +ifdef NEEDS_SSL_WITH_CRYPTO LIB_4_CRYPTO = -lcrypto -lssl else LIB_4_CRYPTO = -lcrypto - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] A new merge algorithm, take 3
Hi,
Here is the new version of the merge algorithm patch.
The major changes compared to the previous patch are:
* No more messing around with merge-cache. git-ls-files used to get
the unmerged entries instead.
* The python code is now contained in two files, git-merge-script and
gitMergeCommon.py.
* The user interface is identical to the interface provided by
git-resolve-script
* In the non-clean case the unmerged cache entries will not be
removed from the cache.
I have also attached a test script which can redo every merge in a
repository with both git-resolve-script and git-merge-script. It will
report any non-clean merges and non-identical results for clean
merges. Do _not_ use this script in repositories you care about. It
calls 'git reset --hard' repeatedly and will probably not leave the
repository in its original state when it's done.
Of the 500 merge commits that currently exists in the kernel
repository 19 produces non-clean merges with git-merge-script. The
four merge cases listed in
<[EMAIL PROTECTED]> are cleanly merged by
git-merge-script. Every merge commit which is cleanly merged by
git-resolve-script is also cleanly merged by git-merge-script,
furthermore the results are identical. There are currently two merges
in the kernel repository which are not cleanly merged by
git-resolve-script but are cleanly merged by git-merge-script.
I guess the need for this has decreased with Daniel's new read-tree
code. Is there any chance of getting this code merged into mainline
git?
- Fredrik
#!/usr/bin/env python
import sys, math, random, os, re, signal, tempfile, time
from heapq import heappush, heappop
from sets import Set
from gitMergeCommon import *
def mergeMerge(a, b):
print 'Running merge-script HEAD', b.sha, '...'
[out, code] = runProgram(['git-merge-script', 'HEAD', b.sha, 'merge message'],
returnCode=True, pipeOutput=False)
if code == 0:
return True
else:
return False
def gitResolveMerge(a, b):
print 'Running git resolve HEAD', b.sha, '...'
[out, code] = runProgram(['git', 'resolve', 'HEAD', b.sha, 'merge message'],
returnCode=True, pipeOutput=False)
if code == 0:
return True
else:
return False
def doWork(graph, commits):
print 'commits:', repr(commits)
result = []
totalMergeTime = 0
totalResolveTime = 0
numCommits = 0
try:
for commit in graph.commits:
if len(commits) > 0 and not (commit.sha in commits):
continue
if len(commit.parents) > 1:
res = commit.sha + ' : '
if len(commit.parents) == 2:
numCommits += 1
print '---'
print 'Testing commit', commit.sha, '(tree)', commit.tree()
a = commit.parents[0]
b = commit.parents[1]
runProgram(['git-reset-script', '--hard', a.sha])
print 'Running git resolve...'
stdout.flush()
startTime = time.time()
resResolve = gitResolveMerge(a, b)
timeResolve = time.time() - startTime
totalResolveTime += timeResolve
if resResolve:
resolveHead = Commit(runProgram(['git-rev-parse', '--verify', 'HEAD']).rstrip(), [a, b])
runProgram(['git-reset-script', '--hard', a.sha])
print 'Running merge...'
stdout.flush()
startTime = time.time()
resMerge = mergeMerge(a, b)
timeMerge = time.time() - startTime
totalMergeTime += timeMerge
if resMerge:
mergeHead = Commit(runProgram(['git-rev-parse', '--verify', 'HEAD']).rstrip(), [a, b])
res += 'time r: ' + str(int(timeResolve)) + ' m: ' + str(int(timeMerge)) + '\t'
if resResolve and resMerge:
if resolveHead.tree() == mergeHead.tree():
res += 'Identical result'
else:
res += 'Non-identical results! resolve: ' + resolveHead.sha + \
' merge: ' + mergeHead.sha
else:
if resResolve:
res += 'resolve succeeded (' + resolveHead.sha + '), '
else:
res += 'resolve failed, '
if resMerge:
res += 'merge succeeded (' + mergeHead.sha + ')'
else:
res += 'merge failed'
else:
res += 'Ignoring octupus merge'
print res
[PATCH 1/2] Add '-i' flag to read-tree to make it ignore whats in the working directory.
This will be used by the merge code.
Signed-off-by: Fredrik Kuivinen <[EMAIL PROTECTED]>
---
read-tree.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
12d226103dc278c5d5aaf6b2dc776af3170ed233
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/read-tree.c
@@ -7,6 +7,7 @@
static int stage = 0;
static int update = 0;
+static int ignore_working_dir = 0;
static int unpack_tree(unsigned char *sha1)
{
@@ -80,7 +81,10 @@ static void verify_uptodate(struct cache
{
struct stat st;
- if (!lstat(ce->name, &st)) {
+if (ignore_working_dir)
+return;
+
+if (!lstat(ce->name, &st)) {
unsigned changed = ce_match_stat(ce, &st);
if (!changed)
return;
@@ -510,7 +514,7 @@ static int read_cache_unmerged(void)
return deleted;
}
-static const char read_tree_usage[] = "git-read-tree ( | -m [-u]
[ []])";
+static const char read_tree_usage[] = "git-read-tree ( | -m [-u] [-i]
[ []])";
static struct cache_file cache_file;
@@ -535,6 +539,11 @@ int main(int argc, char **argv)
continue;
}
+if (!strcmp(arg, "-i")) {
+ignore_working_dir = 1;
+continue;
+}
+
/* This differs from "-m" in that we'll silently ignore
unmerged entries */
if (!strcmp(arg, "--reset")) {
if (stage || merge || emu23)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] A new merge algorithm
The new algorithm handles multiple common ancestors in a better way.
Signed-off-by: Fredrik Kuivinen <[EMAIL PROTECTED]>
---
Makefile |3
git-merge-script | 491 +
gitMergeCommon.py | 286 +++
3 files changed, 779 insertions(+), 1 deletions(-)
create mode 100644 git-merge-script
create mode 100644 gitMergeCommon.py
4c86af6fac9d0f527c277c88d7ae3d200dd24f61
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -66,7 +66,8 @@ SCRIPTS=git git-merge-one-file-script gi
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote-script git-verify-tag-script \
git-ls-remote-script git-rename-script \
- git-request-pull-script git-bisect-script
+ git-request-pull-script git-bisect-script gitMergeCommon.py \
+ git-merge-script
SCRIPTS += git-count-objects-script
SCRIPTS += git-revert-script
diff --git a/git-merge-script b/git-merge-script
new file mode 100755
--- /dev/null
+++ b/git-merge-script
@@ -0,0 +1,491 @@
+#!/usr/bin/env python
+
+import sys, math, random, os, re, signal, tempfile, stat, errno
+from heapq import heappush, heappop
+from sets import Set
+from gitMergeCommon import *
+
+alwaysWriteTree = False
+
+# The actual merge code
+# -
+
+def merge(h1, h2, branch1Name, branch2Name, graph, callDepth=0):
+'''Merge the commits h1 and h2, return the resulting virtual
+commit object and a flag indicating the cleaness of the merge.'''
+assert(isinstance(h1, Commit) and isinstance(h2, Commit))
+assert(isinstance(graph, Graph))
+
+def infoMsg(*args):
+sys.stdout.write(' '*callDepth)
+printList(args)
+infoMsg('Merging:')
+infoMsg(h1)
+infoMsg(h2)
+sys.stdout.flush()
+
+ca = getCommonAncestors(graph, h1, h2)
+infoMsg('found', len(ca), 'common ancestor(s):')
+for x in ca:
+infoMsg(x)
+sys.stdout.flush()
+
+Ms = ca[0]
+for h in ca[1:]:
+[Ms, ignore] = merge(Ms, h,
+ 'Temporary shared merge branch 1',
+ 'Temporary shared merge branch 2',
+ graph, callDepth+1)
+assert(isinstance(Ms, Commit))
+
+if callDepth == 0:
+if len(ca) > 1:
+runProgram(['git-read-tree', h1.tree()])
+runProgram(['git-update-cache', '-q', '--refresh'])
+# Use the original index if we only have one common ancestor
+
+updateWd = True
+if alwaysWriteTree:
+cleanCache = True
+else:
+cleanCache = False
+else:
+runProgram(['git-read-tree', h1.tree()])
+updateWd = False
+cleanCache = True
+
+[shaRes, clean] = mergeTrees(h1.tree(), h2.tree(), Ms.tree(),
+ branch1Name, branch2Name,
+ cleanCache, updateWd)
+
+if clean or alwaysWriteTree:
+res = Commit(None, [h1, h2], tree=shaRes)
+graph.addNode(res)
+else:
+res = None
+
+return [res, clean]
+
+getFilesRE = re.compile('([0-9]+) ([a-z0-9]+) ([0-9a-f]{40})\t(.*)')
+def getFilesAndDirs(tree):
+files = Set()
+dirs = Set()
+out = runProgram(['git-ls-tree', '-r', '-z', tree])
+for l in out.split('\0'):
+m = getFilesRE.match(l)
+if m:
+if m.group(2) == 'tree':
+dirs.add(m.group(4))
+elif m.group(2) == 'blob':
+files.add(m.group(4))
+
+return [files, dirs]
+
+class CacheEntry:
+def __init__(self, path):
+class Stage:
+def __init__(self):
+self.sha1 = None
+self.mode = None
+
+self.stages = [Stage(), Stage(), Stage()]
+self.path = path
+
+unmergedRE = re.compile('^([0-9]+) ([0-9a-f]{40}) ([1-3])\t(.*)$')
+def unmergedCacheEntries():
+'''Create a dictionary mapping file names to CacheEntry
+objects. The dictionary contains one entry for every path with a
+non-zero stage entry.'''
+
+lines = runProgram(['git-ls-files', '-z', '--unmerged']).split('\0')
+lines.pop()
+
+res = {}
+for l in lines:
+m = unmergedRE.match(l)
+if m:
+mode = int(m.group(1), 8)
+sha1 = m.group(2)
+stage = int(m.group(3)) - 1
+path = m.group(4)
+
+if res.has_key(path):
+e = res[path]
+else:
+e = CacheEntry(path)
+res[path] = e
+
+e.stages[stage].mode = mode
+e.stages[stage].sha1 = sha1
+else:
+print 'Error: Merge program failed: Unexpected output from', \
+ 'git-ls-files:', l
+sys.exit(1)
+return res
+
+def mergeTrees(head, merge, common, branch1Name, branch2Name,
+ cleanCache, updateWd):
Re: [PATCH 0/2] A new merge algorithm, take 3
On Wed, 7 Sep 2005, Fredrik Kuivinen wrote: > Of the 500 merge commits that currently exists in the kernel > repository 19 produces non-clean merges with git-merge-script. The > four merge cases listed in > <[EMAIL PROTECTED]> are cleanly merged by > git-merge-script. Every merge commit which is cleanly merged by > git-resolve-script is also cleanly merged by git-merge-script, > furthermore the results are identical. There are currently two merges > in the kernel repository which are not cleanly merged by > git-resolve-script but are cleanly merged by git-merge-script. If you use my read-tree and change git-resolve-script to pass all of the ancestors to it, how does it do? I expect you'll still be slightly ahead, because we don't (yet) have content merge with multiple ancestors. You should also check the merge that Tony Luck reported, which undid a revert, as well as the one that Len Brown reported around the same time which had similar problems. I think maintainer trees are a much better test for a merge algorithm, because the kernel repository is relatively linear, while maintainers tend more to merge things back and forth. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] A new merge algorithm, take 3
Fredrik Kuivinen <[EMAIL PROTECTED]> writes: > I guess the need for this has decreased with Daniel's new read-tree > code. Is there any chance of getting this code merged into mainline > git? I do not think Daniel's code decreased anything. The two algorithms are solving the same problem but they do it differently. There would be cases where multi-base merge would give better results over your base-on-merge-bases merge; and in other cases yours would perform better. I'd like to leave what merge strategy to use as an user option, and leave the door open for other merge strategies to emerge later. I know Pasky wants to look into pcdv merge and other alternatives. This is still off-the-top-of-my-head, but the top-level merge entry point for the end user would be just: git merge and by default 'git-merge-script' (sorry, I am taking over the name of your script for this 'generic driver for underlying merge strategy scripts') would do something like: - Run 'git-merge-base -a' to find common ancestors. - If there is one single common ancestor, do what the current 'git-resolve-script' does: if fast-forward, declare success and exit without touching anything but $GIT_DIR/HEAD; otherwise, run read-tree -m 3-way followed by merge-cache, and commit with the given message if the merge was clean and exit. If the merge was not clean, go on to the next step. - User preference (maybe $HOME/.git/merge-preference, maybe command line option to 'git merge', maybe interactive prompting) can specify which complex merge strategies to use. we probably would want to be able to say "try this, that and that-over-there in this order" in the preference. One of the strategies could be 'I give up, just exit and sort it out by hand'. - The chosen merge backend, be it the one that uses Daniel's multi-base merge or your base-on-merge-bases merge, takes over. In any case, the backend should attempt to resolve the two heads, and stop at the point just before committing. - Evaluate how good the merge is by looking at the result from the backend at this point, and if it is not good enough, reset the working tree back to the pre-merge state and try the next backend. The looping code needs a termination clause that picks the best result after exhausting the list of backends. - Then, if the merge backend auto-resolved the heads, we commit with ; otherwise we exit with non-zero status and have the user sort it out. The above assumes that (1) we are already doing a reasonable thing in simple one-common-ancestor case; (2) it is in the fast path and we want the multiple backend code out of it. You could think of the current 'git-resolve-script' code equivalent of having a single 'complex merge backend' that just 'gives up'. If the above is a good user model, we need a couple of interface convention between merge backends and the above driver: - Some merge backends (like yours) would require that the starting tree is clean while others may not care as long as the paths involved are clean (i.e. index matches and the working file matches index -- the traditional code and Daniel's even allow such a working file being different from index if it happens to match the merge result). They need to be able to say "declined to merge even though I might do a better job than others if given a clean working tree". Then the user can retry the same merge after getting the working tree in a clean state. I personally feel that we do not need this complexity and it is reasonable to always require the starting tree to be clean when the merge is not a fast-forward, though. - When a merge backend finishes, it may leave the working tree in a failed merge state. If we were to try different backends in the loop to find the best result, we would need some way to assign scores to them. The score should be able to tell us if the result can be auto-committable or not, and if not how bad it is. I think exit status from the backend can be used to tell us the former (i.e. exit non-zero if your result has conflicts and you do not want your result to be committed immediately), and number of cache-dirty entries can be used as an indication of how bad it is (i.e. leave the paths you know have not been cleanly merged cache-dirty -- do not run git-update-cache on them). This is essentially the same convention used by the current 'git-resolve-script'. I think the 'renaming merge heuristics' Linus outlined in another thread will fall naturally into this picture as a merge backend. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added an option to cvsimport to specify email domain
David K.ANegedal <[EMAIL PROTECTED]> writes: > The authorship info in commits created by git-cvsimport-script > only contains the username of the CVS committer. This patch > adds a flag -e to git-cvsimport-script that makes it > possible to specify an email domain that is added to all email > addresses in the commit "author" and "committer" fields. > > --- > I have stopped using cvsimport, because cvsps seems to produce bad > output on the repository I'm using it with, but I had already prepared > this patch. Hmph. One reason the original implementation did not do this is because Linus and other people wanted to have a repeatability, so making this an optional thing is good, but if we go this route, I think if it would be nicer to have a --author-map option that lets you feed a list of: ==> "A U Thor <[EMAIL PROTECTED]>" mappings, instead of a single -e, which essentially does not add much information to the result. I take that your oob comment indicates that you do not have much incentive/inclination to further hack on this, so I am not asking you to do the above even if you find my suggestion worthwhile. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add $(LIBS) and set libiconv in tools/Makefile for Darwin
Mark Allen <[EMAIL PROTECTED]> writes: > Looks good to me, Junio. There's a very small typo in your > commit though. :-) Thanks. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Docs for git-checkout-script.
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]> --- Documentation/git-checkout-script.txt | 23 ++- 1 files changed, 14 insertions(+), 9 deletions(-) ac5328903884c402905dd2a778ce51a00c041ffc diff --git a/Documentation/git-checkout-script.txt b/Documentation/git-checkout-script.txt --- a/Documentation/git-checkout-script.txt +++ b/Documentation/git-checkout-script.txt @@ -3,26 +3,31 @@ git-checkout-script(1) NAME -git-checkout-script - Some git command not yet documented. - +git-checkout-script - Checkout and switch to a branch. SYNOPSIS -'git-checkout-script' [ --option ] ... +'git-checkout-script' [-f] [-b ] [] DESCRIPTION --- -Does something not yet documented. - +Updates the index and working tree to reflect the specified branch, +. Updates HEAD to be or, if specified, . OPTIONS --- ---option:: - Some option not yet documented. +-f:: + Force an re-read of everything. + +-b:: + Create a new branch and start it at . -...:: - Some argument not yet documented. +:: + Name for the new branch. +:: + Branch to checkout; may be any object ID that resolves to a + commit. Defaults to HEAD. Author -- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Docs for git-reset-script.
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]> --- Documentation/git-reset-script.txt | 27 +-- 1 files changed, 17 insertions(+), 10 deletions(-) e6c59b4622ab3eac9c4a74cd1571136ab586ac5a diff --git a/Documentation/git-reset-script.txt b/Documentation/git-reset-script.txt --- a/Documentation/git-reset-script.txt +++ b/Documentation/git-reset-script.txt @@ -3,26 +3,33 @@ git-reset-script(1) NAME -git-reset-script - Some git command not yet documented. - +git-reset-script - Reset current HEAD to the specified state. SYNOPSIS -'git-reset-script' [ --option ] ... +'git-reset-script' [--mixed | --soft | --hard] [] DESCRIPTION --- -Does something not yet documented. - +Sets the current head to the specified commit and optionally resets the +index and working tree to match. OPTIONS --- ---option:: - Some option not yet documented. - -...:: - Some argument not yet documented. +--mixed:: + Like --soft but reports what has not been updated. This is the + default action. + +--soft:: + Does not touch the index file nor the working tree at all, but + requires them in a good order. + +--hard:: + Matches the working tree and index to that of the tree being + switched to. +:: + Commit to make the current HEAD. Author -- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Docs for git-show-rev-cache.
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]> --- Documentation/git-show-rev-cache.txt | 19 +-- 1 files changed, 9 insertions(+), 10 deletions(-) 818a8f421dfa978aa4df7103e34aeadf1ba971f5 diff --git a/Documentation/git-show-rev-cache.txt b/Documentation/git-show-rev-cache.txt --- a/Documentation/git-show-rev-cache.txt +++ b/Documentation/git-show-rev-cache.txt @@ -3,26 +3,25 @@ git-show-rev-cache(1) NAME -git-show-rev-cache - Some git command not yet documented. - +git-show-rev-cache - Show the contents of a rev-cache file. SYNOPSIS -'git-show-rev-cache' [ --option ] ... +'git-show-rev-cache' DESCRIPTION --- -Does something not yet documented. +Show the contents of . +A rev-cache file describes the commit ancestry reachable from references +supplied as input to get-build-rev-cache. This file is in an +append-only binary format to make the server side friendly to rsync +mirroring scheme. OPTIONS --- ---option:: - Some option not yet documented. - -...:: - Some argument not yet documented. - +:: + Rev-cache file to display. Author -- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Docs for git-build-rev-cache.
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]> --- Documentation/git-build-rev-cache.txt | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) c7c6e77b9efa05b8a7b84fdf630f4ff64664872f diff --git a/Documentation/git-build-rev-cache.txt b/Documentation/git-build-rev-cache.txt --- a/Documentation/git-build-rev-cache.txt +++ b/Documentation/git-build-rev-cache.txt @@ -3,26 +3,26 @@ git-build-rev-cache(1) NAME -git-build-rev-cache - Some git command not yet documented. - +git-build-rev-cache - Create or update a rev-cache file. SYNOPSIS -'git-build-rev-cache' [ --option ] ... +'git-build-rev-cache' [-v] < list-of-heads DESCRIPTION --- -Does something not yet documented. - +Creates or updates a file that describes the commit ancestry reachable +from the list-of-head read from stdin. This file is in an append-only +binary format to make the server side friendly to rsync mirroring +scheme, and can be read by the git-show-rev-cache command. OPTIONS --- ---option:: - Some option not yet documented. - -...:: - Some argument not yet documented. +-v:: + Verbose. +:: + The rev-cache to operate on. Author -- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs for git-checkout-script.
You read my mind. I just finished documenting some other commands and was about to push things out. Thanks. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs for git-checkout-script.
Actually, I'm cherry-picking the easier ones in an effort to reduce my stress about my impending move to the LA area. Hopefully you did git-diff-script, git-format-patch-script, and git-rev-parse which don't look easy to document. Junio C Hamano wrote: You read my mind. I just finished documenting some other commands and was about to push things out. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs for git-checkout-script.
A Large Angry SCM <[EMAIL PROTECTED]> writes: > Hopefully you did git-diff-script, git-format-patch-script, and > git-rev-parse which don't look easy to document. Not yet and not likely be in 0.99.6 but immediately after. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
GIT 0.99.6
Highlights == * Documentation is in much better shape. Thanks everybody. * Two grave bugs in 'git fetch' were caught and fixed. One is "Fix fetching of tags", the other is "Fix pulling into the same branch.". * We have archimport (unfortunately undocumented yet), and cvsimport is being improved. * Revert, rebase and cherry-pick are done using three-way merge, not a straight patch application. * 'git commit' should be a bit easier to use than before in initial commits and merge commits. * 'git applymbox' is a bit more accomodating and it should be easier to handle MIME patches than before. * As usual, comes with more recent gitk. Better merge algorithms and the infrastructure are being worked on by Daniel and Fredrik; they are not in this release yet. What to expect after 0.99.6 === This is written in a form of to-do list for me, so if I say "accept patch", it means I do not currently plan to do that myself. People interested in seeing it materialize please take a hint. The latest copy of this document is found at http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO Tool Renames Plan - - All non-binary commands will lose -script suffix in $(bindir). The source to git-foo will be either git-foo.sh or git-foo.perl in the source tree, and the documentation will be in Documentation/git-foo.txt. - The commands whose names have 'cache' to mean 'index file' will get 'cache' in their names replaced with 'index'. For git-fsck-cache and git-convert-cache, 'cache' will be replaced with 'objects'. - The commit walkers will have 'pull' in their names replaced with 'fetch'. 'git-ssh-push' will become 'git-ssh-upload'. - We continue to follow the convention to name the C source file that contains the main program of 'git-foo' command 'foo.c'. That means we will have 'fsck-objects.c', for example. - At this moment, I am not planning to rename the symbols used in programs, nor any library sources. "cache.h" will stay "cache.h", so does "read-cache.c". "struct cache_entry" and "ce_match_stat()" will keep their names. We _might_ want to rename them in later rounds but not right now. - In 0.99.7, all renamed commands will have symbolic links in $(bindir) so that old names continue to work. These backward compatible symlinks will not be present in documentation, though. Especially, the main documentation, git(7) will talk about the new names. Old environment names defined in gitenv() will also be removed in this release. Tentatively we aim to do this on Sep 17th. - In 0.99.8, we do not install these backward compatible symbolic links in $(bindir) anymore. The Makefile will have a target to remove old symlinks from $(DESTDIR)$(bindir) you can run manually to help you clean things up. The timeframe for this is around Oct 1st, but I could be talked into delaying the symlink removal if Porcelain people find this schedule too tight. Documentation - * Accept patches from people who actually have done CVS migration and update the cvs-migration documentation. Link the documentation from the main git.txt page. * Accept patches from people who were hit by shiny blue bat to update the SubmittingPatches [ONGOING]. * Talk about using rsync just once at the beginning when initializing a remote repository so that local packs do not need to be expanded. I personally do not think we need tool support for this (but see below about optimized cloning). * Maybe update tutorial with a toy project that involves two or three developers.. * Update tutorial to cover setting up repository hooks to do common tasks. * Accept patches to finish missing docs. Technical (heavier) --- * Tony Luck reported an unfortunate glitch in the 3-way merge. Encourage discussions to come up with a not-so-expensive way to catch the kind of ambiguities that led to his misery. [Daniel's patch looks quite promising, so is the one from Fredrik.] * HPA has two projects, klibc and klibc-kbuild, that have large set of overlapping files in different paths (i.e. one has many renames from the other). There currently is no way for git to help keep these two trees in sync, merging criss-cross between them. The merge logic should be able to take advantage of rename/copy detection smarts git-diff-* family has. Linus, me, and Daniel outlined a smarter merge strategy for this. Try them out. * To make it easier to experiment with different merge strategies, make git-merge driver that will run merge backends for the best merge [Outlined the idea; just do it]. * We might want to optimize cloning with GIT native transport not to explode the pack, and store it in objects/pack instead. We would need a tool to generate an idx file out of a pack file for this. Also this itself may turn out to be a bad idea, making
Tool renames.
Junio C Hamano <[EMAIL PROTECTED]> writes: > My proposal to have git-archimport.perl in the source tree and > install it as $(bindir)/git-archimport solves the editability > issues (sorry, Linus, you will have to say "em *.sh *.perl" > instead of "em *-script" if we did this) and simplifies the > first half of the 'git' wrapper (it just needs to attempt > running "git-$1"), but does not help what the latter half of > 'git' wrapper does (to give you the list of Porcelainish > commands). > > To make 'git' wrapper produce useful 'list of subcommands', we > need to come up with a list of Porcelainish commands, be they > written in C or sh or Perl, and tell 'git' about that list. > Current implementation cheats by assuming everything that ends > with *-script are such, but it does not have to stay that way. I have done this and the first commit since 0.99.6 in the proposed updates branch contains the big rename. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add git-version-script.
Martin Atukunda <[EMAIL PROTECTED]> writes: > This script simply reports the version of git you have installed. I wanted to ahve some way of recording the git version, but I am wondering if 'git' without parameter telling the version number would be good enough without introducing yet another script. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git/cogito suggestion: tags with descriptions
Zack Brown <[EMAIL PROTECTED]> writes: > It would be great if tags also allowed a brief description to go along with > them, that would show up in cg-tag-ls. Then I could seek to a tag that's just > an easy-to-type version number, and still have an idea of what's significant > about that version because of the descriptive text. Do people crave for 'git tag' showing list of tags with their brief descriptions just like 'git branch' does? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git/gitweb - feature request: Add description to the branches.
A Large Angry SCM <[EMAIL PROTECTED]> writes: > Santi B.ANijar wrote: > [...] >> One thing I'm missing is a way to describe a branch. It can >> be >> done in the $GIT_DIR/description, the first line for the whole >> repository and the rest for the branches. So description file >> for the git.git repository could be: >> [description] >> The core git plumbing >> pu: Proposed updates >> rc: Release candidate >> todo: Todo list >> [/description] >> And it can be added to the gitweb tool. > > Having somewhere to describe the intent of a branch would be a useful > convention. But I think the descriptions should be in separate files; > one for each branch and one for the repository as a whole. This reminds me of somebody else wanting to have 'motd' in git-daemon. Once we have a common data format we could also serve this information from there, and possibly from 'git fetch --motd'; pass that to 'git-peek-remote --motd' for git and ssh transports, and do something else using curl for http transport. Anybody interested? I think the git-daemon side would be the cleanest if we introduce a new program to format the motd information and send it out, instead of attempting to enhance git-upload-pack protocol; I do not think the latter can be done in a backward compatible way. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-stripspace unfairly accused of being undocumented.
Junio, Looking over the latest commits I just noticed the "no documentation" section in git.txt lists git-stripspace in error. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patches
Patrick Mauritz <[EMAIL PROTECTED]> writes:
I would have appreciated if you said "Solaris portability patch"
or somesuch on the subject line.
> diff -ur git-core-0.99.4.orig/convert-cache.c git-core-0.99.4/convert-cache.c
> --- git-core-0.99.5.orig/convert-cache.c Wed Aug 17 09:55:00 2005
> +++ git-core-0.99.5/convert-cache.c Wed Aug 17 09:58:48 2005
> @@ -1,4 +1,5 @@
> #define _XOPEN_SOURCE /* glibc2 needs this */
> +#define __EXTENSIONS__ /* solaris needs this */
> #include
> #include
> #include "cache.h"
I'll take this; thanks.
> diff -ur git-core-0.99.4.orig/ident.c git-core-0.99.4/ident.c
> --- git-core-0.99.5.orig/ident.c Wed Aug 17 09:55:00 2005
> +++ git-core-0.99.5/ident.c Wed Aug 17 09:57:54 2005
> @@ -36,12 +36,13 @@
> memcpy(real_email, pw->pw_name, len);
> real_email[len++] = '@';
> gethostname(real_email + len, sizeof(real_email) - len);
> +#ifndef __sun
> if (!strchr(real_email+len, '.')) {
> len = strlen(real_email);
> real_email[len++] = '.';
> getdomainname(real_email+len, sizeof(real_email)-len);
> }
> -
> +#endif
> /* And set the default date */
> datestamp(real_date, sizeof(real_date));
> return 0;
I'll do this slightly differently, because I do not want to have
"ifdef __platform_name" in the code when possible.
> --- git-core-0.99.5/Makefile~ Thu Aug 25 03:54:24 2005
> +++ git-core-0.99.5/Makefile Tue Sep 6 01:18:32 2005
> @@ -146,7 +146,11 @@
> endif
> endif
> endif
> +ifeq ($(shell uname -s),SunOS)
> + LIBS += -lsocket
> +endif
>
> +
> DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
I'll do this in the way similar to how I did -liconv for Darwin.
> +ifdef CURLDIR
> +git-http-pull: LIBS += -lcurl -L$(CURLDIR)/lib -R$(CURLDIR)/lib
> +else
> git-http-pull: LIBS += -lcurl
> +endif
Curious. Doesn't the order of -l and -L/-R matter these days?
I am sympathetic to the reason why you need this, but if we go
this route we should also do openssl as well. I'd drop this
part for now.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add git-version-script.
Junio C Hamano wrote: Martin Atukunda <[EMAIL PROTECTED]> writes: This script simply reports the version of git you have installed. I wanted to ahve some way of recording the git version, but I am wondering if 'git' without parameter telling the version number would be good enough without introducing yet another script. git --version - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git/cogito suggestion: tags with descriptions
Junio C Hamano wrote: Zack Brown <[EMAIL PROTECTED]> writes: It would be great if tags also allowed a brief description to go along with them, that would show up in cg-tag-ls. Then I could seek to a tag that's just an easy-to-type version number, and still have an idea of what's significant about that version because of the descriptive text. Do people crave for 'git tag' showing list of tags with their brief descriptions just like 'git branch' does? Sort of like what gitweb does now? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Do not create bogus branch from flag to git branch
If you run `git branch --help', you will unexpectedly have created a new
branch named "--help". This simple patch adds logic and a usage
statement to catch this and similar problems, and adds a testcase for it.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
git-branch-script | 16
t/t3200-branch.sh | 27 +++
2 files changed, 43 insertions(+), 0 deletions(-)
create mode 100755 t/t3200-branch.sh
09dc220283888eabd4dbb3ca647d13de6d6c876e
diff --git a/git-branch-script b/git-branch-script
--- a/git-branch-script
+++ b/git-branch-script
@@ -2,6 +2,16 @@
. git-sh-setup-script || die "Not a git archive"
+usage () {
+echo >&2 "usage: $(basename $0)"' [ [start-point]]
+
+If no arguments, show available branches and mark current branch with a star.
+If one argument, create a new branch based off of current HEAD.
+If two arguments, create a new branch based off of .
+'
+exit 1
+}
+
case "$#" in
0)
headref=$(readlink "$GIT_DIR/HEAD" | sed -e 's|^refs/heads/||')
@@ -25,6 +35,12 @@ case "$#" in
head="$2^0" ;;
esac
branchname="$1"
+
+case "$branchname" in
+-*)
+ usage;;
+esac
+
rev=$(git-rev-parse --verify "$head") || exit
[ -e "$GIT_DIR/refs/heads/$branchname" ] && die "$branchname already exists"
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
new file mode 100755
--- /dev/null
+++ b/t/t3200-branch.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Amos Waterland
+#
+
+test_description='git branch --foo should not create bogus branch
+
+This test runs git branch --help and checks that the argument is properly
+handled. Specifically, that a bogus branch is not created.
+'
+. ./test-lib.sh
+
+test_expect_success \
+'prepare an trivial repository' \
+'echo Hello > A &&
+ git update-cache --add A &&
+ git commit -m "Initial commit."'
+
+test_expect_failure \
+'git branch --help should return error code' \
+'git branch --help'
+
+test_expect_failure \
+'git branch --help should not have created a bogus branch' \
+'test -f .git/refs/heads/--help'
+
+test_done
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: Add git-version-script.
Add version string to git. Signed-off-by: Martin Atukunda <[EMAIL PROTECTED]> --- Makefile |3 ++- git.in | 25 + 2 files changed, 27 insertions(+), 1 deletions(-) create mode 100755 git.in 6a9edfa27c41b7845bfd519e275c24d7e36ad702 diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -218,7 +218,8 @@ $(LIB_FILE): $(LIB_OBJS) doc: $(MAKE) -C Documentation all - +git: git.in Makefile + sed 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@ ### Testing rules diff --git a/git.in b/git.in new file mode 100755 --- /dev/null +++ b/git.in @@ -0,0 +1,25 @@ +#!/bin/sh + +cmd= +path=$(dirname $0) +case "$#" in +0) ;; +*) cmd="$1" + shift + if [ "$cmd" == "--version" ]; then + echo "git version @@VERSION@@" + exit 0 + fi + test -x $path/git-$cmd-script && exec $path/git-$cmd-script "$@" + test -x $path/git-$cmd && exec $path/git-$cmd "$@" ;; +esac + +echo "git version @@VERSION@@" +echo "Usage: git COMMAND [OPTIONS] [TARGET]" +if [ -n "$cmd" ]; then +echo " git command '$cmd' not found: commands are:" +else +echo " git commands are:" +fi + +ls $path | sed -ne 's/^git-\(.*\)-script/ \1/p' | fmt -- Your entire blood supply is filtered through your kidneys in four minutes. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
gitweb feature request: tarball for each commit
With Archzoom, when looking at a particular commit/cset you get a small "[tarball]" link that does an 'export' of the whole tree at that patchlevel and tars it up for the user. It's heavy on the server and bandwidth, but if you can afford it, it is mighty useful to push out patches immediately to non-git-using end users. Here's an example of an archzoom page --- it's among the top-right links. I'm sure we could do something like this with git-tar-tree... Actually... should get it done. I'll see if I can sneak it in sometime soon... cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] A new merge algorithm, take 3
On Wed, Sep 07, 2005 at 02:33:42PM -0400, Daniel Barkalow wrote: > On Wed, 7 Sep 2005, Fredrik Kuivinen wrote: > > > Of the 500 merge commits that currently exists in the kernel > > repository 19 produces non-clean merges with git-merge-script. The > > four merge cases listed in > > <[EMAIL PROTECTED]> are cleanly merged by > > git-merge-script. Every merge commit which is cleanly merged by > > git-resolve-script is also cleanly merged by git-merge-script, > > furthermore the results are identical. There are currently two merges > > in the kernel repository which are not cleanly merged by > > git-resolve-script but are cleanly merged by git-merge-script. > > If you use my read-tree and change git-resolve-script to pass all of the > ancestors to it, how does it do? I expect you'll still be slightly ahead, > because we don't (yet) have content merge with multiple ancestors. You > should also check the merge that Tony Luck reported, which undid a revert, > as well as the one that Len Brown reported around the same time which had > similar problems. I think maintainer trees are a much better test for a > merge algorithm, because the kernel repository is relatively linear, while > maintainers tend more to merge things back and forth. Junio tested some of the multiple common ancestor cases with your version of read-tree and reported his results in <[EMAIL PROTECTED]>. The two cases my algorithm merges cleanly and git-resolve-script do not merge cleanly are 0e396ee43e445cb7c215a98da4e76d0ce354d9d7 and 0c168775709faa74c1b87f1e61046e0c51ade7f3. Both of them have two common ancestors. The second one have, as far as I know, not been tested with your read-tree. The merge cases reported by Tony Luck and Len Brown are both cleanly merged by my code. You are probably right about the maintainer trees. I should have a look at some of them. Do you know any specific repositories with interesting merge cases? - Fredrik - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
