* [PATCH 1/2] fetch: Misc output cleanup
From: Santi Béjar @ 2006-10-01 3:33 UTC (permalink / raw)
To: git
In particular it removes duplicate information, uses short hashes (as
git-log and company) and uses .. for fast forwarding commits and ... for
not-fast-forwarding commits (shorter, easier to copy&paste). It also
reformat the output as:
1. the ones we store in our local ref (either branches or tags):
1a) fast-forward
* refs/heads/origin: fast forward to branch 'master' of ../git/
old..new: 1ad7a06..bc1a580
1b) same (only shown under -v)
* refs/heads/next: same as branch 'origin/next' of ../git/
commit: ce47b9f
1c) non-fast-forward, forced
* refs/heads/pu: forcing update to not fast forwarding branch 'pu' of ../git/
old...new: 7c733a8...5faa935
1d) non-fast-forward, did not update because not forced
* refs/heads/po: not updating to not fast forwarding branch 'po' of ../git/
old...new: 7c733a8...5faa935
1e) creating a new local ref to store
* refs/tags/v1.4.2-rc4: storing tag 'v1.4.2-rc4' of ../git/
tag: 8c7a107
* refs/heads/next: storing branch 'next' of ../git/
commit: f8a20ae
2. the ones we do not store in our local ref (only shown under -v):
* fetched branch 'master' of ../git
commit: 695dffe
* fetched tag 'v1.4.2-rc4' of ../git
tag: 8c7a107
With the help of Junio.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 41 +++++++++++++++++++++++++----------------
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index f1522bd..60ae552 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -129,22 +129,25 @@ append_fetch_head () {
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
echo "$headc_ $not_for_merge_ $note_" >>"$GIT_DIR/FETCH_HEAD"
- [ "$verbose" ] && echo >&2 "* committish: $head_"
- [ "$verbose" ] && echo >&2 " $note_"
else
echo "$head_ not-for-merge $note_" >>"$GIT_DIR/FETCH_HEAD"
- [ "$verbose" ] && echo >&2 "* non-commit: $head_"
- [ "$verbose" ] && echo >&2 " $note_"
- fi
- if test "$local_name_" != ""
- then
- # We are storing the head locally. Make sure that it is
- # a fast forward (aka "reverse push").
- fast_forward_local "$local_name_" "$head_" "$note_"
fi
+
+ update_local_ref "$local_name_" "$head_" "$note_"
}
-fast_forward_local () {
+update_local_ref () {
+ # If we are storing the head locally make sure that it is
+ # a fast forward (aka "reverse push").
+
+ label_=$(git-cat-file -t $2)
+ newshort_=$(git-rev-parse --short $2)
+ if test -z "$1" ; then
+ [ "$verbose" ] && echo >&2 "* fetched $3"
+ [ "$verbose" ] && echo >&2 " $label_: $newshort_"
+ return 0
+ fi
+ oldshort_=$(git-rev-parse --short "$1" 2>/dev/null)
mkdir -p "$(dirname "$GIT_DIR/$1")"
case "$1" in
refs/tags/*)
@@ -154,13 +157,16 @@ fast_forward_local () {
then
if now_=$(cat "$GIT_DIR/$1") && test "$now_" = "$2"
then
- [ "$verbose" ] && echo >&2 "* $1: same as $3" ||:
+ [ "$verbose" ] && echo >&2 "* $1: same as $3"
+ [ "$verbose" ] && echo >&2 " $label_: $newshort_" ||:
else
echo >&2 "* $1: updating with $3"
+ echo >&2 " $label_: $newshort_"
git-update-ref -m "$rloga: updating tag" "$1" "$2"
fi
else
echo >&2 "* $1: storing $3"
+ echo >&2 " $label_: $newshort_"
git-update-ref -m "$rloga: storing tag" "$1" "$2"
fi
;;
@@ -178,31 +184,34 @@ fast_forward_local () {
if test -n "$verbose"
then
echo >&2 "* $1: same as $3"
+ echo >&2 " $label_: $newshort_"
fi
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
- echo >&2 " from $local to $2"
+ echo >&2 " old..new: $oldshort_..$newshort_"
git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
;;
*)
false
;;
esac || {
- echo >&2 "* $1: does not fast forward to $3;"
case ",$force,$single_force," in
*,t,*)
- echo >&2 " forcing update."
+ echo >&2 "* $1: forcing update to not fast forwarding $3"
+ echo >&2 " old...new: $oldshort_...$newshort_"
git-update-ref -m "$rloga: forced-update" "$1" "$2" "$local"
;;
*)
- echo >&2 " not updating."
+ echo >&2 "* $1: not updating to not fast forwarding $3"
+ echo >&2 " old...new: $oldshort_...$newshort_"
exit 1
;;
esac
}
else
echo >&2 "* $1: storing $3"
+ echo >&2 " $label_: $newshort_"
git-update-ref -m "$rloga: storing head" "$1" "$2"
fi
;;
--
1.4.2.1.g38049
^ permalink raw reply related
* [PATCH 2/2] merge and resolve: Output short hashes and .. in "Updating ..."
From: Santi Béjar @ 2006-10-01 3:34 UTC (permalink / raw)
To: git
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-merge.sh | 2 +-
git-resolve.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 5b34b4d..49c46d5 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -197,7 +197,7 @@ f,*)
;;
?,1,"$head",*)
# Again the most common case of merging one remote.
- echo "Updating from $head to $1"
+ echo "Updating $(git-rev-parse --short $head)..$(git-rev-parse --short $1)"
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
git-read-tree -u -v -m $head "$new_head" &&
diff --git a/git-resolve.sh b/git-resolve.sh
index 729ec65..36b90e3 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -46,7 +46,7 @@ case "$common" in
exit 0
;;
"$head")
- echo "Updating from $head to $merge"
+ echo "Updating $(git-rev-parse --short $head)..$(git-rev-parse --short $merge)"
git-read-tree -u -m $head $merge || exit 1
git-update-ref -m "resolve $merge_name: Fast forward" \
HEAD "$merge" "$head"
--
1.4.2.1.g38049
^ permalink raw reply related
* Re: [PATCH 1/2] Move code resolving packed refs into its own function.
From: Christian Couder @ 2006-10-01 4:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz8hccxl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This patch move Linus' packed refs resolving code from
> > "resolve_ref" into a new "resolve_packed_ref" extern
> > function so that it can be reused when needed.
>
> I think we are stepping on each other's toes. How far into the
> process of making correct branch deletion are you?
I am not farther than the 2 patches I sent yesterday (before going to bed).
Now I will probably add a few more test cases and see what needs to be done
for tags. Tell me when you have finished with branch deletion so I can see
what I can do in this area.
Thanks,
Christian.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-10-01 5:19 UTC (permalink / raw)
To: git
In-Reply-To: <45196628.9010107@gmail.com>
This updates the note based on the discussion the original note
generated. The most significant difference is the ability to specify
a particular version of a subproject.
20061001.0400
Notes on Using Git with Subprojects
===================================
Copyright (C) 2006 by Raymond S Brand
Git does not have native support for subprojects and this is a good
thing because managing subprojects is better handled by the project
build machinery. Managing subprojects with the project build machinery
is more flexible than the native support from an SCM and allows the use
of different SCMs by different subprojects. However, there is a lot of
interest in using Git for the SCM of a project with subprojects.
Git, unfortunately, does not make it easy. What is wanted is to put all
of the subprojects in one repository and be able to checkout the various
parts from a local copy of the repository. The problem is, with Git, a
repository can have at most one working directory associated with it at
a time. This is because Git stores a lot of information about the
contents of the working directory in the repository. In fact, the usual
situation is that the repository, itself, is in the working directory.
An important criteria for supporting subprojects is that a subproject
may be developed and controlled by an entity or organization different
than that of the parent project of the subproject. As a consequence of
this, the build machinery needed to manage a project controlled by
another entity as a subproject must be in the parent project.
This note describes a method to use Git with subprojects; other methods
are also possible.
Definitions
-----------
Parent Project:
A project that logically contains one or more subprojects.
Project:
A set of files that is (relatively) self contained with respect
to changes and treated as a unit by the SCM.
Root Project:
A project that is not a subproject.
Subproject:
A project logically contained in another project.
Super project:
A project composed of subprojects.
Setup
-----
All subprojects are contained in a single repository and referred to by
separate heads or tags. Developers create a local copy of the project
repository; hereafter, referred to as the "local master repository" or
just "local master". All fetches, pulls and pushes by the developers
with the "local master" of other developers should be to and from their
own "local master".
Root Project Checkout
---------------------
The root project is the project that all of the subprojects are a part
of. It is a parent project of one or more subprojects; each of which may
also be parent projects to other subprojects.
To checkout the root project, choose an name for the project working
directory (the working directory must not already exist) and perform the
equivalent of the following commands.
git-clone -s -n $LOCAL_MASTER $ROOT_DIR \
&& cd $ROOT_DIR \
&& git-checkout -b $ROOT_BRANCH--local $ROOT_VERSION
Where:
$LOCAL_MASTER is the path to the "local master"
$ROOT_DIR is the name of the working directory to use
$ROOT_VERSION is the ref name of the root project state
$ROOT_BRANCH--local is a branch for local changes
This will leave the current working directory of the shell in the
project working directory.
This also creates a branch with the suffix of "--local" to hold all of
the local working directory commits and modifications. The $ROOT_BRANCH
is used as a tracking branch so that upstream changes can be fetched
into the working repository without affecting the checked out files.
Once the root project is checked out, the subprojects are checked out.
Subproject Checkout
-------------------
Each project that is a parent project needs to checkout all of the
subprojects of the project. Each subproject is checked out with the
equivalent of the following bash commands:
git-clone -s -n $LOCAL_MASTER $SUBPROJECT_DIR \
&& ( cd $SUBPROJECT_DIR \
&& git-checkout -b $SUBPROJECT_BRANCH--local \
$SUBPROJECT_VERSION
)
Where:
$LOCAL_MASTER is the path to the "local master"
$SUBPROJECT_DIR is the directory name of the subproject
$SUBPROJECT_VERSION is the ref name of the subproject state
$SUBPROJECT_BRANCH--local is a branch for local changes
Project Development
-------------------
Changes to a project are performed in the working directory of the
project and are recorded in the repository in the working directory on
the $PROJECT--local branch.
Receiving Project Upstream Changes
----------------------------------
Upstream project changes are first fetched into the project tracking
branch of the local master repository and are then fetched into the
project tracking branch of the working directory repositories. To merge
upstream changes into the working directory, a pull from the project
tracking branch of the working directory repository executed.
# Fetch project branch from upstream to local master
(cd $LOCAL_MASTER && git-fetch $UPSTREAM $PROJECT_BRANCH)
# Fetch project branch from local master to working repo
git-fetch $LOCAL_MASTER $PROJECT_BRANCH
# Merge upstream changes in to working directory
git-pull --no-commit . $PROJECT_BRANCH
Where:
$LOCAL_MASTER is the path to the "local master"
$UPSTREAM is the Git URL of the upstream repository
$PROJECT_BRANCH is the branch name of the (sub)project
Sending Project Changes Upstream
--------------------------------
To send project changes upstream from a working directory repository,
the changes are first pushed to a branch in the local master repository,
$PROJECT--$IDENT. The changes can then be pushed or pulled from the
local master repository.
# Push project changes to local master
git-push $LOCAL_MASTER \
$PROJECT_BRANCH--local:$PROJECT_BRANCH--$IDENT
# Push project changes from local master to upstream
(cd $LOCAL_MASTER && git-push $UPSTREAM \
$PROJECT_BRANCH--$IDENT:$PROJECT_BRANCH--$NICK--$IDENT)
Where:
$LOCAL_MASTER is the path to the "local master"
$UPSTREAM is the Git URL of the upstream repository
$PROJECT_BRANCH is the tracking branch of the (sub)project
$PROJECT_BRANCH--local is a branch for local changes
$IDENT is a label unique for this set of working directories
$NICK is a (branch name safe) identifier of the developer
Automation
----------
The following proof of concept code can be added to parent project
makefiles to automate most of the operations needed to support
subprojects with Git.
---->8---- ---->8---- ---->8---- ---->8---- ---->8---- ---->8----
# Add this to the makefiles
SUBPROJECTLIST := GIT:s1_ref:s1_dev:s1 \
GIT:s2_ref:s2_dev:s2 \
GIT:s3_ref:s3_dev:s3
include Git_machinery.make
# Rest of the Makefile
---->8---- ---->8---- ---->8---- ---->8---- ---->8---- ---->8----
# Git_machinery.make
GIT-CLONE := gitclone
GIT-CHECKOUT := gitcheckout
GIT_FETCH := gitfetch
GIT-PULL := gitpull
GIT-PUSH := gitpush
include GIT-SUBPROJECT-VARS.mak
GIT-SUBPROJECT-VARS.mak: Makefile
@rm -rf GIT-SUBPROJECT-VARS.mak
@echo "REPOSITORY := $(REPOSITORY)" > GIT-SUBPROJECT-VARS.mak
@echo "IDENT := $(IDENT)" >> GIT-SUBPROJECT-VARS.mak
# SUBPROJECTLIST has the following format:
# Each "word" in the list starts with a scheme identifier followed
# by a ':'. The reainder if the "word" is the scheme specific
# subproject details.
# Scheme: GIT
# The scheme specific subproject details are 3 fields separated by
# ':'s.
# Field 1: Version reference - reference to checkout and fetch
# from.
# Field 2: Development branch ref name.
# Field 3: Sub directory for the subproject.
GIT--subproject--setup::
for SUBPROJECT in $(filter GIT:%,$(SUBPROJECTLIST)) ; do \
PARAM=($$(echo $$SUBPROJECT | tr ':' ' ')) ; \
$(GIT-CLONE) -s -n $(REPOSITORY) $${PARAM[3]} \
&& ( cd $${PARAM[3]} \
&& $(GIT-CHECKOUT) -b $${PARAM[2]}--local $${PARAM[1]} ; \
) ; \
done
GIT--subproject--fetch::
@for SUBPROJECT in $(filter GIT:%,$(SUBPROJECTLIST)) ; do \
PARAM=($$(echo $$SUBPROJECT | tr ':' ' ')) ; \
( cd $${PARAM[3]} \
&& $(GIT-FETCH) $(REPOSITORY) $${PARAM[1]} ; \
) ; \
done
GIT--subproject--pull::
@for SUBPROJECT in $(filter GIT:%,$(SUBPROJECTLIST)) ; do \
PARAM=($$(echo $$SUBPROJECT | tr ':' ' ')) ; \
( cd $${PARAM[3]} \
&& $(GIT-FETCH) $(REPOSITORY) $${PARAM[1]} ; \
&& $(GIT-PULL) --no-commit . $${PARAM[1]} ; \
) ; \
done
GIT--subproject--push::
@for SUBPROJECT in $(filter GIT:%,$(SUBPROJECTLIST)) ; do \
PARAM=($$(echo $$SUBPROJECT | tr ':' ' ')) ; \
( cd $${PARAM[3]} \
&& $(GIT-PUSH) $(REPOSITORY) \
$${PARAM[2]}--local:$${PARAM[2]}--$(IDENT) ; \
) ; \
done
---->8---- ---->8---- ---->8---- ---->8---- ---->8---- ---->8----
The example Makefile code has a number of limitations: There is no error
handling. It only handles Git managed subprojects. There are other Git
commands that can be usefully applied to subprojects.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-10-01 8:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Jeff King
In-Reply-To: <7v64f47uix.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Sat, 30 Sep 2006, Junio C Hamano wrote:
>>>
>>> Especially, "find the closest ancestor" behaviour means when you
>>> get "tag-gXXXX" as an answer, the tag proper does _not_ contain
>>> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of
>>> v1.4.2).
>>
>> Correct.
>>
>> But that just means that we should take the _next_ one in the time-ordered
>> list, no?
>
> I do not think so.
>
> Extending the example (sorry for doing the same topic on two
> separate threads) I just gave Jeff on "fix based on v0.99",
> after finding that the fix is based on v0.99, finding another
> commit that immediately followed the v0.99 commit on my master
> branch does not help finding out that I very recently merged the
> fix in at all. I think we cannot get away without honestly
> doing the first descendant, which is unfortunately a lot more
> expensive.
Maybe not *that* expensive. Here is an outline, thinking aloud.
When describing a commit and a ref, we first run the ancestry
traversal algorithm merge-base uses internally. If the tip of
the ref is not a descendant of the commit, abort (I'll justify
this in a moment).
Otherwise, we would already have parsed all the necessary
commits we need to determine which commits on the given ref's
ancestry is the first one that is a descendant of the target
commit at this point. We collect these commits in a set, and
then mark the ones that are immediate children of the target
commit, then the ones that are children of them, etc. until we
find all the descendant of the target commit.
After that, we can bisect the reflog for the ref to find the
first commit that we have marked as a descendant of the target
commit in the above process.
If the tip of the ref is not a descendant of the commit to begin
with, that does not automatically mean that the target commit
has never been part of the ref -- the ref _could_ have contained
it and then later got rewound. But then the question "when did
the commit has become part of this branch" itself stops being
interesting. It would not do us much good if we know it was
part of the branch for only two days last week but it is not
contained in the branch anymore.
^ permalink raw reply
* Re: git and time
From: Johannes Schindelin @ 2006-10-01 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v64f47uix.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 30 Sep 2006, Junio C Hamano wrote:
> I think we cannot get away without honestly doing the first descendant,
> which is unfortunately a lot more expensive.
... and which happens to be almost implemented in git-name-rev.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Junio C Hamano @ 2006-10-01 9:19 UTC (permalink / raw)
To: git
Instead of labelling each and every line with clickable commit
object name, this makes the blame output to show them only on
the first line of each group of lines from the same revision.
Also it makes mouse-over to show the minimum authorship and
authordate information for extra cuteness ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I've been staying away from the party to paint the bikeshed,
but I had a bit of time to kill tonight. Let's see if people
might like this...
gitweb/gitweb.perl | 67 +++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 44991b1..7e4ec8d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2429,6 +2429,41 @@ sub git_tag {
git_footer_html();
}
+sub git_blame_flush_chunk {
+ my ($name, $revdata, $color, $rev, @line) = @_;
+ my $label = substr($rev, 0, 8);
+ my $line = scalar(@line);
+ my $cnt = 0;
+ my $pop = '';
+
+ if ($revdata->{$rev} ne '') {
+ $pop = ' title="' . esc_html($revdata->{$rev}) . '"';
+ }
+
+ for (@line) {
+ my ($lineno, $data) = @$_;
+ $cnt++;
+ print "<tr class=\"$color\">\n";
+ if ($cnt == 1) {
+ print "<td class=\"sha1\"$pop";
+ if ($line > 1) {
+ print " rowspan=\"$line\"";
+ }
+ print ">";
+ print $cgi->a({-href => href(action=>"commit",
+ hash=>$rev,
+ file_name=>$name)},
+ $label);
+ print "</td>\n";
+ }
+ print "<td class=\"linenr\">".
+ "<a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
+ esc_html($lineno) . "</a></td>\n";
+ print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
+ print "</tr>\n";
+ }
+}
+
sub git_blame2 {
my $fd;
my $ftype;
@@ -2474,27 +2509,33 @@ sub git_blame2 {
<table class="blame">
<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
+ my @chunk = ();
+ my %revdata = ();
while (<$fd>) {
/^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
- my $full_rev = $1;
- my $rev = substr($full_rev, 0, 8);
- my $lineno = $2;
- my $data = $3;
-
+ my ($full_rev, $author, $date, $lineno, $data) =
+ /^([0-9a-f]{40}).*?\s\((.*?)\s+([-\d]+ [:\d]+ [-+\d]+)\s+(\d+)\)\s(.*)/;
+ if (!exists $revdata{$full_rev}) {
+ $revdata{$full_rev} = "$author, $date";
+ }
if (!defined $last_rev) {
$last_rev = $full_rev;
} elsif ($last_rev ne $full_rev) {
+ git_blame_flush_chunk($file_name,
+ \%revdata,
+ $rev_color[$current_color],
+ $last_rev, @chunk);
+ @chunk = ();
$last_rev = $full_rev;
$current_color = ++$current_color % $num_colors;
}
- print "<tr class=\"$rev_color[$current_color]\">\n";
- print "<td class=\"sha1\">" .
- $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
- esc_html($rev)) . "</td>\n";
- print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
- esc_html($lineno) . "</a></td>\n";
- print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
- print "</tr>\n";
+ push @chunk, [$lineno, $data];
+ }
+ if (@chunk) {
+ git_blame_flush_chunk($file_name,
+ \%revdata,
+ $rev_color[$current_color],
+ $last_rev, @chunk);
}
print "</table>\n";
print "</div>";
--
1.4.2.1.gc9fffe
^ permalink raw reply related
* Re: [PATCH 1/2] Move code resolving packed refs into its own function.
From: Junio C Hamano @ 2006-10-01 9:58 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200610010606.32561.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Junio C Hamano wrote:
>> Christian Couder <chriscool@tuxfamily.org> writes:
>> > This patch move Linus' packed refs resolving code from
>> > "resolve_ref" into a new "resolve_packed_ref" extern
>> > function so that it can be reused when needed.
>>
>> I think we are stepping on each other's toes. How far into the
>> process of making correct branch deletion are you?
>
> I am not farther than the 2 patches I sent yesterday (before going to bed).
Thanks. I just did not want to waste your work with overlapping
duplicated efforts.
I think what we have in "next" tonight is in a more-or-less
testable shape, although it has still a long way to reach
"master". Things I know we need to address:
- I've updated lock_ref_sha1_basic() to remove empty left-over
directories and to notice conflicts between 'foo/bar' vs
'foo' when creating a new ref, hopefully in the same spirit
as your patch to safe_create_leading_directories(), but done
differently (safe_... function is meant to be used anywhere
not just $GIT_DIR/refs/, and it felt wrong for it to take
exception for packed refs). We should do the same for the
reflog hierarchy but we currently don't.
- We need to audit our shell scripts to make sure they do not
depend on being able to look directly into $GIT_DIR/refs to
see if the ref they are interested in exists. I've fixed a
few in git-fetch while handling the patch to clean up its
output from Santi, but I would not be surprised if there are
more. The code in git-branch and git-tag to list what's
there are Ok; they use "rev-parse --symbolic --all/--tags".
- I think gitweb should be Ok; it does peek-remote on the
repository. Although we would probably want to update
git_get_references and git_get_refs_list sub to use
for-each-ref there, that can be done as a later optimization.
- Dumb transports are not aware of packed refs on the remote
side. The underlying commit walkers (anything that links
with fetch.c) needs their fetch_ref() implementation updated
to look at the packed-refs file from the remote side and we
should be fine after that. I haven't looked at rsync
transport but the change necessary there shouldn't be too
involved.
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Junio C Hamano @ 2006-10-01 10:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v7iztbldm.fsf@assigned-by-dhcp.cox.net>
I've tagged the tip of the master as v1.4.3-rc1 tonight, after
merging things that I listed in the message last week to be
merged from "next".
Have fun.
^ permalink raw reply
* pushing fails - WHY?
From: Alan Chandler @ 2006-10-01 10:38 UTC (permalink / raw)
To: git
I am just coming back to repeat the setting up of my public git repositories
after loosing them in a disk crash a little while ago.
The first repository I am setting up is called akclib on server roo.home
so in /var/lib/git on that machine I did
mkdir akclib.git
GIT_DIR akclib.git git init-db --shared
Back on my workstation where my master repository resides
~/dev/akcmoney
I have a .git/remotes/public file which contains
URL:roo.home:/var/lib/git/akclib.git
Push:master
BUT WHEN I attempt to push - thus
alan@kanger:~/dev/akclib[master]$ git push public
fatal: remote 'public' has no URL
It fails. But I don't understand why. Can someone point me at what I am doing
wrong.
(git is version 1.4.2.1 on the workstation, 1.4.1 on the server)
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* ANSWER
From: Alan Chandler @ 2006-10-01 11:53 UTC (permalink / raw)
To: git
In-Reply-To: <200610011138.06823.alan@chandlerfamily.org.uk>
On Sunday 01 October 2006 11:38, Alan Chandler wrote:
> I have a .git/remotes/public file which contains
>
> URL:roo.home:/var/lib/git/akclib.git
> Push:master
The URL: and Push: need spaces before the detail
This used to work, so somewhere along the line (when the builtin was
introduced?) the need for the space has arisen.
The documentation, although showing the space is not very clear about it.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* [PATCH 1/2] Fix a remove_empty_dir_recursive problem.
From: Christian Couder @ 2006-10-01 12:36 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
refs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 858c534..221eb38 100644
--- a/refs.c
+++ b/refs.c
@@ -498,7 +498,7 @@ static int remove_empty_dir_recursive(ch
strcpy(path + len, e->d_name) &&
!lstat(path, &st) &&
S_ISDIR(st.st_mode) &&
- remove_empty_dir_recursive(path, len + namlen))
+ !remove_empty_dir_recursive(path, len + namlen))
continue; /* happy */
/* path too long, stat fails, or non-directory still exists */
--
1.4.2.1.g7bc701-dirty
^ permalink raw reply related
* [PATCH 2/2] Clean up "git-branch.sh" and add remove recursive dir test cases.
From: Christian Couder @ 2006-10-01 12:38 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Now that directory recursive remove works in the core C code, we
don't need to do it in "git-branch.sh".
Also add test cases to check that directory recursive remove will
continue to work.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-branch.sh | 10 ----------
t/t3210-pack-refs.sh | 27 +++++++++++++++++++++++++++
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index bf84b30..4379a07 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -111,16 +111,6 @@ rev=$(git-rev-parse --verify "$head") ||
git-check-ref-format "heads/$branchname" ||
die "we do not like '$branchname' as a branch name."
-if [ -d "$GIT_DIR/refs/heads/$branchname" ]
-then
- for refdir in `cd "$GIT_DIR" && \
- find "refs/heads/$branchname" -type d | sort -r`
- do
- rmdir "$GIT_DIR/$refdir" || \
- die "Could not delete '$refdir', there may still be a ref there."
- done
-fi
-
prev=''
if git-show-ref --verify --quiet -- "refs/heads/$branchname"
then
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index 193fe1f..f31e79c 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -67,4 +67,31 @@ test_expect_success \
git-pack-refs &&
git-branch -d g'
+test_expect_failure \
+ 'git branch i/j/k should barf if branch i exists' \
+ 'git-branch i &&
+ git-pack-refs --prune &&
+ git-branch i/j/k'
+
+test_expect_success \
+ 'test git branch k after branch k/l/m and k/lm have been deleted' \
+ 'git-branch k/l &&
+ git-branch k/lm &&
+ git-branch -d k/l &&
+ git-branch k/l/m &&
+ git-branch -d k/l/m &&
+ git-branch -d k/lm &&
+ git-branch k'
+
+test_expect_success \
+ 'test git branch n after some branch deletion and pruning' \
+ 'git-branch n/o &&
+ git-branch n/op &&
+ git-branch -d n/o &&
+ git-branch n/o/p &&
+ git-branch -d n/op &&
+ git-pack-refs --prune &&
+ git-branch -d n/o/p &&
+ git-branch n'
+
test_done
--
1.4.2.1.g7bc701-dirty
^ permalink raw reply related
* [BUG] 'git mv a/fileA b/fileB' causes 'c/fileC' to be deleted
From: Michael Cassar @ 2006-10-01 14:21 UTC (permalink / raw)
To: git
Hi,
I'm new to git, so this may be user error, but I am getting some
strange behaviour using the 'git mv' command. In particular,
attempting to move a file from one directory to another (performing
a rename in the process) causes an unrelated third-party file to
be deleted after commit.
I have flicked through the git man pages and googled for git mv
related issues, but haven't come up with anything.
Here is a transcript. These results are reproducable using the same
files, but I can't seem to reproduce with different files.
## Create initial respository
[mike@simba ~] git version
git version 1.4.2.1
[mike@simba ~] mkdir repos; cd repos
[mike@simba ~/repos] git init-db
defaulting to local storage area
[mike@simba ~/repos] cp -r ~/thesis_work/* .
[mike@simba ~/repos] ls -a
. .. .git metathesis notes papers partA
[mike@simba ~/repos] git add metathesis notes papers partA
[mike@simba ~/repos] git commit -m 'initial import'
Committing initial tree 77d618ebc7c8e655c1d2f0e223e1957b6b5ff247
## Files that we are going to deal with. Note that 'outline.txt' is an
## innocent third party.
[mike@simba ~/repos] sha1sum partA/outline.txt
891256d20531ebc288f1abb5e23f9979597889d3 partA/outline.txt
[mike@simba ~/repos] sha1sum papers/unsorted/Thesis.pdf
52446ade19a067253e8407bf092b52e5efa35247 papers/unsorted/Thesis.pdf
## Move 'Thesis.pdf' to a new name, and commit
[mike@simba ~/repos] git mv papers/unsorted/Thesis.pdf
papers/all-papers/new-name.pdf
[mike@simba ~/repos] git commit -m 'moved a file'
## Have a look at what git just did. In particular, note that 'outline.txt'
## has magically appeared in the log
[mike@simba ~/repos] cg log -f | head
commit aa544a0d58118eb01fa6768e438fa0f521d6095b
tree 07c4971e3946b7c33742515e8915ec6e8abc4e40
parent 0d4292e44aa999707eddf31c4bbcadd711a170be
author mike <mike@simba.home> Sun, 01 Oct 2006 23:39:06 +1000
committer mike <mike@simba.home> Sun, 01 Oct 2006 23:39:06 +1000
* papers/all-papers/new-name.pdf, partA/outline.txt:
moved a file
## What changes are in the commit?
[mike@simba ~/repos] git show aa544a0d58118eb01fa6768e438fa0f521d6095b
| head -19
commit aa544a0d58118eb01fa6768e438fa0f521d6095b
Author: mike <mike@simba.home>
Date: Sun Oct 1 23:39:06 2006 +1000
moved a file
diff --git a/papers/all-papers/new-name.pdf b/papers/all-papers/new-name.pdf
new file mode 100644
index 0000000..5441543
Binary files /dev/null and b/papers/all-papers/new-name.pdf differ
diff --git a/partA/outline.txt b/partA/outline.txt
deleted file mode 100644
index d3ac280..0000000
--- a/partA/outline.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-
-Thesis Part A
-
[rest of file outline.txt deleted]
Is this just me being an idiot, or could there be a bigger problem
here?
Please CC me in any replies.
Cheers,
Mike
^ permalink raw reply related
* Re: [PATCH] gitweb: Add history and blame to git_difftree_body()
From: Jakub Narebski @ 2006-10-01 16:41 UTC (permalink / raw)
To: git
In-Reply-To: <20060928002449.64051.qmail@web31802.mail.mud.yahoo.com>
Luben Tuikov wrote:
> Add blame and history to Deleted files.
> Add blame and history to Modified or Type changed files.
> Add blame and history to Renamed or Copied files.
Blame has to be added conditionally (gitweb_have_blame).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Decode long title for link tooltips
From: Jakub Narebski @ 2006-10-01 16:45 UTC (permalink / raw)
To: git
In-Reply-To: <87zmcmroqf.wl@mail2.atmark-techno.com>
Yasushi SHOJI wrote:
> This is a simple one liner to decode long title string in perl's
> internal form to utf-8 for link tooltips.
>
> This is not crucial if the commit message is all in ASCII, however, if
> you decide to use other encoding, such as UTF-8, tooltips ain't
> readable any more.
Perhaps it would be better to abstract it away into esc_attr (as escape
attribute) subroutine, if such situation i.e. output of generated string
into some attribute of some element happens in some other place.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [BUG] 'git mv a/fileA b/fileB' causes 'c/fileC' to be deleted
From: Junio C Hamano @ 2006-10-01 17:34 UTC (permalink / raw)
To: Michael Cassar; +Cc: git
In-Reply-To: <750170aa0610010721p66899ba5pcc7efa13be4cd10a@mail.gmail.com>
"Michael Cassar" <m.e.cassar@gmail.com> writes:
> Is this just me being an idiot, or could there be a bigger problem
> here?
>
> Please CC me in any replies.
There could be a bigger problem, but it does not seem to easily
reproduce as you noted in the message. It could be that some
unrelated thing in the working tree is playing a role in this
breakage, but I do not think of offhand what that is.
Here is what I just ran.
-- >8 cut >8 --
#!/bin/sh
report () {
echo
echo "* $*"
echo
}
rm -fr test0
mkdir test0
cd test0
report working tree preparation
mkdir -p partA papers/unsorted papers/all-papers
echo outline >partA/outline.txt
echo Thesis >papers/unsorted/Thesis.pdf
report repository initialization
git init-db
report initial import
git add papers partA
git commit -m 'initial'
git show --root --stat --summary
report run mv
git mv papers/unsorted/Thesis.pdf papers/all-papers/Thesis.pdf
report before commit
git diff --stat HEAD
report make a commit
git commit -m 'moved a file'
report final result
git show --stat --summary
-- 8< cut 8< --
and I did not see the breakage. Care to show a bit more details
on your working tree? I do not think this depends on any
contents of the individual files, but
> Here is a transcript. These results are reproducable using the same
> files, but I can't seem to reproduce with different files.
>
> ## Create initial respository
>
> [mike@simba ~] git version
> git version 1.4.2.1
>
> [mike@simba ~] mkdir repos; cd repos
>
> [mike@simba ~/repos] git init-db
> defaulting to local storage area
>
> [mike@simba ~/repos] cp -r ~/thesis_work/* .
>
> [mike@simba ~/repos] ls -a
> . .. .git metathesis notes papers partA
>
> [mike@simba ~/repos] git add metathesis notes papers partA
output from "find metathesis notes papers partA -ls" and "git
ls-files -s" at this step may be a starter.
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Linus Torvalds @ 2006-10-01 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd59c2vev.fsf@assigned-by-dhcp.cox.net>
On Sun, 1 Oct 2006, Junio C Hamano wrote:
>
> I've tagged the tip of the master as v1.4.3-rc1 tonight, after
> merging things that I listed in the message last week to be
> merged from "next".
>
> Have fun.
I hate that perl crud.
...
make -C perl
make[1]: Entering directory `/home/torvalds/git/perl'
cp private-Error.pm blib/lib/Error.pm
cp Git.pm blib/lib/Git.pm
gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE" Git.c
In file included from Git.xs:8:
../cache.h:6:10: error: #include expects "FILENAME" or <FILENAME>
Git.xs: In function 'XS_Git_xs_version':
Git.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)
Git.xs:62: error: (Each undeclared identifier is reported only once
Git.xs:62: error: for each function it appears in.)
make[1]: *** [Git.o] Error 1
make[1]: Leaving directory `/home/torvalds/git/perl'
make: *** [all] Error 2
I don't like how git now doesn't compile just out of the box on a
perfectly regular FC5 box.
The whole Git.xs stuff has been buggered from the very beginning, at some
point somebody needs to just admit it.
Please?
And how come does this actually work for anybody else? I've got PPC_SHA1
defined, but I don't see what the difference is..
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-10-01 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7v64f9hku2.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Sep 2006, Junio C Hamano wrote:
> If the only objection is that it is harder to realize that the
> remaining one (the other one that did not get removed by this
> redundancy elimination) is clickable, maybe that is what needs
> to be fixed.
But that is plain impossible without compromising interface usability.
Let me explain.
In the case of tree view (directory listing) we have blobs (files and
symlinks) and trees (directories). To mark item unequivocably as link
it has to have default link color (blue) and default link decoration
(underline). That means that we cannot distinguish really well (at
least color) between tree and blob entries. I'd rather have redundant
"blob"/"tree" (self)links, clearly marked as links, and tree entries
using link decoration (blue, underlined) while blob entries have
default text decoration (black, no underline).
In the case of shortlog/log/history/heads/tags view, to clearly mark
subject/title of a commit or tag as link, we would have to use default
link decoration. Let's for a while abandon link-within-link, i.e. using
some of committags also in commit title (in shortlog/history view)...
But underlined text is harder to read, and blue underlined text even
more so (as for example it is hard to read italics, commonly used for
emphasis). I'd rather have additional "commit" link, clearly marked as
link, and leave subject as is, as hidden link, as a shortcut.
I think that redundancy in a visual interface (and not only visual, as
seen in the example of Perl programming language) is a good idea,
contrary to the redundancy in code or data (database).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Junio C Hamano @ 2006-10-01 18:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610011132040.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 1 Oct 2006, Junio C Hamano wrote:
>>
>> I've tagged the tip of the master as v1.4.3-rc1 tonight, after
>> merging things that I listed in the message last week to be
>> merged from "next".
>>
>> Have fun.
>
> I hate that perl crud.
>...
> Git.xs: In function 'XS_Git_xs_version':
> Git.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)
> Git.xs:62: error: (Each undeclared identifier is reported only once
> Git.xs:62: error: for each function it appears in.)
> make[1]: *** [Git.o] Error 1
> make[1]: Leaving directory `/home/torvalds/git/perl'
> make: *** [all] Error 2
>
> I don't like how git now doesn't compile just out of the box on a
> perfectly regular FC5 box.
Everybody hated the perl crud, so we removed Git.xs and is not
even part of the source anymore.
This is a symptom that Git.c leftover from an earlier build was
in the working tree. Could you try running "rm -f perl/Git.c"
before building and see if it helps?
The sad thing is that we do not ship Git.xs nor generate Git.c
from our Makefile, and while it is nicer to have an entry to
remove leftover perl/Git.c in our Makefile, it does not really
help in all cases. We discussed this exact issue a few days
ago:
http://thread.gmane.org/gmane.comp.version-control.git/27730/focus=27853
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-10-01 18:49 UTC (permalink / raw)
To: git
In-Reply-To: <7v3baekp5p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
>> where Jakub Narebski <jnareb@gmail.com> said that...
>>> I'd rather not. The fact that the file name and tree name is link,
>>> and the fact that commit title and tag title is link is a _convenience_.
>>> Not always it is visible (without mouseover) that it is link.
>>> And it is _not_ visible in the case of files!
>>
>> Then that should be fixed.
>>
>> And directories should have trailing slash in their name in the tree
>> listing, for people with non-UNIX background who don't understand the
>> ls -l like output.
>
> I am with you on both counts. For the latter, people might
> actually like mode string to be changed to pretty pictures,
> though.
And perhaps we could also use yet another decoration for symbolic links.
Perhaps different color? Perhaps 'ls -l' view, i.e. 'link -> target'?
But if we use different colors for tree entries and blob entries (and
perhaps yet another color for symbolic links), it is impossible to mark all
of them clearly as links. So I'd rather have redundancy, than hidden
functionality (BTW. I hate MS idea of vanishing menu entries based on
usage).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Johannes Schindelin @ 2006-10-01 18:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610011132040.3952@g5.osdl.org>
Hi,
On Sun, 1 Oct 2006, Linus Torvalds wrote:
> Git.xs: In function 'XS_Git_xs_version':
> Git.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)
> Git.xs:62: error: (Each undeclared identifier is reported only once
> Git.xs:62: error: for each function it appears in.)
We had that discussion in another thread already.
Just rm perl/{Git.{bs,c},Makefile} and remake.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Junio C Hamano @ 2006-10-01 18:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610012041.15296.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> ... That means that we cannot distinguish really well (at
> least color) between tree and blob entries.
Do we even say links are blue and underlined by forcing that in
our css?
Doesn't leading drwxr-xr-x mean anything?
Why is making the distinction important in the first place?
> In the case of shortlog/log/history/heads/tags view, to clearly mark
> subject/title of a commit or tag as link, we would have to use default
> link decoration....
> But underlined text is harder to read, and blue underlined text even
> more so...
This is something in which I can see some more sense than tree
vs blob issue, but only as a principle issue. In practice, the
list of commit subjects is the first thing users encounter, and
as long as there is some visual indication (e.g. mousing over it
makes it obvious it is something that is clickable), I think
users will quickly pick up that it will lead to the commit's
detail.
^ permalink raw reply
* Multiple checkouts of the same repository
From: Matt McCutchen @ 2006-10-01 19:03 UTC (permalink / raw)
To: git
Dear git people,
Maybe this is common knowledge, but I thought I should mention it in
case it isn't. I had a git repository in a directory A and I wanted
to check out a branch of the repository to a different directory B.
So I created B/.git and filled it with symlinks pointing to the files
in A/.git, except for index and HEAD because those need to be
different for each checkout; then I ran git-checkout <branch> to fill
B. Now I can view and edit each checkout independently, but they are
backed by the same set of objects and refs. However, I must remember
to commit to each branch only through the checkout whose HEAD is
linked to it, otherwise that checkout won't get updated.
Matt
^ permalink raw reply
* Re: Multiple checkouts of the same repository
From: Johannes Schindelin @ 2006-10-01 19:08 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <3bbc18d20610011203p40d631b7o3bd2c6971a2bfcca@mail.gmail.com>
Hi,
On Sun, 1 Oct 2006, Matt McCutchen wrote:
> Maybe this is common knowledge, but I thought I should mention it in
> case it isn't. I had a git repository in a directory A and I wanted
> to check out a branch of the repository to a different directory B.
> So I created B/.git and filled it with symlinks pointing to the files
> in A/.git, except for index and HEAD because those need to be
> different for each checkout;
A better method is to use a local clone:
git-clone --local --shared A B
Such a clone will be very fast, and cheap, because it sets up links (not
just symbolic links, but links that git understands).
Hth,
Dscho
^ 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