* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-18 13:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Catalin Marinas wrote:
>>
>>If I uderstand correctly you never commit patches from StGIT stack directly
>>in your base git repository, in this example git HEAD, but you always round
>>trip to MAIN.
>
When I say 'you always round trip to MAIN', I mean you send patches
upstream and someone commits to MAIN, then you pull from MAIN.
Sorry if it was not clear.
>
>One usually doesn't maintain MAIN. That's an example for the Linux
>kernel development where you can't control what get merged into MAIN.
>
>There is a bit of confusion here since you said in a previous e-mail
>that more people can commit to the stable branch. In this case, you
>would need a separate repository for stable with a maintainer pulling
>changes from others.
>
When I said 'more people can commit to the stable branch' I meant more
people sends patches to a mantainer that commits the patches in a stable branch.
Sorry, peraphs also this was not clearly expressed.
>>Then you don't have two git repository: HEAD and MAIN
>>
>>Infact there is only one git repository, MAIN, cloned on your box
>>and called HEAD and with a StGIT stack added on top.
>
>
>The StGIT usage idea is that you only know what patches you have on
>top of a main repository. Since you expect your patches to be merged
>upstream or just updated every time the main repository changes, it
>might not make sense to commit the patches onto the base.
>
Yes, you better explained what I was badly trying to say before.
>
>I need a bit more clarification about your work flow.
>
I was thinking at two different kind of workflow, one were you are tracking a
remote repository ( Linux kernel project like ) and one as single developer with
both stable and develop lines ( qgit or StGIT ;-) projects like ).
You clarified me for both cases.
Thanks
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Catalin Marinas @ 2005-08-18 11:16 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050818100023.80893.qmail@web26310.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> wrote:
> Catalin Marinas wrote:
>>That's how you would normally do development on Linux using StGIT -
>>clone the mainline kernel, create patches in your StGIT tree and submit
>>them either via e-mail or ask the gatekeeper to pull directly from your
>>tree (assuming that you only push those patches that need to be merged).
>>Doing a 'stg pull' would retrieve the latest changes from the mainline
>>kernel (including the changes made by your patches which were merged
>>upstream).
>
> If I uderstand correctly you never commit patches from StGIT stack directly
> in your base git repository, in this example git HEAD, but you always round
> trip to MAIN.
One usually doesn't maintain MAIN. That's an example for the Linux
kernel development where you can't control what get merged into MAIN.
There is a bit of confusion here since you said in a previous e-mail
that more people can commit to the stable branch. In this case, you
would need a separate repository for stable with a maintainer pulling
changes from others.
> Then you don't have two git repository: HEAD and MAIN
>
> Infact there is only one git repository, MAIN, cloned on your box
> and called HEAD and with a StGIT stack added on top.
The StGIT usage idea is that you only know what patches you have on
top of a main repository. Since you expect your patches to be merged
upstream or just updated every time the main repository changes, it
might not make sense to commit the patches onto the base.
If you want to keep a stable branch (and only you comitting to it), I
would recommend having separate branches for stable and development in
the same tree (and avoid having separate trees) rather than directly
modifying the base. StGIT doesn't support this directly (didn't think
anyone would ask) but you can do the following steps:
1. Use 'stg clone <remote repository>' to create the initial
clone. The 'master' branch will be used for development. You can
use 'git-init-db' and 'stg init' if you don't follow a remote
repository
2. 'git checkout -b stable' will create the stable branch. This will
initially be the same as the master one since there are not patches
applied to the master stack
3. switch back to the devel branch with 'git checkout master' and do
the normal StGIT development (create patches, commit them etc.). If
you are tracking a remote respository, you could pull the latest
changes with 'stg pull'
4. Once you have a set of patches applied and your stack is stable
(some patches can be unapplied, they don't affect the head of the
development branch), you can switch to the stable branch with 'stg
checkout stable' and merge the changes in master with
'git-resolve-script'.
I think it might make more sense to simply do a 'cp
.git/refs/heads/master .git/refs/heads/stable' instead of the
previous paragraph since the stable branch doesn't have additional
data from what's in master. The remote repository tracking is done
via master.
5. You can advance the base of the stack to what's in stable with an
'stg pull stable' but it's not clear for me whether this makes any
sense since you lose the StGIT patches already added to stable and
you will might later get conflicts when pulling the changes from
the remote repository you are tracking.
For the 2, 3 and 4 steps above I will add a 'snapshot' command to
StGIT but I'm not sure why one would want step 5 since this would mean
that the devel branch needs to track both the remote repository and
the stable branch.
Some questions: do you track a remote repository? Do you need a stable
repository or branch where more people can update? If you track the
remote repository, do you want the latest remote changes merged into
the stable branch directly (i.e. is the stable branch tracking the
remote repository)?
I need a bit more clarification about your work flow.
--
Catalin
^ permalink raw reply
* Re: [PATCH/RFC] Allow file removal when "git commit --all" is used.
From: Johannes Schindelin @ 2005-08-18 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64u3k74m.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 18 Aug 2005, Junio C Hamano wrote:
> After you deleted files from your working tree, automatic
> git-update-cache used when the "--all" flag is given to "git
> commit" barfs because it lacks the --remove flag.
>
> It can be argued that this is a feature; people should be
> careful and something with a grave consequence like removing
> files should be done manually, in which case the current
> behaviour may be OK.
>
> The patch is for people who thinks the user who uses the "--all"
> flag deserves the danger that comes with the convenience.
>
> Comments?
This is a sane default behaviour. Maybe introduce yet another flag
"--no-remove", which says that removes should not be performed? But then,
"--all" is mostly used by lazy people, who probably expect the removes to
take place.
Ciao,
Dscho
^ permalink raw reply
* Re: Multi-head pulling series
From: Josef Weidendorfer @ 2005-08-18 10:45 UTC (permalink / raw)
To: git
In-Reply-To: <7vek8rlnbn.fsf@assigned-by-dhcp.cox.net>
On Thursday 18 August 2005 09:24, Junio C Hamano wrote:
> $ cat $GIT_DIR/remotes/www
> URL: http://www.kernel.org/pub/scm/git/git.git/
> Pull: master:ko-master pu:ko-pu
> Push: master:master pu:pu foo:bar
Isn't this mixing two kinds of information:
1) Some default/persistent mapping of local to remote heads
2) The default heads which are pulled/pushed when only giving the remote, like
in:
> $ git push mko ;# push our master and pu to the same
> # name, foo to .git/refs/heads/bar.
I think it makes sense to be able to store mappings without adding the head to
the default group of heads pulled.
Can we put the default pull/push actions in separate lines, like
$ cat $GIT_DIR/remotes/mko
URL: master.kernel.org:/pub/scm/git/git.git/
Pull: master:ko-master pu:ko-pu mylocal:myremote
Push: master:master pu:pu foo:bar
Default-Pull: master pu
Default-Push: master pu foo
> $ git push mko pu:refs/heads/testing
> # instead of pushing to the usual ref,
> # push our pu to refs/heads/testing,
> # this time only.
With a command (push/fetch/pull) giving an explicit local/remote mapping, it
would be cool to automatically add the given mapping to the remotes/ file if
there is no push-mapping for pu yet, so that you can have the same later with
only
git push mko pu
And finally, it would be nice to specify a default mapping for arbitrary heads
$ cat $GIT_DIR/remotes/www
URL: http://www.kernel.org/pub/scm/git/git.git/
Pull: www#*:*
Such that
git fetch www#pu
will fetch head pu into local head .refs/heads/www#pu
Josef
PS: I know I should provide patches for my proposals. But let discuss them
first.
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: David Kågedal @ 2005-08-18 10:32 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0508171253190.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 17 Aug 2005, Jeff Garzik wrote:
>>
>> 1) Fix applymbox such that it understands RFC822-valid Subject lines
>> which wrap across multiple text lines.
>
> It already should do this.
>
>> 2) Teach it to understand MIME, and not treat the MIME headers like part
>> of the message.
>
> But this one I really realyl disagree with.
>
> The fact is, anybody who doesn't edit the emails that come in is BROKEN.
> There are two kinds of emails:
>
> - the nicely formatted ones where the author follows all the rules
>
> This kind of email doesn't need MIME decoding anyway.
Unless they want to write something that doesn't fit in ASCII, as
discussed in another thread here.
But maybe you are only talking about MIME attachments, and not about
MIME content encodings? We probably need to separate the two.
Note that I'm not really talking about your patch handling for Linux;
you are free to disallow my name in Linux patches if you want to. But
I'd like to see a way to get rid of that limitation for other uses of
git.
--
David Kågedal
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Catalin Marinas @ 2005-08-18 10:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git
In-Reply-To: <Pine.LNX.4.63.0508172336280.17758@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> maybe it is time for a quick run through the typical jobs you do with
> StGIT, much like what Jeff sent the other day?
I hope I will find some time this weekend and write some tutorials on
an StGIT wiki.
--
Catalin
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-18 10:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Catalin Marinas wrote:
>
>The base of the StGIT stack in the HEAD repository (branch) should
>always be the head of the MAIN repository.
That's the point I missed, now it's more clear.
>
>That's how you would normally do development on Linux using StGIT -
>clone the mainline kernel, create patches in your StGIT tree and submit
>them either via e-mail or ask the gatekeeper to pull directly from your
>tree (assuming that you only push those patches that need to be merged).
>Doing a 'stg pull' would retrieve the latest changes from the mainline
>kernel (including the changes made by your patches which were merged
>upstream).
>
If I uderstand correctly you never commit patches from StGIT stack directly
in your base git repository, in this example git HEAD, but you always round
trip to MAIN.
Then you don't have two git repository: HEAD and MAIN
Infact there is only one git repository, MAIN, cloned on your box and called HEAD and
with a StGIT stack added on top.
>
>Please let me know if this needs further clarification.
>
I think so.
Please, reading my notes above tell me if I thinking right ;-)
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Small team cogito/git setup
From: Matthias Urlichs @ 2005-08-18 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f9050817211446684aac@mail.gmail.com>
Hi, Martin Langhoff wrote:
> Or are we forced to run an 'integration' repo so that we work with a
> 'star' arrangement? I am actually trying to avoid needing a central
> repo if possible.
Personally, I like the idea of an integration repository. The main reason
is that it avoids duplicate work and shifting blame for broken software,
particularly if you have a test suite.
My workflow is "develop, test, check-in, pull-and-merge, test-if-merged,
push". That tends to yield a saner change history, and requires less work,
than doing it for every co-worker.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"Fundamentalists are like the fir trees in German forests: they cannot
stand alone, and are only stable when crowded together, branches locked
with those of their brothers. That is why we must always fear them,
because they will always hate us for our individualism."
[Brent Yaciw, with inspirational regards to Jack M. Bickham]
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Matthias Urlichs @ 2005-08-18 9:27 UTC (permalink / raw)
To: git
In-Reply-To: <200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl>
Hi, Horst von Brand wrote:
> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.
Ummm... why?
make's SCCS support depends on the presence of a SCCS/s.<name> file
for each <name>. We don't have that. Teaching make about git would be
equivalent to teaching it about parsing the index file.
Technically, that would require a stable libgit.so or so.
In reality, however, I don't know when I last had a tree which wasn't
fully populated, but it's been a while, and it's something that can be
readily fixed by "git-checkout-cache -a".
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.
^ permalink raw reply
* [PATCH/RFC] Allow file removal when "git commit --all" is used.
From: Junio C Hamano @ 2005-08-18 7:59 UTC (permalink / raw)
To: git
After you deleted files from your working tree, automatic
git-update-cache used when the "--all" flag is given to "git
commit" barfs because it lacks the --remove flag.
It can be argued that this is a feature; people should be
careful and something with a grave consequence like removing
files should be done manually, in which case the current
behaviour may be OK.
The patch is for people who thinks the user who uses the "--all"
flag deserves the danger that comes with the convenience.
Comments?
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -88,13 +88,13 @@ esac
case "$all,$#" in
t,*)
git-diff-files --name-only -z |
- xargs -0 git-update-cache -q --
+ xargs -0 git-update-cache -q --remove --
;;
,0)
;;
*)
git-diff-files --name-only -z "$@" |
- xargs -0 git-update-cache -q --
+ xargs -0 git-update-cache -q --remove --
;;
esac || exit 1
git-update-cache -q --refresh || exit 1
^ permalink raw reply
* [PATCH 1/3] Start adding the $GIT_DIR/remotes/ support.
From: Junio C Hamano @ 2005-08-18 7:39 UTC (permalink / raw)
To: GIT mailing list; +Cc: Junio C Hamano
In-Reply-To: <7vek8rlnbn.fsf@assigned-by-dhcp.cox.net>
All the necessary parsing code is in git-parse-remote-script;
update git-push-script to use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 -
git-parse-remote-script | 122 +++++++++++++++++++++++++++++++++++++++++++++++
git-push-script | 28 ++---------
3 files changed, 129 insertions(+), 23 deletions(-)
create mode 100755 git-parse-remote-script
f8892bf17675056cd18a252d3bc4e4ba381fb3bc
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -64,7 +64,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-reset-script git-add-script git-checkout-script git-clone-script \
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
- git-branch-script git-parse-remote git-verify-tag-script \
+ git-branch-script git-parse-remote git-parse-remote-script git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
git-request-pull-script git-bisect-script
diff --git a/git-parse-remote-script b/git-parse-remote-script
new file mode 100755
--- /dev/null
+++ b/git-parse-remote-script
@@ -0,0 +1,122 @@
+#!/bin/sh
+
+. git-sh-setup-script || die "Not a git archive"
+
+get_data_source () {
+ case "$1" in
+ */*)
+ # Not so fast. This could be the partial URL shorthand...
+ token=$(expr "$1" : '\([^/]*\)/')
+ remainder=$(expr "$1" : '[^/]*/\(.*\)')
+ if test -f "$GIT_DIR/branches/$token"
+ then
+ echo branches-partial
+ else
+ echo ''
+ fi
+ ;;
+ *)
+ if test -f "$GIT_DIR/remotes/$1"
+ then
+ echo remotes
+ elif test -f "$GIT_DIR/branches/$1"
+ then
+ echo branches
+ else
+ echo ''
+ fi ;;
+ esac
+}
+
+get_remote_url () {
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '')
+ echo "$1" ;;
+ remotes)
+ sed -ne '/^URL: */{
+ s///p
+ q
+ }' "$GIT_DIR/remotes/$1" ;;
+ branches)
+ sed -e 's/#.*//' "$GIT_DIR/branches/$1" ;;
+ branches-partial)
+ token=$(expr "$1" : '\([^/]*\)/')
+ remainder=$(expr "$1" : '[^/]*/\(.*\)')
+ url=$(sed -e 's/#.*//' "$GIT_DIR/branches/$token")
+ echo "$url/$remainder"
+ ;;
+ *)
+ die "internal error: get-remote-url $1" ;;
+ esac
+}
+
+get_remote_default_refs_for_push () {
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '' | branches | branches-partial)
+ ;; # no default push mapping, just send matching refs.
+ remotes)
+ sed -ne '/^Push: */{
+ s///p
+ }' "$GIT_DIR/remotes/$1" ;;
+ *)
+ die "internal error: get-remote-default-ref-for-push $1" ;;
+ esac
+}
+
+# Subroutine to caninicalize remote:local notation
+canon_refs_list_for_fetch () {
+ for ref
+ do
+ expr "$ref" : '.*:' >/dev/null || ref="${ref}:"
+ remote=$(expr "$ref" : '\([^:]*\):')
+ local=$(expr "$ref" : '[^:]*:\(.*\)')
+ case "$remote" in
+ '') remote=HEAD ;;
+ *) remote="refs/heads/$remote" ;;
+ esac
+ case "$local" in
+ '') local= ;;
+ *) local="refs/heads/$local" ;;
+ esac
+ echo "${remote}:${local}"
+ done
+}
+
+# Returns list of src: (no store), or src:dst (store)
+get_remote_default_refs_for_fetch () {
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '' | branches-partial)
+ echo "HEAD:" ;;
+ branches)
+ remote_branch=$(sed -ne '/#/s/.*#//p' "$GIT_DIR/branches/$1")
+ case "$remote_branch" in '') remote_branch=master ;; esac
+ echo "refs/heads/${remote_branch}:refs/heads/$1"
+ ;;
+ remotes)
+ canon_refs_list_for_fetch $(sed -ne '/^Pull: */{
+ s///p
+ }' "$GIT_DIR/remotes/$1")
+ ;;
+ *)
+ die "internal error: get-remote-default-ref-for-push $1" ;;
+ esac
+}
+
+get_remote_refs_for_push () {
+ case "$#" in
+ 0) die "internal error: get-remote-refs-for-push." ;;
+ 1) get_remote_default_refs_for_push "$@" ;;
+ *) shift; echo "$@" ;;
+ esac
+}
+
+get_remote_refs_for_fetch () {
+ case "$#" in
+ 0) die "internal error: get-remote-refs-for-fetch." ;;
+ 1) get_remote_default_refs_for_fetch "$@" ;;
+ *) shift; canon_refs_list_for_fetch "$@" ;;
+ esac
+}
diff --git a/git-push-script b/git-push-script
--- a/git-push-script
+++ b/git-push-script
@@ -20,8 +20,6 @@ do
-*)
die "Unknown parameter $1" ;;
*)
- remote="$1"
- shift
set x "$@"
shift
break ;;
@@ -29,27 +27,13 @@ do
shift
done
-case "$remote" in
-*:* | /* | ../* | ./* )
- # An URL, host:/path/to/git, absolute and relative paths.
- ;;
-* )
- # Shorthand
- if expr "$remote" : '..*/..*' >/dev/null
- then
- # a short-hand followed by a trailing path
- shorthand=$(expr "$remote" : '\([^/]*\)')
- remainder=$(expr "$remote" : '[^/]*\(/.*\)$')
- else
- shorthand="$remote"
- remainder=
- fi
- remote=$(sed -e 's/#.*//' "$GIT_DIR/branches/$remote") &&
- expr "$remote" : '..*:' >/dev/null &&
- remote="$remote$remainder" ||
- die "Cannot parse remote $remote"
- ;;
+. git-parse-remote-script
+remote=$(get_remote_url "$@")
+case "$has_all" in
+--all) set x ;;
+'') set x $(get_remote_refs_for_push "$@") ;;
esac
+shift
case "$remote" in
http://* | https://* | git://* | rsync://* )
^ permalink raw reply
* [PATCH 3/3] Update git-pull to match updated git-fetch.
From: Junio C Hamano @ 2005-08-18 7:39 UTC (permalink / raw)
To: GIT mailing list; +Cc: Junio C Hamano
In-Reply-To: <7vek8rlnbn.fsf@assigned-by-dhcp.cox.net>
This retires the git-parse-remote script, and allows pull to fetch
from multiple remote references. There is no support for resolving
more than two heads, so that would be next.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +
git-parse-remote | 79 ------------------------------------------------------
git-pull-script | 14 ++++++----
3 files changed, 10 insertions(+), 85 deletions(-)
delete mode 100755 git-parse-remote
3a071a02828c71bbfdc2749d25814906cd9c8b18
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -64,7 +64,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-reset-script git-add-script git-checkout-script git-clone-script \
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
- git-branch-script git-parse-remote git-parse-remote-script git-verify-tag-script \
+ git-branch-script git-parse-remote-script git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
git-request-pull-script git-bisect-script
diff --git a/git-parse-remote b/git-parse-remote
deleted file mode 100755
--- a/git-parse-remote
+++ /dev/null
@@ -1,79 +0,0 @@
-: To be included in git-pull and git-fetch scripts.
-
-# A remote repository can be specified on the command line
-# in one of the following formats:
-#
-# <repo>
-# <repo> <head>
-# <repo> tag <tag>
-#
-# where <repo> could be one of:
-#
-# a URL (including absolute or local pathname)
-# a short-hand
-# a short-hand followed by a trailing path
-#
-# A short-hand <name> has a corresponding file $GIT_DIR/branches/<name>,
-# whose contents is a URL, possibly followed by a URL fragment #<head>
-# to name the default branch on the remote side to fetch from.
-
-_remote_repo= _remote_store= _remote_head= _remote_name=
-
-case "$1" in
-*:* | /* | ../* | ./* )
- _remote_repo="$1"
- ;;
-* )
- # otherwise, it is a short hand.
- case "$1" in
- */*)
- # a short-hand followed by a trailing path
- _token=$(expr "$1" : '\([^/]*\)/')
- _rest=$(expr "$1" : '[^/]*\(/.*\)$')
- ;;
- *)
- _token="$1"
- _rest=
- _remote_store="refs/heads/$_token"
- ;;
- esac
- test -f "$GIT_DIR/branches/$_token" ||
- die "No such remote branch: $_token"
-
- _remote_repo=$(cat "$GIT_DIR/branches/$_token")"$_rest"
- ;;
-esac
-
-case "$_remote_repo" in
-*"#"*)
- _remote_head=`expr "$_remote_repo" : '.*#\(.*\)$'`
- _remote_repo=`expr "$_remote_repo" : '\(.*\)#'`
- ;;
-esac
-
-_remote_name=$(echo "$_remote_repo" | sed 's|\.git/*$||')
-
-case "$2" in
-tag)
- _remote_name="tag '$3' of $_remote_name"
- _remote_head="refs/tags/$3"
- _remote_store="$_remote_head"
- ;;
-?*)
- # command line specified a head explicitly; do not
- # store the fetched head as a branch head.
- _remote_name="head '$2' of $_remote_name"
- _remote_head="refs/heads/$2"
- _remote_store=''
- ;;
-'')
- case "$_remote_head" in
- '')
- _remote_head=HEAD ;;
- *)
- _remote_name="head '$_remote_head' of $_remote_name"
- _remote_head="refs/heads/$_remote_head"
- ;;
- esac
- ;;
-esac
diff --git a/git-pull-script b/git-pull-script
--- a/git-pull-script
+++ b/git-pull-script
@@ -1,12 +1,16 @@
#!/bin/sh
#
. git-sh-setup-script || die "Not a git archive"
-. git-parse-remote "$@"
-merge_name="$_remote_name"
-
git-fetch-script "$@" || exit 1
+merge_head=$(sed -e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ')
+merge_name=$(sed -e 's/^[0-9a-f]* //' "$GIT_DIR"/FETCH_HEAD |
+ tr '\012' ' ')
+
+case "$merge_head" in
+'' | *' '?*) die "Cannot resolve multiple heads at the same time (yet)." ;;
+esac
+
git-resolve-script \
"$(cat "$GIT_DIR"/HEAD)" \
- "$(cat "$GIT_DIR"/FETCH_HEAD)" \
- "Merge $merge_name"
+ $merge_head "Merge $merge_name"
^ permalink raw reply
* [PATCH 2/3] Multi-head fetch.
From: Junio C Hamano @ 2005-08-18 7:39 UTC (permalink / raw)
To: GIT mailing list; +Cc: Junio C Hamano
In-Reply-To: <7vek8rlnbn.fsf@assigned-by-dhcp.cox.net>
Traditionally, fetch takes these forms:
$ git fetch <remote>
$ git fetch <remote> <head>
$ git fetch <remote> tag <tag>
This patch updates it to take
$ git fetch <remote> <refspec>...
where:
- A <refspec> of form "<src>:<dst>" is to fetch the objects
needed for the remote ref that matches <src>, and if <dst>
is not empty, store it as a local <dst>.
- "tag" followed by <next> is just an old way of saying
"refs/tags/<next>:refs/tags/<next>"; this mimics the
current behaviour of the third form above and means "fetch
that tag and store it under the same name".
- A single token <refspec> without colon is a shorthand for
"<refspec>:" That is, "fetch that ref but do not store
anywhere".
- when there is no <refspec> specified
- if <remote> is the name of a file under $GIT_DIR/remotes/
(i.e. a new-style shorthand), then it is the same as giving
the <refspec>s listed on Pull: line in that file.
- if <remote> is the name of a file under $GIT_DIR/branches/
(i.e. an old-style shorthand, without trailing path), then it
is the same as giving a single <refspec>
"<remote-name>:refs/heads/<remote>" on the command line, where
<remote-name> is the remote branch name (defaults to HEAD, but
can be overridden by .git/branches/<remote> file having the
URL fragment notation). That is, "fetch that branch head and
store it in refs/heads/<remote>".
- otherwise, it is the same as giving a single <refspec>
that is "HEAD:".
The SHA1 object names of fetched refs are stored in FETCH_HEAD,
one name per line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-fetch-script | 154 ++++++++++++++++++++++++++++++++++++++----------------
1 files changed, 108 insertions(+), 46 deletions(-)
7dbfeb149dfc049015f27f15dd9135fd15d5f99f
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -1,54 +1,116 @@
#!/bin/sh
#
. git-sh-setup-script || die "Not a git archive"
-. git-parse-remote "$@"
-merge_repo="$_remote_repo"
-merge_head="$_remote_head"
-merge_store="$_remote_store"
-
-TMP_HEAD="$GIT_DIR/TMP_HEAD"
-
-case "$merge_repo" in
-http://* | https://*)
- if [ -n "$GIT_SSL_NO_VERIFY" ]; then
- curl_extra_args="-k"
- fi
- _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]' &&
- _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40" &&
- head=$(curl -nsf $curl_extra_args "$merge_repo/$merge_head") &&
- expr "$head" : "$_x40\$" >/dev/null || {
- echo >&2 "Failed to fetch $merge_head from $merge_repo"
- exit 1
- }
- echo Fetching "$merge_head" using http
- git-http-pull -v -a "$head" "$merge_repo/" || exit
- ;;
-rsync://*)
- rsync -L "$merge_repo/$merge_head" "$TMP_HEAD" || exit 1
- head=$(git-rev-parse TMP_HEAD)
- rm -f "$TMP_HEAD"
- rsync -avz --ignore-existing "$merge_repo/objects/" "$GIT_OBJECT_DIRECTORY/"
- ;;
-*)
- head=$(git-fetch-pack "$merge_repo" "$merge_head")
- if h=`expr "$head" : '\([^ ][^ ]*\) '`
+. git-parse-remote-script
+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+
+remote_nick="$1"
+remote=$(get_remote_url "$@")
+refs=
+rref=
+prev_was_literal_tag=
+rsync_slurped_objects=
+: >$GIT_DIR/FETCH_HEAD
+
+fast_forward_local () {
+
+ # NEEDSWORK: probably use the same cmpxchg protocol here...
+ echo "$2" >"$GIT_DIR/$1.lock"
+ if test -f "$GIT_DIR/$1"
then
- head=$h
+ local=$(git-rev-parse --verify "$1^0") &&
+ mb=$(git-merge-base "$local" "$2") &&
+ test "$mb" = "$local" || {
+ rm -f "$GIT_DIR/$1.lock"
+ die "$1 does not fast forward to $4 from $3.";
+ }
fi
- ;;
-esac || exit 1
-
-git-rev-parse --verify "$head" > /dev/null || exit 1
+ mv "$GIT_DIR/$1.lock" "$GIT_DIR/$1"
+}
-case "$merge_store" in
-'')
- ;;
-*)
- echo "$head" > "$GIT_DIR/$merge_store"
-esac &&
+for ref in $(get_remote_refs_for_fetch "$@")
+do
+ if test "$prev_was_literal_tag"
+ then
+ ref="refs/tags/${ref}:refs/tags/${ref}"
+ prev_was_literal_tag=
+ else
+ case "$ref" in
+ tag)
+ prev_was_literal_tag=yes
+ continue
+ ;;
+ esac
+ fi
-# FETCH_HEAD is fed to git-resolve-script which will eventually be
-# passed to git-commit-tree as one of the parents. Make sure we do
-# not give a tag object ID.
+ refs="$refs $ref"
-git-rev-parse "$head^0" >"$GIT_DIR/FETCH_HEAD"
+ # These are relative path from $GIT_DIR, typically starting at refs/
+ # but may be HEAD
+ remote_name=$(expr "$ref" : '\([^:]*\):')
+ local_name=$(expr "$ref" : '[^:]*:\(.*\)')
+
+ rref="$rref $remote_name"
+
+ # There are transports that can fetch only one head at a time...
+ case "$remote" in
+ http://* | https://*)
+ if [ -n "$GIT_SSL_NO_VERIFY" ]; then
+ curl_extra_args="-k"
+ fi
+ head=$(curl -nsf $curl_extra_args "$remote/$remote_name") &&
+ expr "$head" : "$_x40\$" >/dev/null ||
+ die "Failed to fetch $remote_name from $remote"
+ echo Fetching "$remote_name from $remote" using http
+ git-http-pull -v -a "$head" "$remote/" || exit
+ ;;
+ rsync://*)
+ TMP_HEAD="$GIT_DIR/TMP_HEAD"
+ rsync -L "$remote/$remote_name" "$TMP_HEAD" || exit 1
+ head=$(git-rev-parse TMP_HEAD)
+ rm -f "$TMP_HEAD"
+ test "$rsync_slurped_objects" || {
+ rsync -avz --ignore-existing "$remote/objects/" \
+ "$GIT_OBJECT_DIRECTORY/" || exit
+ rsync_slurped_objects=t
+ }
+ ;;
+ *)
+ # We will do git native transport at one go.
+ continue ;;
+ esac
+ head=$(git-rev-parse --verify "$head^0") || exit
+ echo "$head $remote_name from $remote_nick" >>$GIT_DIR/FETCH_HEAD
+ case "$local_name" in '') continue ;; esac
+
+ # We are storing the head locally. Make sure that it is
+ # a fast forward (aka "reverse push").
+ fast_forward_local "$local_name" "$head" "$remote" "$remote_name"
+
+done
+
+case "$remote" in
+http://* | https://* | rsync://* )
+ ;; # we are already done.
+*)
+ git-fetch-pack "$remote" $rref |
+ while read sha1 remote_name
+ do
+ found=
+ for ref in $refs
+ do
+ case "$ref" in
+ $remote_name:*)
+ found="$ref"
+ break ;;
+ esac
+ done
+ head=$(git-rev-parse --verify "$sha1^0") || exit
+ echo "$head $remote_name from $remote_nick" >>$GIT_DIR/FETCH_HEAD
+ case "$found" in '' | *:) continue ;; esac
+ local=$(expr "$found" : '[^:]*:\(.*\)')
+ fast_forward_local "$local" "$sha1" "$remote" "$remote_name"
+ done
+ ;;
+esac
^ permalink raw reply
* Multi-head pulling series
From: Junio C Hamano @ 2005-08-18 7:24 UTC (permalink / raw)
To: git
Here is the current status of the multi-head download support.
[PATCH 1/3] Start adding the $GIT_DIR/remotes/ support.
[PATCH 2/3] Multi-head fetch.
[PATCH 3/3] Update git-pull to match updated git-fetch.
The first one in the series adds support for the long promised
$GIT_DIR/remotes/ files; they use the following format:
$ cat $GIT_DIR/remotes/www
URL: http://www.kernel.org/pub/scm/git/git.git/
Pull: master:ko-master pu:ko-pu
$ cat $GIT_DIR/remotes/mko
URL: master.kernel.org:/pub/scm/git/git.git/
Pull: master:ko-master pu:ko-pu
Push: master:master pu:pu foo:bar
The idea is that you should be able to say:
$ git push mko ;# push our master and pu to the same
# name, foo to .git/refs/heads/bar.
$ git push mko pu:refs/heads/testing
# instead of pushing to the usual ref,
# push our pu to refs/heads/testing,
# this time only.
$ git fetch www ;# get their master and pu to our ko-master
# and ko-pu.
$ git pull www bar
# instead of fetching from usual ref,
# fetch from there bar, and merge with it.
Having a Push: entry that uses anything but hostname:/path or
just local directory as its URL does not make any sense at this
moment, because git native send-pack transport is the only one
that is supported for push, as before.
Note that using a $GIT_DIR/branches/ file as a short-cut is
still supported, for both upload and download.
The second one extends "git fetch" to allow pulling from more
than one head. Earlier, "git fetch <remote>" with shorthand
form (i.e. a file $GIT_DIR/branches/<remote> exists and
describes the URL) always overwrote
$GIT_DIR/refs/heads/<remote>, but it does the "reverse push",
meaning it does not overwrite when the update does not result in
a fast-forward merge with the existing value of the reference.
The above "git fetch www" example would fetch both their master
and pu, and tries to fast forward our ko-master and ko-pu with
them. When fast forwarding fails, currently it just stops and
does not try to download all the heads. This may need to
change. The fetch results, whether they update the local
refs/heads/ hierarchy by fast forwarding or not, will be also
stored in $GIT_DIR/FETCH_HEAD.
Note that the format of this file has changed to accomodate
multiple heads. I've checked that neither Cogito nor StGIT
looks at this file, so this change should hopefully be a safe
one.
The third one is to update the "git pull" to prevent people from
abusing the extended "git fetch" and attempt to create a king
ghidorah. "git resolve" has not been updated to do anything but
two-head merge yet, so when you say "git pull www master pu rc",
it would run "git fetch www master pu rc" but stops without
running the resolving step. While it would not make much sense
xsto do an octopus merge against master, pu and rc from git.git
repository, doing an octopus would probably make a lot more
sense when pulling from a repository like what Jeff Garzik has,
so that would be an interesting future project.
I have tested the very basic form of the above works reasonably
well, but there probably are bugs, maybe attempting to pull
heads to a wrong local heads, or something silly like that.
Please handle it with care. It will stay in "pu" branch for
now.
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Linus Torvalds @ 2005-08-18 5:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Wolfgang Denk, git
In-Reply-To: <17155.64070.264664.926461@cargo.ozlabs.ibm.com>
On Thu, 18 Aug 2005, Paul Mackerras wrote:
>
> I added support for grafts to gitk just yesterday, and it should be on
> kernel.org by now. I also committed the changes to send lines into
> hyperspace.
Paul, I hate to tell you about yet another flag to git-rev-list, but did
you realize that in addition to all the other magic flags, there's a flag
called "--parents"?
Right now you use "git-rev-list --header --topo-order", which gives you
both the commit ID's and the header. Add a "--parents" there, and you'll
notice that the first line of each NUL-terminated record changes from just
the commit ID to the "commit ID + parent list".
That way gitk wouldn't need to actually know about grafts, because it
would just pick it up from the git-rev-list output which gets it from the
regular commit parsing code.
Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
need to look at any other internal git information, you're probably doing
something wrong, or you've missed yet another flag ;)
Linus
^ permalink raw reply
* Small team cogito/git setup
From: Martin Langhoff @ 2005-08-18 4:14 UTC (permalink / raw)
To: GIT
We have a small team of 3, and our main activity is to run local
branches of upstream projects, plus some local development. In that
context, I am designing our cogito/git usage strategy, and I'm
interested in comments.
My intention is to use cogito as much as possible, and insulate our
team from git internals. I find that using cogito is actually easier
than cvs, and a mile easier than Arch (the two tools we use currently)
and I rather keep it that way: simple.
The upstream projects run on CVS, so I am setting up a repo fed by
git-cvsimport for each of those. We all pull from that repo
(cg-clone), so we can all see the upstream in its git representation.
Now, we are going to run a few branches off that, and I want to have
those branches _teamwide_ with the same name, so it is trivial for us
to keep synching.
All our work directories on our LAN will available via HTTP, so we can
pull from the team repositories easily. Is there a good technique with
cogito to have a team pull from each other, so that a single cg-update
or cg-pull when working on a branch pulls from all my teammembers.
Or are we forced to run an 'integration' repo so that we work with a
'star' arrangement? I am actually trying to avoid needing a central
repo if possible.
How should branch creation be handled for team-wide branches? I'd like
to have branches use the same name across the team to avoid confusion.
Phew. Every time I think I understand how things go with git, I find I
don't know sh*t about it yet ;)
martin
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Paul Mackerras @ 2005-08-18 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wolfgang Denk, git
In-Reply-To: <7vd5ocouus.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> My Tcl/Tk is really rusty, and I do not like this patch, but
> here is my stab at teaching the code that reads commit objects
> how to use grafts as well.
I added support for grafts to gitk just yesterday, and it should be on
kernel.org by now. I also committed the changes to send lines into
hyperspace.
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Junio C Hamano @ 2005-08-18 2:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Paul Mackerras, git
In-Reply-To: <20050818003036.C53FD353BF9@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> The display in gitk --all gets changed a bit (before the branch was
> the leftmost line, now it's the rightmost one), but it's still a
> dangling head, and the selected "merge point" (commit 24ee89) is
> still displayed with just one parent (de180e) - I would expect to
> also see d9af3c listed as parent, and the branch merging in here?
>
> Am I missing something?
The graft info is not used by anything other than those that use
parse_commit() to figure out the commit ancestry information.
The list of commits that appear in the top pane of the gitk is
generated by git-rev-list which knows how to do it, but the
parent and child links, and the lines between nodes are drawn by
gitk using the information it reads directly from the commit
objects.
My Tcl/Tk is really rusty, and I do not like this patch, but
here is my stab at teaching the code that reads commit objects
how to use grafts as well.
------------
[PATCH] Teach gitk to use grafts info
Finding commits to draw is done by git-rev-list which knows how
to do the grafts, but the lines between commits and the
parent / child links needs to be drawn by reading from the
commit objects. Teach that part of the code how to grok grafts
info so that "fake" ancestry is shown sensibly in gitk.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
gitk | 36 +++++++++++++++++++++++++++++++++++-
1 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -155,7 +155,7 @@ proc readcommit {id} {
}
proc parsecommit {id contents listed} {
- global commitinfo children nchildren parents nparents cdate ncleft
+ global commitinfo children nchildren parents nparents cdate ncleft grafts
set inhdr 1
set comment {}
@@ -171,6 +171,23 @@ proc parsecommit {id contents listed} {
}
set parents($id) {}
set nparents($id) 0
+ set has_graft [array get grafts $id]
+ if {"" != $has_graft} {
+ set parents($id) $grafts($id)
+ set nparents($id) [llength $parents($id)]
+ foreach p $parents($id) {
+ if {![info exists nchildren($p)]} {
+ set children($p) {}
+ set nchildren($p) 0
+ set ncleft($p) 0
+ }
+ if {$listed && [lsearch -exact $children($p) $id] < 0} {
+ lappend children($p) $id
+ incr nchildren($p)
+ incr ncleft($p)
+ }
+ }
+ }
foreach line [split $contents "\n"] {
if {$inhdr} {
if {$line == {}} {
@@ -178,6 +195,9 @@ proc parsecommit {id contents listed} {
} else {
set tag [lindex $line 0]
if {$tag == "parent"} {
+ if {"" != $has_graft} {
+ continue
+ }
set p [lindex $line 1]
if {![info exists nchildren($p)]} {
set children($p) {}
@@ -3194,6 +3214,20 @@ foreach arg $argv {
set history {}
set historyindex 0
+set grafts('') nothing
+array unset grafts ''
+if {![catch { set graft [exec cat [gitdir]/info/grafts] }]} {
+ global grafts
+ foreach line [split $graft "\n"] {
+ set commit [lindex $line 0]
+ set llen [llength $line]
+ set pp {}
+ for {set i 1} {$i < $llen} {incr i} {
+ lappend pp [lindex $line $i]
+ }
+ set grafts($commit) $pp
+ }
+}
set stopped 0
set redisplaying 0
^ permalink raw reply
* Subject: [PATCH] Assorted changes to glossary
From: Johannes Schindelin @ 2005-08-18 1:20 UTC (permalink / raw)
To: Junio C Hamano, git
Based on the discussion on the git list, here are some important changes
to the glossary. (There is no cache, but an index. Use "object name"
rather than "SHA1". Reorder. Clarify.)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/glossary.txt | 104 ++++++++++++++++++++++++++------------------
1 files changed, 61 insertions(+), 43 deletions(-)
8d8a819f8f1d93c460c0b76a006f1a3830fb1f06
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -3,21 +3,27 @@ object::
the SHA1 of its contents. Consequently, an object can not
be changed.
+object name::
+ The unique identifier of an object. The hash of the object's contents
+ using the Secure Hash Algorithm 1 and usually represented by the 40
+ character hexadecimal encoding of the hash of the object (possibly
+ followed by a white space).
+
SHA1::
- A 20-byte sequence (or 41-byte file containing the hex
- representation and a newline). It is calculated from the
- contents of an object by the Secure Hash Algorithm 1.
+ Synonym for object name.
+
+object identifier::
+ Synonym for object name.
+
+hash::
+ In git's context, synonym to object name.
object database::
Stores a set of "objects", and an individial object is identified
- by its SHA1 (its ref). The objects are either stored as single
- files, or live inside of packs.
-
-object name::
- Synonym for SHA1.
+ by its object name. The object usually live in $GIT_DIR/objects/.
blob object::
- Untyped object, i.e. the contents of a file.
+ Untyped object, e.g. the contents of a file.
tree object::
An object containing a list of blob and/or tree objects.
@@ -29,42 +35,43 @@ tree::
dependent blob and tree objects (i.e. a stored representation
of a working tree).
-cache::
- A collection of files whose contents are stored as objects.
- The cache is a stored version of your working tree. Well, can
- also contain a second, and even a third version of a working
- tree, which are used when merging.
+index::
+ A collection of files with stat information, whose contents are
+ stored as objects. The cache is a stored version of your working
+ tree. Truth be told, it can also contain a second, and even a third
+ version of a working tree, which are used when merging.
-cache entry::
+index entry::
The information regarding a particular file, stored in the index.
- A cache entry can be unmerged, if a merge was started, but not
+ An index entry can be unmerged, if a merge was started, but not
yet finished (i.e. if the cache contains multiple versions of
that file).
-index::
- Contains information about the cache contents, in particular
- timestamps and mode flags ("stat information") for the files
- stored in the cache. An unmerged index is an index which contains
- unmerged cache entries.
+unmerged index:
+ An index which contains unmerged index entries.
+
+cache::
+ Obsolete for: index.
working tree::
- The set of files and directories currently being worked on.
- Think "ls -laR"
+ The set of files and directories currently being worked on,
+ i.e. you can work in your working tree without using git at all.
directory::
The list you get with "ls" :-)
-checkout::
- The action of updating the working tree to a revision which was
- stored in the object database.
-
revision::
A particular state of files and directories which was stored in
the object database. It is referenced by a commit object.
+checkout::
+ The action of updating the working tree to a revision which was
+ stored in the object database.
+
commit::
- The action of storing the current state of the cache in the
+ As a verb: The action of storing the current state of the cache in the
object database. The result is a revision.
+ As a noun: Short hand for commit object.
commit object::
An object which contains the information about a particular
@@ -72,14 +79,15 @@ commit object::
tree object which corresponds to the top directory of the
stored revision.
+parent::
+ A commit object contains a (possibly empty) list of the logical
+ predecessor(s) in the line of development, i.e. its parents.
+
changeset::
BitKeeper/cvsps speak for "commit". Since git does not store
changes, but states, it really does not make sense to use
the term "changesets" with git.
-ent::
- Favorite synonym to "tree-ish" by some total geeks.
-
clean::
A working tree is clean, if it corresponds to the revision
referenced by the current head.
@@ -94,13 +102,12 @@ head::
branch::
A non-cyclical graph of revisions, i.e. the complete history of
- a particular revision, which does not (yet) have children, which
- is called the branch head. The branch heads are stored in
- $GIT_DIR/refs/heads/.
+ a particular revision, which is called the branch head. The
+ branch heads are stored in $GIT_DIR/refs/heads/.
ref::
A 40-byte hex representation of a SHA1 pointing to a particular
- object. These are stored in $GIT_DIR/refs/.
+ object. These may be stored in $GIT_DIR/refs/.
head ref::
A ref pointing to a head. Often, this is abbreviated to "head".
@@ -108,7 +115,10 @@ head ref::
tree-ish::
A ref pointing to either a commit object, a tree object, or a
- tag object pointing to a commit or tree object.
+ tag object pointing to a tag or commit or tree object.
+
+ent::
+ Favorite synonym to "tree-ish" by some total geeks.
tag object::
An object containing a ref pointing to another object. It can
@@ -120,6 +130,8 @@ tag::
a tag is not changed by a commit. Tags (not tag objects) are
stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
a Lisp tag (which is called object type in git's context).
+ A tag is most typically used to mark a particular point in the
+ commit ancestry chain.
merge::
To merge branches means to try to accumulate the changes since a
@@ -133,9 +145,18 @@ resolve::
repository::
A collection of refs together with an object database containing
- all objects, which are reachable from the refs. A repository can
+ all objects, which are reachable from the refs, possibly accompanied
+ by meta data from one or more porcelains. A repository can
share an object database with other repositories.
+git archive::
+ Synonym for repository (for arch people).
+
+file system::
+ Linus Torvalds originally designed git to be a user space file
+ system, i.e. the infrastructure to hold files and directories.
+ That ensured the efficiency and speed of git.
+
alternate object database::
Via the alternates mechanism, a repository can inherit part of its
object database from another object database, which is called
@@ -150,10 +171,6 @@ chain::
reference to its successor (for example, the successor of a commit
could be one of its parents).
-parent::
- A commit object contains a (possibly empty) list of the logical
- predecessor(s) in the line of development, i.e. its parents.
-
fetch::
Fetching a branch means to get the branch's head ref from a
remote repository, to find out which objects are missing from
@@ -176,8 +193,8 @@ pack::
space or to transmit them efficiently).
pack index::
- Contains offsets into a pack, so the pack can be used instead of
- the unpacked objects.
+ The list of identifiers, and other information, of the objects in a
+ pack, to assist in efficiently accessing the contents of a pack.
plumbing::
Cute name for core git.
@@ -196,3 +213,4 @@ SCM::
dircache::
You are *waaaaay* behind.
+
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Wolfgang Denk @ 2005-08-18 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslxw4tb1.fsf_-_@assigned-by-dhcp.cox.net>
In message <7vslxw4tb1.fsf_-_@assigned-by-dhcp.cox.net> you wrote:
> Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
> which is a list of "fake commit parent records". Each line of
> this file is a commit ID, followed by parent commit IDs, all
> 40-byte hex SHA1 separated by a single SP in between. The
> records override the parent information we would normally read
> from the commit objects, allowing both adding "fake" parents
> (i.e. grafting), and pretending as if a commit is not a child of
> some of its real parents (i.e. cauterizing).
How exactly is this used?
I gave up trying to have CVS merges autimatically recognized upon
import, and tried to follow Matthias Urlichs' advice to fake it using
the grafts file.
I have this situation:
Branch point (actually this is the inital import into CVS):
Commit: 0b666f81da14bf46cada222856762f7fd6641c26
Child: 9956b03b956994bb4e2cee4161f3626bcfd71924 (Das U-Boot: Universal Boot Loader)
Child: 7309612797ed5e6b3b20027e28bca970b4f6b8fd (Initial revision)
End of branch to merge (in CVS 1.1.1.1):
Commit: d9af3c87df93e1a8126b1a52adf8db978e9a0d40
Parent: 0bb9c6d97b195bd0efcdda02f109e6d1519074a9 (Das U-Boot: Universal Boot Loader)
<no child>
This is the commit where I would like to show the branch merged in
(before; this is the first real commit in CVS):
Commit: 24ee89b97a49826ea800b4a6c0d5c0769328e317
Parent: de180e6daa529dc78668c99bdf17a9cdd440782d (Initial revision)
Child: 699b13a6064e642280caffaa83c10b359a6c1114 (* Fix mdelay() on TRAB - this was still the debugging version with)
I tried with a grafts file like this:
24ee89b97a49826ea800b4a6c0d5c0769328e317 de180e6daa529dc78668c99bdf17a9cdd440782d d9af3c87df93e1a8126b1a52adf8db978e9a0d40
The display in gitk --all gets changed a bit (before the branch was
the leftmost line, now it's the rightmost one), but it's still a
dangling head, and the selected "merge point" (commit 24ee89) is
still displayed with just one parent (de180e) - I would expect to
also see d9af3c listed as parent, and the branch merging in here?
Am I missing something?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
"That we but teach bloody instructions,
which, being taught, return to plague the inventor..."
^ permalink raw reply
* Re: gitk with hyperspace support
From: Junio C Hamano @ 2005-08-17 22:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17155.2581.888904.526537@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> OK, you're the second person to ask for that, so I'll see what I can
> do about it. I can think of 3 possible behaviors when you click on
> the arrowhead:
>
> 1. scroll to bring the other arrowhead on-screen and briefly make it
> larger or something similar to draw attention to it
>
> 2. scroll to bring the other arrowhead on-screen and warp the pointer
> to it
>
> 3. select the next commit in the indicated direction which is a child
> or parent that the line connects (scroll to make it visible,
> highlight it, show its diff).
>
> Which do you think would be best?
Hmph. I think, aside from being color challenged, the primary
source of confusion for me was that the lines with arrowheads
were too long, and the node and the arrowhead did not fit within
the height of the graphical pane, at least with my window
configuration.
I wonder if not having downward or upward arrows for a long
stretch would work better. Lose the vertical line for such
hyperspace links, and instead have a horizonal short line with
arrowheads to denote that there are also hyperspace lines coming
into or out of that node. That way you can save one column for
a vertical line, and my preference for clicking on such an
arrowhead would be #3 from the above.
^ permalink raw reply
* Re: First stab at glossary
From: Johannes Schindelin @ 2005-08-17 22:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508171630140.23242@iabervon.org>
Hi,
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
> On Wed, 17 Aug 2005, Johannes Schindelin wrote:
>
> > On Wed, 17 Aug 2005, Daniel Barkalow wrote:
> > > [...]
> > Okay for "hash".
>
> I think we only need at most two names for this, so this is more a matter
> of fixing old usage than documenting it.
It's short enough to keep it in the glossary _and_ fix the old
documentation.
> > [blabla] index [blable] cache [bliblo]
>
> Well, it often contains information not present anywhere else (the status
> of a merge; the set of files being committed, added, or removed), so it
> isn't really a cache at all.
Okay, okay. I stand corrected.
> > Maybe I was too cautious. Linus very new idea was to think of the lowest
> > level of an SCM as a file system. But I did not want to mention that.
> > Thinking of it again, maybe I should.
>
> You probably don't need to mention that tree objects and index files can
> be thought of as filesystems, but you should specify that the working tree
> really is in the Unix filesystem, in case people have heard of the idea.
>
> It should be clear to say 'You can "cd" there and "ls" to list your
> files.', rather than 'Think "ls -laR"' which makes my think of the output,
> which is like the output from git-ls-files.
How about this:
working tree::
The set of files and directories currently being worked on,
i.e. you can work in your working tree without using git at all.
> > > > checkout::
> > >
> > > Move after "revision"?
> >
> > Ultimately, the glossary terms will be sorted alphabetically. If you look
> > at the file attached to my original mail, this is already sorted and
> > marked up using asciidoc. However, I wanted you and the list to understand
> > how I grouped terms. The asciidoc'ed file is generated by a perl script.
>
> Ah, okay.
Sorry, I attributed these "moving suggestions" to the large and angry SCM,
while those were your comments. Since Junio decided to keep the "topic
ordered" form in his repository, I moved them around according to your
mail.
> > > > resolve::
> > > > The action of fixing up manually what a failed automatic merge
> > > > left behind.
> > >
> > > "Resolve" is also used for the automatic case (e.g., in
> > > "git-resolve-script", which goes from having two commits and a message to
> > > having a new commit). I'm not sure what the distinction is supposed to be.
> >
> > I did not like that naming anyway. In reality, git-resolve-script does not
> > resolve anything, but it merges two revisions, possibly leaving something
> > to resolve.
>
> Right; I think we should change the name of the script.
How many users are there? Probably many call git-pull-script anyway,
right?
Ciao,
Dscho
^ permalink raw reply
* Re: First stab at glossary
From: Daniel Barkalow @ 2005-08-17 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508172156090.17234@wgmdd8.biozentrum.uni-wuerzburg.de>
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 17 Aug 2005, Daniel Barkalow wrote:
>
> > On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> >
> > > object name::
> > > Synonym for SHA1.
> >
> > Have we killed the use of the third term "hash" for this? I'd say that
> > "object name" is the standard term, and "SHA1" is a nickname, if only
> > because "object name" is more descriptive of the particular use of the
> > term.
>
> Okay for "hash".
I think we only need at most two names for this, so this is more a matter
of fixing old usage than documenting it.
> > I think we might want to entirely kill the "cache" term, and talk only
> > about the "index" and "index entries". Of course, a bunch of the code will
> > have to be renamed to make this completely successful, but we could change
> > the glossary and documentation, and mention "cache" and "cache entry" as
> > old names for "index" and "index entry" respectively.
>
> For me, "index" is just the file named "index" (holding stat data and a
> ref for each cache entry). That is why I say an "index" contains "cache
> entries", not "index entries" (wee, that sounds wrong :-).
Well, it often contains information not present anywhere else (the status
of a merge; the set of files being committed, added, or removed), so it
isn't really a cache at all.
> > > working tree::
> > > The set of files and directories currently being worked on.
> > > Think "ls -laR"
> >
> > This is where the data is actually in the filesystem, and you can edit and
> > compile it (as opposed to a tree object or the index, which semantically
> > have the same contents, but aren't presented in the filesystem that way).
>
> Maybe I was too cautious. Linus very new idea was to think of the lowest
> level of an SCM as a file system. But I did not want to mention that.
> Thinking of it again, maybe I should.
You probably don't need to mention that tree objects and index files can
be thought of as filesystems, but you should specify that the working tree
really is in the Unix filesystem, in case people have heard of the idea.
It should be clear to say 'You can "cd" there and "ls" to list your
files.', rather than 'Think "ls -laR"' which makes my think of the output,
which is like the output from git-ls-files.
> > > checkout::
> >
> > Move after "revision"?
>
> Ultimately, the glossary terms will be sorted alphabetically. If you look
> at the file attached to my original mail, this is already sorted and
> marked up using asciidoc. However, I wanted you and the list to understand
> how I grouped terms. The asciidoc'ed file is generated by a perl script.
Ah, okay.
> > > resolve::
> > > The action of fixing up manually what a failed automatic merge
> > > left behind.
> >
> > "Resolve" is also used for the automatic case (e.g., in
> > "git-resolve-script", which goes from having two commits and a message to
> > having a new commit). I'm not sure what the distinction is supposed to be.
>
> I did not like that naming anyway. In reality, git-resolve-script does not
> resolve anything, but it merges two revisions, possibly leaving something
> to resolve.
Right; I think we should change the name of the script.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Johannes Schindelin @ 2005-08-17 21:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Marco Costalba, git
In-Reply-To: <1124314075.7130.49.camel@localhost.localdomain>
Hi Catalin,
maybe it is time for a quick run through the typical jobs you do with
StGIT, much like what Jeff sent the other day?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Johannes Schindelin @ 2005-08-17 21:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508171253190.3553@g5.osdl.org>
Hi,
On Wed, 17 Aug 2005, Linus Torvalds wrote:
> On Wed, 17 Aug 2005, Jeff Garzik wrote:
> >
> > 2) Teach it to understand MIME, and not treat the MIME headers like part
> > of the message.
>
> [...]
>
> Ergo: if somebody sends you mime-encoded patches, hit them with a baseball
> bat (politely) and teach them not to do that. "Fixing" the tools really
> will just make things worse if it means that you apply raw emails without
> having edited them.
I'd say that QP and the MIME/alternate formats are not really the fault of
the sender, but rather the mailer. So there might be value in supporting
at least these, to make the life of maintainers easier.
Ciao,
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