* Re: Tags not transferred with git pull?
From: Erik Mouw @ 2005-11-04 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <20051104155914.GA9567@ferdyx.org>
On Fri, Nov 04, 2005 at 04:59:14PM +0100, Fernando J. Pereda wrote:
> On Fri, Nov 04, 2005 at 04:53:14PM +0100, Erik Mouw wrote:
> | Is it OK that the latest git (0.99.9c) doesn't get the tags
> | (refs/tags/*) when doing a git pull? It's getting a bit of a nuisance
> | to do a separate rsync to get them right.
>
> As Linus explained in a message earlier, a git fetch --tags will do it.
Ah, right. I got the impression that the latest git was supposed to do
that automatically with a git pull.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Josef Weidendorfer @ 2005-11-04 16:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This allows to specify remote branch names from the
repository this one was cloned from (= remote repository of
"origin" branch), without explicitly adding a branch for them.
Therefore, these remote branches are called implicit.
Use them together with cg-fetch or cg-update.
Example: Your current repository was cloned with
cg-clone git+ssh://remotehost:/path myrep
If this remote repository contains a branch "foo",
you can say inside of myrep:
cg-fetch foo
This fetches "git+ssh://remotehost:/path#foo" into
a local branch "foo" (created if not existing).
Similarily, a "cg-update foo" will fetch the remote
branch and merge it into your current local branch.
After fetching from an implicit remote branch, cg-status
will show the corresponding local branch, but still without
an "R", because that is only shown for explicit branches.
The implicit remote branch in the example above can be
made explicit with
cg-branch-add foo git+ssh://remotehost:/path#foo
Note that cg-update now always tries to fetch from a
remote repository, as every non-explicit branch
name is supposed to be an implicit remote branch.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This patch is RFC. IMHO, it simplifies the usage of Cogito
quite a lot. One difference of cloning with GIT vs. with
Cogito is that Git always clones all remote branches. This can
be limiting if you want to work with multiple repositories,
but allows you to immediatly work with all the branches.
Cogito instead clones only one remote branch, and requires
you to explicitly add further branches with "cg-branch-add".
This is not necessary with implicit remote branches, and
they should cover the standard use case which works with
branches from the repository you clone from.
The nice thing here is that the patch is really small for
the added functionality. If you accept it, I will provide
updates for the documentation and tutorial.
Josef
cg-fetch | 10 +++++++++-
cg-update | 6 +-----
2 files changed, 10 insertions(+), 6 deletions(-)
applies-to: 22948869bcf0ec216ed9aa14e1c5ecc22114d66b
769aa2148fc2b583b071354e8eef3dae74e09c14
diff --git a/cg-fetch b/cg-fetch
index 759488a..5a5aeb1 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -262,7 +262,15 @@ name=${ARGS[0]}
[ "$name" ] || { [ -s "$_git/branches/origin" ] && name=origin; }
[ "$name" ] || die "where to fetch from?"
-uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
+uri=$(cat "$_git/branches/$name" 2>/dev/null) || \
+ { if [ -s "$_git/branches/origin" ]; then
+ uri=$(cat "$_git/branches/origin" 2>/dev/null)
+ uri="$(echo "$uri" | cut -d '#' -f 1)#$name"
+ echo Fetching implicit remote branch "$uri".
+ else
+ die "unknown branch: $name"
+ fi
+ }
rembranch=
if echo "$uri" | grep -q '#'; then
diff --git a/cg-update b/cg-update
index 96035c5..534bf4a 100755
--- a/cg-update
+++ b/cg-update
@@ -39,11 +39,7 @@ name=${ARGS[0]}
[ "$name" ] || { [ -s $_git/branches/origin ] && name=origin; }
[ "$name" ] || die "where to update from?"
-if [ -s "$_git/branches/$name" ]; then
- cg-fetch $force $name || exit 1
-else
- echo "Updating from a local branch."
-fi
+cg-fetch $force $name || exit 1
echo
echo "Applying changes..."
cg-merge $name
^ permalink raw reply related
* Re: Tags not transferred with git pull?
From: Fernando J. Pereda @ 2005-11-04 15:59 UTC (permalink / raw)
To: git
In-Reply-To: <20051104155314.GB23790@harddisk-recovery.nl>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On Fri, Nov 04, 2005 at 04:53:14PM +0100, Erik Mouw wrote:
| Hi,
|
| Is it OK that the latest git (0.99.9c) doesn't get the tags
| (refs/tags/*) when doing a git pull? It's getting a bit of a nuisance
| to do a separate rsync to get them right.
|
As Linus explained in a message earlier, a git fetch --tags will do it.
Cheers,
Ferdy
--
Fernando J. Pereda Garcimart�n
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Tags not transferred with git pull?
From: Jan Harkes @ 2005-11-04 15:57 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20051104155314.GB23790@harddisk-recovery.nl>
On Fri, Nov 04, 2005 at 04:53:14PM +0100, Erik Mouw wrote:
> Is it OK that the latest git (0.99.9c) doesn't get the tags
> (refs/tags/*) when doing a git pull? It's getting a bit of a nuisance
> to do a separate rsync to get them right.
You don't need to fall back on rsync,
git fetch --tags
Jan
^ permalink raw reply
* Tags not transferred with git pull?
From: Erik Mouw @ 2005-11-04 15:53 UTC (permalink / raw)
To: git
Hi,
Is it OK that the latest git (0.99.9c) doesn't get the tags
(refs/tags/*) when doing a git pull? It's getting a bit of a nuisance
to do a separate rsync to get them right.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Marcel Holtmann @ 2005-11-04 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Gleixner
In-Reply-To: <7vmzkl3yl0.fsf@assigned-by-dhcp.cox.net>
Hi Thomas,
> > # cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> > defaulting to local storage area
> > 09:53:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> > Getting alternates list
> > Getting pack list
> > error: The requested URL returned error: 404
>
> That repository is packed but lacks objects/info/packs file.
> Perhaps you need to ask tglx to run git-update-server-info in
> the repository.
can please try to fix it according to Junio's proposal.
Regards
Marcel
^ permalink raw reply
* CFLAGS usage
From: Morten Welinder @ 2005-11-04 15:21 UTC (permalink / raw)
To: GIT Mailing List
Various stuff is being added to CFLAGS, but CFLAGS is not being used
after being composed in CFLAGS_ALL.
Morten
grep CFLAGS Makefile
CFLAGS = -g -O2 -Wall
ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
CFLAGS += -I$(CURLDIR)/include
CFLAGS += -I$(OPENSSLDIR)/include
CFLAGS += -I$(ICONVDIR)/include
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
$(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIB_FILE) $(SIMPLE_LIB)
$(CC) -c $(ALL_CFLAGS) \
$(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o ctype.o
$(CC) $(ALL_CFLAGS) -o $@ $^
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
^ permalink raw reply
* Re: New ASCII Art
From: Jon Loeliger @ 2005-11-04 15:14 UTC (permalink / raw)
To: git
Junio wrote:
> Thanks for doing this. You have a sale.
Oh wow! You already added them. I won't send you
a patch to do so then. :-) Thanks!
Except this one:
Git Merge Operations
====================
> Logically this belongs to "Merging two branches" in the Tutorial
> document. The Tutorial introduction claims the document intends to
> show how the core level operates to implement higher level scripts,
> but currently we lack the lower-level details in the text that would
> go well together with this illustration. Please remind me that I
> should write something up at the very end of that section soonish ;-).
Reminder. :-)
jdl
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Paul Collins @ 2005-11-04 14:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xw5h898.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Paul Collins <paul@briny.ondioline.org> writes:
>
>> * Where should git_use_proxy() look? Some git configuration file?
>> An environment variable? Both? Somewhere else?
>
> My preference is put something in .git/config to describe which
> proxy command (maybe the same one with different argument) to
> use depending on where you are going. When you have internal
> hosts and external hosts you would want this to apply only to
> external hosts. Maybe you have two or more gateways and
> depending on which external host you are going you may want to
> use different proxied connection. On top of the config file,
> making it overridable from an environment variable would be
> sensible.
Here is an updated patch that first looks for GIT_PROXY_COMMAND in the
environment and then git.proxycommand in the repository's
configuration file. I have left the calling convention the same --
argv[1] is the host and argv[2] is the port.
I've taken the hostname parsing verbatim from git_tcp_connect(), so it
should now support an explicit port number and whatever that business
with the square brackets is. (Should I move this to a helper function?)
Regarding internal vs. external hosts, the proxy command can simply
run netcat locally to internal hosts, so perhaps that is sufficient.
diff --git a/connect.c b/connect.c
index c2badc7..43eec67 100644
--- a/connect.c
+++ b/connect.c
@@ -448,6 +448,73 @@ static int git_tcp_connect(int fd[2], co
#endif /* NO_IPV6 */
+static char *git_proxy_command = NULL;
+
+static int git_proxy_command_options(const char *var, const char *value)
+{
+ if (git_proxy_command == NULL) {
+ if (!strcmp(var, "git.proxycommand")) {
+ git_proxy_command = xmalloc(strlen(value) + 1);
+ strcpy(git_proxy_command, value);
+ return 0;
+ }
+ }
+
+ return git_default_config(var, value);
+}
+
+static int git_use_proxy(void)
+{
+ git_proxy_command = getenv("GIT_PROXY_COMMAND");
+ git_config(git_proxy_command_options);
+ return git_proxy_command != NULL;
+}
+
+static int git_proxy_connect(int fd[2], const char *prog, char *host, char *path)
+{
+ char *port = STR(DEFAULT_GIT_PORT);
+ char *colon, *end;
+ int pipefd[2][2];
+ pid_t pid;
+
+ if (host[0] == '[') {
+ end = strchr(host + 1, ']');
+ if (end) {
+ *end = 0;
+ end++;
+ host++;
+ } else
+ end = host;
+ } else
+ end = host;
+ colon = strchr(end, ':');
+
+ if (colon) {
+ *colon = 0;
+ port = colon + 1;
+ }
+
+ if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
+ die("unable to create pipe pair for communication");
+ pid = fork();
+ if (!pid) {
+ dup2(pipefd[1][0], 0);
+ dup2(pipefd[0][1], 1);
+ close(pipefd[0][0]);
+ close(pipefd[0][1]);
+ close(pipefd[1][0]);
+ close(pipefd[1][1]);
+ execlp(git_proxy_command, git_proxy_command, host, port, NULL);
+ die("exec failed");
+ }
+ fd[0] = pipefd[0][0];
+ fd[1] = pipefd[1][1];
+ close(pipefd[0][1]);
+ close(pipefd[1][0]);
+ packet_write(fd[1], "%s %s\n", prog, path);
+ return pid;
+}
+
/*
* Yeah, yeah, fixme. Need to pass in the heads etc.
*/
@@ -482,8 +549,11 @@ int git_connect(int fd[2], char *url, co
}
}
- if (protocol == PROTO_GIT)
+ if (protocol == PROTO_GIT) {
+ if (git_use_proxy())
+ return git_proxy_connect(fd, prog, host, path);
return git_tcp_connect(fd, prog, host, path);
+ }
if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
die("unable to create pipe pair for communication");
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related
* [PATCH] Document the --no-commit flag
From: Petr Baudis @ 2005-11-04 14:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Also add the reference to merge and fetch options in git-pull's synopsis.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-merge.txt | 6 +++++-
Documentation/git-pull.txt | 2 +-
git-pull.sh | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 8c9c4d8..4174da9 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -8,7 +8,7 @@ git-merge - Grand Unified Merge Driver
SYNOPSIS
--------
-'git-merge' [-n] [-s <strategy>]... <msg> <head> <remote> <remote>...
+'git-merge' [-n] [--no-commit] [-s <strategy>]... <msg> <head> <remote> <remote>...
DESCRIPTION
@@ -22,6 +22,10 @@ OPTIONS
-n::
Do not show diffstat at the end of the merge.
+--no-commit::
+ Do not commit right away - it just does the merge and lets you commit
+ manually after you inspect the changes done.
+
-s <strategy>::
use that merge strategy; can be given more than once to
specify them in the order they should be tried. If
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index cef4c0a..a46d6b9 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -8,7 +8,7 @@ git-pull - Pull and merge from another r
SYNOPSIS
--------
-'git-pull' <repository> <refspec>...
+'git-pull' [merge_options] [fetch_options] <repository> <refspec>...
DESCRIPTION
diff --git a/git-pull.sh b/git-pull.sh
index 9601627..e23d4f5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -7,7 +7,7 @@
. git-sh-setup || die "Not a git archive"
usage () {
- die "git pull [-n] [-s strategy]... <repo> <head>..."
+ die "git pull [-n] [--no-commit] [-s strategy]... <repo> <head>..."
}
strategy_args= no_summary= no_commit=
^ permalink raw reply related
* Re: Trying to Update All Heads of a Repository
From: Jon Loeliger @ 2005-11-04 14:49 UTC (permalink / raw)
To: git
Junio says:
My "pu" is somewhat special; it is rewound and rebased all the time,
so merging with its older self would conflict with it. That's why
my example remotes/origin file has '+' in front of it. It tells
git-fetch that the other side _might_ rebase and fetch would not
result in a fast-forward merge when that happens.
So, from the git-pull man page:
For "git push", the local ref that matches <src> is used to fast
forward the remote ref that matches <dst>. If the optional plus + is
used, the remote ref is updated even if it does not result in a fast
forward update.
Ah-ha! Wait. But here's the conceptual missing piece: When might I
_know_ I have the situation where a fast-forward update might not
happen? And as a remote puller, that would be "never" -- unless I know
something about the nature of the remote end. That is, like you said,
"pu" is subject to wild fluctuation and non-linear behavior. But any
random puller can't know that a priori. So far, that is out-of-band
information about a branch that needs to be "available".
I think my previous "Ah ha!" paragraph should be massaged and added to
the git-pull man page as part of the above (man page) quoted material.
That's one.
Junio explained:
> Alternatively, with your original remotes/origin
> file, you should be able to do:
>
> $ git checkout master
> $ git fetch origin master:origin +pu:pu maint:maint
> $ git pull . origin
What an excellent example for the git-pull man page! That's two.
Junio also exampled:
My "guinea pig" repository has this in $GIT_DIR/remotes/origin:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
Pull: +pu:pu
Pull: maint:maint
This means that my "master" is copied to the "origin" branch of
the guinea pig repository and "pu" and "maint" are copies of my
"pu" and "maint" branches. You never do your own development on
branches that appear on the right hand side of colon on "Pull"
lines (i.e. origin, pu and maint) in this repository. They are
to be updated by git-fetch.
The notion that multiple pull lines can be placed in the .git/remotes
file should be added to the git-pull man page. That's three.
Furthermore, there is one very important guideline you just
stated in that paragraph:
You never do your own development on branches that appear on the
right hand side of colon on "Pull" lines in a repository. They are
to be updated by git-fetch.
And it might bear stating the corollary:
The reason for a "Pull: master:origin" line is to side-step
the above maxim and provide a unique place where the local
developer can do her own work.
I'll consider that concept item four for the git-pull man page . :-)
> Sorry, my "pu" does not fast forward. The branch is to showcase what
> I've received or picked up from the list, and what changes are under
> consideration for inclusion.
Heh. I understand it now! :-) No problem.
And finally:
> The "hold/draw" topic branch (thanks for your ASCII art) is fully
> merged into my "master"; in fact it's head is the master branch head.
That's five-ish. I'm on deck for some git-pull man page and
drawing documentation patches. Coming up Real Soon Now.
Thanks for the explanations!
jdl
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Wolfgang Denk @ 2005-11-04 13:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacgkzqau.fsf@assigned-by-dhcp.cox.net>
In message <7vacgkzqau.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> > Missing object of tag v2.6.14-rc3... unable to retrieve
>
> I do not have a clue on this one; I am assuming that it is
> coming from cg-fetch.
>
> Quick question. Is the source repository fully packed (i.e. git
> repack followed by git prune)? If that is the case there is
Yes, it is. I decided to run repack + update-server-info hoping that
would help to cleanup the state.
> nothing to worry about. The latest git prunes empty
> $GIT_OBJECT_DIRECTORY/??/ directories and recreates them on
> demand.
I see. Thanks.
> > error: Could not interpret tags/DENX-2005-10-02-18:30 as something to pull
>
> This one I can answer. It is the colon in your tag name.
> Please rename it to make git-check-ref-format(1) happy, run
> git-update-server-info(1) and try again.
Understood. Thanks.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown
^ permalink raw reply
* RPMS: git and cogito
From: Horst von Brand @ 2005-11-03 23:24 UTC (permalink / raw)
To: git
Just built and installed git and cogito from RPMs, after doing a "make rpm"
in each from current repositories. This was on x86_64, Fedora rawhide.
I will continue building and installing RPMs almost daily from now on.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Junio C Hamano @ 2005-11-04 9:59 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20051104092146.E5E35353C33@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> Missing object of tag v2.6.14-rc3... unable to retrieve
I do not have a clue on this one; I am assuming that it is
coming from cg-fetch.
> [Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/bc
>
> These directories really don't exist:
>
> $ cd /srv/git/linux-2.6-denx.git/objects
> . ls -l
> total 8
> drwxrwxr-x 2 wd wd 4096 Nov 4 09:52 info
> drwxrwxr-x 2 wd wd 4096 Nov 3 15:15 pack
Quick question. Is the source repository fully packed (i.e. git
repack followed by git prune)? If that is the case there is
nothing to worry about. The latest git prunes empty
$GIT_OBJECT_DIRECTORY/??/ directories and recreates them on
demand.
> The question is : why are they requested?
Fetching over http is what we call a "commit walker" -- it
learns the top commit object names, gets that object and reads
it to learn what other objects it needs to slurp, and keeps
asking the next object, one by one. When dealing with a packed
repository, it first asks individual objects (expecting they
would be found in $GIT_OBJECT_DIRECTORY/??/ directory), and when
not found it fetchs packs and looks inside. Recent commit
walker knows how to issue multiple requests while earlier
request is still in transit, so you can expect some requests to
individual objects. That is benign.
>> Cloning over git native transport should work, though:
>>
>> $ git clone git://git.kernel.org/pub/scm/lin.../history.git history
>
> This does not work for me, either.
The above uses git:// URL but your failure below uses http://
> -> git clone http://www.denx.de/git/linux-2.6-denx.git bar
> ...
> walk c264852726dde251a0c09ec22f61a9be8b0db68b
> walk 69903d6500c73af8329a5fba7153b0d50748981c
> walk b59a9504cb93db7fae31e60760725d48652a1fc3
> error: Could not interpret tags/DENX-2005-10-02-18:30 as something to pull
This one I can answer. It is the colon in your tag name.
Please rename it to make git-check-ref-format(1) happy, run
git-update-server-info(1) and try again.
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Junio C Hamano @ 2005-11-04 9:44 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Petr Baudis, Marcel Holtmann, git
In-Reply-To: <20051104092626.GL1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> 09:58:42 URL:http://www.denx.de/git/linux-2.6-denx.git/refs/tags/DENX-2005-10-02-18:30 [41/41] -> "refs/tags/DENX-2005-10-02-18:30" [1]
I do not know if Cogito works it around or the above just
happens to work, but (notice colon there) tag names that do not
pass git-check-ref-format(1) are not supported.
>> And I did run git-update-server-info, even with --force.
You may want to double check that all your refs appear in
denx.git/info/refs file, and similarly all your packs are
described in denx.git/objects/info/packs file.
> And what exactly is the problem? It seemed to clone ok.
Oh, if that is the case I would stop worrying about it, then.
However, there is this bit that looks suspicious.
>> Missing object of tag v2.6.14-rc3... unable to retrieve
This does not look like an error message I generate, so I am
assuming it is coming from cg-fetch.
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Wolfgang Denk @ 2005-11-04 9:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Marcel Holtmann, git
In-Reply-To: <20051104092626.GL1431@pasky.or.cz>
In message <20051104092626.GL1431@pasky.or.cz> you wrote:
>
> > 09:58:42 ERROR 404: Not Found.
> > 09:58:42 URL:http://www.denx.de/git/linux-2.6-denx.git/refs/tags/DENX-2005-10-02-18:30 [41/41] -> "refs/tags/DENX-2005-10-02-18:30" [1]
> > ...
> > Missing object of tag v2.6.14-rc3... unable to retrieve
> And what exactly is the problem? It seemed to clone ok.
There was a 404 error, and the "Missing object of tag" message.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It usually takes more than three weeks to prepare a good impromptu
speech. - Mark Twain
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Petr Baudis @ 2005-11-04 9:26 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Junio C Hamano, Marcel Holtmann, git
In-Reply-To: <20051104092146.E5E35353C33@atlas.denx.de>
Dear diary, on Fri, Nov 04, 2005 at 10:21:46AM CET, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> In message <7vmzkl3yl0.fsf@assigned-by-dhcp.cox.net> you wrote:
> >
> > > # cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> > > defaulting to local storage area
> > > 09:53:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> ...
> > That repository is packed but lacks objects/info/packs file.
> > Perhaps you need to ask tglx to run git-update-server-info in
> > the repository.
>
> I have the same (or a very similar) problem with our Linux repo:
>
> -> cg-clone http://www.denx.de/git/linux-2.6-denx.git foo
> ...
> defaulting to local storage area
> 09:54:53 URL:http://www.denx.de/git/linux-2.6-denx.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> Getting alternates list
> Getting pack list
> Getting index for pack eceba3479417b338c2e156b1c6dfd69f3f0eaad1
> Getting index for pack b3c6fbdfa36a326815de6358885c7a570a986b1b
> Getting index for pack 6122f3ffa476a089122c0bffbbb7a7ce31304b56
> Getting index for pack 06949712bb970fc1dd2e13f50accdcd2bf992536
> Getting index for pack 459148e2ea863c15479d69ed4886a6f200c79a49
> Getting pack 459148e2ea863c15479d69ed4886a6f200c79a49
> which contains 010a4c0059a82b834b4d7f65d5cdd4a9717d8ea7
> progress: 3 objects, 0 bytes
> Getting pack 06949712bb970fc1dd2e13f50accdcd2bf992536
> which contains 5014bfa48ac169e0748e1e9651897788feb306dc
> progress: 12210 objects, 0 bytes
> 09:58:42 ERROR 404: Not Found.
> 09:58:42 URL:http://www.denx.de/git/linux-2.6-denx.git/refs/tags/DENX-2005-10-02-18:30 [41/41] -> "refs/tags/DENX-2005-10-02-18:30" [1]
> ...
> 09:58:43 URL:http://www.denx.de/git/linux-2.6-denx.git/refs/tags/v2.6.14-rc5 [41/41] -> "refs/tags/v2.6.14-rc5" [1]
> FINISHED --09:58:43--
> Downloaded: 19,240 bytes in 30 files
> Missing object of tag v2.6.14-rc3... unable to retrieve
> New branch: 010a4c0059a82b834b4d7f65d5cdd4a9717d8ea7
> Cloned to foo/ (origin http://www.denx.de/git/linux-2.6-denx.git available as branch "origin")
>
> And I did run git-update-server-info, even with --force.
And what exactly is the problem? It seemed to clone ok.
> In the server log I see messages like these:
>
> [Fri Nov 04 09:54:52 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/01
..snip..
> [Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/bc
The fetching code first tries to look into the unpacked object store
(that are those errors) and if that fails, it grabs a pack.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Wolfgang Denk @ 2005-11-04 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marcel Holtmann, git
In-Reply-To: <7vmzkl3yl0.fsf@assigned-by-dhcp.cox.net>
In message <7vmzkl3yl0.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> > # cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> > defaulting to local storage area
> > 09:53:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
...
> That repository is packed but lacks objects/info/packs file.
> Perhaps you need to ask tglx to run git-update-server-info in
> the repository.
I have the same (or a very similar) problem with our Linux repo:
-> cg-clone http://www.denx.de/git/linux-2.6-denx.git foo
...
defaulting to local storage area
09:54:53 URL:http://www.denx.de/git/linux-2.6-denx.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
Getting alternates list
Getting pack list
Getting index for pack eceba3479417b338c2e156b1c6dfd69f3f0eaad1
Getting index for pack b3c6fbdfa36a326815de6358885c7a570a986b1b
Getting index for pack 6122f3ffa476a089122c0bffbbb7a7ce31304b56
Getting index for pack 06949712bb970fc1dd2e13f50accdcd2bf992536
Getting index for pack 459148e2ea863c15479d69ed4886a6f200c79a49
Getting pack 459148e2ea863c15479d69ed4886a6f200c79a49
which contains 010a4c0059a82b834b4d7f65d5cdd4a9717d8ea7
progress: 3 objects, 0 bytes
Getting pack 06949712bb970fc1dd2e13f50accdcd2bf992536
which contains 5014bfa48ac169e0748e1e9651897788feb306dc
progress: 12210 objects, 0 bytes
09:58:42 ERROR 404: Not Found.
09:58:42 URL:http://www.denx.de/git/linux-2.6-denx.git/refs/tags/DENX-2005-10-02-18:30 [41/41] -> "refs/tags/DENX-2005-10-02-18:30" [1]
...
09:58:43 URL:http://www.denx.de/git/linux-2.6-denx.git/refs/tags/v2.6.14-rc5 [41/41] -> "refs/tags/v2.6.14-rc5" [1]
FINISHED --09:58:43--
Downloaded: 19,240 bytes in 30 files
Missing object of tag v2.6.14-rc3... unable to retrieve
New branch: 010a4c0059a82b834b4d7f65d5cdd4a9717d8ea7
Cloned to foo/ (origin http://www.denx.de/git/linux-2.6-denx.git available as branch "origin")
And I did run git-update-server-info, even with --force.
In the server log I see messages like these:
[Fri Nov 04 09:54:52 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/01
[Fri Nov 04 09:54:52 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/info/http-alternates
[Fri Nov 04 09:54:53 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/info/alternates
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/5b
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/ca
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/50
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/98
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/79
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/4e
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/79
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/c1
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/f9
[Fri Nov 04 09:55:12 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/e5
[Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/e1
[Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/67
[Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/0c
[Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/b6
[Fri Nov 04 09:55:13 2005] [error] [client 84.150.96.170] File does not exist: /srv/git/linux-2.6-denx.git/objects/bc
These directories really don't exist:
$ cd /srv/git/linux-2.6-denx.git/objects
. ls -l
total 8
drwxrwxr-x 2 wd wd 4096 Nov 4 09:52 info
drwxrwxr-x 2 wd wd 4096 Nov 3 15:15 pack
The question is : why are they requested?
> Cloning over git native transport should work, though:
>
> $ git clone git://git.kernel.org/pub/scm/lin.../history.git history
This does not work for me, either. It runs a long time without
obvious problems, but finally fails with:
-> git clone http://www.denx.de/git/linux-2.6-denx.git bar
...
walk c264852726dde251a0c09ec22f61a9be8b0db68b
walk 69903d6500c73af8329a5fba7153b0d50748981c
walk b59a9504cb93db7fae31e60760725d48652a1fc3
error: Could not interpret tags/DENX-2005-10-02-18:30 as something to pull
I have to admit that I have absolutely no clue (1) what might have
caused this situation nor (2) how to fix it :-(
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* Re: RFC: GIT networked storage
From: Junio C Hamano @ 2005-11-04 9:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <436AE6A3.4040103@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> How easy is it to add a new storage backend to git?
Almost everything is contained within sha1_file.c.
Object creation side is simple -- everybody who creates an
object (e.g update-index registering blobs, write-tree writing
the toplevel and intermediate level trees, commit-tree building
a commit object, unpack-objects exploding a pack) goes through
write_sha1_file(), which checks if the object is already
available using has_sha1_file() and creates a new object in the
local .git/objects/?? directory. I am assuming that you are not
planning to create objects in a remote peer from within the git
code path, and instead to have background process that replicate
them over the network to peer repositories, so you probably do
not have to touch this side.
Extending inspection and reading from existing objects for your
networked storage may be somewhat messy, but starting points
are:
. has_sha1_file() takes the object name and returns true/false;
if the object is available to us in any form (be it in one of
the alternate object stores or the local repository, as
individual object in an objects/??/ file or stored in a pack).
Currently it looks at packs and then checks individual files
for performance reasons (to minimize seeks and to prevent
polluting dcache with many negative hits); you would be adding
another data source.
. read_sha1_file() takes the object name, and returns the
uncompressed contents of the object in addition to the type
and the size.
. sha1_object_info() takes the object name and returns the type
of the object and optionally returns the size of it, without
reading the contents. Some programs call this before reading
the data using read_sha1_file(), so you might want to use this
as a cue to prefetch from a remote peer; also you _might_ want
to keep type and size cached if you plan to implement
forgetful storage that deliberately loses objects and expects
to refetch it from its peers. Good test program once you are
done extending this part is git-cat-file with -t and -s flag.
The above three are the primary read interfaces, but there are
some places that cheat by assuming that packs and individual
objects are the only two kinds of sources for the object data,
so you need to be careful. For example, write_sha1_to_fd(),
which is used only by ssh-upload, first tries to call
map_sha1_file_internal(), which is only valid for individual
objects, to grab the object data, and when it fails, calls
read_packed_sha1(), which is only valid for objects in packs,
without even checking if read_packed_sha1() succeeded. This
doesn't crash only because the caller of write_sha1_to_fd()
checks if the object is available by calling has_sha1_file()
itself before calling this function, but you would need to
change it to fall back on your networked storage if you do not
want to crash when used by ssh-upload.
HTH, and have fun.
^ permalink raw reply
* RFC: GIT networked storage
From: Jeff Garzik @ 2005-11-04 4:42 UTC (permalink / raw)
To: git; +Cc: H. Peter Anvin
In-Reply-To: <7vwtjp2h59.fsf@assigned-by-dhcp.cox.net>
Here's an experiment I've been dying to try.
The current "tracker-less" BitTorrent[1] employs a distributed hash
table[2] called Kademlia, where the total content is spread across a
bunch of computers on the network. I kinda prefer TANGLE[3] to Kademlia.
Anyway, I was thinking that it would be a neat experiment to add simple
TANGLE-like peer-to-peer code, to enable git to query "the git network
hash table" for content.
Comments, or any pre-code-creation objections?
How easy is it to add a new storage backend to git?
To restrict unlimited uploading, I'm thinking that I'll want the system
to fall back to {www,git,rsync}.kernel.org as the original source of
content. [though the code will obviously be generic, and not hardcode
*.kernel.org policy]
Thanks,
Jeff
[1] http://www.bittorrent.com/trackerless.html
[2] http://www.etse.urv.es/~cpairot/dhts.html
[3] http://www.nicemice.net/amc/research/tangle/
^ permalink raw reply
* GIT 0.99.9c
From: Junio C Hamano @ 2005-11-04 4:04 UTC (permalink / raw)
To: git
GIT 0.99.9c is found at http://kernel.org/pub/software/scm/git/
as usual. It includes the following fixes and documentation
updates since 0.99.9b:
Alex Riesen:
remove CR/LF from .gitignore
Jon Loeliger
Illustration: "Fundamental Git Index Operations"
Illustration: "Git Diff Types"
Illustration: "Commit DAG Revision Naming"
Junio C Hamano:
Do not put automatic merge message after signed-off-by line.
git-clone: do not forget to create origin branch.
Make test-date buildable again.
Do not fail on hierarchical branch names.
Ignore '\r' at the end of line in $GIT_DIR/config
Be careful when dereferencing tags (credits Pasky).
Document --since and --until options to rev-parse.
Add --no-commit to git-merge/git-pull.
Add 'ours' merge strategy.
git-merge-ours: make sure our index matches HEAD
GIT 0.99.9c
Peter Eriksen:
Clean up the SunOS Makefile rule
The slow and steady march toward 1.0 continues.
I plan to do another full sweep in the documentation directory
on my next GIT day.
On the proposed updates front, I am hoping to include Nick's
http-push using DAV in the "master" branch soon. And I would
appreciate somebody who actually uses svnimport to Ack on
Yaacov's svnimport fix.
^ permalink raw reply
* Re: binary safe?
From: Chris Wedgwood @ 2005-11-04 3:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0511031447020.27915@g5.osdl.org>
On Thu, Nov 03, 2005 at 02:50:21PM -0800, Linus Torvalds wrote:
> So the _only_ problem should be "git diff" (and related patch-based
> tools - git-apply etc). They'll simply not work. For similar
> reasons, a three-way merge will obviously fail.
I always thought it would be nice for binary files if SCMs could
export a summary of what ranges of bytes changes or even xdelta'ish
details.
Given that people do stick large multi-MB binary blobs in SCMs and
sometimes these update only a few bytes at a time it has some value.
^ permalink raw reply
* Re: Problem cloning the Linux history tree
From: Junio C Hamano @ 2005-11-04 3:02 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1131008187.6634.14.camel@localhost.localdomain>
Marcel Holtmann <marcel@holtmann.org> writes:
> # cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> defaulting to local storage area
> 09:53:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> Getting alternates list
> Getting pack list
> error: The requested URL returned error: 404
That repository is packed but lacks objects/info/packs file.
Perhaps you need to ask tglx to run git-update-server-info in
the repository.
Cloning over git native transport should work, though:
$ git clone git://git.kernel.org/pub/scm/lin.../history.git history
^ permalink raw reply
* Re: Trying to Update All Heads of a Repository
From: Junio C Hamano @ 2005-11-04 2:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EXpN9-00034x-7g@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> First, I have this, because it came with a git-clone:
>
> % cat .git/remotes/origin
> URL: rsync://rsync.kernel.org/pub/scm/git/git.git
> Pull: master:origin
>
> I don't know how to say "Grab all the updates for
> all the heads for which I have heads in my .git/refs".
My "guinea pig" repository has this in $GIT_DIR/remotes/origin:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
Pull: +pu:pu
Pull: maint:maint
This means that my "master" is copied to the "origin" branch of
the guinea pig repository and "pu" and "maint" are copies of my
"pu" and "maint" branches. You never do your own development on
branches that appear on the right hand side of colon on "Pull"
lines (i.e. origin, pu and maint) in this repository. They are
to be updated by git-fetch.
And the regular workflow over there is:
$ cd over-there
$ git checkout master
$ git pull
... build, test, install
> So I hope "git pull --help" will tell me:
You're right. We need to add --help to that command.
> Like could I have just said?:
>
> % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git
> or
> % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git master:origin
> % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu
> % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git todo:todo
You could. Alternatively, with your original remotes/origin
file, you should be able to do:
$ git checkout master
$ git fetch origin master:origin +pu:pu maint:maint
$ git pull . origin
> On to the pu branch:
>
> Rats. But why did this fail? I've changed nothing in my tree.
> I'm pulling remote pu into local pu directly. I think this
> should Just Work...
My "pu" is somewhat special; it is rewound and rebased all the
time, so merging with its older self would conflict with it.
That's why my example remotes/origin file has '+' in front of
it. It tells git-fetch that the other side _might_ rebase and
fetch would not result in a fast-forward merge when that happens.
I should advertise that fact more often, for people who came
here after I did the last such advertisement.
> But I really thought that this should Just Work?
> Shouldn't this be a fast forward, nice-n-clean-n-easy?
Sorry, my "pu" does not fast forward. The branch is to showcase
what I've received or picked up from the list, and what changes
are under consideration for inclusion.
The "pu" head is built by pulling a handful topic branches on
top of the "master" branch. My private repository right now
looks like this:
! [hold/draw] Illustration: "Commit DAG Revision Naming"
! [hold/http] [PATCH 2/2] Add support for git-http-push to git-pu...
! [hold/svn] Several fixes to import mono's svn tree
! [jcmu] git-tag: Do not assume the working tree root is writab...
! [maint] GIT 0.99.9c
* [master] Illustration: "Commit DAG Revision Naming"
! [pu] Merge branch 'toys'
! [toys] git-shallow-pack
--------
+ [pu] Merge branch 'toys'
++ [toys] git-shallow-pack
+ [pu^] Merge branches 'hold/svn' and 'hold/http'
+ + [hold/http] [PATCH 2/2] Add support for git-http-push to ...
+ + [hold/http^] [PATCH 1/2] Add support for pushing to a rem...
+ + [hold/svn] Several fixes to import mono's svn tree
+ + [jcmu] git-tag: Do not assume the working tree root is wr...
+ [maint] GIT 0.99.9c
+ ++++ [hold/draw] Illustration: "Commit DAG Revision Naming"
+ ++++ [hold/draw^] Illustration: "Git Diff Types"
+ ++++ [hold/draw~2] Illustration: "Fundamental Git Index Operat...
+ ++++ [hold/draw~3] git-merge-ours: make sure our index matches...
+ ++++ [hold/draw~4] Add 'ours' merge strategy.
+ ++++ [hold/draw~5] Add --no-commit to git-merge/git-pull.
+ ++++ [hold/draw~6] Document --since and --until options to rev...
++++++++ [hold/draw~7] Be careful when dereferencing tags.
The "hold/draw" topic branch (thanks for your ASCII art) is
fully merged into my "master"; in fact it's head is the master
branch head. Nick's http-push and Yaacov's svnimport fixes are
kept in separate topic branches, which originated at the
previous "master" (now master~7 == hold/draw~7), and they have
not been rebased, partly I am lazy and partly there are no
changes that would cause merge conflicts with other branches.
On the other hand, the commit structure of my public repository
right now looks like this:
! [maint] GIT 0.99.9c
* [master] Illustration: "Commit DAG Revision Naming"
! [pu] Merge branch 'toys'
---
+ [pu] Merge branch 'toys'
+ [pu^2] git-shallow-pack
+ [pu^] Merge branches 'hold/svn' and 'hold/http'
+ [pu^^3] [PATCH 2/2] Add support for git-http-push to git-push script
+ [pu^^3^] [PATCH 1/2] Add support for pushing to a remote reposito...
+ [pu^^2] Several fixes to import mono's svn tree
+ [pu~2] git-tag: Do not assume the working tree root is writable.
+ [maint] GIT 0.99.9c
+++ [master] Illustration: "Commit DAG Revision Naming"
That is, I do not publish the heads of my topic branches, but
you can get them yourselves by looking at the merge logs in the
"pu" branch. "toys" head is pu^2, "hold/svn" head is pu^^2, etc.
I think this "bundling together into one pu" head policy
somewhat discourages contributor developments on top of "pu"
material, but on the other hand the topic branches in my
repository tend to have relatively short lifespan, and I'd
rather not clutter people's cloned repositories with these
transient branches.
If you wanted to try out Nick's http-push from "hold/http"
branch, for example, but prefer not to worry about bugs in other
things in "pu", you need to do this:
1. Find out if I keep the change as a separate topic branch.
Either run "gitk --all" and inspect the commit structure
between "master" and "pu", or look at the "pu" merge log from
"git-show-branch" output above.
2. Isolate the topic branch from "pu", discarding other stuff
you are not interested in. After step 1, you figured out
that pu^^3 is the tip of hold/http branch, so make a local
branch for that, and merge the tip of "origin" on top of it,
because hold/http branch may not have been rebased to the
current master:
$ git checkout -b http-push pu^^3
$ git pull -n . origin
$ git show-branch origin http-push http-push^
! [origin] Illustration: "Commit DAG Revision Naming"
* [http-push] Merge branch 'master'
! [http-push^] [PATCH 2/2] Add support for git-http-push to ...
---
+ [http-push] Merge branch 'master'
++ [origin] Illustration: "Commit DAG Revision Naming"
++ [origin^] Illustration: "Git Diff Types"
++ [origin~2] Illustration: "Fundamental Git Index Operations"
++ [origin~3] git-merge-ours: make sure our index matches HEAD
++ [origin~4] Add 'ours' merge strategy.
++ [origin~5] Add --no-commit to git-merge/git-pull.
++ [origin~6] Document --since and --until options to rev-parse.
++ [http-push^] [PATCH 2/2] Add support for git-http-push to ...
++ [http-push^^] [PATCH 1/2] Add support for pushing to a rem...
+++ [http-push^~2] Be careful when dereferencing tags.
3. Build, test, install and have fun.
4. Suppose you came up with a neat enhancement idea or two to
Nick's http-push. Do your development and make commits on
top of the current branch. Your commit structure would look
like this after a couple of commits:
$ git show-branch origin http-push
! [origin] Illustration: "Commit DAG Revision Naming"
* [http-push] Add feature nitfol.
--
+ [http-push] Add feature nitfol.
+ [http-push^] Add feature frotz.
+ [http-push~2] Merge branch 'master'
++ [origin] Illustration: "Commit DAG Revision Naming"
5. Then feed me your changes, perhaps CC:ing the original author:
$ git format-patch -k -m http-push~2
* 0001-Add-feature-frotz.txt
* 0002-Add-feature-nitfol.txt
You could publish the head of this branch and tell me to pull
from there, but I have a slight preference to receiving e-mail
patches if the changes are about the material still in "pu".
^ permalink raw reply
* Re: Empty temp files in the .git/objects subdirectories
From: Junio C Hamano @ 2005-11-04 2:32 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051104015452.GB3001@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> These are created by git-http-fetch to hold data as it's being
> fetch from the remote repository. They are left behind after a transfer
> error so that the next time git-http-fetch runs it can pick up where it
> left off. If they're empty though, it would make more sense to delete
> them rather than leaving them behind for the next attempt.
That makes sense. Thanks.
^ 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