* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Jeff King @ 2007-11-21 15:21 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster
In-Reply-To: <1195648601-21736-3-git-send-email-win@wincent.com>
On Wed, Nov 21, 2007 at 01:36:39PM +0100, Wincent Colaiuta wrote:
> If supplied a single file path parameter the git-add--interactive script
> now bypasses the command loop and jumps straight to the patch subcommand
> using the passed path. After returning from the subcommand the main
> command loop is entered. If a non-resolvable path is supplied the
> operation is a no-op and the command loop is entered.
Great, the lack of this feature has bugged me in the past. Thank you for
working on it. However...
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index fb1e92a..8f21c03 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -803,6 +803,11 @@ sub main_loop {
> }
> }
>
> +die "add --interactive may take only 1 optional parameter" if ($#ARGV > 0);
> refresh();
> +if ($#ARGV == 0) {
> + patch_update_file($ARGV[0]);
> +}
> status_cmd();
> main_loop();
> +
Why only one file? How about something like this instead:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index fb1e92a..8036c95 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -804,5 +804,8 @@ sub main_loop {
}
refresh();
+foreach my $file (@ARGV) {
+ patch_update_file($file);
+}
status_cmd();
main_loop();
On top of that, it would be great to be able to do something like
git-add -i *.c
and just get prompted for changed files (right now, you only get
prompted for changed files, but unchanged files seem to print a spurious
newline).
And at any rate, this would require fixing 3/4 to handle the multiple
files from git-add.
What do you think?
-Peff
^ permalink raw reply related
* Re: Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-21 15:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fi1heo$u4i$1@ger.gmane.org>
On Nov 21, 2007 4:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Santi Béjar wrote:
>
> > 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
> >
> > [remote "bundle"]
> > url = /file/to/bundle
> > fetch = "+refs/heads/*:refs/remotes/bundle/*"
> >
> > $ git push bundle
> >
> > would create a bundle in /file/to/bundle with the same branches as a
> > normal git push, but considering the remote branches as the local
> > remotes/bundle/*
>
> And how you would differentiate between path meaning bundle, and
> path meaning "local" protocol, i.e. git repository on the same
> filesystem? "bundle = /file/to/bundle" perhaps...
Good point. The git repository must exist before pushing, but the bundle:
1) Exist and is a file, do nothing by default, maybe requiere a --overwrite
2) Does not exist, create the bundle, but maybe you've written badly the url, so
the best thing would be to say explicitly that you wanted a bundle
like you said.
Santi
^ permalink raw reply
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Jeff King @ 2007-11-21 15:28 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Dan Zwell, git, gitster
In-Reply-To: <1195655278-19535-1-git-send-email-win@wincent.com>
On Wed, Nov 21, 2007 at 03:27:58PM +0100, Wincent Colaiuta wrote:
> The user interface provided by the command loop in git-add--interactive
> gives the impression that subcommands can only be launched by entering
> an integer identifier from 1 through 8.
>
> A "hidden" feature is that any string can be entered, and an anchored
> regex search is used to find the first matching option.
>
> This patch makes this feature a little more obvious by highlighting the
> first character of each subcommand (for example "patch" is displayed as
> "[p]atch"). The mechanism for doing this is to add an optional third
I think this is reasonable. It is also a candidate for colorization in
Dan Zwell's patches. Dan, any progress on the next revision of the patch
series?
-Peff
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 15:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, sbejar
In-Reply-To: <fi1heo$u4i$1@ger.gmane.org>
Hi,
On Wed, 21 Nov 2007, Jakub Narebski wrote:
> Santi B?jar wrote:
>
> > 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
> >
> > [remote "bundle"]
> > ? url = /file/to/bundle
> > ? fetch = "+refs/heads/*:refs/remotes/bundle/*"
> >
> > $ git push bundle
> >
> > would create a bundle in /file/to/bundle with the same branches as a
> > normal git push, but considering the remote branches as the local
> > remotes/bundle/*
>
> And how you would differentiate between path meaning bundle, and path
> meaning "local" protocol, i.e. git repository on the same filesystem?
Maybe because the git repository is specified as an existing directory?
The bundle is specified as a (possibly non-existing) file...
Hth,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-21 15:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Sixt, git
In-Reply-To: <47444A1B.4000907@op5.se>
Hi,
On Wed, 21 Nov 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> >
> > P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.
>
> I can't find a reference to ptrint_t anywhere on either my system,
> and the 10 first hits on Google finds it on typedef lines, most
> commonly like this:
>
> typedef unsigned long ptrint_t;
It is really called intptr_t, and it is C99.
Ciao,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Andreas Ericsson @ 2007-11-21 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0711211546410.27959@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 21 Nov 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>> P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.
>> I can't find a reference to ptrint_t anywhere on either my system,
>> and the 10 first hits on Google finds it on typedef lines, most
>> commonly like this:
>>
>> typedef unsigned long ptrint_t;
>
> It is really called intptr_t, and it is C99.
>
That'd explain it I guess. Thanks for the clarification.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH RFC] Use "git fetch" when cloning
From: Santi Béjar @ 2007-11-21 15:40 UTC (permalink / raw)
To: Git Mailing List; +Cc: Santi Béjar
With this all the "git fetch" supported protocols are automatically
supported by "git clone", in particular bundle files.
There are two more changes:
1) It always use "git fetch" even if local. So now it checks the validity
of the new repo, in particular it does not create a broken repository
when there are too many nested alternates.
2) It connects with the remote repo when fetching the branches/tags
and the remote HEAD.
3) The quiet mode of "git fetch" prints the changed branches/tags, so "git clone"
prints always the new branches/tags.
---
git-clone.sh | 178 +++++++--------------------------------------
t/t5710-info-alternate.sh | 2 +-
2 files changed, 27 insertions(+), 153 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 3f00693..ed8efc1 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -28,68 +28,6 @@ get_repo_base() {
) 2>/dev/null
}
-if [ -n "$GIT_SSL_NO_VERIFY" -o \
- "`git config --bool http.sslVerify`" = false ]; then
- curl_extra_args="-k"
-fi
-
-http_fetch () {
- # $1 = Remote, $2 = Local
- curl -nsfL $curl_extra_args "$1" >"$2" ||
- case $? in
- 126|127) exit ;;
- *) return $? ;;
- esac
-}
-
-clone_dumb_http () {
- # $1 - remote, $2 - local
- cd "$2" &&
- clone_tmp="$GIT_DIR/clone-tmp" &&
- mkdir -p "$clone_tmp" || exit 1
- if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
- "`git config --bool http.noEPSV`" = true ]; then
- curl_extra_args="${curl_extra_args} --disable-epsv"
- fi
- http_fetch "$1/info/refs" "$clone_tmp/refs" ||
- die "Cannot get remote repository information.
-Perhaps git-update-server-info needs to be run there?"
- test "z$quiet" = z && v=-v || v=
- while read sha1 refname
- do
- name=`expr "z$refname" : 'zrefs/\(.*\)'` &&
- case "$name" in
- *^*) continue;;
- esac
- case "$bare,$name" in
- yes,* | ,heads/* | ,tags/*) ;;
- *) continue ;;
- esac
- if test -n "$use_separate_remote" &&
- branch_name=`expr "z$name" : 'zheads/\(.*\)'`
- then
- tname="remotes/$origin/$branch_name"
- else
- tname=$name
- fi
- git-http-fetch $v -a -w "$tname" "$sha1" "$1" || exit 1
- done <"$clone_tmp/refs"
- rm -fr "$clone_tmp"
- http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" ||
- rm -f "$GIT_DIR/REMOTE_HEAD"
- if test -f "$GIT_DIR/REMOTE_HEAD"; then
- head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
- case "$head_sha1" in
- 'ref: refs/'*)
- ;;
- *)
- git-http-fetch $v -a "$head_sha1" "$1" ||
- rm -f "$GIT_DIR/REMOTE_HEAD"
- ;;
- esac
- fi
-}
-
quiet=
local=no
use_local_hardlink=yes
@@ -197,6 +135,8 @@ if base=$(get_repo_base "$repo"); then
local=yes
fi
+export GIT_REFLOG_ACTION="clone: from $repo"
+
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
@@ -265,8 +205,6 @@ then
fi
fi
-rm -f "$GIT_DIR/CLONE_HEAD"
-
# We do local magic only when the user tells us to.
case "$local" in
yes)
@@ -299,105 +237,41 @@ yes)
cd "$repo" &&
find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
fi
- git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
- ;;
-*)
- case "$repo" in
- rsync://*)
- case "$depth" in
- "") ;;
- *) die "shallow over rsync not supported" ;;
- esac
- rsync $quiet -av --ignore-existing \
- --exclude info "$repo/objects/" "$GIT_DIR/objects/" ||
- exit
- # Look at objects/info/alternates for rsync -- http will
- # support it natively and git native ones will do it on the
- # remote end. Not having that file is not a crime.
- rsync -q "$repo/objects/info/alternates" \
- "$GIT_DIR/TMP_ALT" 2>/dev/null ||
- rm -f "$GIT_DIR/TMP_ALT"
- if test -f "$GIT_DIR/TMP_ALT"
- then
- ( cd "$D" &&
- . git-parse-remote &&
- resolve_alternates "$repo" <"$GIT_DIR/TMP_ALT" ) |
- while read alt
- do
- case "$alt" in 'bad alternate: '*) die "$alt";; esac
- case "$quiet" in
- '') echo >&2 "Getting alternate: $alt" ;;
- esac
- rsync $quiet -av --ignore-existing \
- --exclude info "$alt" "$GIT_DIR/objects" || exit
- done
- rm -f "$GIT_DIR/TMP_ALT"
- fi
- git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
- ;;
- https://*|http://*|ftp://*)
- case "$depth" in
- "") ;;
- *) die "shallow over http or ftp not supported" ;;
- esac
- if test -z "@@NO_CURL@@"
- then
- clone_dumb_http "$repo" "$D"
- else
- die "http transport not supported, rebuild Git with curl support"
- fi
- ;;
- *)
- case "$upload_pack" in
- '') git-fetch-pack --all -k $quiet $depth $no_progress "$repo";;
- *) git-fetch-pack --all -k $quiet "$upload_pack" $depth $no_progress "$repo" ;;
- esac >"$GIT_DIR/CLONE_HEAD" ||
- die "fetch-pack from '$repo' failed."
- ;;
- esac
- ;;
esac
-test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp"
-if test -f "$GIT_DIR/CLONE_HEAD"
+if [ -n "$use_separate_remote" ]
then
- # Read git-fetch-pack -k output and store the remote branches.
- if [ -n "$use_separate_remote" ]
- then
- branch_top="remotes/$origin"
- else
- branch_top="heads"
- fi
- tag_top="tags"
- while read sha1 name
- do
- case "$name" in
- *'^{}')
- continue ;;
- HEAD)
- destname="REMOTE_HEAD" ;;
- refs/heads/*)
- destname="refs/$branch_top/${name#refs/heads/}" ;;
- refs/tags/*)
- destname="refs/$tag_top/${name#refs/tags/}" ;;
- *)
- continue ;;
- esac
- git update-ref -m "clone: from $repo" "$destname" "$sha1" ""
- done < "$GIT_DIR/CLONE_HEAD"
+ remote_top="refs/remotes/$origin"
+else
+ remote_top="refs/heads"
fi
+case "$repo" in
+https://*|http://*|ftp://*|rsync://*) keep=;;
+*) keep=-k
+esac
+
+case "$upload_pack" in
+'') git fetch $keep --tags $quiet $depth "$repo" "+refs/heads/*:$remote_top/*";;
+*) git fetch $keep --tags $quiet $depth "$upload_pack" "$repo" "+refs/heads/*:$remote_top/*"
+esac || die "fetch from '$repo' failed."
+
+test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp"
+
if test -n "$W"; then
cd "$W" || exit
else
cd "$D" || exit
fi
-if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"
+head_sha1=`
+ case "$upload_pack" in
+ '') git ls-remote "$repo" ;;
+ *) git ls-remote "$upload_pack" "$repo"
+ esac 2>/dev/null | awk '{if ($2=="HEAD") print $1;}'`
+
+if test -z "$bare" && test -n "$head_sha1"
then
- # a non-bare repository is always in separate-remote layout
- remote_top="refs/remotes/$origin"
- head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
case "$head_sha1" in
'ref: refs/'*)
# Uh-oh, the remote told us (http transport done against
@@ -466,6 +340,6 @@ then
git read-tree -m -u $v HEAD HEAD
esac
fi
-rm -f "$GIT_DIR/CLONE_HEAD" "$GIT_DIR/REMOTE_HEAD"
+rm -f "$GIT_DIR/FETCH_HEAD"
trap - 0
diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
index 699df6e..9b7f638 100755
--- a/t/t5710-info-alternate.sh
+++ b/t/t5710-info-alternate.sh
@@ -53,7 +53,7 @@ git prune'
cd "$base_dir"
-test_expect_failure 'creating too deep nesting' \
+test_expect_success 'creating too deep nesting' \
'git clone -l -s C D &&
git clone -l -s D E &&
git clone -l -s E F &&
--
1.5.3.5.next.428.g67f5d-dirty
^ permalink raw reply related
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 15:59 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <8aa486160711210654p357ccd87i4809e0cda9471303@mail.gmail.com>
Hi,
On Wed, 21 Nov 2007, Santi B?jar wrote:
> 1) git-clone does not accept a bundle file, even if git-fetch does. I've
> made a patch to use git-fetch in git-clone for this.
This, along with rewriting git-clone as a very thin wrapper over git-init,
-remote and -fetch, is a really low hanging fruit.
Or maybe go the full nine yards and build it in. Should be a breeze now,
given parse_options() and run_command().
> 2) The bundles created with "git bundle" does not record the HEAD, they
> resolve the symbolic name to a branch name.
It imitates ls-remote output.
> 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
>
> [remote "bundle"]
> url = /file/to/bundle
> fetch = "+refs/heads/*:refs/remotes/bundle/*"
>
> $ git push bundle
>
> would create a bundle in /file/to/bundle with the same branches as a
> normal git push, but considering the remote branches as the local
> remotes/bundle/*
Does not seem to be too complicated to add it to transport.c IMHO.
Something similar to rsync_transport_push(). And I'd definitely refuse to
overwrite any existing file.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH RFC] Use "git fetch" when cloning
From: Johannes Schindelin @ 2007-11-21 16:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <1195659613-5290-1-git-send-email-sbejar@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1365 bytes --]
Hi,
On Wed, 21 Nov 2007, Santi Béjar wrote:
> 1) It always use "git fetch" even if local. So now it checks the validity
> of the new repo, in particular it does not create a broken repository
> when there are too many nested alternates.
I doubt that this is a good change. It will make local clones much, much
more expensive now.
> 2) It connects with the remote repo when fetching the branches/tags
> and the remote HEAD.
>
> 3) The quiet mode of "git fetch" prints the changed branches/tags, so "git clone"
> prints always the new branches/tags.
These changes would merit a split so that we could cherry-pick what we
want, and leave what we don't want.
> diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
> index 699df6e..9b7f638 100755
> --- a/t/t5710-info-alternate.sh
> +++ b/t/t5710-info-alternate.sh
> @@ -53,7 +53,7 @@ git prune'
>
> cd "$base_dir"
>
> -test_expect_failure 'creating too deep nesting' \
> +test_expect_success 'creating too deep nesting' \
> 'git clone -l -s C D &&
> git clone -l -s D E &&
> git clone -l -s E F &&
> --
> 1.5.3.5.next.428.g67f5d-dirty
What on _earth_?
After thinking a bit harder about it, _and_ reading the commit message, I
understand why it succeeds now.
But what would you _yourself_ think when reading this part of the code in
half a year? Exactly.
Ciao,
Dscho
^ permalink raw reply
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Kay Sievers @ 2007-11-21 16:06 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: J. Bruce Fields, Petr Baudis, linux-kernel, git
In-Reply-To: <20071121075217.GA1642@ff.dom.local>
On Nov 21, 2007 8:52 AM, Jarek Poplawski <jarkao2@o2.pl> wrote:
> On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
> > On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> > > I don't know git, but it seems, at least if done for web only, this
> > > shouldn't be so 'heavy'. It could be a 'simple' translation of commit
> > > date by querying a small database with kernel versions & dates.
> >
> > If I create a commit in my linux working repo today, but Linus doesn't
> > merge it into his repository until after he releases 2.6.24, then my
> > commit will be created with an earlier date than 2.6.24, even though it
> > isn't included until 2.6.25.
> >
> > So you have to actually examine the history graph to figure this out
> > this sort of thing.
>
> Of course, you are right, and I probably miss something, but to be
> sure we think about the same thing let's look at some example: so, I
> open a page with current Linus' tree, go to something titled:
> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history
>
> and see:
> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
> and just below something with 2007-08-14 date.
>
> Accidentally, I can remember this patch introduced many changes, and
> this big interval in dates suggests some waiting. Then I look at the
> commit, and there are 2 dates visible, so the patch really was created
> earlier. Then I go back to:
> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary
>
> and at the bottom I can see this:
>
> ...
> tags
> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3
> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2
> 4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1
> 6 weeks ago v2.6.23 Linux 2.6.23
>
> which drives me crazy, because, without looking at the calendar, and
> calculator, I don't really know which month was 6 weeks ago, and 4
> days ago, either!
>
> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/,
> do some scrolling, look at this:
> ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M
>
> and only now I can guess, this napi patch didn't manage to 2.6.23.
> Of course, usually I've to do a few more clicks and reading to make
> sure where it really started.
>
> So, this could suggest this 2007-10-10 (probably stored with time
> too), could be useful here... but it seems, I'm wrong.
>
> Of course, this problem doesn't look so hard if we forget about
> git internals: I can imagine keeping a simple database, which
> could simply retrieve commit numbers from these ChangeLogs, and
> connecting this with gitweb's commit page as well... For
> performance reasons, doing it only for stable and testing, so with
> -rc 'precision' would be very helpful too.
The "plain" view of the patch has the "version" included:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=bea3348eef27e6044b6161fd04c3152215f96411
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 3 Oct 2007 23:41:36 +0000 (-0700)
Subject: [NET]: Make NAPI polling independent of struct net_device objects.
X-Git-Tag: v2.6.24-rc1~1454^2~841
Is that what you are looking for?
Kay
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-21 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711211554370.27959@racer.site>
On Nov 21, 2007 4:59 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 21 Nov 2007, Santi B?jar wrote:
>
> > 1) git-clone does not accept a bundle file, even if git-fetch does. I've
> > made a patch to use git-fetch in git-clone for this.
>
> This, along with rewriting git-clone as a very thin wrapper over git-init,
> -remote and -fetch, is a really low hanging fruit.
For the basic/normal mode it can be a very thin wrapper but you have
to support --local, --shared, --reference...
> > 2) The bundles created with "git bundle" does not record the HEAD, they
> > resolve the symbolic name to a branch name.
>
> It imitates ls-remote output.
No, it does not.
With a newly created project with one commit:
$ git ls-remote git.git
b71992713c17c3a29f9566e1b50e8cf402375faf HEAD
b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
$ git bundle create git.bdl HEAD master
$ git bundle list-heads git.bdl
b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
Santi
^ permalink raw reply
* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Wincent Colaiuta @ 2007-11-21 16:15 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20071121152118.GG24108@sigill.intra.peff.net>
El 21/11/2007, a las 16:21, Jeff King escribió:
> On Wed, Nov 21, 2007 at 01:36:39PM +0100, Wincent Colaiuta wrote:
>
>> +if ($#ARGV == 0) {
>> + patch_update_file($ARGV[0]);
>> +}
>
> Why only one file? How about something like this instead:
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index fb1e92a..8036c95 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -804,5 +804,8 @@ sub main_loop {
> }
>
> refresh();
> +foreach my $file (@ARGV) {
> + patch_update_file($file);
> +}
> status_cmd();
> main_loop();
Yes, that makes sense. I wasn't sure how to handle multiple files, but
I guess just looping through them is fine.
> On top of that, it would be great to be able to do something like
>
> git-add -i *.c
>
> and just get prompted for changed files (right now, you only get
> prompted for changed files, but unchanged files seem to print a
> spurious
> newline).
That spurious newline comes from the last line of the
patch_update_file function (previously named patch_update_cmd):
print "\n";
The solution will be to do an early return, printing nothing for those
unchanged files (and same thing for untracked files). Will look into it.
> And at any rate, this would require fixing 3/4 to handle the multiple
> files from git-add.
>
> What do you think?
Should have some time later this evening or tomorrow to incorporate
your suggestions.
Cheers,
Wincent
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Kristian Høgsberg @ 2007-11-21 16:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711211554370.27959@racer.site>
On Wed, 2007-11-21 at 15:59 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 21 Nov 2007, Santi B?jar wrote:
>
> > 1) git-clone does not accept a bundle file, even if git-fetch does. I've
> > made a patch to use git-fetch in git-clone for this.
>
> This, along with rewriting git-clone as a very thin wrapper over git-init,
> -remote and -fetch, is a really low hanging fruit.
>
> Or maybe go the full nine yards and build it in. Should be a breeze now,
> given parse_options() and run_command().
I started doing this, which is pretty stupid as I'm pressed to find time
to finish up builtin-commit. Nevertheless, could you elaborate on the
plan here? How would you rewrite it to just use remote and fetch? I
just finished the boilerplate option parsing stuff (patch below) and
started reading the core of git-clone.sh, but if most of this can be
replaced I'd like to hear about it :)
cheers,
Kristian
>From ccfa6b7b6c0bad98201166db3f91760b423ab0c9 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Kristian=20H=C3=B8gsberg?= <krh@redhat.com>
Date: Sun, 18 Nov 2007 18:48:04 -0500
Subject: [PATCH] builtin-clone: first steps, up to and including
git-init.
---
Makefile | 2 +-
builtin-clone.c | 286
+++++++++++++++++++++++++
builtin-init-db.c | 90 ++++----
builtin.h | 1 +
cache.h | 4 +
git-clone.sh => contrib/examples/git-clone.sh | 0
git.c | 1 +
7 files changed, 341 insertions(+), 43 deletions(-)
create mode 100644 builtin-clone.c
rename git-clone.sh => contrib/examples/git-clone.sh (100%)
diff --git a/Makefile b/Makefile
index 4d23d12..f39b7e8 100644
--- a/Makefile
+++ b/Makefile
@@ -213,7 +213,6 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
- git-clone.sh \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh git-rebase--interactive.sh \
git-repack.sh git-request-pull.sh \
@@ -327,6 +326,7 @@ BUILTIN_OBJS = \
builtin-checkout-index.o \
builtin-check-ref-format.o \
builtin-clean.o \
+ builtin-clone.o \
builtin-commit.o \
builtin-commit-tree.o \
builtin-count-objects.o \
diff --git a/builtin-clone.c b/builtin-clone.c
new file mode 100644
index 0000000..8a569e0
--- /dev/null
+++ b/builtin-clone.c
@@ -0,0 +1,286 @@
+/*
+ * Builtin "git clone"
+ *
+ * Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>
+ * Based on git-commit.sh by Junio C Hamano and Linus Torvalds
+ *
+ * Clone a repository into a different directory that does not yet
exist.
+ */
+
+#include "cache.h"
+#include "parse-options.h"
+
+/*
+ * Implementation notes:
+ * - dropping use-separate-remote and no-separate-remote compatibility
+ *
+ */
+static const char * const builtin_clone_usage[] = {
+ "git-clone [options] [--] <repo> [<dir>]",
+ NULL
+};
+
+static int option_quiet, option_no_checkout, option_bare;
+static int option_local, option_no_hardlinks, option_shared,
option_depth;
+static char *option_template, *option_reference, *option_origin;
+static char *option_upload_pack;
+
+static struct option builtin_clone_options[] = {
+ OPT__QUIET(&option_quiet),
+ OPT_BOOLEAN('n', "no-checkout", &option_no_checkout,
+ "don't create a checkout"),
+ OPT_BOOLEAN(0, "bare", &option_bare, "create a bare repository"),
+ OPT_BOOLEAN(0, "naked", &option_bare, "create a bare repository"),
+ OPT_BOOLEAN('l', "local", &option_local,
+ "to clone from a local repository"),
+ OPT_BOOLEAN(0, "no-hardlinks", &option_no_hardlinks,
+ "don't use local hardlinks, always copy"),
+ OPT_BOOLEAN('s', "shared", &option_shared,
+ "setup as shared repository"),
+ OPT_STRING(0, "template", &option_template, "path",
+ "path the template repository"),
+ OPT_STRING(0, "reference", &option_reference, "repo",
+ "reference repository"),
+ OPT_STRING('o', "origin", &option_origin, "branch",
+ "use <branch> instead or 'origin' to track upstream"),
+ OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
+ "path to git-upload-pack on the remote"),
+ OPT_INTEGER(0, "depth", &option_depth,
+ "create a shallow clone of that depth"),
+
+ OPT_END()
+};
+
+static char *get_repo_path(const char *repo)
+{
+ const char *path;
+ struct stat buf;
+
+ path = mkpath("%s/.git", repo);
+ if (!stat(path, &buf) && S_ISDIR(buf.st_mode))
+ return xstrdup(make_absolute_path(path));
+
+ path = mkpath("%s.git", repo);
+ if (!stat(path, &buf) && S_ISDIR(buf.st_mode))
+ return xstrdup(make_absolute_path(path));
+
+ if (!stat(repo, &buf) && S_ISDIR(buf.st_mode))
+ return xstrdup(make_absolute_path(repo));
+
+ return NULL;
+}
+
+static char *guess_dir_name(const char *repo)
+{
+ const char *p, *start, *end, *limit;
+ int after_slash_or_colon;
+
+ /* Guess dir name from repository: strip trailing '/',
+ * strip trailing '[:/]*git', strip leading '.*[/:]'. */
+
+ after_slash_or_colon = 1;
+ limit = repo + strlen(repo);
+ start = repo;
+ end = limit;
+ for (p = repo; p < limit; p++) {
+ if (!prefixcmp(p, ".git")) {
+ if (!after_slash_or_colon)
+ end = p;
+ p += 3;
+ } else if (*p == '/' || *p == ':') {
+ if (end == limit)
+ end = p;
+ after_slash_or_colon = 1;
+ } else if (after_slash_or_colon) {
+ start = p;
+ end = limit;
+ after_slash_or_colon = 0;
+ }
+ }
+
+ return xstrndup(start, end - start);
+}
+
+static void
+setup_reference(void)
+{
+ struct stat buf;
+ const char *ref_git, *alternates;
+ int fd;
+
+ if (!option_reference)
+ return;
+
+ if (!stat(mkpath("%s/.git/objects", option_reference), &buf) &&
+ S_ISDIR(buf.st_mode))
+ ref_git = mkpath("%s/.git", option_reference);
+ else if (!stat(mkpath("%s/objects", option_reference), &buf) &&
+ S_ISDIR(buf.st_mode))
+ ref_git = option_reference;
+ else
+ die("reference repository '%s' is not a local directory.",
+ option_reference);
+
+ ref_git = make_absolute_path(ref_git);
+
+ fd = open(git_path("objects/info/alternates"),
+ O_WRONLY | O_CREAT, 0666);
+ if (fd < 0)
+ die("could not create alternates file\n");
+ alternates = mkpath("%s/objects\n", ref_git);
+ write_or_die(fd, alternates, strlen(alternates));
+ if (close(fd) < 0)
+ die("could not close alternates file\n");
+
+ /* This part is going to be tricky, since it deals with two
+ * repositories. Most code in git works on global state
+ * assumed to be coming from the one active repository, but
+ * here we want to do for-each-ref in one repository and say
+ * update-ref in another. We could just say set_git_dir() and
+ * then say for-each-ref and store the refs in an array and
+ * the say set_git_dir() again to switch to the repository
+ * we're creating and then write out the refs using update-ref. */
+
+ /*
+
+ echo "$ref_git/objects" >"$GIT_DIR/objects/info/alternates"
+ (
+ GIT_DIR="$ref_git" git for-each-ref \
+ --format='%(objectname) %(*objectname)'
+ ) |
+ while read a b
+ do
+ test -z "$a" ||
+ git update-ref "refs/reference-tmp/$a" "$a"
+ test -z "$b" ||
+ git update-ref "refs/reference-tmp/$b" "$b"
+ done
+
+ */
+}
+
+static void
+cleanup_reference(void)
+{
+ /*
+ test -d "$GIT_DIR/refs/reference-tmp" &&
+ rm -fr "$GIT_DIR/refs/reference-tmp"
+ */
+}
+
+static void
+clone_local(const char *path)
+{
+ /* local hardlink magic */
+ printf("local, from %s\n", path);
+}
+
+static void
+clone_rsync(const char *repo)
+{
+ printf("rsync, from %s\n", repo);
+ if (option_depth > 0)
+ die("shallow over rsync not supported");
+}
+
+static void
+clone_native(const char *repo)
+{
+ printf("native git, from %s\n", repo);
+}
+
+static void
+clone_curl(const char *repo)
+{
+ printf("curl, from %s\n", repo);
+ if (option_depth > 0)
+ die("shallow over rsync not supported");
+}
+
+int cmd_clone(int argc, const char **argv, const char *prefix)
+{
+ int use_local_hardlinks = 1;
+ int use_separate_remote = 1;
+ struct stat buf;
+ const char *repo, *work_tree, *git_dir;
+ char *path, *dir;
+
+ argc = parse_options(argc, argv, builtin_clone_options,
+ builtin_clone_usage, 0);
+
+ if (argc == 0)
+ die("You must specify a repository to clone.");
+
+ if (option_no_hardlinks)
+ use_local_hardlinks = 0;
+
+ if (option_bare) {
+ if (option_origin)
+ die("--bare and --origin %s options are incompatible.",
+ option_origin);
+ option_no_checkout = 1;
+ use_separate_remote = 0;
+ }
+
+ if (!option_origin)
+ option_origin = "origin";
+
+ repo = argv[0];
+ path = get_repo_path(repo);
+
+ if (argc == 2) {
+ dir = xstrdup(argv[1]);
+ } else {
+ dir = guess_dir_name(repo);
+ }
+
+ printf("repo: %s, path: %s\n", repo, path);
+ printf("dir: %s\n", dir);
+
+ if (!stat(dir, &buf))
+ die("destination directory '%s' already exists.", dir);
+
+ if (option_bare)
+ work_tree = NULL;
+ else {
+ work_tree = getenv("GIT_WORK_TREE");
+ if (work_tree && !stat(work_tree, &buf))
+ die("working tree '%s' already exists.", work_tree);
+ }
+
+ if (mkdir(dir, 0755))
+ die("could not create repository dir '%s'.", dir);
+ if (work_tree && mkdir(work_tree, 0755))
+ die("could not create work tree dir '%s'.", work_tree);
+
+ if (option_bare || work_tree)
+ git_dir = xstrdup(dir);
+ else
+ git_dir = xstrdup(mkpath("%s/.git", dir));
+
+ set_git_dir(make_absolute_path(git_dir));
+ init_db(git_dir, option_template, option_quiet ? INIT_DB_QUIET : 0);
+
+ if (option_bare)
+ git_config_set("core.bare", "true");
+
+ setup_reference();
+
+ if (path != NULL) {
+ clone_local(path);
+ } else if (!prefixcmp(repo, "rsync://")) {
+ clone_rsync(repo);
+ } else if (!prefixcmp(repo, "https://") ||
+ !prefixcmp(repo, "http://") ||
+ !prefixcmp(repo, "ftp://")) {
+ clone_curl(repo);
+ } else {
+ clone_native(repo);
+ }
+
+ cleanup_reference();
+
+
+
+ return 0;
+}
diff --git a/builtin-init-db.c b/builtin-init-db.c
index e1393b8..0ddfb46 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -330,49 +330,11 @@ static void guess_repository_type(const char
*git_dir)
return;
}
-static const char init_db_usage[] =
-"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
-
-/*
- * If you want to, you can share the DB area with any number of
branches.
- * That has advantages: you can save space by sharing all the SHA1
objects.
- * On the other hand, it might just make lookup slower and messier. You
- * be the judge. The default case is to have one DB per managed
directory.
- */
-int cmd_init_db(int argc, const char **argv, const char *prefix)
+int init_db(const char *git_dir, const char *template_dir, unsigned int
flags)
{
- const char *git_dir;
const char *sha1_dir;
- const char *template_dir = NULL;
char *path;
- int len, i, reinit;
- int quiet = 0;
-
- for (i = 1; i < argc; i++, argv++) {
- const char *arg = argv[1];
- if (!prefixcmp(arg, "--template="))
- template_dir = arg+11;
- else if (!strcmp(arg, "--shared"))
- shared_repository = PERM_GROUP;
- else if (!prefixcmp(arg, "--shared="))
- shared_repository = git_config_perm("arg", arg+9);
- else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
- quiet = 1;
- else
- usage(init_db_usage);
- }
-
- /*
- * GIT_WORK_TREE makes sense only in conjunction with GIT_DIR
- * without --bare. Catch the error early.
- */
- git_dir = getenv(GIT_DIR_ENVIRONMENT);
- if ((!git_dir || is_bare_repository_cfg == 1)
- && getenv(GIT_WORK_TREE_ENVIRONMENT))
- die("%s (or --work-tree=<directory>) not allowed without "
- "specifying %s (or --git-dir=<directory>)",
- GIT_WORK_TREE_ENVIRONMENT,
- GIT_DIR_ENVIRONMENT);
+ int len, reinit;
guess_repository_type(git_dir);
@@ -388,7 +350,6 @@ int cmd_init_db(int argc, const char **argv, const
char *prefix)
/*
* Set up the default .git directory contents
*/
- git_dir = getenv(GIT_DIR_ENVIRONMENT);
if (!git_dir)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
safe_create_dir(git_dir, 0);
@@ -427,7 +388,7 @@ int cmd_init_db(int argc, const char **argv, const
char *prefix)
git_config_set("receive.denyNonFastforwards", "true");
}
- if (!quiet)
+ if (!(flags & INIT_DB_QUIET))
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
shared_repository ? " shared" : "",
@@ -435,3 +396,48 @@ int cmd_init_db(int argc, const char **argv, const
char *prefix)
return 0;
}
+
+static const char init_db_usage[] =
+"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
+
+/*
+ * If you want to, you can share the DB area with any number of
branches.
+ * That has advantages: you can save space by sharing all the SHA1
objects.
+ * On the other hand, it might just make lookup slower and messier. You
+ * be the judge. The default case is to have one DB per managed
directory.
+ */
+int cmd_init_db(int argc, const char **argv, const char *prefix)
+{
+ const char *git_dir;
+ const char *template_dir = NULL;
+ unsigned int flags = 0;
+ int i;
+
+ for (i = 1; i < argc; i++, argv++) {
+ const char *arg = argv[1];
+ if (!prefixcmp(arg, "--template="))
+ template_dir = arg+11;
+ else if (!strcmp(arg, "--shared"))
+ shared_repository = PERM_GROUP;
+ else if (!prefixcmp(arg, "--shared="))
+ shared_repository = git_config_perm("arg", arg+9);
+ else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
+ flags |= INIT_DB_QUIET;
+ else
+ usage(init_db_usage);
+ }
+
+ /*
+ * GIT_WORK_TREE makes sense only in conjunction with GIT_DIR
+ * without --bare. Catch the error early.
+ */
+ git_dir = getenv(GIT_DIR_ENVIRONMENT);
+ if ((!git_dir || is_bare_repository_cfg == 1)
+ && getenv(GIT_WORK_TREE_ENVIRONMENT))
+ die("%s (or --work-tree=<directory>) not allowed without "
+ "specifying %s (or --git-dir=<directory>)",
+ GIT_WORK_TREE_ENVIRONMENT,
+ GIT_DIR_ENVIRONMENT);
+
+ return init_db(git_dir, template_dir, flags);
+}
diff --git a/builtin.h b/builtin.h
index 6f01e96..8e59778 100644
--- a/builtin.h
+++ b/builtin.h
@@ -24,6 +24,7 @@ extern int cmd_check_attr(int argc, const char **argv,
const char *prefix);
extern int cmd_check_ref_format(int argc, const char **argv, const char
*prefix);
extern int cmd_cherry(int argc, const char **argv, const char *prefix);
extern int cmd_cherry_pick(int argc, const char **argv, const char
*prefix);
+extern int cmd_clone(int argc, const char **argv, const char *prefix);
extern int cmd_clean(int argc, const char **argv, const char *prefix);
extern int cmd_commit(int argc, const char **argv, const char *prefix);
extern int cmd_commit_tree(int argc, const char **argv, const char
*prefix);
diff --git a/cache.h b/cache.h
index 510154b..8c5f6af 100644
--- a/cache.h
+++ b/cache.h
@@ -230,6 +230,10 @@ extern const char *prefix_filename(const char
*prefix, int len, const char *path
extern void verify_filename(const char *prefix, const char *name);
extern void verify_non_filename(const char *prefix, const char *name);
+#define INIT_DB_QUIET 0x0001
+
+extern int init_db(const char *git_dir, const char *template_dir,
unsigned int flags);
+
#define alloc_nr(x) (((x)+16)*3/2)
/*
diff --git a/git-clone.sh b/contrib/examples/git-clone.sh
similarity index 100%
rename from git-clone.sh
rename to contrib/examples/git-clone.sh
diff --git a/git.c b/git.c
index 9606937..9236833 100644
--- a/git.c
+++ b/git.c
@@ -293,6 +293,7 @@ static void handle_internal_command(int argc, const
char **argv)
{ "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ "cherry", cmd_cherry, RUN_SETUP },
{ "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { "clone", cmd_clone },
{ "clean", cmd_clean, RUN_SETUP | NEED_WORK_TREE },
{ "commit", cmd_commit, RUN_SETUP | NEED_WORK_TREE },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
--
1.5.3.4
^ permalink raw reply related
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 16:36 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <8aa486160711210815g5a1973c2see28a6263fc56030@mail.gmail.com>
Hi,
On Wed, 21 Nov 2007, Santi B?jar wrote:
> On Nov 21, 2007 4:59 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 21 Nov 2007, Santi B?jar wrote:
> >
> > > 1) git-clone does not accept a bundle file, even if git-fetch does.
> > > I've made a patch to use git-fetch in git-clone for this.
> >
> > This, along with rewriting git-clone as a very thin wrapper over
> > git-init, -remote and -fetch, is a really low hanging fruit.
>
> For the basic/normal mode it can be a very thin wrapper but you have to
> support --local, --shared, --reference...
That is not all that difficult.
> > > 2) The bundles created with "git bundle" does not record the HEAD,
> > > they resolve the symbolic name to a branch name.
> >
> > It imitates ls-remote output.
>
> No, it does not.
>
> With a newly created project with one commit:
>
> $ git ls-remote git.git
> b71992713c17c3a29f9566e1b50e8cf402375faf HEAD
> b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
>
> $ git bundle create git.bdl HEAD master
>
> $ git bundle list-heads git.bdl
> b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
> b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
Ah, I misunderstood. I thought you were expecting that the first line
would read
refs/heads/master HEAD
Alas, this behaviour stems from dwim_ref() returning "refs/heads/master"
as real ref.
I am not quite sure how to solve this, though. Let me see what I can come
up with.
Ciao,
Dscho
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-21 16:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711211632090.27959@racer.site>
On Nov 21, 2007 5:36 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 21 Nov 2007, Santi B?jar wrote:
>
> > On Nov 21, 2007 4:59 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > On Wed, 21 Nov 2007, Santi B?jar wrote:
> > >
> > > > 1) git-clone does not accept a bundle file, even if git-fetch does.
> > > > I've made a patch to use git-fetch in git-clone for this.
> > >
> > > This, along with rewriting git-clone as a very thin wrapper over
> > > git-init, -remote and -fetch, is a really low hanging fruit.
> >
> > For the basic/normal mode it can be a very thin wrapper but you have to
> > support --local, --shared, --reference...
>
> That is not all that difficult.
I did not say it was difficult, I said it was not a very thin wrapper.
>
> > > > 2) The bundles created with "git bundle" does not record the HEAD,
> > > > they resolve the symbolic name to a branch name.
> > >
> > > It imitates ls-remote output.
> >
> > No, it does not.
> >
> > With a newly created project with one commit:
> >
> > $ git ls-remote git.git
> > b71992713c17c3a29f9566e1b50e8cf402375faf HEAD
> > b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
> >
> > $ git bundle create git.bdl HEAD master
> >
> > $ git bundle list-heads git.bdl
> > b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
> > b71992713c17c3a29f9566e1b50e8cf402375faf refs/heads/master
>
> Ah, I misunderstood.
Maybe because of my non-native english :-)
> I thought you were expecting that the first line
> would read
>
> refs/heads/master HEAD
or
ref: refs/heads/master HEAD
That would be perfect, but it is a different story.
>
> Alas, this behaviour stems from dwim_ref() returning "refs/heads/master"
> as real ref.
>
> I am not quite sure how to solve this, though. Let me see what I can come
> up with.
Thank you.
Santi
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-21 16:52 UTC (permalink / raw)
To: Johannes Schindelin, Santi Béjar; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711211544510.27959@racer.site>
Johannes Schindelin wrote:
> On Wed, 21 Nov 2007, Jakub Narebski wrote:
>> Santi Bejar wrote:
>>
>>> 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
>>>
>>> [remote "bundle"]
>>> url = /file/to/bundle
>>> fetch = "+refs/heads/*:refs/remotes/bundle/*"
>>>
>>> $ git push bundle
>>>
>>> would create a bundle in /file/to/bundle with the same branches as a
>>> normal git push, but considering the remote branches as the local
>>> remotes/bundle/*
>>
>> And how you would differentiate between path meaning bundle, and path
>> meaning "local" protocol, i.e. git repository on the same filesystem?
>
> Maybe because the git repository is specified as an existing directory?
> The bundle is specified as a (possibly non-existing) file...
That has the disadvantage of pushing to bundle when you make an error
in the lastpart of path to existing repository.
After thinking about it a bit, I think it would be better to use
bundle:// pseudoprotocol for the URL including config (bundle://file,
bundle:///path/to/bundle) and --bundle option to git push for
commandline.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] bundle create: keep symbolic refs' names instead of resolving them
From: Johannes Schindelin @ 2007-11-21 16:53 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <8aa486160711210815g5a1973c2see28a6263fc56030@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2328 bytes --]
When creating a bundle, symbolic refs used to be resolved to the
non-symbolic refs they point to before being written to the list
of contained refs. I.e. "git bundle create a1.bundle HEAD master"
would show something like
388afe7881b33102fada216dd07806728773c011 refs/heads/master
388afe7881b33102fada216dd07806728773c011 refs/heads/master
Introduce a special handling so that the symbolic refs are listed
with the names passed on the command line.
Noticed by Santi Béjar.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
bundle.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index e4d60cd..5e8242f 100644
--- a/bundle.c
+++ b/bundle.c
@@ -6,6 +6,7 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "refs.h"
static const char bundle_signature[] = "# v2 git bundle\n";
@@ -231,12 +232,17 @@ int create_bundle(struct bundle_header *header, const char *path,
for (i = 0; i < revs.pending.nr; i++) {
struct object_array_entry *e = revs.pending.objects + i;
unsigned char sha1[20];
- char *ref;
+ const char *ref;
+ int flag;
if (e->item->flags & UNINTERESTING)
continue;
- if (dwim_ref(e->name, strlen(e->name), sha1, &ref) != 1)
+ ref = resolve_ref(e->name, sha1, 1, &flag);
+ if (!ref)
continue;
+ if (flag & REF_ISSYMREF)
+ ref = e->name;
+
/*
* Make sure the refs we wrote out is correct; --max-count and
* other limiting options could have prevented all the tips
@@ -249,7 +255,6 @@ int create_bundle(struct bundle_header *header, const char *path,
if (!(e->item->flags & SHOWN) && e->item->type == OBJ_COMMIT) {
warning("ref '%s' is excluded by the rev-list options",
e->name);
- free(ref);
continue;
}
/*
@@ -280,7 +285,6 @@ int create_bundle(struct bundle_header *header, const char *path,
obj->flags |= SHOWN;
add_pending_object(&revs, obj, e->name);
}
- free(ref);
continue;
}
@@ -289,7 +293,6 @@ int create_bundle(struct bundle_header *header, const char *path,
write_or_die(bundle_fd, " ", 1);
write_or_die(bundle_fd, ref, strlen(ref));
write_or_die(bundle_fd, "\n", 1);
- free(ref);
}
if (!ref_count)
die ("Refusing to create empty bundle.");
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 16:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Santi Béjar, git
In-Reply-To: <200711211752.40264.jnareb@gmail.com>
Hi,
On Wed, 21 Nov 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
> > On Wed, 21 Nov 2007, Jakub Narebski wrote:
> >> Santi Bejar wrote:
> >>
> >>> 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
> >>>
> >>> [remote "bundle"]
> >>> url = /file/to/bundle
> >>> fetch = "+refs/heads/*:refs/remotes/bundle/*"
> >>>
> >>> $ git push bundle
> >>>
> >>> would create a bundle in /file/to/bundle with the same branches as a
> >>> normal git push, but considering the remote branches as the local
> >>> remotes/bundle/*
> >>
> >> And how you would differentiate between path meaning bundle, and path
> >> meaning "local" protocol, i.e. git repository on the same filesystem?
> >
> > Maybe because the git repository is specified as an existing directory?
> > The bundle is specified as a (possibly non-existing) file...
>
> That has the disadvantage of pushing to bundle when you make an error
> in the lastpart of path to existing repository.
As I wrote in another reply, I would not allow overwriting an existing
file.
> After thinking about it a bit, I think it would be better to use
> bundle:// pseudoprotocol for the URL including config (bundle://file,
> bundle:///path/to/bundle) and --bundle option to git push for
> commandline.
I don't like that at all.
Specifying a non-existing file should be good enough.
Ciao,
Dscho
^ permalink raw reply
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Jakub Narebski @ 2007-11-21 16:44 UTC (permalink / raw)
To: linux-kernel; +Cc: git
In-Reply-To: <20071121151831.GO1001@machine.or.cz>
Petr Baudis wrote:
> On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
>> ...
>> tags
>> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3
>> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2
>> 4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1
>> 6 weeks ago v2.6.23 Linux 2.6.23
>>
>> which drives me crazy, because, without looking at the calendar, and
>> calculator, I don't really know which month was 6 weeks ago, and 4
>> days ago, either!
>
> I have myself never been sure if the relative times are a good idea or
> not. :-) Sometimes I hate them, sometimes they are more convenient...
Additionally if we want support caching in gitweb, and not need to rewrite
cached file, then we should use absolute time everywhere in gitweb (perhaps
rewriting to relative using JavaScript, or output filter,...).
There is some cutoff where gitweb stops displaying relative time and
displays date; gitweb should also always provide absolute date in tooltip
on mouseover (in title attribute), if it does not then it is a bug.
[...]
>> Of course, this problem doesn't look so hard if we forget about
>> git internals: I can imagine keeping a simple database, which
>> could simply retrieve commit numbers from these ChangeLogs, and
>> connecting this with gitweb's commit page as well... For
>> performance reasons, doing it only for stable and testing, so with
>> -rc 'precision' would be very helpful too.
>
> It isn't too hard if we don't forget about git internals either. It's
> just that getting this information might not be cheap. But maybe I'm
> wrong and this won't be a problem for sane projects. Someone should post
> a patch. ;-)
Perhaps the following solution would be good idea:
1. use git-describe to find nearest commit
2. if it took long / if the distance from tag is large
then make some special tag denoting calculated git-describe e.g.
in tag name
3. if found tag is helper tag created in previous step, recaulculate
true git-describe from it, or just output closest contained tag.
This needs write access to repository, although can be done using simple
database... what do you think?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 17:07 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <1195662180.28318.19.camel@hinata.boston.redhat.com>
Hi,
On Wed, 21 Nov 2007, Kristian H?gsberg wrote:
> On Wed, 2007-11-21 at 15:59 +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Wed, 21 Nov 2007, Santi B?jar wrote:
> >
> > > 1) git-clone does not accept a bundle file, even if git-fetch does. I've
> > > made a patch to use git-fetch in git-clone for this.
> >
> > This, along with rewriting git-clone as a very thin wrapper over git-init,
> > -remote and -fetch, is a really low hanging fruit.
> >
> > Or maybe go the full nine yards and build it in. Should be a breeze now,
> > given parse_options() and run_command().
>
> I started doing this, which is pretty stupid as I'm pressed to find time
> to finish up builtin-commit. Nevertheless, could you elaborate on the
> plan here? How would you rewrite it to just use remote and fetch? I
> just finished the boilerplate option parsing stuff (patch below) and
> started reading the core of git-clone.sh, but if most of this can be
> replaced I'd like to hear about it :)
After handling the options like --reference, and except for special
handling of a local clone (not via file:// protocol), it should be as easy
as
git remote add -f origin $url &&
case "$no_checkout" in
t)
;;
*)
git checkout -f -b master remotes/origin/HEAD
;;
esac
(Of course I'd use run_command() for this.)
I would avoid at all costs to reimplement the different methods for the
different protocols.
Ciao,
Dscho
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-21 17:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Santi Béjar, git
In-Reply-To: <Pine.LNX.4.64.0711211658510.27959@racer.site>
Johannes Schindelin wrote:
> On Wed, 21 Nov 2007, Jakub Narebski wrote:
>> Johannes Schindelin wrote:
>>> On Wed, 21 Nov 2007, Jakub Narebski wrote:
>>>> Santi Bejar wrote:
>>>>
>>>>> 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
>>>>>
>>>>> [remote "bundle"]
>>>>> url = /file/to/bundle
>>>>> fetch = "+refs/heads/*:refs/remotes/bundle/*"
>>>>>
>>>>> $ git push bundle
>>>>>
>>>>> would create a bundle in /file/to/bundle with the same branches as a
>>>>> normal git push, but considering the remote branches as the local
>>>>> remotes/bundle/*
>>>>
>>>> And how you would differentiate between path meaning bundle, and path
>>>> meaning "local" protocol, i.e. git repository on the same filesystem?
>>>
>>> Maybe because the git repository is specified as an existing directory?
>>> The bundle is specified as a (possibly non-existing) file...
>>
>> That has the disadvantage of pushing to bundle when you make an error
>> in the lastpart of path to existing repository.
>
> As I wrote in another reply, I would not allow overwriting an existing
> file.
> Specifying a non-existing file should be good enough.
What I meant here that if you do "git push /some/path/to/rpeo.git", with
mistake in the last part of path to repository, you would end up with
a bundle, and you would have to really watch what happened to catch
the error.
I'd rather use "git push bundle:///some/path/to/bundle" or
"git push --bundle bundlename" to catch errors better.
Besides it should be IMHO be possible to overwrite bundle if you are
doing fast-forward push...
--
Jakub Narebski
Poland
^ permalink raw reply
* [RFC] use typechange as rename source
From: Jeff King @ 2007-11-21 17:12 UTC (permalink / raw)
To: git
Today in one of my repositories I did something like this:
$ mv foo bar
$ ln -s bar foo
$ git add .
and I expected git-status to claim:
typechange: foo
renamed: foo -> bar
but it didn't find the rename (without -C) because the path 'foo' still
exists. So there is a disconnect in what git and I think of as "exists".
Should typechanges make a file eligible as a rename src?
A quickie patch to implement this is:
diff --git a/diffcore-rename.c b/diffcore-rename.c
index f9ebea5..5a34e8a 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -417,6 +417,10 @@ void diffcore_rename(struct diff_options *options)
p->one->rename_used++;
register_rename_src(p->one, p->score);
}
+ else if (DIFF_PAIR_TYPE_CHANGED(p)) {
+ p->one->rename_used++;
+ register_rename_src(p->one, p->score);
+ }
else if (detect_rename == DIFF_DETECT_COPY) {
/*
* Increment the "rename_used" score by
There are a few add-on questions:
- should typechanges in both directions be used, or just file ->
symlink?
- this actually produces a 'copied' status rather than a 'renamed'
since the 'foo' entry does still exist. Is this reasonable?
-Peff
^ permalink raw reply related
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-21 17:06 UTC (permalink / raw)
To: git
In-Reply-To: <8aa486160711210654p357ccd87i4809e0cda9471303@mail.gmail.com>
[Cc: Santi Béjar <sbejar@gmail.com>, git@vger.kernel.org]
Santi Béjar wrote:
> 1) git-clone does not accept a bundle file, even if git-fetch does.
> I've made a patch to use git-fetch in git-clone for this.
[...]
> 3) I can "git fetch" a bundle but I cannot "git push" a bundle
We would also need "git ls-remote <bundle>" and "git fsck <bundle>"
to demote git-bundle to porcelain status :-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 17:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Santi Béjar, git
In-Reply-To: <200711211811.34391.jnareb@gmail.com>
Hi,
On Wed, 21 Nov 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
> > On Wed, 21 Nov 2007, Jakub Narebski wrote:
> >
> >> That has the disadvantage of pushing to bundle when you make an error
> >> in the lastpart of path to existing repository.
> >
> > As I wrote in another reply, I would not allow overwriting an existing
> > file.
>
> > Specifying a non-existing file should be good enough.
>
> What I meant here that if you do "git push /some/path/to/rpeo.git", with
> mistake in the last part of path to repository, you would end up with a
> bundle, and you would have to really watch what happened to catch the
> error.
I use tab completion all the time, so this would not happen to me. IMHO
that is a lesser issue than to introduce a "protocol".
> I'd rather use "git push bundle:///some/path/to/bundle" or "git push
> --bundle bundlename" to catch errors better.
>
> Besides it should be IMHO be possible to overwrite bundle if you are
> doing fast-forward push...
Not as far as I can see. A push there would see what the bundle has
already, and put them into the new bundle as _prerequisites_. So the
bundle would lose information.
BTW this was my gripe (that I decided not to make public earlier) with
Santi's proposal to begin with: a push would not have any way to specify
what the other side has already. So I think "git push <bundle>" is the
wrong way of creating a bundle.
Except if we add some cunning strategy not to overwrite, ever, but to
create <bundle>.<n> with an incrementing <n>. But that might be too much.
Ciao,
Dscho
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Johannes Schindelin @ 2007-11-21 17:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fi1ojd$pva$1@ger.gmane.org>
Hi,
On Wed, 21 Nov 2007, Jakub Narebski wrote:
> We would also need "git ls-remote <bundle>" and "git fsck <bundle>" to
> demote git-bundle to porcelain status :-)
git ls-remote <bundle> worked, last time I checked (15 seconds ago). But
git fsck? Since when does something like "git fsck
git://repo.or.cz/git.git" work?
Besides, "git bundle verify <bundle>" works quite well.
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