* Re: efficient cloning
From: Junio C Hamano @ 2006-03-20 23:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060320224123.GP18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Then you can make a simple change that if a refname matches a directory
> in refs/remotes/, you rewrite it as refs/remotes/<refname>/master. This
> makes 'origin' work seamlessly in a natural way and a lot more elegantly
> than if you make up an artifical rule like "if the remote's branch is
> master, save it as origin, but save all the other branches verbatim".
The "origin" rename applies only to the traditional one.
Separate remote stuff stores master in remotes/master.
At least that is the way I remember I designed it to work.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-20 23:04 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200603201730.19373.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Monday 20 March 2006 09:54, you wrote:
>> * A new flag --use-separate-remote stops contaminating local
>> branch namespace by upstream branch names. The upstream
>> branch heads are copied in .git/refs/remotes/ instead of
>
> Shouldn't this be .git/refs/remotes/origin/?
> Ie. different namespaces for different remotes?
>
> Linus wanted to still be able to say "origin" which automatically
> would map to "remotes/origin/master", where the name of the remote
I do not remember that, but even if he said something similar to
that, I suspect it would not be "map remotes/origin/master to
origin", but "origin could mean remotes/origin when origin is
the unique tail-name anywhere under refs/".
I think what is reasonable is something like this:
- If you start from a repository cloned in the traditional
way, the upstream "master" is kept track of with your
"origin", so "diff origin master" would be "my changes on top
of the upstream".
- If your repository was cloned with --use-separate-remote, the
upstream "master" is refs/remotes/master, so the same diff
can be had with "diff remotes/master master".
- Regardless of how you started your cloned repository, with an
$GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in
a separate message, you can rearrange things to organize the
refs/ hierarchy any way you want.
- You could for example arrange to track my "master" as
refs/heads/origin and all the other branch heads under
refs/remotes/junkio/ (or not even track my other branches
if you are not interested). Then the same diff can be had
with "diff origin master".
- You could for example arrange to track all my branches in
refs/remotes/junkio/, and if git-pasky were still alive,
Pasky's branches in refs/remotes/pasky. If we had a "take
the unique tail-name anywhere under refs/" logic, the same
diff can be had with "diff junkio/master master".
So I think two things that would be nice to have on top of what
we have are (1) the said "remotes-and-refs editor" [*1*], and
(2) a change to sha1_name.c to look for places other than
built-in tags/ and heads/ under refs/ to find a unique
tail-match.
Since I do not do Porcelain, (2) would obviously be the next
thing for me to work on on this topic. I should also address
"Ouch I did not realize I have given the same name to a tag and
a branch" warning issue while doing so.
[Footnote]
*1* ... which currently I do not plan to do myself unless I have
absolutely nothing else to do and really bored. A sound of huge
hint dropping ;-).
^ permalink raw reply
* Re: efficient cloning
From: Petr Baudis @ 2006-03-20 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6aokd7m.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Mar 20, 2006 at 10:39:41PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> You are commenting on the initial 'git-clone' and specifically
> on one of its optional feature. What multiple upstreams?
>
> The whole point of what git-clone does on top of making a
> straight clone of the remote is to give you a reasonable
> starting point. The traditional "master" -> "origin" mapping is
> good for cloning a typical single-head repository. If your
> upsteram has more branches, --use-separate-remote would help you
> to start your branch namespace uncluttered.
Yes, but I just see no connecting with a "starting point" whatsoever -
why should this be inherent to initial clone? I can see no greater
chance that I will want all the branches than when I want to fetch from
another repository later (especially in a truly distributed
environment).
So, it doesn't make sense to me to limit this feature only to the
initial clone case - I want to be able to reasonably "fetch all
branches" of any repository I wish. Without massive namespace clashes,
the reasonable way is to just have a separate directory in
.git/refs/remotes/ for each repository (and it's my understanding that
this was the original proposal as well).
Then you can make a simple change that if a refname matches a directory
in refs/remotes/, you rewrite it as refs/remotes/<refname>/master. This
makes 'origin' work seamlessly in a natural way and a lot more elegantly
than if you make up an artifical rule like "if the remote's branch is
master, save it as origin, but save all the other branches verbatim".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-20 21:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060320151833.GN18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I think this sucks the way it is, because you still have only a single
> namespace for remotes (still quite a huge improvement to the current git
> situation), but you can have many upstreams.
Come on, give me a break.
You are commenting on the initial 'git-clone' and specifically
on one of its optional feature. What multiple upstreams?
The whole point of what git-clone does on top of making a
straight clone of the remote is to give you a reasonable
starting point. The traditional "master" -> "origin" mapping is
good for cloning a typical single-head repository. If your
upsteram has more branches, --use-separate-remote would help you
to start your branch namespace uncluttered.
If you want to go fancier after the initial clone to
"cg-add-branch" more upstreams, you can implement a customized
editor, even a graphical one if you want, that inspects
$GIT_DIR/[branches,remotes} _and_ $GIT_DIR/{heads,remotes},
shows the current status, and lets you edit the contents of a
$GIT_DIR/remotes/foobar _while_ making matching changes to what
are under $GIT_DIR/{heads,remotes}.
^ permalink raw reply
* Re: Pulling tags from git.git
From: Junio C Hamano @ 2006-03-20 20:31 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87lkv5ynnp.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> It's not obvious from the git-tag documentation that signing makes a
> difference down the road in terms of replication. IOW, I don't
> question the distinction per se, but it's counter-intuitive if you
> aren't told about it.
Agreed. Please make it so ;-).
^ permalink raw reply
* Re: Pulling tags from git.git
From: Florian Weimer @ 2006-03-20 18:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <441064DD.2010903@op5.se>
* Andreas Ericsson:
>> The current implementation is rather counter-intuitive because it's
>> much easier to create lightweight tags, and you wonder why they aren't
>> replicated by fetches (but some other tags are).
> Well, you wouldn't want to go through the trouble of writing a
> tag-message for a temporary tag, but signing and writing a short note
> for a tag that you intend those who share your workload to have is not
> that much of a bother imo.
It's not obvious from the git-tag documentation that signing makes a
difference down the road in terms of replication. IOW, I don't
question the distinction per se, but it's counter-intuitive if you
aren't told about it.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Nick Hengeveld @ 2006-03-20 19:54 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano, Paolo Ciarrocchi
In-Reply-To: <441EF46E.5050907@etek.chalmers.se>
On Mon, Mar 20, 2006 at 07:29:02PM +0100, Lukas Sandström wrote:
> Perhaps a repository config option to treat a 302 as a 404?
FWIW, it used to work that way and was modified to follow redirects back at
commit 66c9ec25553ce7332c46e2017b9c4d7c26310fff.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] http-push: don't assume char is signed
From: Nick Hengeveld @ 2006-03-20 19:50 UTC (permalink / raw)
To: git
Declare remote_dir_exists[] as signed char to be sure that values of -1
are valid.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
446e5a54db80664a0ae2a418766811136952067e
diff --git a/http-push.c b/http-push.c
index 42b0d59..a35e74d 100644
--- a/http-push.c
+++ b/http-push.c
@@ -66,7 +66,7 @@ enum XML_Status {
static int pushing = 0;
static int aborted = 0;
-static char remote_dir_exists[256];
+static signed char remote_dir_exists[256];
static struct curl_slist *no_pragma_header;
static struct curl_slist *default_headers;
--
1.2.4.g55c6-dirty
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Petr Baudis @ 2006-03-20 19:43 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano, Paolo Ciarrocchi
In-Reply-To: <441EF46E.5050907@etek.chalmers.se>
Dear diary, on Mon, Mar 20, 2006 at 07:29:02PM CET, I got a letter
where Lukas Sandström <lukass@etek.chalmers.se> said that...
> Junio C Hamano wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >>http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
> >
> > To be fair, the site is _not_ missing anything from HTTP
> > protocol perspective, because when git asks 8d/ea0351... file,
> > the server responds with a regular "HTTP/1.0 200 OK" response.
> > So it is _your_ repository that is corrupt -- instead of
> > correctly _lacking_ the file you should have removed with
> > prune-packed, it has a garbage file.
>
> Actually, it sends a 302 redirect.
>
> Perhaps a repository config option to treat a 302 as a 404?
I think that would be too ugly _and_ specific a workaround for the
particular site. It's reasonable to keep it generalized for all the
broken repositories when already doing it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Signed char assumption..
From: Linus Torvalds @ 2006-03-20 19:20 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
On ppc, I now get:
http-push.c: In function 'add_fetch_request':
http-push.c:831: warning: comparison is always false due to limited range of data type
http-push.c: In function 'add_send_request':
http-push.c:864: warning: comparison is always false due to limited range of data type
because the code assumes that "char" is signed and can take a -1.
Linus
^ permalink raw reply
* [PATCH] http-push: add support for deleting remote branches
From: Nick Hengeveld @ 2006-03-20 18:31 UTC (permalink / raw)
To: git
Processes new command-line arguments -d and -D to remove a remote branch
if the following conditions are met:
- one branch name is present on the command line
- the specified branch name matches exactly one remote branch name
- the remote HEAD is a symref
- the specified branch is not the remote HEAD
- the remote HEAD resolves to an object that exists locally (-d only)
- the specified branch resolves to an object that exists locally (-d only)
- the specified branch is an ancestor of the remote HEAD (-d only)
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 219 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 218 insertions(+), 1 deletions(-)
245873d765d8d380a146c7b77d09c1e9c2645daa
diff --git a/http-push.c b/http-push.c
index 42b0d59..e44310f 100644
--- a/http-push.c
+++ b/http-push.c
@@ -7,6 +7,7 @@
#include "http.h"
#include "refs.h"
#include "revision.h"
+#include "exec_cmd.h"
#include <expat.h>
@@ -32,6 +33,7 @@ enum XML_Status {
#define DAV_PROPFIND "PROPFIND"
#define DAV_PUT "PUT"
#define DAV_UNLOCK "UNLOCK"
+#define DAV_DELETE "DELETE"
/* DAV lock flags */
#define DAV_PROP_LOCKWR (1u << 0)
@@ -64,6 +66,9 @@ enum XML_Status {
#define FETCHING (1u << 7)
#define PUSHING (1u << 8)
+/* We allow "recursive" symbolic refs. Only within reason, though */
+#define MAXDEPTH 5
+
static int pushing = 0;
static int aborted = 0;
static char remote_dir_exists[256];
@@ -2103,6 +2108,197 @@ static int remote_exists(const char *pat
return -1;
}
+static void fetch_symref(char *path, char **symref, unsigned char *sha1)
+{
+ char *url;
+ struct buffer buffer;
+ struct active_request_slot *slot;
+ struct slot_results results;
+
+ url = xmalloc(strlen(remote->url) + strlen(path) + 1);
+ sprintf(url, "%s%s", remote->url, path);
+
+ buffer.size = 4096;
+ buffer.posn = 0;
+ buffer.buffer = xmalloc(buffer.size);
+
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (results.curl_result != CURLE_OK) {
+ die("Couldn't get %s for remote symref\n%s",
+ url, curl_errorstr);
+ }
+ } else {
+ die("Unable to start remote symref request");
+ }
+ free(url);
+
+ if (*symref != NULL)
+ free(*symref);
+ *symref = NULL;
+ memset(sha1, 0, 20);
+
+ if (buffer.posn == 0)
+ return;
+
+ /* If it's a symref, set the refname; otherwise try for a sha1 */
+ if (!strncmp((char *)buffer.buffer, "ref: ", 5)) {
+ *symref = xcalloc(buffer.posn - 5, 1);
+ strncpy(*symref, (char *)buffer.buffer + 5, buffer.posn - 6);
+ } else {
+ get_sha1_hex(buffer.buffer, sha1);
+ }
+
+ free(buffer.buffer);
+}
+
+static int verify_merge_base(unsigned char *head_sha1, unsigned char *branch_sha1)
+{
+ int pipe_fd[2];
+ pid_t merge_base_pid;
+ char line[PATH_MAX + 20];
+ unsigned char merge_sha1[20];
+ int verified = 0;
+
+ if (pipe(pipe_fd) < 0)
+ die("Verify merge base: pipe failed");
+
+ merge_base_pid = fork();
+ if (!merge_base_pid) {
+ static const char *args[] = {
+ "merge-base",
+ "-a",
+ NULL,
+ NULL,
+ NULL
+ };
+ args[2] = strdup(sha1_to_hex(head_sha1));
+ args[3] = sha1_to_hex(branch_sha1);
+
+ dup2(pipe_fd[1], 1);
+ close(pipe_fd[0]);
+ close(pipe_fd[1]);
+ execv_git_cmd(args);
+ die("merge-base setup failed");
+ }
+ if (merge_base_pid < 0)
+ die("merge-base fork failed");
+
+ dup2(pipe_fd[0], 0);
+ close(pipe_fd[0]);
+ close(pipe_fd[1]);
+ while (fgets(line, sizeof(line), stdin) != NULL) {
+ if (get_sha1_hex(line, merge_sha1))
+ die("expected sha1, got garbage:\n %s", line);
+ if (!memcmp(branch_sha1, merge_sha1, 20)) {
+ verified = 1;
+ break;
+ }
+ }
+
+ return verified;
+}
+
+static int delete_remote_branch(char *pattern, int force)
+{
+ struct ref *refs = remote_refs;
+ struct ref *remote_ref = NULL;
+ unsigned char head_sha1[20];
+ char *symref = NULL;
+ int match;
+ int patlen = strlen(pattern);
+ int i;
+ struct active_request_slot *slot;
+ struct slot_results results;
+ char *url;
+
+ /* Find the remote branch(es) matching the specified branch name */
+ for (match = 0; refs; refs = refs->next) {
+ char *name = refs->name;
+ int namelen = strlen(name);
+ if (namelen < patlen ||
+ memcmp(name + namelen - patlen, pattern, patlen))
+ continue;
+ if (namelen != patlen && name[namelen - patlen - 1] != '/')
+ continue;
+ match++;
+ remote_ref = refs;
+ }
+ if (match == 0)
+ return error("No remote branch matches %s", pattern);
+ if (match != 1)
+ return error("More than one remote branch matches %s",
+ pattern);
+
+ /*
+ * Remote HEAD must be a symref (not exactly foolproof; a remote
+ * symlink to a symref will look like a symref)
+ */
+ fetch_symref("HEAD", &symref, head_sha1);
+ if (!symref)
+ return error("Remote HEAD is not a symref");
+
+ /* Remote branch must not be the remote HEAD */
+ for (i=0; symref && i<MAXDEPTH; i++) {
+ if (!strcmp(remote_ref->name, symref))
+ return error("Remote branch %s is the current HEAD",
+ remote_ref->name);
+ fetch_symref(symref, &symref, head_sha1);
+ }
+
+ /* Run extra sanity checks if delete is not forced */
+ if (!force) {
+ /* Remote HEAD must resolve to a known object */
+ if (symref)
+ return error("Remote HEAD symrefs too deep");
+ if (is_zero_sha1(head_sha1))
+ return error("Unable to resolve remote HEAD");
+ if (!has_sha1_file(head_sha1))
+ return error("Remote HEAD resolves to object %s\nwhich does not exist locally, perhaps you need to fetch?", sha1_to_hex(head_sha1));
+
+ /* Remote branch must resolve to a known object */
+ if (is_zero_sha1(remote_ref->old_sha1))
+ return error("Unable to resolve remote branch %s",
+ remote_ref->name);
+ if (!has_sha1_file(remote_ref->old_sha1))
+ return error("Remote branch %s resolves to object %s\nwhich does not exist locally, perhaps you need to fetch?", remote_ref->name, sha1_to_hex(remote_ref->old_sha1));
+
+ /* Remote branch must be an ancestor of remote HEAD */
+ if (!verify_merge_base(head_sha1, remote_ref->old_sha1)) {
+ return error("The branch '%s' is not a strict subset of your current HEAD.\nIf you are sure you want to delete it, run:\n\t'git http-push -D %s %s'", remote_ref->name, remote->url, pattern);
+ }
+ }
+
+ /* Send delete request */
+ fprintf(stderr, "Removing remote branch '%s'\n", remote_ref->name);
+ url = xmalloc(strlen(remote->url) + strlen(remote_ref->name) + 1);
+ sprintf(url, "%s%s", remote->url, remote_ref->name);
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_DELETE);
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ free(url);
+ if (results.curl_result != CURLE_OK)
+ return error("DELETE request failed (%d/%ld)\n",
+ results.curl_result, results.http_code);
+ } else {
+ free(url);
+ return error("Unable to start DELETE request");
+ }
+
+ return 0;
+}
+
int main(int argc, char **argv)
{
struct transfer_request *request;
@@ -2112,6 +2308,8 @@ int main(int argc, char **argv)
struct remote_lock *ref_lock = NULL;
struct remote_lock *info_ref_lock = NULL;
struct rev_info revs;
+ int delete_branch = 0;
+ int force_delete = 0;
int objects_to_send;
int rc = 0;
int i;
@@ -2138,7 +2336,15 @@ int main(int argc, char **argv)
push_verbosely = 1;
continue;
}
- usage(http_push_usage);
+ if (!strcmp(arg, "-d")) {
+ delete_branch = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-D")) {
+ delete_branch = 1;
+ force_delete = 1;
+ continue;
+ }
}
if (!remote->url) {
remote->url = arg;
@@ -2158,6 +2364,9 @@ int main(int argc, char **argv)
if (!remote->url)
usage(http_push_usage);
+ if (delete_branch && nr_refspec != 1)
+ die("You must specify only one branch name when deleting a remote branch");
+
memset(remote_dir_exists, -1, 256);
http_init();
@@ -2193,6 +2402,14 @@ int main(int argc, char **argv)
fprintf(stderr, "Fetching remote heads...\n");
get_dav_remote_heads();
+ /* Remove a remote branch if -d or -D was specified */
+ if (delete_branch) {
+ if (delete_remote_branch(refspec[0], force_delete) == -1)
+ fprintf(stderr, "Unable to delete remote branch %s\n",
+ refspec[0]);
+ goto cleanup;
+ }
+
/* match them up */
if (!remote_tail)
remote_tail = &remote_refs;
--
1.2.4.g55c6-dirty
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Lukas Sandström @ 2006-03-20 18:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Paolo Ciarrocchi
In-Reply-To: <7vk6aqql9e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>>http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
>
> To be fair, the site is _not_ missing anything from HTTP
> protocol perspective, because when git asks 8d/ea0351... file,
> the server responds with a regular "HTTP/1.0 200 OK" response.
> So it is _your_ repository that is corrupt -- instead of
> correctly _lacking_ the file you should have removed with
> prune-packed, it has a garbage file.
Actually, it sends a 302 redirect.
Perhaps a repository config option to treat a 302 as a 404?
/Lukas Sandström
^ permalink raw reply
* Re: [ANNOUNCE] qgit 1.1.1
From: Marco Costalba @ 2006-03-20 16:32 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, proski
In-Reply-To: <20060320144613.GA25617@elte.hu>
On 3/20/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Marco Costalba <mcostalba@gmail.com> wrote:
>
> > The wrong command is git-diff-tree -r -c -p 46571...
> >
> > I think it's about the quite new option -c of git-diff-tree.
> >
> > Please upgrade your git to latest version, better upstream one, but
> > 1.2.4 should be enough.
>
> ok, that did the trick.
>
> there's a weird rendering artifact as well, see the white line in the
> screenshot [that i'll send you in a separate mail]. It goes away if i
> drag another window in front of the qgit window. It happens if i
> double-click a 'merge' branch, exit qgit and start it again [and the
> separator line needs to obscur the commit line just partially]. This is
> an uptodate FC4 installation.
>
Yes, sometimes I see it either. To remove I use the scrollbar to
hide/unhide the line,
i.e. to force a repaint.
I think it is something related to Qt rendering engine, I doubt I
could do something about it.
BTW someone off list suggested me to implement a 'git version check'
control and related message box to avoid your troubles to someone
else: I'm surely going to do it.
Marco
^ permalink raw reply
* Re: efficient cloning
From: Josef Weidendorfer @ 2006-03-20 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu09tjy38.fsf@assigned-by-dhcp.cox.net>
On Monday 20 March 2006 09:54, you wrote:
> * A new flag --use-separate-remote stops contaminating local
> branch namespace by upstream branch names. The upstream
> branch heads are copied in .git/refs/remotes/ instead of
Shouldn't this be .git/refs/remotes/origin/?
Ie. different namespaces for different remotes?
Linus wanted to still be able to say "origin" which automatically
would map to "remotes/origin/master", where the name of the remote
branch (here "master") is the first mentioned in the Pull line of
the .git/remotes file in eg.
git diff origin..master
I am not sure whether we really want "take first refspec mentioned on Pull
line", as there can be multiple tracked remote branches with their own local
developments...
Ie. I want to be able to specify: "The local development branch X is based on
the following remote branch Y , which is tracked locally as Z.".
This way, you also could warn/prohobit accidential nonsense merges because of wrong use
of "git-pull".
Josef
^ permalink raw reply
* Question about possible git races
From: Radoslaw Szkodzinski @ 2006-03-20 16:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
I'd like to write a multithreaded application using git, so I'd like to see if
there are any races:
- push vs pull
One thread pushes to the repository while another is pulling from it at the
same time. I should get the older commit.
- push vs push
Both threads push at the same time. What happens?
Any good way to merge those pushes?
(I have full access to both repos)
Possibly those two aren't fast-forward of each other.
I think one of the pushes should abort in this case unless I force it.
- fetch vs fetch
I mean that two threads try to fetch from different repositories to a single
one. Possibly those two aren't fast-forward of each other.
Any good way to merge those fetches?
(I have full access to both repos)
I'm meaning really bare git there, w/o bash+perl scripts.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: efficient cloning
From: Petr Baudis @ 2006-03-20 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Cloos, git
In-Reply-To: <7vu09tjy38.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Mar 20, 2006 at 09:54:03AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> * A new flag --use-separate-remote stops contaminating local
> branch namespace by upstream branch names. The upstream
> branch heads are copied in .git/refs/remotes/ instead of
> .git/refs/heads/ and .git/remotes/origin file is set up to
> reflect this as well. It requires to have fetch/pull update
> to understand .git/refs/remotes by Eric Wong to further
> update the repository cloned this way.
I think this sucks the way it is, because you still have only a single
namespace for remotes (still quite a huge improvement to the current git
situation), but you can have many upstreams. So it would be a quite more
reasonable to have:
.git/refs/remotes/<remotename>/<headname>
This is also how I would like to do it for cg-clone -a (which I planned
to implement the last weekend... well... ;). Actually, I think I will
stay in .git/refs/heads/ at least for now until git versions with
.git/refs/remotes/ in the refs search path will be released.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [ANNOUNCE] qgit 1.1.1
From: Ingo Molnar @ 2006-03-20 14:46 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, proski
In-Reply-To: <e5bfff550603200413i22a37a43n4d5a9b0ba63e880d@mail.gmail.com>
* Marco Costalba <mcostalba@gmail.com> wrote:
> The wrong command is git-diff-tree -r -c -p 46571...
>
> I think it's about the quite new option -c of git-diff-tree.
>
> Please upgrade your git to latest version, better upstream one, but
> 1.2.4 should be enough.
ok, that did the trick.
there's a weird rendering artifact as well, see the white line in the
screenshot [that i'll send you in a separate mail]. It goes away if i
drag another window in front of the qgit window. It happens if i
double-click a 'merge' branch, exit qgit and start it again [and the
separator line needs to obscur the commit line just partially]. This is
an uptodate FC4 installation.
Ingo
^ permalink raw reply
* Re: What should I use instead of git show?
From: Olivier Galibert @ 2006-03-20 13:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Radoslaw Szkodzinski, git
In-Reply-To: <17438.37643.583091.800359@cargo.ozlabs.ibm.com>
On Mon, Mar 20, 2006 at 10:33:31PM +1100, Paul Mackerras wrote:
> Olivier Galibert writes:
>
> > gitk does not seem to have an export function. Dunno about qgit.
>
> Right-click on a commit should bring up a context menu which includes
> a "write commit to file" option. Or did you mean something different
> by "export"?
No, I meant exactly that. Thanks, that can be quite useful.
OG.
^ permalink raw reply
* [PATCH] Be verbose when !initial commit
From: Yasushi SHOJI @ 2006-03-20 13:11 UTC (permalink / raw)
To: git
verbose option in git-commit.sh lead us to run git-diff-index, which
needs a commit-ish we are making diff against. When we are commiting
the fist set, we obviously don't have any commit-ish in the repo. So
we just skip the git-diff-index run.
It might be possible to produce diff against empty but do we need
that?
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
e071afdc1c6e9ce6bbee14aa0652e7bb7043550c
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..1e7c09e 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -161,7 +161,7 @@ run_status () {
}
'
- if test -n "$verbose"
+ if test -n "$verbose" -a -z "$IS_INITIAL"
then
git-diff-index --cached -M -p --diff-filter=MDTCRA $REFERENCE
fi
--
1.2.4
^ permalink raw reply related
* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-20 12:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xr5ld38.fsf@assigned-by-dhcp.cox.net>
On 3/20/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >> This is totally untested, but maybe something like this?
> >
> > It works for me. Just some trailing white space warning when applying.
>
> The change only removes the error message without changing any
> other logic, so if that works for you, I wonder if leaving
> things as they are is a better option than doing anything short
> of implementing an AI that tries to pattern-match the "allegedly
> corrupt file" with "sorry no such page found" in many natural
> languages.
>
> My test patch makes it impossible to track down the real
> breakage when an HTTP-reachable repository _does_ have a corrupt
> object.
>
> So how about doing this instead?
>
> -- >8 --
> + fprintf(stderr,
> +"Some loose object were found to be corrupt, but they might be just\n"
> +"a false '404 Not Found' error message sent with incorrect HTTP\n"
> +"status code. Suggest running git fsck-objects.\n");
> + }
> return rc;
> }
>
I think it's better, read more correct.
Could be a real corrupted file or just a false 404, so better a
warning then an error message and also better a warning then nothing.
Marco
^ permalink raw reply
* Re: [ANNOUNCE] qgit 1.1.1
From: Marco Costalba @ 2006-03-20 12:13 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, proski
In-Reply-To: <20060320102022.GA21917@elte.hu>
On 3/20/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Marco Costalba <mcostalba@gmail.com> wrote:
>
> > > Put in this way it seems a very major bug! really not a small one!
> > >
> > > I cannot reproduce it. Please can you give me some more info as repository
> > > (linux tree?) and commit sha.
> > >
> >
> > And please also the error message that appears in qgit window so to
> > know what git command failed.
>
> i've attached a screenshot of the failure message. It's plain Linus'
> kernel git tree, clicking on any merge commit produces this window. FC4
> box.
>
The wrong command is git-diff-tree -r -c -p 46571...
I think it's about the quite new option -c of git-diff-tree.
Please upgrade your git to latest version, better upstream one, but
1.2.4 should be enough.
Marco
^ permalink raw reply
* Re: What should I use instead of git show?
From: Paul Mackerras @ 2006-03-20 11:33 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Radoslaw Szkodzinski, git
In-Reply-To: <20060313165015.GC87487@dspnet.fr.eu.org>
Olivier Galibert writes:
> gitk does not seem to have an export function. Dunno about qgit.
Right-click on a commit should bring up a context menu which includes
a "write commit to file" option. Or did you mean something different
by "export"?
Paul.
^ permalink raw reply
* Re: gitk: bug report: invalid command name "contmergediff"
From: Paul Mackerras @ 2006-03-20 11:31 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <20060308183718.GA9855@nospam.com>
Rutger Nijlunsing writes:
> Bug report on gitk, maybe already reported.
>
> do:
> gitk HEAD~1000..
>
> ...select first commit (why is this not done automatically?), and keep
> pressing down-arrow.
>
> This gives me:
> Error: invalid command name "contmergediff"
Ooooh, it does too! Thanks, I'll fix that.
Paul.
^ permalink raw reply
* Re: [PATCH] Fix multi-paragraph list items in OPTIONS section
From: Francis Daly @ 2006-03-20 10:41 UTC (permalink / raw)
To: git
On Mon, Mar 20, 2006 at 10:39:46, Jonas Fonseca wrote:
> Asciidoc cannot handle multi-paragraph description list items without the
> need for adding special control characters and reindenting all paragraphs
> but the first.
This issue affects the display of current git-cvsimport and
git-svnimport doc pages. There was a general tidy-up done in
df8baa42fe4eeb5a021ac262caf601f44d2a5746 last October, but additions
since then didn't keep the layout.
I don't think there is a full "fix" for this; either the html docs are
ugly (see the -A section in the pages mentioned above as they are now),
or the asciidoc source files look odd (although that's probably not a
big problem) or the manpages look a bit funny.
This patch makes the html docs right, makes the asciidoc docs a bit odd
but consistent with what is there already, and makes the manpages look
OK using docbook-xsl 1.68, but miss a paragraph separator when using 1.69.
For the manpages, current is like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT
With this patch, docbook-xsl v1.68 looks like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
while docbook-xsl v1.69 becomes
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
The extra indentation is to keep the v1.69 manpage looking sane.
---
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 57027b4..b0c6d7c 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -99,21 +99,24 @@ If you need to pass multiple options, se
CVS by default uses the unix username when writing its
commit logs. Using this option and an author-conv-file
in this format
-
++
+---------
exon=Andreas Ericsson <ae@op5.se>
spawn=Simon Pawn <spawn@frog-pond.org>
- git-cvsimport will make it appear as those authors had
- their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
- all along.
-
- For convenience, this data is saved to $GIT_DIR/cvs-authors
- each time the -A option is provided and read from that same
- file each time git-cvsimport is run.
-
- It is not recommended to use this feature if you intend to
- export changes back to CVS again later with
- git-link[1]::git-cvsexportcommit.
+---------
++
+git-cvsimport will make it appear as those authors had
+their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
+all along.
++
+For convenience, this data is saved to $GIT_DIR/cvs-authors
+each time the -A option is provided and read from that same
+file each time git-cvsimport is run.
++
+It is not recommended to use this feature if you intend to
+export changes back to CVS again later with
+git-link[1]::git-cvsexportcommit.
OUTPUT
------
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 9d38657..b1b87c2 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -75,18 +75,21 @@ When importing incrementally, you might
-A <author_file>::
Read a file with lines on the form
++
+------
+ username = User's Full Name <email@addr.es>
- username = User's Full Name <email@addr.es>
-
- and use "User's Full Name <email@addr.es>" as the GIT
- author and committer for Subversion commits made by
- "username". If encountering a commit made by a user not in the
- list, abort.
-
- For convenience, this data is saved to $GIT_DIR/svn-authors
- each time the -A option is provided, and read from that same
- file each time git-svnimport is run with an existing GIT
- repository without -A.
+------
++
+and use "User's Full Name <email@addr.es>" as the GIT
+author and committer for Subversion commits made by
+"username". If encountering a commit made by a user not in the
+list, abort.
++
+For convenience, this data is saved to $GIT_DIR/svn-authors
+each time the -A option is provided, and read from that same
+file each time git-svnimport is run with an existing GIT
+repository without -A.
-m::
Attempt to detect merges based on the commit message. This option
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* Re: [ANNOUNCE] qgit 1.1.1
From: Ingo Molnar @ 2006-03-20 10:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, proski
In-Reply-To: <e5bfff550603191404l7511e76awe980fad51ffde98d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
* Marco Costalba <mcostalba@gmail.com> wrote:
> > Put in this way it seems a very major bug! really not a small one!
> >
> > I cannot reproduce it. Please can you give me some more info as repository
> > (linux tree?) and commit sha.
> >
>
> And please also the error message that appears in qgit window so to
> know what git command failed.
i've attached a screenshot of the failure message. It's plain Linus'
kernel git tree, clicking on any merge commit produces this window. FC4
box.
Ingo
[-- Attachment #2: qgit-bug.png --]
[-- Type: image/png, Size: 46247 bytes --]
^ 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