* Re: t6021-merge-criss-cross.sh fails on some systems
From: Junio C Hamano @ 2005-12-11 8:07 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20051210.235818.90276521.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> ... but a lot of us are doing:
>
> git pull && make && make test && make install
Fair enough.
Next such round would fail at "make test" stage with t0000;
otherwise please let me know
^ permalink raw reply
* Re: t6021-merge-criss-cross.sh fails on some systems
From: David S. Miller @ 2005-12-11 8:12 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <7v64pwoy45.fsf@assigned-by-dhcp.cox.net>
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 11 Dec 2005 00:07:38 -0800
> Next such round would fail at "make test" stage with t0000;
> otherwise please let me know
t0000-basic.sh looks wonderful, thanks :)
^ permalink raw reply
* Branches merging by only overwrite files
From: Ben Lau @ 2005-12-11 8:30 UTC (permalink / raw)
To: Git Mailing List
Hi,
I am looking for a solution to merge two branches but do not perform
file level merge. Instead, I wish the result file is the copy from any
one of the branches.
For example, assumes it has two branches A and B, some of the files
are modified in both of them. In this case, `/usr/bin/merge` could not
be execated, it just have to choose the revision from branch A and
discards all the changes from B. For the rest of files, it just simply
choose the newest copy from A or B.
How can I perform this action?
Thanks in advance.
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Marcel Holtmann @ 2005-12-11 8:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051211001106.GV22159@pasky.or.cz>
Hi Petr,
> > The cogito is the latest from kernel.org and when calling cg-commit it
> > fails with this message:
> >
> > cg-commit: line 200: syntax error near unexpected token `('
> > cg-commit: line 200: ` eval commitfiles=($(cat $filter | path_xargs git-diff-index -r -m HEAD -- | \'
> >
> > I played a little bit with it and it seems all the eval statements are
> > broken with this bash version. I have no clue how to fix this, but maybe
> > you do.
>
> it seems like the newer bash is stricter than the older versions in
> some obscure regards. Quoting the eval arguments (which is the proper
> thing to do anyway) fixed that particular problem; I've hit another
> problem during a test commit wrt. whitespace separators - I've fixed
> that too, and pushed out.
it's now working again. Thanks. What do you think about another release?
I haven't checked the other distributions yet, but I just saw that
Debian unstable also moved to version 3.1 of bash.
There exists also another problem with the new bash. It is the broken
pipe error from cg-log.
cg-log: line 141: echo: write error: Broken pipe
The line number varies depending how much you scrolled and when you
scrolled to the end no broken pipe error comes up. Do you have any idea
on how to deal with this. I saw your comment about that bash is broken
and the extra trap command, but it doesn't help. I never saw that
problem with older versions of bash.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] merge-recursive: leave unmerged entries in the index.
From: Fredrik Kuivinen @ 2005-12-11 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vek4ktai1.fsf@assigned-by-dhcp.cox.net>
On Sat, Dec 10, 2005 at 10:26:30PM -0800, Junio C Hamano wrote:
> This does two things.
>
> - When one branch renamed and the other branch did not, the
> resulting half-merged file in the working tree used to swap
> branches around and showed as if renaming side was "ours".
> This was confusing and inconsistent (even though the conflict
> markers were marked with branch names, it was not a good
> enough excuse). This changes the order of arguments to
> mergeFile in such a case to make sure we always see "our"
> change between <<< and ===, and "their" change between ===
> and >>>.
>
> - When both branches renamed to the same path, and when one
> branch renamed and the other branch did not, we attempt
> mergeFile. When this automerge conflicted, we used to
> collapse the index. Now we use update-index --index-info
> to inject higher stage entries to leave the index in unmerged
> state for these two cases.
>
> What this still does _not_ do is to inject unmerged state into
> the index when the structural changes conflict. I have not
> thought things through what to do in each case yet, but the
> cases this commit cover are the most common ones, so this would
> be a good start.
>
Good work! I have one comment, see below.
> e5c23ede9ccc6ddd5f2cf13154f977bb1b687051
> diff --git a/git-merge-recursive.py b/git-merge-recursive.py
> index b7fb096..767b13c 100755
> --- a/git-merge-recursive.py
> +++ b/git-merge-recursive.py
> @@ -280,6 +280,22 @@ def updateFileExt(sha, mode, path, updat
> runProgram(['git-update-index', '--add', '--cacheinfo',
> '0%o' % mode, sha, path])
>
> +def setIndexStages(path,
> + oSHA1, oMode,
> + aSHA1, aMode,
> + bSHA1, bMode):
> + prog = ['git-update-index', '-z', '--index-info']
> + proc = subprocess.Popen(prog, stdin=subprocess.PIPE)
> + pipe = proc.stdin
> + # Clear stages first.
> + pipe.write("0 " + ("0" * 40) + "\t" + path + "\0")
> + # Set stages
> + pipe.write("%o %s %d\t%s\0" % (oMode, oSHA1, 1, path))
> + pipe.write("%o %s %d\t%s\0" % (aMode, aSHA1, 2, path))
> + pipe.write("%o %s %d\t%s\0" % (bMode, bSHA1, 3, path))
> + pipe.close()
> + proc.wait()
> +
It might be cleaner to use
runProgram(['git-update-index', '-z', '--index-info'],
input="0 " + ("0" * 40) + "\t" + path + "\0" + \
"%o %s %d\t%s\0" % (oMode, oSHA1, 1, path) + \
"%o %s %d\t%s\0" % (aMode, aSHA1, 2, path) + \
"%o %s %d\t%s\0" % (bMode, bSHA1, 3, path))
here instead. With this code we will get an exception if
git-update-index exits with an error code. It is also consistent with
the rest of the code.
- Fredrik
^ permalink raw reply
* Re: Branches merging by only overwrite files
From: Junio C Hamano @ 2005-12-11 9:33 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <439BE3B9.3040308@ust.hk>
Ben Lau <benlau@ust.hk> writes:
> I am looking for a solution to merge two branches but do not perform
> file level merge. Instead, I wish the result file is the copy from any
> one of the branches.
It might be better to state why you need this first. It could
be that what you really want to solve is not related to merge at
all.
> For example, assumes it has two branches A and B, some of the files
> are modified in both of them. In this case, `/usr/bin/merge` could not
> be execated, it just have to choose the revision from branch A and
> discards all the changes from B. For the rest of files, it just simply
> choose the newest copy from A or B.
I wonder why you say "could not be executed". I take it to mean
you just do not want to even when it could.
Now, it is not clear if you always want copy from branch A and
not from branch B when both branches have the same path, or you
want to pick one at random between A and B. If branch A kept
the file intact and branch B modified it, what do you want to
happen? The default "merge" semantics in git (unless you are
using "ours" strategy) in such a case is always to take the
version from branch B. Is that consistent with what you want?
What do you exactly mean "newest copy from A or B"? What are
you basing the "newest" determination on? The commit date of A
and B commits, or the author date ot two?
Assuming that you can give reasonable and consistent answer to
the above question to define the semantics of your "new merge
algorithm", what you would do is to write a new script
git-merge-benlau to implement whatever semantics you picked.
You could model it after existing merge strategy, such as
git-merge-resolve.sh or git-merge-stupid.sh. Then you give the
new merge strategy to "git-merge" or "git-pull".
For example, if you want all the usual "trivial merges" to work
just like the default git merge algorithms, but always take
"our" version instead of running file-level merge when both
sides modified a file, then you start from a copy of
git-merge-stupid.sh, and replace "git-merge-one-file" with
"git-merge-one-file-benlau'. Copy "git-merge-one-file.sh" to
create another new script, "git-merge-one-file-benlau", and
replace this line:
merge "$src1" "$orig" "$src"
with
cat "$orig" >"$src1"
and you are done.
I outlined the above without knowing what you really want to
achieve, and I do not think the resulting merge strategy makes
much sense, but that is what I get form hacking without knowing
what you are really trying to do ;-).
^ permalink raw reply
* Re: [PATCH] merge-recursive: leave unmerged entries in the index.
From: Junio C Hamano @ 2005-12-11 9:42 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20051211092531.GA4919@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> It might be cleaner to use
>
> runProgram(['git-update-index', '-z', '--index-info'],
> input="0 " + ("0" * 40) + "\t" + path + "\0" + \
> "%o %s %d\t%s\0" % (oMode, oSHA1, 1, path) + \
> "%o %s %d\t%s\0" % (aMode, aSHA1, 2, path) + \
> "%o %s %d\t%s\0" % (bMode, bSHA1, 3, path))
>
> here instead. With this code we will get an exception if
> git-update-index exits with an error code. It is also consistent with
> the rest of the code.
Thanks. I did not know how to feed the string through
runProgram (well, I did not look close enough).
^ permalink raw reply
* [RFC, PATCH] Usage message clean-up, take #2
From: Fredrik Kuivinen @ 2005-12-11 9:55 UTC (permalink / raw)
To: git
Hi,
There were some problems with the usage message clean-up patch
series. I hadn't realised that subdirectory aware scripts can't source
git-sh-setup. I propose that we change this and let the scripts which
are subdirectory aware set a variable, SUBDIRECTORY_OK, before they
source git-sh-setup.
The scripts will also set USAGE and possibly LONG_USAGE before they
source git-sh-setup. If LONG_USAGE isn't set it defaults to USAGE.
If we go this way it's easy to catch --help in git-sh-setup, print the
(long) usage message to stdout and exit cleanly. git-sh-setup can
define a 'usage' shell function which can be called by the scripts to
print the short usage string to stderr and exit non-cleanly. It will
also be easy to change $0 to basename $0 or something else, if would
like to do that sometime in the future.
What follows is a patch to convert a couple of the commands to this
style. If it's ok with everyone to do it this way I will convert the
rest of the scripts too.
- Fredrik
---
git-bisect.sh | 24 +++++++++++-------------
git-branch.sh | 21 ++++++---------------
git-sh-setup.sh | 34 +++++++++++++++++++++++++++++-----
git-status.sh | 11 ++++++++++-
4 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 05dae8a..51e1e44 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,4 +1,15 @@
#!/bin/sh
+
+USAGE='[start|bad|good|next|reset|visualize]'
+LONG_USAGE='git bisect start [<pathspec>] reset bisect state and start bisection.
+git bisect bad [<rev>] mark <rev> a known-bad revision.
+git bisect good [<rev>...] mark <rev>... known-good revisions.
+git bisect next find next bisection to test and check it out.
+git bisect reset [<branch>] finish bisection search and go back to branch.
+git bisect visualize show bisect status in gitk.
+git bisect replay <logfile> replay bisection log
+git bisect log show bisect log.'
+
. git-sh-setup
sq() {
@@ -11,19 +22,6 @@ sq() {
' "$@"
}
-usage() {
- echo >&2 'usage: git bisect [start|bad|good|next|reset|visualize]
-git bisect start [<pathspec>] reset bisect state and start bisection.
-git bisect bad [<rev>] mark <rev> a known-bad revision.
-git bisect good [<rev>...] mark <rev>... known-good revisions.
-git bisect next find next bisection to test and check it out.
-git bisect reset [<branch>] finish bisection search and go back to branch.
-git bisect visualize show bisect status in gitk.
-git bisect replay <logfile> replay bisection log
-git bisect log show bisect log.'
- exit 1
-}
-
bisect_autostart() {
test -d "$GIT_DIR/refs/bisect" || {
echo >&2 'You need to start by "git bisect start"'
diff --git a/git-branch.sh b/git-branch.sh
index 5306b27..0266f46 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,21 +1,12 @@
#!/bin/sh
-GIT_DIR=`git-rev-parse --git-dir` || exit $?
-
-die () {
- echo >&2 "$*"
- exit 1
-}
-
-usage () {
- echo >&2 "usage: $(basename $0)"' [-d <branch>] | [[-f] <branch> [start-point]]
-
-If no arguments, show available branches and mark current branch with a star.
+USAGE='[-d <branch>] | [[-f] <branch> [start-point]]'
+LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
-If two arguments, create a new branch <branchname> based off of <start-point>.
-'
- exit 1
-}
+If two arguments, create a new branch <branchname> based off of <start-point>.'
+
+SUBDIRECTORY_OK='Yes'
+. git-sh-setup
headref=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index b4f1022..1e638e4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -11,13 +11,37 @@
# exporting it.
unset CDPATH
-: ${GIT_DIR=.git}
-: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
-
die() {
echo >&2 "$@"
exit 1
}
-# Make sure we are in a valid repository of a vintage we understand.
-GIT_DIR="$GIT_DIR" git-var GIT_AUTHOR_IDENT >/dev/null || exit
+usage() {
+ die "Usage: $0 $USAGE"
+}
+
+if [ -z "$LONG_USAGE" ]
+then
+ LONG_USAGE="Usage: $0 $USAGE"
+else
+ LONG_USAGE="Usage: $0 $USAGE
+
+$LONG_USAGE"
+fi
+
+case "$1" in
+ --h|--he|--hel|--help)
+ echo "$LONG_USAGE"
+ exit
+esac
+
+if [ -z "$SUBDIRECTORY_OK" ]
+then
+ : ${GIT_DIR=.git}
+ : ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
+
+ # Make sure we are in a valid repository of a vintage we understand.
+ GIT_DIR="$GIT_DIR" git-var GIT_AUTHOR_IDENT >/dev/null || exit
+else
+ GIT_DIR=$(git-rev-parse --git-dir) || exit
+fi
diff --git a/git-status.sh b/git-status.sh
index 2dda0c5..50ccd24 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -2,7 +2,16 @@
#
# Copyright (c) 2005 Linus Torvalds
#
-GIT_DIR=$(git-rev-parse --git-dir) || exit
+
+USAGE=''
+SUBDIRECTORY_OK='Yes'
+
+. git-sh-setup
+
+if [ "$#" != "0" ]
+then
+ usage
+fi
report () {
header="#
^ permalink raw reply related
* Re: [RFC, PATCH] Usage message clean-up, take #2
From: Junio C Hamano @ 2005-12-11 10:15 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20051211095549.GB4919@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> The scripts will also set USAGE and possibly LONG_USAGE before they
> source git-sh-setup. If LONG_USAGE isn't set it defaults to USAGE.
Looks like a good start to allow us to mechanically generate
parts of the manpages in the future.
Last time I played around with various bourne derivative shells,
I was annoyed by that scripts sourced with '.' behaved slightly
differently regarding positional arguments such as "$1", which
may be one thing to watch out for (sorry, I do not remember the
details right now, other than one case: ". ./foobra.sh arg1
arg2", and depending on the shell the value of $# and $1
foobra.sh sees was different. I do not think this would matter
for our purpose because in our case ". script" form is never
used with extra parameters).
^ permalink raw reply
* Re: Branches merging by only overwrite files
From: Ben Lau @ 2005-12-11 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqzonfkx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Ben Lau <benlau@ust.hk> writes:
>
>
>> I am looking for a solution to merge two branches but do not perform
>>file level merge. Instead, I wish the result file is the copy from any
>>one of the branches.
>>
>
>It might be better to state why you need this first. It could
>be that what you really want to solve is not related to merge at
>all.
>
>
Sorry for not giving the reason to require this merge strategy. I just
afraid it need to write too long and discourge people in reading my email.
Recently, besides to use git for kernel's version control. I used it to
manage the change of a content management software called xoops. It is a
PHP system. I have maintained several websites based on this engine.
Those website's code was maintained by CVS in the past. But CVS's branch
management is quite terrible and therefore each site have their own
repository. And now I am going to merge all the sites into a single git
repository with multple branches.
Source layout of xoops:
html/class
html/themes
html/include
[[:snipped:]]
html/modules
As it is module-based CMS system, after install the core system, users
may choose to install any module to enchance their site by placing codes
under the path of 'html/modules' .
That means every user must have their own changes. To simplify the
upgrade process, users just have to replace the old files by newest
source , no matter it is the core system or modules.
Consider the following tree:
v2.0
/ \
tag1 v2.2
/ \ \
site1 site2 tag2
\
site3
Branches site1 and site2 are dervated from v2.0 and have installed
several different modules. In the tree, it may have another sites
running v2.2 like site3. Now, I am going to upgrade site2 to tag2(based
on v2.2) by merge the branches the produce the tree as follow:
v2.0
/ \
tag1 v2.2
/ \ \
site1 \ tag2
\ / \
site2 site3
But the merge is not smooth, tag2 may contains some modules that are
newer then what site2 has been installed. Replace those conflict files
from tag2 should be the simplest method , and that is why I want this
merge strategy.
>> For example, assumes it has two branches A and B, some of the files
>>are modified in both of them. In this case, `/usr/bin/merge` could not
>>be execated, it just have to choose the revision from branch A and
>>discards all the changes from B. For the rest of files, it just simply
>>choose the newest copy from A or B.
>>
>
>I wonder why you say "could not be executed". I take it to mean
>you just do not want to even when it could.
>
>
well... a typo mistake, should be "should not be execated"
>Now, it is not clear if you always want copy from branch A and
>not from branch B when both branches have the same path, or you
>want to pick one at random between A and B. If branch A kept
>the file intact and branch B modified it, what do you want to
>happen? The default "merge" semantics in git (unless you are
>using "ours" strategy) in such a case is always to take the
>version from branch B. Is that consistent with what you want?
>
>What do you exactly mean "newest copy from A or B"? What are
>you basing the "newest" determination on? The commit date of A
>and B commits, or the author date ot two?
>
>
If the file is modified in branch A, choose the revision from A.
If branch A kept the file intact and branch B modified it, It could use
the branch B's version.
In fact, It just copy files from branch A to branch B.
>Assuming that you can give reasonable and consistent answer to
>the above question to define the semantics of your "new merge
>algorithm", what you would do is to write a new script
>git-merge-benlau to implement whatever semantics you picked.
>You could model it after existing merge strategy, such as
>git-merge-resolve.sh or git-merge-stupid.sh. Then you give the
>new merge strategy to "git-merge" or "git-pull".
>
>
hmmm. Do you think my answer make sense? May be I could call it
"git-merge-direct-copy". Although it just copy and overwrite files from
a branch to another , it could help to manage web-based CMS like xoops
where add-ons are installed by source within the source tree.
>For example, if you want all the usual "trivial merges" to work
>just like the default git merge algorithms, but always take
>"our" version instead of running file-level merge when both
>sides modified a file, then you start from a copy of
>git-merge-stupid.sh, and replace "git-merge-one-file" with
>"git-merge-one-file-benlau'. Copy "git-merge-one-file.sh" to
>create another new script, "git-merge-one-file-benlau", and
>replace this line:
>
> merge "$src1" "$orig" "$src"
>
>with
>
> cat "$orig" >"$src1"
>
>and you are done.
>
>I outlined the above without knowing what you really want to
>achieve, and I do not think the resulting merge strategy makes
>much sense, but that is what I get form hacking without knowing
>what you are really trying to do ;-).
>
>
Spent some times reading the manual and source code, I found similar way
to implement. But I don't want to waste the effort in coding , that is
why I sent this email out to see would it have any solutions that don't
require to add a new algorithm and changes the source code. If no such
method, then I will start coding, at least it will be useful to me.
Thanks!!
^ permalink raw reply
* Re: [PATCH 0/25] Usage message clean-up
From: Nikolai Weibull @ 2005-12-11 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
freku045@student.liu.se wrote:
> * The message is of the form "usage: $0 options"
I don’t really care, but most GNU utils seem to use a large 'U' in
"Usage". Is there a particular reason that git doesn't? (Other than
git not being GNU software?)
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
^ permalink raw reply
* [PATCH] Offload most of cg-object-id to git-rev-parse
From: Jonas Fonseca @ 2005-12-11 18:19 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20051207213905.GA25890@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Forget the other 4 patches. Here's one that fixes the thing we
discussed on IRC, i.e. ambiguous ID's are handled correctly
(unfortunately without giving a proper warning message).
This one also assumes that there is no reason for checking revs
returned by git-rev-list with git-rev-parse --revs-only.
TODO | 2 --
cg-object-id | 58 ++++++++++++++++------------------------------------------
2 files changed, 16 insertions(+), 44 deletions(-)
diff --git a/TODO b/TODO
index 0658b39..26bb4d0 100644
--- a/TODO
+++ b/TODO
@@ -27,8 +27,6 @@ cg-*patch should be pre-1.0.)
Includes merge-order cg-log and cg-diff checking for renames.
-* Offload most of cg-object-id to git-rev-parse
-
* Show only first 12 (or so) nibbles of the hashes everywhere
Even this might be too much, but more than this is really useless
for anyone remotely human. And it's less scary, too.
diff --git a/cg-object-id b/cg-object-id
index 1628e93..49d6d99 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -40,54 +40,29 @@ deprecated_alias cg-object-id commit-id
normalize_id()
{
local id="$1"
+ local revid=
+ local valid=
- if [ "${id:(-1):1}" = "^" ]; then
- # find first parent
- normalize_id "${id%^}"
- normid=$(git-cat-file commit "$normid" | \
- awk '/^parent/{print $2; exit};/^$/{exit}') || exit 1
- type="commit"
- return
- fi
-
- if [ ! "$id" ] || [ "$id" = "this" ] || [ "$id" = "HEAD" ]; then
- read id < "$_git/$(git-symbolic-ref HEAD)"
-
- elif [ -r "$_git/refs/tags/$id" ]; then
- read id < "$_git/refs/tags/$id"
-
- elif [ -r "$_git/refs/heads/$id" ]; then
- read id < "$_git/refs/heads/$id"
-
- elif [ -r "$_git/refs/$id" ]; then
- read id < "$_git/refs/$id"
-
- # Short id's must be lower case and at least 4 digits.
- elif [[ "$id" == [0-9a-f][0-9a-f][0-9a-f][0-9a-f]* ]]; then
- idpref=${id:0:2}
- idpost=${id:2}
-
- # Assign array elements to matching names
- idmatch=($_git_objects/$idpref/$idpost*)
-
- if [ ${#idmatch[*]} -eq 1 ] && [ -r "$idmatch" ]; then
- exid=$idpref${idmatch#$_git_objects/$idpref/}
- [ ${#exid} -eq 40 ] && [ "$(git-rev-parse --revs-only "$exid")" ] && id="$exid"
- elif [ ${#idmatch[*]} -gt 1 ]; then
- echo "Ambiguous id: $id" >&2
- echo "${idmatch[@]}" >&2
- exit 1
- fi
+ if [ ! "$id" ] || [ "$id" = "this" ]; then
+ id=HEAD;
+ fi
+
+ revid="$(git-rev-parse --verify "$id^0" 2>/dev/null)"
+ if [ "$revid" ]; then
+ id="$revid"
+ valid=1
fi
- valid=; [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
# date does the wrong thing for empty and single-letter ids
if [ ${#id} -gt 1 ] && [ ! "$valid" ]; then
reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
if [ "$reqsecs" ]; then
- id=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
- valid=; [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
+ revid=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
+ if [ ${#revid} -eq 40 ]; then
+ id="$revid"
+ valid=1
+ fi
fi
fi
@@ -147,7 +122,7 @@ fi
if [ "$show_parent" ]; then
- git-cat-file commit "$normid" | awk '/^parent/{print $2};/^$/{exit}'
+ git-rev-parse "$normid^"
exit 0
fi
@@ -170,4 +145,3 @@ else
fi
echo $normid
-
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Make the Cogito manpage references more colorful
From: Jonas Fonseca @ 2005-12-11 18:19 UTC (permalink / raw)
To: Petr Baudis, git
... by copying the gitlink macro from git.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 3b8f92d921868da0af9195db03b277650147498f
tree 64f6668d5e12777811e65f7c5e4bcfd70b4e8714
parent c10cc1d2a99b01ed3bf45d5f2ad6157940a22365
author Jonas Fonseca <fonseca@diku.dk> Tue, 06 Dec 2005 23:56:24 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Tue, 06 Dec 2005 23:56:24 +0100
Documentation/asciidoc.conf | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 9a1bbc5..baefb2f 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -9,7 +9,10 @@
ifdef::backend-docbook[]
[gitlink-inlinemacro]
-{target}{0?({0})}
+{0%{target}}
+{0#<citerefentry>}
+{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
+{0#</citerefentry>}
endif::backend-docbook[]
ifdef::backend-xhtml11[]
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] cg-object-id: use git-rev-parse(1) for date parsing
From: Jonas Fonseca @ 2005-12-11 18:31 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20051211181901.GA2960@diku.dk>
Using the --until switch, git-rev-parse(1) will first be given the ID.
If it cannot make sense of the ID fallback to using date(1).
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/cg-object-id b/cg-object-id
index 49d6d99..4e3a3e2 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -55,7 +55,14 @@ normalize_id()
# date does the wrong thing for empty and single-letter ids
if [ ${#id} -gt 1 ] && [ ! "$valid" ]; then
- reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
+ cursecs=$(git-rev-parse --until=yksap); cursecs=${cursecs:10}
+ reqsecs=$(git-rev-parse --until="$id"); reqsecs=${reqsecs:10}
+
+ # git-rev-parse(1) will output the current time if the ID
+ # doesn't make sense. Workaround it so date(1) can have a try.
+ if [ "$cursecs" -le "$reqsecs" ]; then
+ reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
+ fi
if [ "$reqsecs" ]; then
revid=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] cg-status: handle subdirs when listing heads
From: Jonas Fonseca @ 2005-12-11 19:03 UTC (permalink / raw)
To: Petr Baudis, git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
fonseca@antimatter:~/src/cogito/cogito > cg switch -r master tmp/work
Creating new branch tmp/work: 218ee732bee381746890bf5ffb9bfc4672795954
Switching to branch tmp/work...
fonseca@antimatter:~/src/cogito/cogito > cg status
Heads:
cg-object-id c10cc1d2a99b01ed3bf45d5f2ad6157940a22365
cg-Xedit 41447107236a7d23daa6ab0f40a0829935485bc8
master 218ee732bee381746890bf5ffb9bfc4672795954
R origin 218ee732bee381746890bf5ffb9bfc4672795954
cat: .git/refs/heads/tmp: Is a directory
tmp
commit 2e7be765ca86117dc7af8aa0cd0f090269fee428
tree 0154d7f35e6ae7c357ff18e7b1f46e2ee4d25309
parent 218ee732bee381746890bf5ffb9bfc4672795954
author Jonas Fonseca <fonseca@diku.dk> Sun, 11 Dec 2005 19:57:31 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sun, 11 Dec 2005 19:57:31 +0100
cg-status | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/cg-status b/cg-status
index a4c5e7a..629c796 100755
--- a/cg-status
+++ b/cg-status
@@ -106,6 +106,24 @@ if [ ! "$gitstatus" ] && [ ! "$workstatu
fi
+list_heads()
+{
+ local path="$1"
+
+ if [ -d "$path" ]; then
+ for head in "$path"/*; do
+ list_heads "$head"
+ done
+ else
+ headsha1=$(cat "$path")
+ headname=${path#$_git/refs/heads/}
+ [ "$headname" = "cg-seek-point" ] && continue
+ cf=" "; rf=" "
+ [ "$headname" = "$_git_head" ] && cf=">"
+ [ -s "$_git/branches/$headname" ] && rf="R"
+ echo -e " $rf$cf$headname\t$headsha1"
+ fi
+}
if [ "$gitstatus" ]; then
mkdir -p $_git/refs/heads
@@ -123,15 +141,7 @@ if [ "$gitstatus" ]; then
fi
echo "Heads:"
- for head in $_git/refs/heads/*; do
- headsha1=$(cat "$head")
- headname=$(basename "$head")
- [ "$headname" = "cg-seek-point" ] && continue
- cf=" "; rf=" "
- [ "$headname" = "$_git_head" ] && cf=">"
- [ -s "$_git/branches/$headname" ] && rf="R"
- echo -e " $rf$cf$headname\t$headsha1"
- done
+ list_heads "$_git/refs/heads"
if [ -s "$_git/merging" ]; then
tmp=$(cat "$_git/merging")
\f
!-------------------------------------------------------------flip-
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] cg-merge: Improve the hook description
From: Jonas Fonseca @ 2005-12-11 19:07 UTC (permalink / raw)
To: Petr Baudis, git
Make it into a HOOKS section and place the argument list in the term
line.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Just an idea. The current thing is renderered poorly in cg-merge(1).
commit 4b1142df28132c12ce82c71757c417d8d41474ca
tree 3c317897b6ce1dde87d5ab41b1611fce3c902e56
parent 3b8f92d921868da0af9195db03b277650147498f
author Jonas Fonseca <fonseca@diku.dk> Tue, 06 Dec 2005 23:57:22 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Tue, 06 Dec 2005 23:57:22 +0100
cg-merge | 24 +++++++++++-------------
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/cg-merge b/cg-merge
index 08a6075..c06e4be 100755
--- a/cg-merge
+++ b/cg-merge
@@ -64,23 +64,21 @@
# "do it I", "fix it", "do it II", "fix it II", "fix it III" commits
# like you would get with a regular merge).
#
-# FILES
+# HOOKS
# -----
-# $GIT_DIR/hooks/merge-pre::
+# '.git/hooks/merge-pre' BRANCH BASE CURHEAD MERGEDHEAD MERGETYPE::
# If the file exists and is executable it will be executed right
-# before the merge itself happens. The script is passed those
-# arguments:
-# BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE
-# MERGETYPE is either "forward", "squash", or "tree". The merge is
-# cancelled if the script returns non-zero exit code.
+# before the merge itself happens. The merge is cancelled if the script
+# returns non-zero exit code.
+# - MERGETYPE is either "forward", "squash", or "tree".
#
-# $GIT_DIR/hooks/merge-post::
+# '.git/hooks/merge-post' BRANCH BASE CURHEAD MERGEDHEAD MERGETYPE STATUS::
# If the file exists and is executable it will be executed after
-# the merge is done. The script is passed those arguments:
-# BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE STATUS
-# MERGETYPE is either "forward", "squash", or "tree". For "forward",
-# the STATUS is always "ok", while for "squash" and "tree" the STATUS
-# can be "localchanges", "conflicts", "nocommit", or "ok".
+# the merge is done.
+# - MERGETYPE is either "forward", "squash", or "tree".
+# - For 'forward', the STATUS is always "ok", while for "squash"
+# and "tree" the STATUS can be "localchanges", "conflicts",
+# "nocommit", or "ok".
# Developer's documentation:
#
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] cg-completion: improve options and command listing
From: Jonas Fonseca @ 2005-12-11 19:09 UTC (permalink / raw)
To: Petr Baudis, git
Complete help options and improve filtering for command name completion.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
The current filtering causes all sorts of garbage to be listed in the
command listing.
commit f0535e9952f1cace89d03649e8238aca69a6df44
tree e05dfadb63bd92ead0dc29d326065b7a797e2109
parent 3c14cded46e110396127fc5b5e65883eb5cd60b9
author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 20:58:50 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07 Dec 2005 20:58:50 +0100
contrib/cg-completion.bash | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/contrib/cg-completion.bash b/contrib/cg-completion.bash
index 428f320..20b758f 100644
--- a/contrib/cg-completion.bash
+++ b/contrib/cg-completion.bash
@@ -23,8 +23,7 @@ __cg_branches()
__cg_cmdlist()
{
- (cg help && cg help tag && cg help branch && cg help admin) | grep --regexp "cg-[^ ]* " | sed 's/^.*\cg-\([^ ]*\) .*$/\1/' | grep -v COMMAND
-
+ (cg help && cg help tag && cg help branch && cg help admin) | sed -n 's/.*cg-\([^ ]*\) .*/\1/p' | sort -u
}
_cg ()
@@ -33,17 +32,17 @@ _cg ()
cur=${COMP_WORDS[COMP_CWORD]}
COMPREPLY=()
if [ $COMP_CWORD -eq 1 ]; then
- COMPREPLY=( $(compgen -W "$(__cg_cmdlist)" -- $cur) )
+ COMPREPLY=( $(compgen -W "$(__cg_cmdlist) -h --help --version" -- $cur) )
else
local cmd=${COMP_WORDS[1]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
- local o_help="-h --help"
+ local o_help="-h --help --long-help"
local o_branch="-b --branch"
case $cmd in
add)
# cg-add [-N] [-r] file...
# XXX here could generate list of files and dirs excluding .git
- opts="-N -r"
+ opts="-N -r $o_help"
COMPREPLY=( $(compgen -d -f -W "${opts}" -- $cur ) )
;;
@@ -58,18 +57,18 @@ _cg ()
clean)
# Usage: cg-clean [-d] [-D] [-q] [-x]
- opts="-d -D -q -x"
+ opts="-d -D -q -x $o_help"
COMPREPLY=( $(compgen -W "${opts}" -- $cur ) )
;;
help)
- opts="-c"
+ opts="-c $o_help"
COMPREPLY=( $(compgen -W "$(__cg_cmdlist) ${opts}" -- $cur) )
;;
push)
# cg-push [BRANCH_NAME] [-t TAG]
- opts="-t"
+ opts="-t $o_help"
if [ "$prev" = "-t" ]; then
COMPREPLY=( $(compgen -W "$(__git_tags)" -- $cur) )
else
@@ -79,7 +78,7 @@ _cg ()
merge)
# cg-merge [-c] [-b BASE_COMMIT] [BRANCH_NAME]
- opts="-c -b"
+ opts="-c -b $o_help"
if [ "$prev" = "-b" ]; then
COMPREPLY=( $(compgen -W "$(__git_refs)" -- $cur) )
else
@@ -89,7 +88,7 @@ _cg ()
commit)
# cg-commit [-m MESSAGE]... [-C] [-e | -E] [-c COMMIT_ID] [FILE]
- opts="-m -C -e -E -c"
+ opts="-m -C -e -E -c $o_help"
if [ "$prev" = "-m" ]; then
COMPREPLY="\"\""
elif [ "$prev" = "-c" ]; then
@@ -101,7 +100,7 @@ _cg ()
diff)
# cg-diff [-c] [-m] [-s] [-p] [-r FROM_ID[:TO_ID]] [FILE]...
- opts="-c -m -s -p -r"
+ opts="-c -m -s -p -r $o_help"
if [ "$prev" = "-r" ]; then
# TODO need some kinkiness to handle -r FROM:TO completion
COMPREPLY=( $(compgen -W "$(__git_refs)" -- $cur) )
@@ -111,7 +110,7 @@ _cg ()
;;
log)
- opts="-c -f -r -d -m -s -u --summary"
+ opts="-c -f -r -d -m -s -u --summary $o_help"
if [ "$prev" = "-r" ]; then
# TODO need some kinkiness to handle -r FROM:TO completion
COMPREPLY=( $(compgen -W "$(__git_refs)" -- $cur) )
@@ -131,7 +130,7 @@ _cg ()
;;
switch)
# Usage: cg-switch [-f] [-n] [-r COMMIT_ID] BRANCH
- opts="-f -n -r" # TODO -r
+ opts="-f -n -r $o_help" # TODO -r
COMPREPLY=( $(compgen -W "${opts} $(__git_heads)" -- $cur) )
;;
--
Jonas Fonseca
^ permalink raw reply related
* Cogito limitation in tag names?
From: H. Peter Anvin @ 2005-12-11 19:23 UTC (permalink / raw)
To: Git Mailing List
From cg-tag in 0.16:
(echo $name | egrep -qv '[^a-zA-Z0-9_.@!:-]') || \
die "name contains invalid characters"
WHY? I can see rejecting control characters, but the above will reject
pretty much anything written in a non-English language, which is rude to
say the least...
-hpa
^ permalink raw reply
* Re: Cogito limitation in tag names?
From: Junio C Hamano @ 2005-12-11 19:36 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <439C7CA9.4030404@zytor.com>
Probably it can safely be updated to use check-ref-format, and I
suspect that the only reason why it does not do so is because
check-ref-format came later.
^ permalink raw reply
* [PATCH] cg-status: handle subdirs when listing heads
From: Jonas Fonseca @ 2005-12-11 19:49 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20051211190305.GD2960@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
And here's one which handles empty directories and is cleaner.
diff --git a/cg-status b/cg-status
index a4c5e7a..bd4d0ce 100755
--- a/cg-status
+++ b/cg-status
@@ -123,9 +123,9 @@ if [ "$gitstatus" ]; then
fi
echo "Heads:"
- for head in $_git/refs/heads/*; do
+ find "$_git/refs/heads" ! -type d | sort | while read head; do
headsha1=$(cat "$head")
- headname=$(basename "$head")
+ headname=${head#$_git/refs/heads/}
[ "$headname" = "cg-seek-point" ] && continue
cf=" "; rf=" "
[ "$headname" = "$_git_head" ] && cf=">"
--
Jonas Fonseca
^ permalink raw reply related
* Re: [RFC] Planning a git-cvsdaemon
From: Mike McCormack @ 2005-12-11 20:57 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90512101844q326b3d43nf8b40617bd82c576@mail.gmail.com>
Martin Langhoff wrote:
> In any case, I am after feedback in general (and any truly
> insurmountable issues you can think of), I haven't found yet a good
> library implementing the server side of the protocol (other than
> cvs's). git-cvsdaemon will probably take shape in Perl initially,
> though if there's a good cvs protocol library in other scripting
> language, I'm interested...
Hey Martin,
That's a neat idea, and a great way to get projects to move from CVS to GIT.
I'd recommend that you avoid providing commit access to a GIT repository
via CVS for starters. Many projects (eg. Wine) would benefit greatly
from just having a way for people to get the source via CVS without
having to write scripts to maintain a CVS tree in parallel. Serious
developers will use GIT if the master repository is GIT anyway.
Mike
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Petr Baudis @ 2005-12-12 0:26 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1134289867.9541.9.camel@blade>
Hello,
Dear diary, on Sun, Dec 11, 2005 at 09:31:07AM CET, I got a letter
where Marcel Holtmann <marcel@holtmann.org> said that...
> it's now working again. Thanks. What do you think about another release?
> I haven't checked the other distributions yet, but I just saw that
> Debian unstable also moved to version 3.1 of bash.
yes, I was planning 0.16.1 on Sunday anyway. Going to tag it now.
> There exists also another problem with the new bash. It is the broken
> pipe error from cg-log.
>
> cg-log: line 141: echo: write error: Broken pipe
>
> The line number varies depending how much you scrolled and when you
> scrolled to the end no broken pipe error comes up. Do you have any idea
> on how to deal with this. I saw your comment about that bash is broken
> and the extra trap command, but it doesn't help. I never saw that
> problem with older versions of bash.
Then that's quite funny, one-line broken pipe message has been always
there (in the past it looked much worse, we thankfully managed to bring
it down to this at least).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Martin Langhoff @ 2005-12-12 0:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marcel Holtmann, git
In-Reply-To: <20051212002631.GW22159@pasky.or.cz>
On 12/12/05, Petr Baudis <pasky@suse.cz> wrote:
> Then that's quite funny, one-line broken pipe message has been always
> there (in the past it looked much worse, we thankfully managed to bring
> it down to this at least).
I assume there's no reasonable workaround to that then? What would
take to get rid of that (say, if I had a boring weekend ;)?
cheers,
m
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Petr Baudis @ 2005-12-12 0:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Marcel Holtmann, git
In-Reply-To: <46a038f90512111658x5fe3198ey38515fc2745dd42b@mail.gmail.com>
Dear diary, on Mon, Dec 12, 2005 at 01:58:00AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 12/12/05, Petr Baudis <pasky@suse.cz> wrote:
> > Then that's quite funny, one-line broken pipe message has been always
> > there (in the past it looked much worse, we thankfully managed to bring
> > it down to this at least).
>
> I assume there's no reasonable workaround to that then?
The trapping is apparently the best we can do - at least I know of
nothing better.
> What would take to get rid of that (say, if I had a boring weekend ;)?
Fixing bash, IIRC - and more importantly, convincing its maintainers to
take the patch. ;-) Sometime in the spring someone even posted the exact
location in bash where this is broken.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.16.1
From: Petr Baudis @ 2005-12-12 1:12 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
this is Cogito version 0.16.1, the next stable release of the
human-friendly version control UI for the Linus' GIT tool. Share
and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
This crispy new release gives you a few minor to medium bugfixes and
a significant cg-patch speedup. You can reach it as the "v0.16" branch
of the Cogito repository. Note that this is just the stable branch, more
interesting stuff is happenning (and especially going to happen) on the
master development branch; if everything goes well, I might release
cogito-0.17rc1 at the end of this week).
So the new stuff since 0.16 is:
Jonas Fonseca:
cg-merge: Improve the hook description
cg-status: handle subdirs when listing heads
Petr Baudis:
Fix cg-admin-setuprepo warning on missing post-update hook
Initial cg-push to a remote branch wouldn't work properly
Fix cg-object-id <singleletter>
Fix unsafe sed usage in scripts
cg-clean -n will just pretend to remove stuff
Make cg-clean whitespace-safe
If you use filenames with spaces _and_ cg-clean (or cg-clean
at all, after all), you should certainly upgrade!
bash-3.1-related fixes
Fix broken cg-log FILE in subdirectory
Drastically speed up cg-patch
cogito-0.16.1
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox