* Re: Some tips for doing a CVS importer
From: Johannes Sixt @ 2006-11-23 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611212116340.26827@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> I started playing with MinGW, and got it to compile and run, with some
> features lacking. See
>
> Message-ID: <Pine.LNX.4.63.0609021724110.28360@wbgn013.biozentrum.uni-wuerzburg.de>
>
> for details. From TFM
>
> : The two biggest obstacles are fork() and the network stuff (I do not
> : plan on supporting Git.pm there). To overcome the absence of fork() I
> : wanted to use the subprocess stuff in MinGW's port of GNU make.
I'd like to do something about it. Is your work accessible in some way?
At the moment I'm limping along with CVS on Windows, which really is the
wrong tool for my current task (CVS I mean, not Windows ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/3] git-fetch: allow glob pattern in refspec
From: Andy Parkins @ 2006-11-23 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmaik4mi.fsf@assigned-by-dhcp.cox.net>
On Thursday 2006 November 23 07:24, Junio C Hamano wrote:
> * Andy, I think this does the same thing as you wanted to do,
> but is cleaner implementation-wise and also at the concept
It certainly is. Looking at your implementation I see that I was worrying
unnecessarily about passing extra globals/parameters to git-parse-remote.
Your version is much better than mine; and I see that noone else calls
get_remote_refs_for_fetch anyway.
> level, to pretend as if the user listed the expanded form in
> the configuration. I deliberately decided not to apply the
> wildcard expansion on refspecs that came from command line,
> but if we wanted to we can move the expand_refs_wildcard call
> a few lines down to make it also apply to them.
That's probably the most sensible method. Using globs on the command line
could get people into trouble if they accidentally hit a shell expansion.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH/RFC] Implemented glob support in pull refspecs
From: Andy Parkins @ 2006-11-23 8:46 UTC (permalink / raw)
To: git
In-Reply-To: <200611230833.45904.andyparkins@gmail.com>
Sorry for the resend; I didn't get a copy of my send from last night from the
mailing list so thought I hadn't sent it.
Please ignore this dupe.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Adding glob support to remotes
From: Andy Parkins @ 2006-11-23 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <7v3b8bryt6.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006 November 22 20:50, Junio C Hamano wrote:
> I do not understand and that is why I do not understand why you
> would need to touch check-ref-format.
The problem is that I didn't want to call git-ls-remote in git-parse-remote,
as git-parse-remote doesn't know about $uploadpack or what the actual remote
in use is. It seemed fairly intrusive to completely alter the functions in
git-parse-remote; which is obviously a set of library functions.
Instead I did the expansion in git-fetch.sh. Unfortunately that meant
disabling the check-ref-format call in canon_refs_list_for_fetch.
> point at" is to ask ls-remote, and if you do one ls-remote
> upfront then all you need to do here is a single grep.
I understand now. I'll look again at this tonight and send a further patch.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [PATCH/RFC] Implemented glob support in pull refspecs
From: Andy Parkins @ 2006-11-23 8:33 UTC (permalink / raw)
To: git
git-ls-remote is now called early on and the list categorised into heads and
tags. Any time a refspec has a "*" in the remote part, the git-ls-remote head
list is searched for matches against that refspec. If found then the part of
the remote ref that matches the "*" is substituted into the local part of the
refspec.
This allows refspecs like
refs/heads/*:refs/remotes/origin/*
Which will ensure that all branches on the remote are created locally.
Note, no local branch will be deleted, so if it is deleted upstream it will
remain in the local repository.
As an added bonus, because the output of git-ls-remote is now stored, the other
calls to it for tag processing are replaced with simple accesses to the
previously stored remote tag list
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
The problem with this patch is that I've removed the sanity check in
git-parse-remote.sh using git-check-ref-format. Where should I do this now?
Perhaps after the expansion of the glob?
git-fetch.sh | 77 +++++++++++++++++++++++++++++++++++++++++++++-----
git-parse-remote.sh | 10 +++---
2 files changed, 74 insertions(+), 13 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index eb32476..1875fe9 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -224,6 +224,24 @@ case "$update_head_ok" in
;;
esac
+# Prefetch the remote list and categorise it into tags and heads
+remotereflist=$(git-ls-remote $upload_pack "$remote")
+remoteheads=
+remotetags=
+for ref in $remotereflist
+do
+ # Convert the tab to a comma so that the case below works
+ ref=$(echo $ref | sed -e "s/\t/,/")
+ case $ref in
+ *,refs/heads/*)
+ remoteheads="$remoteheads$ref$LF"
+ ;;
+ *,refs/tags/*)
+ remotetags="$remotetags$ref$LF"
+ ;;
+ esac
+done
+
# If --tags (and later --heads or --all) is specified, then we are
# not talking about defaults stored in Pull: line of remotes or
# branches file, and just fetch those and refspecs explicitly given.
@@ -232,12 +250,9 @@ esac
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
- taglist=`IFS=" " &&
- (
- git-ls-remote $upload_pack --tags "$remote" ||
- echo fail ouch
- ) |
- while read sha1 name
+ taglist=`IFS="," &&
+ echo -n $remotetags |
+ while read sha1 name
do
case "$sha1" in
fail)
@@ -263,6 +278,52 @@ then
fi
fi
+# Expand any refspecs that contain "*"
+newreflist=
+for refspec in $reflist
+do
+ remotename=$(expr "z$refspec" : 'z\([^:]*\):')
+ localname=$(expr "z$refspec" : 'z[^:]*:\(.*\)')
+ if gotglob=$(expr "z$remotename" : 'zrefs/.*/\*$')
+ then
+ # If this is a glob-containing ref, then expand it using every
+ # matching remote head
+ for remoteref in $remoteheads
+ do
+ # remoteheads stores the heads with the hashes still present
+ remoteref=$(expr "$remoteref" : "$_x40,\\(.*\\)")
+
+ # For example, if
+ # remotename = refs/heads/*
+ # localname = refs/remotes/up/*
+ # Then we find a potential remote head of
+ # remoteref = refs/heads/branchname
+
+ # First see if it matches the remotename glob
+ case $remoteref in
+ $remotename)
+ # So we know remoteref is the going to be the remote
+ # in the new fetch line, however we need to substitute the
+ # "*" in the local part to get the local name
+ # First we manufacture the regexps to do the work
+ remotereg=$(echo $remotename | sed -e 's/\*/\\(.*\\)/')
+ remotebranch=$(expr "$remoteref" : "$remotereg")
+ # Now substitute this into the localname
+ localref=$(echo $localname | sed -e "s|\\*|$remotebranch|")
+ # And construct the new refspec
+ newreflist="$newreflist$remoteref:$localref$LF"
+ ;;
+ esac
+
+ done
+ else
+ # Non glob refs just get copied literally
+ newreflist="$newreflist$ref$LF"
+ fi
+done
+reflist=$newreflist
+
+
fetch_main () {
reflist="$1"
refs=
@@ -430,8 +491,8 @@ case "$no_tags$tags" in
*:refs/*)
# effective only when we are following remote branch
# using local tracking branch.
- taglist=$(IFS=" " &&
- git-ls-remote $upload_pack --tags "$remote" |
+ taglist=$(IFS="," &&
+ echo -n $remotetags |
sed -n -e 's|^\('"$_x40"'\) \(refs/tags/.*\)^{}$|\1 \2|p' \
-e 's|^\('"$_x40"'\) \(refs/tags/.*\)$|\1 \2|p' |
while read sha1 name
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c325ef7..e541144 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -145,11 +145,11 @@ canon_refs_list_for_fetch () {
*) local="refs/heads/$local" ;;
esac
- if local_ref_name=$(expr "z$local" : 'zrefs/\(.*\)')
- then
- git-check-ref-format "$local_ref_name" ||
- die "* refusing to create funny ref '$local_ref_name' locally"
- fi
+# if local_ref_name=$(expr "z$local" : 'zrefs/\(.*\)')
+# then
+# git-check-ref-format "$local_ref_name" ||
+# die "* refusing to create funny ref '$local_ref_name' locally"
+# fi
echo "${dot_prefix}${force}${remote}:${local}"
done
}
--
1.4.3.5
^ permalink raw reply related
* [PATCH 3/3] git-fetch: allow glob pattern in refspec
From: Junio C Hamano @ 2006-11-23 7:24 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
This adds Andy's refspec glob. You can have a single line:
Pull: refs/heads/*:refs/remotes/origin/*
in your ".git/remotes/origin" and say "git fetch" to retrieve
all refs under heads/ at the remote side to remotes/origin/ in
the local repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Andy, I think this does the same thing as you wanted to do,
but is cleaner implementation-wise and also at the concept
level, to pretend as if the user listed the expanded form in
the configuration. I deliberately decided not to apply the
wildcard expansion on refspecs that came from command line,
but if we wanted to we can move the expand_refs_wildcard call
a few lines down to make it also apply to them.
git-parse-remote.sh | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c325ef7..e281b7c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -90,6 +90,39 @@ get_remote_default_refs_for_push () {
esac
}
+# Called from canon_refs_list_for_fetch -d "$remote", which
+# is called from get_remote_default_refs_for_fetch to grok
+# refspecs that are retrieved from the configuration, but not
+# from get_remote_refs_for_fetch when it deals with refspecs
+# supplied on the command line. $ls_remote_result has the list
+# of refs available at remote.
+expand_refs_wildcard () {
+ for ref
+ do
+ # a non glob pattern is given back as-is.
+ expr "z$ref" : 'zrefs/.*/\*:refs/.*/\*$' >/dev/null || {
+ echo "$ref"
+ continue
+ }
+ from=`expr "z$ref" : 'z\(refs/.*/\)\*:refs/.*/\*$'`
+ to=`expr "z$ref" : 'zrefs/.*/\*:\(refs/.*/\)\*$'`
+ echo "$ls_remote_result" |
+ (
+ IFS=' '
+ while read sha1 name
+ do
+ mapped=${name#"$from"}
+ if test "z$name" != "z${name#'^{}'}" ||
+ test "z$name" = "z$mapped"
+ then
+ continue
+ fi
+ echo "${name}:${to}${mapped}"
+ done
+ )
+ done
+}
+
# Subroutine to canonicalize remote:local notation.
canon_refs_list_for_fetch () {
# If called from get_remote_default_refs_for_fetch
@@ -107,6 +140,8 @@ canon_refs_list_for_fetch () {
merge_branches=$(git-repo-config \
--get-all "branch.${curr_branch}.merge")
fi
+ set x $(expand_refs_wildcard "$@")
+ shift
fi
for ref
do
--
1.4.4.1.g77614
^ permalink raw reply related
* [PATCH 2/3] git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
From: Junio C Hamano @ 2006-11-23 7:24 UTC (permalink / raw)
To: git
Earlier, commit walkers downloaded loose refs from refs/ hierarchy
of the remote side to find where to start walking; this would
not work for a repository whose refs are packed and then pruned.
With the previous change, we have ls-remote output from the
remote in-core; we can use the value from there without
requiring loose refs anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-fetch.sh | 28 +++++++++++++---------------
1 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 170c2cb..06b66b9 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -307,22 +307,20 @@ fetch_main () {
"`git-repo-config --bool http.noEPSV`" = true ]; then
noepsv_opt="--disable-epsv"
fi
- max_depth=5
- depth=0
- head="ref: $remote_name"
- while (expr "z$head" : "zref:" && expr $depth \< $max_depth) >/dev/null
- do
- remote_name_quoted=$(@@PERL@@ -e '
- my $u = $ARGV[0];
- $u =~ s/^ref:\s*//;
- $u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
- print "$u";
- ' "$head")
- head=$(curl -nsfL $curl_extra_args $noepsv_opt "$remote/$remote_name_quoted")
- depth=$( expr \( $depth + 1 \) )
- done
+
+ # Find $remote_name from ls-remote output.
+ head=$(
+ IFS=' '
+ echo "$ls_remote_result" |
+ while read sha1 name
+ do
+ test "z$name" = "z$remote_name" || continue
+ echo "$sha1"
+ break
+ done
+ )
expr "z$head" : "z$_x40\$" >/dev/null ||
- die "Failed to fetch $remote_name from $remote"
+ die "No such ref $remote_name at $remote"
echo >&2 "Fetching $remote_name from $remote using $proto"
git-http-fetch -v -a "$head" "$remote/" || exit
;;
--
1.4.4.1.g77614
^ permalink raw reply related
* [PATCH 1/3] git-fetch: reuse ls-remote result.
From: Junio C Hamano @ 2006-11-23 7:24 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
In-Reply-To: <200611222213.44336.andyparkins@gmail.com>
This will become necessary to update the dumb protocol
transports to fetch from a repository with packed and then
pruned tags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I am doing this to allow dumb protocol transports to work
with a repository with packed and then pruned refs, but it
should be reusable for other purposes, such as wildcarding the
refspecs Andy is interested in.
git-fetch.sh | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index eb32476..170c2cb 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -88,6 +88,10 @@ then
: >"$GIT_DIR/FETCH_HEAD"
fi
+# Global that is reused later
+ls_remote_result=$(git ls-remote $upload_pack "$remote") ||
+ die "Cannot find the reflist at $remote"
+
append_fetch_head () {
head_="$1"
remote_="$2"
@@ -233,10 +237,7 @@ reflist=$(get_remote_refs_for_fetch "$@"
if test "$tags"
then
taglist=`IFS=" " &&
- (
- git-ls-remote $upload_pack --tags "$remote" ||
- echo fail ouch
- ) |
+ echo "$ls_remote_result" |
while read sha1 name
do
case "$sha1" in
@@ -245,6 +246,8 @@ then
esac
case "$name" in
*^*) continue ;;
+ refs/tags/*) ;;
+ *) continue ;;
esac
if git-check-ref-format "$name"
then
@@ -431,7 +434,7 @@ case "$no_tags$tags" in
# effective only when we are following remote branch
# using local tracking branch.
taglist=$(IFS=" " &&
- git-ls-remote $upload_pack --tags "$remote" |
+ echo "$ls_remote_result" |
sed -n -e 's|^\('"$_x40"'\) \(refs/tags/.*\)^{}$|\1 \2|p' \
-e 's|^\('"$_x40"'\) \(refs/tags/.*\)$|\1 \2|p' |
while read sha1 name
--
1.4.4.1.g77614
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-11-23 2:49 UTC (permalink / raw)
To: git
The 'maint' and 'master' are at the same commit; a maintenance
release v1.4.4.1 has been cut.
A handful enhancements that have been cooking in 'next' will
start graduating to 'master' shortly; as usual, they won't be
in the future v1.4.4.x maintenance series.
* gitweb updates.
* shortlog is now built-in.
* enhance packed-refs file to optimize "show-ref -d".
* retire merge-recursive-old.
* shallow clone.
----------------------------------------------------------------
* The 'next' branch, in addition to what are in 'master', has these.
Andy Parkins (2):
Improve git-prune -n output
Add support to git-branch to show local and remote branches
Jakub Narebski (7):
gitweb: Protect against possible warning in git_commitdiff
gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
gitweb: New improved formatting of chunk header in diff
gitweb: Add an option to href() to return full URL
gitweb: Refactor feed generation, make output prettier, add Atom feed
gitweb: Finish restoring "blob" links in git_difftree_body
Johannes Schindelin (5):
Build in shortlog
shortlog: do not crash on parsing "[PATCH"
shortlog: read mailmap from ./.mailmap again
shortlog: handle email addresses case-insensitively
shortlog: fix "-n"
Junio C Hamano (9):
upload-pack: stop the other side when they have more roots than we do.
adjust_shared_perm: chmod() only when needed.
apply --numstat: mark binary diffstat with - -, not 0 0
pack-objects: tweak "do not even attempt delta" heuristics
Store peeled refs in packed-refs file.
remove merge-recursive-old
git-merge: make it usable as the first class UI
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
Store peeled refs in packed-refs (take 2).
Nicolas Pitre (1):
builtin git-shortlog is broken
* The 'pu' branch, in addition, has these.
Alexandre Julliard (1):
Shallow clone: do not ignore shallowness when following tags
Johannes Schindelin (5):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
allow deepening of a shallow repository
add tests for shallow stuff
Junio C Hamano (10):
git-commit: show --summary after successful commit.
para-walk: walk n trees, index and working tree in parallel
rev-list --left-right
merge: allow merging into a yet-to-be-born branch.
blame: --show-stats for easier optimization work.
gitweb: steal loadavg throttle from kernel.org
We should make sure that the protocol is still extensible.
Why does it mean we do not have to register shallow if we have one?
Why didn't we mark want_obj as ~UNINTERESTING in the old code?
shallow clone: unparse and reparse an unshallowed commit
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.4.1
From: Junio C Hamano @ 2006-11-23 2:49 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.4.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.4.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4.1-1.$arch.rpm (RPM)
This contains mostly small post-release fixups.
----------------------------------------------------------------
Changes since v1.4.4 are as follows:
Alexandre Julliard (1):
gitweb: Put back shortlog instead of graphiclog in the project list.
Chris Riddoch (1):
Move --pretty options into Documentation/pretty-formats.txt
Jim Meyering (1):
Run "git repack -a -d" once more at end, if there's 1MB or more of not-packed data.
Johannes Schindelin (1):
Seek back to current filepos when mmap()ing with NO_MMAP
Junio C Hamano (7):
git-checkout: do not allow -f and -m at the same time.
git-checkout: allow pathspec to recover lost working tree directory
convert-objects: set _XOPEN_SOURCE to 600
git-fetch: follow lightweit tags as well.
do_for_each_ref: perform the same sanity check for leftovers.
trust-executable-bit: fix breakage for symlinks
GIT 1.4.4.1
Linus Torvalds (2):
git-pull: allow pulling into an empty repository
"git fmt-merge-msg" SIGSEGV
Michal Rokos (1):
archive: use setvbuf() instead of setlinebuf()
Paolo Ciarrocchi (2):
Teach SubmittingPatches about git-commit -s
Doc: Make comment about merging in tutorial.txt more clear
Petr Baudis (4):
Fix git-for-each-refs broken for tags
git-apply: Documentation typo fix
Documentation: Define symref and update HEAD description
Documentation: Correct alternates documentation, document http-alternates
Rene Scharfe (4):
sparse fix: non-ANSI function declaration
sparse fix: Using plain integer as NULL pointer
git-apply: slightly clean up bitfield usage
Document git-runstatus
^ permalink raw reply
* git crash when cg-fetch:ing dash
From: Horst H. von Brand @ 2006-11-23 2:47 UTC (permalink / raw)
To: git
I did:
git clone http://gondor.apana.org.au/~herbert/dash/dash.git
and got:
error: Unable to start request
error: Could not interpret heads/master as something to pull
(broken repo? cogito only?). Then I tried:
cg-clone http://gondor.apana.org.au/~herbert/dash/dash.git
and got:
defaulting to local storage area
Fetching head...
Fetching objects...
*** glibc detected *** git-http-fetch: double free or corruption (fasttop): 0x0869f858 ***
Known problem?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: rebase fails but not sure why
From: Alan Chandler @ 2006-11-23 0:30 UTC (permalink / raw)
To: git
In-Reply-To: <200611230026.58936.alan@chandlerfamily.org.uk>
On Thursday 23 November 2006 00:26, Alan Chandler wrote:
> I have now got to a point where the following error occurs during a rebase.
>
> fatal: empty ident <alan@chandlerfamily.org.uk> not allowed
> Commit failed, please do not call "git commit"
> directly, but instead do one of the following:
I had run
git rebase --merge --onto b1 b2 b3
I aborted it and ran
git rebase --onto b1 b2 b3
and it works!
--
Alan Chandler
^ permalink raw reply
* rebase fails but not sure why
From: Alan Chandler @ 2006-11-23 0:26 UTC (permalink / raw)
To: git
I have been doing repeated rebase on my repository to try and separate out
mixed streams of development into separate branches.
I have now got to a point where the following error occurs during a rebase.
fatal: empty ident <alan@chandlerfamily.org.uk> not allowed
Commit failed, please do not call "git commit"
directly, but instead do one of the following:
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
but I am not sure how to solve issue.
git status shows a number of files waiting to be commited, but no unmerged
files. but git rebase --continue just pumps out the same error message.
--
Alan Chandler
^ permalink raw reply
* Re: StGit metadata grabbing with git clone
From: Robin Rosenberg @ 2006-11-22 23:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Otavio Salvador, git
In-Reply-To: <20061122213800.GM7201@pasky.or.cz>
onsdag 22 november 2006 22:38 skrev Petr Baudis:
> On Wed, Nov 22, 2006 at 09:29:24PM CET, Robin Rosenberg wrote:
> > onsdag 22 november 2006 13:05 skrev Otavio Salvador:
> > > Hello,
> > >
> > > I'm a happy user of stgit together with git to maintain a patch queue
> > > while I or the company team is working on patches that will be send
> > > for merging. Both works great but we're having troubles when we try to
> > > clone a stgit repository.
> > >
> > > When I clone the repository it grab the source but it loses the
> > > metadata. I would like to grab those too. Does anybody has a solution
> > > or a trick how I can do that?
> >
> > You can copy the repo using rsync or scp instead of git-clone or use stg
> > uncommit after the regular clone.
>
> How do you sync them then?
1) Don't. You're supposed to share stgit patches via email.
2) Want to mess try anyway?
At first I was thinking NO!, but then again, it might be "interesting" to try
it.
You can publish the state of a branch using git push. This will look like the
pu branch in the official Git repo, i.e. a branch whose list of commits get
changed completely, rather than being appended to. This could be considered
sane, ie. you publish the current state of your work.
You can also pull from a stgitted branch. Still sane, if you wan't to look at
somebody else's work.
I mentioned uncommit. I'm not sure that was a wise suggestion. If you wan't to
push and pull changes. don't uncommit incomming changes and don't pretend to
work on the same patch and you'll probably be just fine. .....
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Sanjoy Mahajan @ 2006-11-22 23:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git, Nicolas Pitre, Linus Torvalds
In-Reply-To: <20061116160700.GA3383@thunk.org>
The car analogy is excellently clear.
> they need more than the "stupid simple" git usage, but if they don't
> need the extreme power of git, Hg is simpler for people to learn how
> to use.
As a 80%-hg/20%-git user, I'm curious what features of git you had in
mind, so I know where to look as I wander up the git learning curve.
My experience with the git user interface, for what it's worth, is
that I never quite get the conceptual model crystal clear enough in my
head. So it won't stay for long enough for me to progress up the
learning curve and retain the gains. I move up a bit, but the gain
soon evaporates and I backslide, and then just hack my way through it.
I found hg's conceptual model very easy to learn, almost as if I don't
have to remember anything. Maybe that simplicity comes at a price,
whence my question at the start about the extreme-power features of
git.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
^ permalink raw reply
* Re: Feature request: git-pull -e/--edit
From: Junio C Hamano @ 2006-11-22 23:02 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061119212611.13038.qmail@science.horizon.com>
linux@horizon.com writes:
> But I notice that --no-commit actually changes git's merging
> technique. If it's specified, the trivial in-index merge doesn't
> appear to be attempted. I don't think it makes a huge difference,
> but is any difference desirable?
This was done in response to a specific request from the list
but I do not remember the details. If I were to research the
background I would
(1) first, look at the authordate of the commit that introduced
the change. For this, I would most likely use:
git log -p -S--no-commit -- git-pull.sh
(2) go back to the list archive and find the thread that
predates that commit by a few days.
^ permalink raw reply
* Re: Stupid Git question
From: Junio C Hamano @ 2006-11-22 22:43 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <89b129c60611221328l333d22c6o3668aef2706f92c7@mail.gmail.com>
"Sean Kelley" <sean.v.kelley@gmail.com> writes:
> One other question - how do you rename a branch on the remote
> repository once you have created it?
Right now, there is no way to remove a ref, so even "create new
and then remove" would not work. You need a way to ssh-in to
the machine and run "branch -d" there.
You would need an access to run git tools on the remote site
for:
- repository creation and deletion
- ref deletion
- fsck, pruning and repacking
- adding entries to objects/info/alternates
- managing hook scripts
with the current set of tools, which pretty much means an
account with a full shell access over SSH.
Earlier in another thread, Linus said that it is justifiable to
treat repository creation as a special event and outside of
git. For one thing you need to have the account on the site and
arrange access permissions and authentication before you can
create a repository, so it is an understandable position to
take, and for people with full SSH access it is a minor nuisance
that they have to first go there to perform the above operations
instead of running "git-do-things-at-remote host:path" locally.
However, for sites that want to restrict the access via
git-shell, after a repository owner secured such an account and
access rights, not being able to allow the user to do some of
the above things himself is a burden on site administrators.
This _could_ be improved by allowing some common operations via
git-shell.
Even under git-shell, the process'es user and group
credentials are the primary means to control the access
rights. So in that sense, letting the user to say things
like the following might make sense:
$ REPO=repo.example.com:/pub/scm/git/project.git
$ git remote-admin $REPO create-repository
$ git remote-admin $REPO delete-repository
$ git remote-admin $REPO repack
$ git remote-admin $REPO fsck-objects
$ git remote-admin $REPO count-objects
And for the sake of both simplicity (which would lead to
security) and to allow the site administrator to make policy
decision, I think we do not have to (and we shouldn't) make the
above commands to take any flags. The command's availability
and what parameters to be passed to underlying commands such as
git-repack are determined by the site administrator. For
example, an administrator may give a restricted account to a
user _and_ set up one repository for him but may not want to
give him rights to create another repository nor delete that
initial repository given to him, in which case create-repository
and delete-repository actions would be disabled.
I have a feeling that the users should not be given full control
over 'hook' scripts, but I am not sure. A site administator
might want to forbid too expensive hooks from running, even the
process spawned by the user would work only in directories that
the user has access to. If we give the users a full control,
then:
$ git remote-admin $REPO get-hook $hookname >old-contents
$ git remote-admin $REPO put-hook $hookname <new-contents
$ git remote-admin $REPO remove-hook $hookname
would be the set of commands we could use (I am assuming
put-hook installs the hook in "enabled" state, and get-hook
would give a failure for nonexistent or disabled hooks).
The most straightforward extension of the above for ref deletion
is to say:
$ git remote-admin $REPO delete-refs refs/heads/foo refs/tags/v1.0
and that would be the simplest way to implement it if we were to
go with "git remote-admin". However, I think people would find
it more natural if manipulation of refs were part of "git push".
"git push $REPO $src:$dst" means "take what I have in $src in my
local repository, and update the $REPO's $dst ref with that".
So as a natural extension of that, we could make:
$ git push $REPO '':$dst
to mean "store nothingness in $dst" and make that a way to
express the desire to remove $dst ref.
^ permalink raw reply
* Re: filemode=false somewhat broken
From: Junio C Hamano @ 2006-11-22 22:39 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: git
In-Reply-To: <17764.44236.473000.729015@lapjr.intranet.kiel.bmiag.de>
Juergen Ruehle <j.ruehle@bmiag.de> writes:
> Commit fd28b34afd9bbd58297a25edced3f504c9a5487a tried to ignore the
> executable bit if filemode=false, but instead forced all files to be
> regular with 644 permission bits nuking symlink support.
Thanks for noticing. Yes, that change is _seriously_ broken. I
should really raise the bar for patch acceptance.
^ permalink raw reply
* [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Inaki Arenaza @ 2006-11-22 22:26 UTC (permalink / raw)
To: git; +Cc: I�aki Arenaza
From: =?utf-8?q?I=F1aki_Arenaza?= <iarenuno@eteo.mondragon.edu>
Quoting from the CVS info manual:
......................................................................
The `gserver' and `pserver' connection methods all accept optional
method options, specified as part of the METHOD string, like so:
:METHOD[;OPTION=ARG...]:
Currently, the only two valid connection options are `proxy', which
takes a hostname as an argument, and `proxyport', which takes a port
number as an argument. These options can be used to connect via an HTTP
tunnel style web proxy. For example, to connect pserver via a web proxy
at www.myproxy.net and port 8000, you would use a method of:
:pserver;proxy=www.myproxy.net;proxyport=8000:
*NOTE: The rest of the connection string is required to connect to
the server as noted in the upcoming sections on password authentication,
gserver and kserver. The example above would only modify the METHOD
portion of the repository name.*
PROXY must be supplied to connect to a CVS server via a proxy
server, but PROXYPORT will default to port 8080 if not supplied.
PROXYPORT may also be set via the CVS_PROXY_PORT environment variable.
......................................................................
This patch adds support for 'proxy' and 'proxyport' connection options
when using the pserver method for the CVS Root.
It has been tested with a Squid 2.5.x proxy server.
Please, CC me as I am not in the list.
Signed-off-by: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
---
git-cvsimport.perl | 49 ++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index b54a948..394f3c3 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -161,8 +161,22 @@ sub new {
sub conn {
my $self = shift;
my $repo = $self->{'fullrep'};
- if($repo =~ s/^:pserver:(?:(.*?)(?::(.*?))?@)?([^:\/]*)(?::(\d*))?//) {
- my($user,$pass,$serv,$port) = ($1,$2,$3,$4);
+ if($repo =~ s/^:pserver(?:([^:]*)):(?:(.*?)(?::(.*?))?@)?([^:\/]*)(?::(\d*))?//) {
+ my($param,$user,$pass,$serv,$port) = ($1,$2,$3,$4,$5);
+
+ my($proxyhost,$proxyport);
+ if($param && ($param =~ m/proxy=([^;]+)/)) {
+ $proxyhost = $1;
+ # Default proxyport, if not specified, is 8080.
+ $proxyport = 8080;
+ if($ENV{"CVS_PROXY_PORT"}) {
+ $proxyport = $ENV{"CVS_PROXY_PORT"};
+ }
+ if($param =~ m/proxyport=([^;]+)/){
+ $proxyport = $1;
+ }
+ }
+
$user="anonymous" unless defined $user;
my $rr2 = "-";
unless($port) {
@@ -187,13 +201,38 @@ sub conn {
}
$pass="A" unless $pass;
- my $s = IO::Socket::INET->new(PeerHost => $serv, PeerPort => $port);
- die "Socket to $serv: $!\n" unless defined $s;
+ my ($s, $rep);
+ if($proxyhost) {
+
+ # Use a HTTP Proxy. Only works for HTTP proxies that
+ # don't require user authentication
+ #
+ # See: http://www.ietf.org/rfc/rfc2817.txt
+
+ $s = IO::Socket::INET->new(PeerHost => $proxyhost, PeerPort => $proxyport);
+ die "Socket to $proxyhost: $!\n" unless defined $s;
+ $s->write("CONNECT $serv:$port HTTP/1.1\r\nHost: $serv:$port\r\n\r\n")
+ or die "Write to $proxyhost: $!\n";
+ $s->flush();
+
+ $rep = <$s>;
+
+ # The answer should loook like 'HTTP/1.x 2yy ....'
+ if(!($rep =~ m#^HTTP/1\.. 2[0-9][0-9]#)) {
+ die "Proxy connect: $rep\n";
+ }
+ # Skip the empty line of the proxy server output
+ <$s>;
+ } else {
+ my $s = IO::Socket::INET->new(PeerHost => $serv, PeerPort => $port);
+ die "Socket to $serv: $!\n" unless defined $s;
+ }
+
$s->write("BEGIN AUTH REQUEST\n$repo\n$user\n$pass\nEND AUTH REQUEST\n")
or die "Write to $serv: $!\n";
$s->flush();
- my $rep = <$s>;
+ $rep = <$s>;
if($rep ne "I LOVE YOU\n") {
$rep="<unknown>" unless $rep;
--
1.4.4
^ permalink raw reply related
* [PATCH/RFC] Implemented glob support in pull refspecs
From: Andy Parkins @ 2006-11-22 22:13 UTC (permalink / raw)
To: git
git-ls-remote is now called early on and the list categorised into heads and
tags. Any time a refspec has a "*" in the remote part, the git-ls-remote head
list is searched for matches against that refspec. If found then the part of
the remote ref that matches the "*" is substituted into the local part of the
refspec.
This allows refspecs like
refs/heads/*:refs/remotes/origin/*
Which will ensure that all branches on the remote are created locally.
Note, no local branch will be deleted, so if it is deleted upstream it will
remain in the local repository.
As an added bonus, because the output of git-ls-remote is now stored, the other
calls to it for tag processing are replaced with simple accesses to the
previously stored remote tag list
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
The problem with this patch is that I had to disable the safety check
in git-parse-remote.sh to allow the "*" in the refspec. I'm not sure what
the appropriate place to put that call now is? Perhaps after the expansion
of the globbed refspecs?
git-fetch.sh | 77 +++++++++++++++++++++++++++++++++++++++++++++-----
git-parse-remote.sh | 10 +++---
2 files changed, 74 insertions(+), 13 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index eb32476..1875fe9 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -224,6 +224,24 @@ case "$update_head_ok" in
;;
esac
+# Prefetch the remote list and categorise it into tags and heads
+remotereflist=$(git-ls-remote $upload_pack "$remote")
+remoteheads=
+remotetags=
+for ref in $remotereflist
+do
+ # Convert the tab to a comma so that the case below works
+ ref=$(echo $ref | sed -e "s/\t/,/")
+ case $ref in
+ *,refs/heads/*)
+ remoteheads="$remoteheads$ref$LF"
+ ;;
+ *,refs/tags/*)
+ remotetags="$remotetags$ref$LF"
+ ;;
+ esac
+done
+
# If --tags (and later --heads or --all) is specified, then we are
# not talking about defaults stored in Pull: line of remotes or
# branches file, and just fetch those and refspecs explicitly given.
@@ -232,12 +250,9 @@ esac
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
- taglist=`IFS=" " &&
- (
- git-ls-remote $upload_pack --tags "$remote" ||
- echo fail ouch
- ) |
- while read sha1 name
+ taglist=`IFS="," &&
+ echo -n $remotetags |
+ while read sha1 name
do
case "$sha1" in
fail)
@@ -263,6 +278,52 @@ then
fi
fi
+# Expand any refspecs that contain "*"
+newreflist=
+for refspec in $reflist
+do
+ remotename=$(expr "z$refspec" : 'z\([^:]*\):')
+ localname=$(expr "z$refspec" : 'z[^:]*:\(.*\)')
+ if gotglob=$(expr "z$remotename" : 'zrefs/.*/\*$')
+ then
+ # If this is a glob-containing ref, then expand it using every
+ # matching remote head
+ for remoteref in $remoteheads
+ do
+ # remoteheads stores the heads with the hashes still present
+ remoteref=$(expr "$remoteref" : "$_x40,\\(.*\\)")
+
+ # For example, if
+ # remotename = refs/heads/*
+ # localname = refs/remotes/up/*
+ # Then we find a potential remote head of
+ # remoteref = refs/heads/branchname
+
+ # First see if it matches the remotename glob
+ case $remoteref in
+ $remotename)
+ # So we know remoteref is the going to be the remote
+ # in the new fetch line, however we need to substitute the
+ # "*" in the local part to get the local name
+ # First we manufacture the regexps to do the work
+ remotereg=$(echo $remotename | sed -e 's/\*/\\(.*\\)/')
+ remotebranch=$(expr "$remoteref" : "$remotereg")
+ # Now substitute this into the localname
+ localref=$(echo $localname | sed -e "s|\\*|$remotebranch|")
+ # And construct the new refspec
+ newreflist="$newreflist$remoteref:$localref$LF"
+ ;;
+ esac
+
+ done
+ else
+ # Non glob refs just get copied literally
+ newreflist="$newreflist$ref$LF"
+ fi
+done
+reflist=$newreflist
+
+
fetch_main () {
reflist="$1"
refs=
@@ -430,8 +491,8 @@ case "$no_tags$tags" in
*:refs/*)
# effective only when we are following remote branch
# using local tracking branch.
- taglist=$(IFS=" " &&
- git-ls-remote $upload_pack --tags "$remote" |
+ taglist=$(IFS="," &&
+ echo -n $remotetags |
sed -n -e 's|^\('"$_x40"'\) \(refs/tags/.*\)^{}$|\1 \2|p' \
-e 's|^\('"$_x40"'\) \(refs/tags/.*\)$|\1 \2|p' |
while read sha1 name
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c325ef7..e541144 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -145,11 +145,11 @@ canon_refs_list_for_fetch () {
*) local="refs/heads/$local" ;;
esac
- if local_ref_name=$(expr "z$local" : 'zrefs/\(.*\)')
- then
- git-check-ref-format "$local_ref_name" ||
- die "* refusing to create funny ref '$local_ref_name' locally"
- fi
+# if local_ref_name=$(expr "z$local" : 'zrefs/\(.*\)')
+# then
+# git-check-ref-format "$local_ref_name" ||
+# die "* refusing to create funny ref '$local_ref_name' locally"
+# fi
echo "${dot_prefix}${force}${remote}:${local}"
done
}
--
1.4.3.5
^ permalink raw reply related
* Re: StGit metadata grabbing with git clone
From: Petr Baudis @ 2006-11-22 21:38 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Otavio Salvador, git
In-Reply-To: <200611222129.24369.robin.rosenberg.lists@dewire.com>
On Wed, Nov 22, 2006 at 09:29:24PM CET, Robin Rosenberg wrote:
> onsdag 22 november 2006 13:05 skrev Otavio Salvador:
> > Hello,
> >
> > I'm a happy user of stgit together with git to maintain a patch queue
> > while I or the company team is working on patches that will be send
> > for merging. Both works great but we're having troubles when we try to
> > clone a stgit repository.
> >
> > When I clone the repository it grab the source but it loses the
> > metadata. I would like to grab those too. Does anybody has a solution
> > or a trick how I can do that?
>
> You can copy the repo using rsync or scp instead of git-clone or use stg
> uncommit after the regular clone.
How do you sync them then?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: Stupid Git question
From: Sean Kelley @ 2006-11-22 21:28 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <871wnvxwg4.wl%cworth@cworth.org>
Hi,
On 11/22/06, Carl Worth <cworth@cworth.org> wrote:
> On Wed, 22 Nov 2006 08:28:58 -0600, "Sean Kelley" wrote:
> > How do I add a branch to the remote repository that is visible to all
> > team members. It seems like the git checkout -b commands just create
> > local topic branches.
>
> Just push the branch out to the remote repository. You even gave the
> command sequence to do that:
>
> > git checkout Project
> > git pull . fm-modulator
> > git push origin Project
>
One other question - how do you rename a branch on the remote
repository once you have created it?
Thanks,
Sean
> -Carl
>
>
>
--
^ permalink raw reply
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
From: Petr Baudis @ 2006-11-22 20:56 UTC (permalink / raw)
To: Kir Kolyshkin; +Cc: git
In-Reply-To: <45641195.2000804@openvz.org>
On Wed, Nov 22, 2006 at 10:00:05AM CET, Kir Kolyshkin wrote:
> Petr Baudis wrote:
> >On Tue, Nov 21, 2006 at 11:02:36PM CET, Kir Kolyshkin wrote:
> >
> >>Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
> >>
> >
> >...but in git's gitweb view it will make this <a
> >href="http://git.openvz.org/.">http://git.openvz.org/.</a>. :-)
> Not a problem actually since "." means "current directory", so it will
> work fine (and I have checked that) :)
> Sure there is a room for improvement for this regex -- and I am
> collecting those.
But "http://git.openvz.org/index.html." might not work so fine, nor
"http://git.openvz.org/,"...
Bad URLs matchers which don't snip unlikely (!= invalid!) characters
from the end of the URL are my pet peeve. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: Adding glob support to remotes
From: Junio C Hamano @ 2006-11-22 20:50 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611221441.02459.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006 November 22 12:56, Junio C Hamano wrote:
>
>> > However, git-ls-remote needs the name of the remote repository (of
>> > course), but that isn't directly available in git-parse-remote.sh.
>>
>> Is it really the case? I do not remember the details offhand,
>> but I do not think canon_refs_list_for_fetch is the function you
>> should be messing with to implement the remote."origin".fetch
>> stuff. It should be get_remote_default_refs_for_fetch(). The
>> function returns the list based on which remote, so it surely
>> knows which remote the caller is talking about.
>
> The problem is that canon_refs_list_for_fetch bombs out too early because "*"
> is not an acceptable name for a ref.
I do not understand and that is why I do not understand why you
would need to touch check-ref-format.
"remote.$1.fetch" is read by get_remote_default_refs_for_fetch
and currently the value is given canon_refs_list_for_fetch
without any preprocessing. My suggestion is to catch the
"wildcard" in get_remote_default_refs_for_fetch, do your
replacement based on an earlier ls-remote output, and give
replaced values to canon_refs_list_for_fetch. That way I do not
think check-ref-format that is used by canon_refs_list_for_fetch
needs to see any wildcard.
Both config and remotes but not branches _could_ have wildcard
so you would need to do the same wildcard replacement in two
case arms of get_remote_default_refs_for_fetch but I think that
can be done in a common helper function.
If on the other hand if you want to do this in canon_*, then you
could do that before the "for ref" loop to set "$@" to the
wildcard-expanded form. But there are other codepaths that use
this function and I do not know if you want to apply the
wildcarding to all of them (I haven't checked all the callers).
If you are sure all the callers want the wildcarding the same
way, it would be more appropriate to do so there than doing it
in get_remote_default_refs_for_fetch as I suggested in the
above. I.e. something like this perhaps.
canon_refs_list_for_fetch () {
...
--get-all "branch.${curr_branch}.merge")
fi
fi
+
+ expanded_ref_list=
+ for ref
+ do
+ if ref is wildcard
+ then
+ compute wildcard replacement and set it to nref
+ expanded_ref_list="$expanded_ref_list $nref"
+ else
+ expanded_ref_list="$expanded_ref_list $ref"
+ fi
+ done
+ set x $expanded_ref_list
+ shift
+
for ref
do
force=
>> (1) dumb protocols currently cannot deal with a remote that has
>
> I'm not sure I've understood this point. I shall look at git-fetch.sh more
> closely to try and address this though.
I was talking about this part of the code:
case "$remote" in
http://* | https://* | ftp://*)
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
"`git-repo-config --bool http.noEPSV`" = true ]; then
noepsv_opt="--disable-epsv"
fi
max_depth=5
depth=0
head="ref: $remote_name"
while (expr "z$head" : "zref:" && expr $depth \< $max_depth) >/dev/null
do
remote_name_quoted=$(@@PERL@@ -e '
my $u = $ARGV[0];
$u =~ s/^ref:\s*//;
$u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
print "$u";
' "$head")
head=$(curl -nsfL $curl_extra_args $noepsv_opt "$remote/$remote_name_quoted")
depth=$( expr \( $depth + 1 \) )
done
expr "z$head" : "z$_x40\$" >/dev/null ||
die "Failed to fetch $remote_name from $remote"
echo >&2 Fetching "$remote_name from $remote" using http
git-http-fetch -v -a "$head" "$remote/" || exit
;;
The while loop is initialized with "ref: refs/heads/$branch",
extracts the "refs/heads/$branch" from it by hand, and runs
"curl -nsfL" to get http://host/repo.git/refs/heads/$branch,
until it is not a symref anymore (refs/heads/$branch _could_
be a symref that points at refs/heads/$another, and that is the
loop is about). At the end of the loop, $head would contain
what is read from the ref -- 40-byte object name. That is given
to git-http-fetch.
However, the above assumes $GIT_DIR/refs/heads/$branch file
exists at the remote end for "curl -nsfL" to fetch. When refs
are packed-and-pruned, refs/heads/$branch may not exist as a
standalone file; the right way to learn "what object does a ref
point at" is to ask ls-remote, and if you do one ls-remote
upfront then all you need to do here is a single grep.
^ permalink raw reply
* Re: A documentation to-do list
From: lamikr @ 2006-11-22 20:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Chris Riddoch, git
In-Reply-To: <Pine.LNX.4.63.0611221044180.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 21 Nov 2006, Chris Riddoch wrote:
>
>
>> Having decided to take it on myself to improve Git's documentation, I
>> asked on #git if people had particular things they felt I should focus
>> on.
>>
>
> I have a request, which is not about _what_ to document, but _how_. People
> often complained about the bad introduction into git, pointing to
> http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart for a "way
> better" tutorial.
>
I agree with this. In addition at least I have always missed official
"home page" as even currently the kernel.org points for example just to
http://www.kernel.org/pub/software/scm/git/
Ok, by clicking the "docs" subfolder one gets to man pages. But man
pages does not specify the basic things like, where is the official git
repository
and how to pull the latest official or development versions from there.
In addition man pages are not the fastest way to get started.
Instead small tutorial for example with a following kind of usage
scenario might be quite useful for many. (I do not know even myself to
step 10 :-)
1) One clones architehture specific git repository
(for example git-clone
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git)
2) This repository has omap specific things in master branch which is
often synced with main kernel
3) Once omap specific things are working agains the release kernel
(let's say 2.6.16), master is tagged with keys like
"linux-omap-2.6.16-omap1"
4) User creates "MY_DEV" branch and adds own changes to there
5) User tags the branch with "MY_OMAP1_2_6_16" and releases own
2.6.16-omap1 based kernel
6) Master branch in OMAP is synced with the main kernel which is now
somewhere like 2.6.18-rc5
7) User changes to master branch, pulls the master branch to 2.6.18-rc5
level
8) User switches to MY_DEV branch has pulls it it 2.6.18-rc5 level from
master branch. Fix merge errors and commits them there.
9) Stable team releases bug fix version 2.6.16.25 to own git
10) User wants to release MY_OMAP1_2_6_16_25 version and would like to
use git-pull instead of using patch files
- How to jump back to tagged version in repository?
- How to pull the stable team changes here?
Other common issues that comes to my mind are but which are not easy to
find out from the current official
man based documentation:
1) where is the repository and gitweb for git itself. (only man pages
are easy to find out currently from net).
2) how to checkout the latest from there (even announcement emails does
not mention this currently!)
3) how to pull the git repository to newer version when Junio announces
new tar-balls
4) how to change to older tagged version (or to some older non tagged
commit version) and build from there
5) how to create own work branch, commit changes to there and
a) use git-format-patches to create patch files
b) automatize the patch sending via emails
c) use push for sending changes back to master repository
6) what is the difference between origin and master. Can user push
changes to origin or should they always be pushed to master or own branch
7) how to create own repository
8) how to set-up gitweb to show your own git repository
9) how to allow others to pull over http connection from your repository
(this was for example easy, but it is hard to find any documentation
from this)
10) how to allow others to pull over git connection from your repository
(requires git-daemon + touch command with magic keyword)
^ 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