* 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: 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
* [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
* 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
* 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
* [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: 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
* 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: 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: 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: 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 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: 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: Petr Baudis @ 2006-03-20 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7voe00iupp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Mar 21, 2006 at 12:04:34AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I think what is reasonable is something like this:
<insert all of the arguments in my other mail here ;>
> - 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".
Which is ugly. There is no reason why you couldn't go on using 'origin'
which is shorter and we can usually still unambiguously decide what did
you mean (unless you have a local head/tag 'origin' _and_ a remote named
'origin' at the same time).
> - 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.
Yes, but that makes no sense to do when you usually need this only in
some very special cases (and then you ought to be able to set up the
weird thing yourself), while we can do the doubtlessly right thing in
the general case, WITHOUT confusing the user, WHILE keeping things tidy
and easy to use (and without excessive typing). In fact, you described
it yourself:
> - 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".
Except that you can just name the refs/remotes/directory the same way
you name the remote repository identifier (be it a Git-style remote or
Cogito's remote branch).
I still don't get what's wrong on what I'm proposing. I'm not seeing the
disadvantages, if there are any.
--
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 23:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, git
In-Reply-To: <20060320232101.GQ18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I still don't get what's wrong on what I'm proposing. I'm not seeing the
> disadvantages, if there are any.
The only thing I think there is is that I do not get what you
are proposing ;-), since I am not paying full attention while at
day-job.
If you are proposing to root --use-separate-remote not at
refs/remotes but refs/remotes/origin/, I think it makes kind of
sense. It would make tons of sense _if_ dealing more than one
remote repository is the norm, but otherwise you would have an
extra level of directory refs/remotes which almost always have
only one subdirectory 'origin' and nothing else, which is
pointless.
I am not sure if you are also advocating to map (somehow) origin
to remotes/origin/master (or whatever branch remote's HEAD
points at), but if so I am not quite sure what its semantics
would be. Which remote branch would you pick (that would not
necessarily be "master") and where are you going to record that
and when. It all sounds to me complicating things
unnecessarily.
^ permalink raw reply
* Re: efficient cloning
From: Josef Weidendorfer @ 2006-03-21 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe00iupp.fsf@assigned-by-dhcp.cox.net>
On Tuesday 21 March 2006 00:04, you wrote:
> > 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,
See
http://www.gelato.unsw.edu.au/archives/git/0603/17405.html
I found it strange at first. But I think it is the right thing.
> 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".
Yes. And it would be nice if the same would work with the new layout,
assuming that there is no local "origin" branch, but a .git/remotes/origin
file and .git/refs/remotes/origin directory.
> - 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.
Yes.
Still it would be nice to have a fixed convention here.
Eg. gitk could decorate the namespace in a special way.
Even if it is most of the time "origin" only.
> [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 ;-).
It should be as simple as (probably with quite some errors)
~/> cat git-rename-remote.sh
mv .git/refs/remotes/$1 .git/refs/remotes/$2
sed -e "s|remotes/$1|remotes/$2" .git/remotes/$1 > .git/remotes/$2
rm .git/remotes/$1
If you allow more freedom regarding the use of refs/remotes, it gets more
complicated both for the script and for the user to understand.
Josef
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 0:57 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200603210126.59870.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> 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".
>
> Yes. And it would be nice if the same would work with the new layout,
> assuming that there is no local "origin" branch, but a .git/remotes/origin
> file and .git/refs/remotes/origin directory.
My primary aversion comes from that I'd rather avoid teaching
the really core stuff about .git/remotes file, and the part that
interprets refname is fairly a low-level part.
We _could_ record refs/remotes/origin/HEAD that points at
refs/remotes/origin/master (or some other branch) upon cloning,
and if Pasky wants to do something similar upon fetching, that
fetch command could do the same thing.
^ permalink raw reply
* [PATCH] contrib/git-svn: allow rebuild to work on non-linear remote heads
From: Eric Wong @ 2006-03-21 4:51 UTC (permalink / raw)
To: Junio C Hamano, git
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
85bed4cd937921844574fe66da95977fdeece993
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index cf233ef..f3fc3ec 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -850,11 +850,23 @@ sub assert_revision_unknown {
}
}
+sub trees_eq {
+ my ($x, $y) = @_;
+ my @x = safe_qx('git-cat-file','commit',$x);
+ my @y = safe_qx('git-cat-file','commit',$y);
+ if (($y[0] ne $x[0]) || $x[0] !~ /^tree $sha1\n$/
+ || $y[0] !~ /^tree $sha1\n$/) {
+ print STDERR "Trees not equal: $y[0] != $x[0]\n";
+ return 0
+ }
+ return 1;
+}
+
sub assert_revision_eq_or_unknown {
my ($revno, $commit) = @_;
if (-f "$REV_DIR/$revno") {
my $current = file_to_s("$REV_DIR/$revno");
- if ($commit ne $current) {
+ if (($commit ne $current) && !trees_eq($commit, $current)) {
croak "$REV_DIR/$revno already exists!\n",
"current: $current\nexpected: $commit\n";
}
--
1.2.4.gb622a
^ permalink raw reply related
* Re: efficient cloning
From: Andreas Ericsson @ 2006-03-21 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <7vfylcismx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>
>>I still don't get what's wrong on what I'm proposing. I'm not seeing the
>>disadvantages, if there are any.
>
>
> The only thing I think there is is that I do not get what you
> are proposing ;-), since I am not paying full attention while at
> day-job.
>
> If you are proposing to root --use-separate-remote not at
> refs/remotes but refs/remotes/origin/, I think it makes kind of
> sense. It would make tons of sense _if_ dealing more than one
> remote repository is the norm, but otherwise you would have an
> extra level of directory refs/remotes which almost always have
> only one subdirectory 'origin' and nothing else, which is
> pointless.
>
afaiu, this is exactly what Pasky's proposing, and I agree. We could
then teach 'git diff origin master' to mean 'origin/master' *if* no
other tag/branch is found in the lookup order. I think it makes sense to
do searching like this, for a ref named foo
(current order, with .git/, .git/refs/, etc...)
.git/refs/remotes/foo
.git/refs/remotes/foo/master
That way the only extra dwimery would be to add "remotes" after "heads"
under .git/refs and accept directory in .git/remotes/ as ref and tack on
'/master' at the end of it as the last option to search. For a specific
branch on an imported remote, one would have to say "jc/next". This
means we still only handle 'master' specially so we don't introduce any
new protected or special names.
> I am not sure if you are also advocating to map (somehow) origin
> to remotes/origin/master (or whatever branch remote's HEAD
> points at), but if so I am not quite sure what its semantics
> would be. Which remote branch would you pick (that would not
> necessarily be "master") and where are you going to record that
> and when. It all sounds to me complicating things
> unnecessarily.
>
Not too much so, I think. I'll look into it tonight, although I'm not
very familiar with the core stuff so possibly (/ hopefully) someone else
will beat me to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 8:28 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Petr Baudis
In-Reply-To: <200603201730.19373.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Shouldn't this be .git/refs/remotes/origin/?
> Ie. different namespaces for different remotes?
OK, here is a second try, that comes on top of the one from the
last night.
Together with another topic in the "next" branch, you can now do
this:
$ git clone --use-separate-remote --reference git.git \
git://git.kernel.org/pub/scm/git/git.git new.git
$ cd new.git
$ git branch
* master
$ git log --pretty=oneline master..origin/next | wc -l
72
What the last one shows is that sha1_basic() lets you omit
refs/remotes; it does not let you say "origin" to mean
"refs/remotes/origin/master", although I agree that abbreviation
would be useful. As I am still not yet convinced that using
what is in .git/remotes/origin is a good way to implement that
shorthand, and would rather avoid reading .git/remotes/origin
from the C level (even though sha1_basic() is not _that_ core
but a lot closer to the UI, compared to other C level routines),
I am leaving that part for later rounds.
-- >8 --
[PATCH] revamp git-clone (take #2).
This builds on top of the previous one.
* --use-separate-remote uses .git/refs/remotes/$origin/
directory to keep track of the upstream branches.
* The $origin above defaults to "origin" as usual, but the
existing "-o $origin" option can be used to override it.
I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-clone.sh | 50 +++++++++++++++++++++++++++++++-------------------
1 files changed, 31 insertions(+), 19 deletions(-)
47874d6d9a7f49ade6388df049597f03365961ca
diff --git a/git-clone.sh b/git-clone.sh
index 9db678b..3b54753 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -61,8 +61,9 @@ use File::Path qw(mkpath);
use File::Basename qw(dirname);
my $git_dir = $ARGV[0];
my $use_separate_remote = $ARGV[1];
+my $origin = $ARGV[2];
-my $branch_top = ($use_separate_remote ? "remotes" : "heads");
+my $branch_top = ($use_separate_remote ? "remotes/$origin" : "heads");
my $tag_top = "tags";
sub store {
@@ -127,7 +128,12 @@ while
*,--reference=*)
reference=`expr "$1" : '--reference=\(.*\)'` ;;
*,-o)
- git-check-ref-format "$2" || {
+ case "$2" in
+ */*)
+ echo >&2 "'$2' is not suitable for an origin name"
+ exit 1
+ esac
+ git-check-ref-format "heads/$2" || {
echo >&2 "'$2' is not suitable for a branch name"
exit 1
}
@@ -165,14 +171,9 @@ then
no_checkout=yes
fi
-if test -z "$origin_override$origin"
+if test -z "$origin"
then
- if test -n "$use_separate_remote"
- then
- origin=remotes/master
- else
- origin=heads/origin
- fi
+ origin=origin
fi
# Turn the source into an absolute path if
@@ -317,7 +318,7 @@ test -d "$GIT_DIR/refs/reference-tmp" &&
if test -f "$GIT_DIR/CLONE_HEAD"
then
# Figure out where the remote HEAD points at.
- perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote"
+ perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin"
fi
cd "$D" || exit
@@ -328,8 +329,18 @@ then
# Figure out which remote branch HEAD points at.
case "$use_separate_remote" in
'') remote_top=refs/heads ;;
- *) remote_top=refs/remotes ;;
+ *) remote_top="refs/remotes/$origin" ;;
esac
+
+ # What to use to track the remote primary branch
+ if test -n "$use_separate_remote"
+ then
+ origin_tracking="remotes/$origin/master"
+ else
+ origin_tracking="heads/$origin"
+ fi
+
+ # The name under $remote_top the remote HEAD seems to point at
head_points_at=$(
(
echo "master"
@@ -349,25 +360,26 @@ then
done
)
)
+
+ # Write out remotes/$origin file.
case "$head_points_at" in
?*)
mkdir -p "$GIT_DIR/remotes" &&
- echo >"$GIT_DIR/remotes/origin" \
+ echo >"$GIT_DIR/remotes/$origin" \
"URL: $repo
-Pull: refs/heads/$head_points_at:refs/$origin" &&
+Pull: refs/heads/$head_points_at:refs/$origin_tracking" &&
case "$use_separate_remote" in
t) git-update-ref HEAD "$head_sha1" ;;
*) git-update-ref "refs/$origin" $(git-rev-parse HEAD)
esac &&
- (cd "$GIT_DIR" && find "$remote_top" -type f -print) |
- while read ref
+ (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
+ while read dotslref
do
- head=`expr "$ref" : 'refs/\(.*\)'` &&
- name=`expr "$ref" : 'refs/[^\/]*/\(.*\)'` &&
+ name=`expr "$dotslref" : './\(.*\)'` &&
test "$head_points_at" = "$name" ||
test "$origin" = "$head" ||
echo "Pull: refs/heads/${name}:$remote_top/${name}"
- done >>"$GIT_DIR/remotes/origin"
+ done >>"$GIT_DIR/remotes/$origin"
esac
case "$no_checkout" in
--
1.2.4.ge2fc
^ permalink raw reply related
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 8:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <441FB715.1000500@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> That way the only extra dwimery would be to add "remotes" after
> "heads" under .git/refs and accept directory in .git/remotes/ as ref
> and tack on '/master' at the end of it as the last option to
> search. For a specific branch on an imported remote, one would have to
> say "jc/next". This means we still only handle 'master' specially so
> we don't introduce any new protected or special names.
Two things that holding me back from doing what you suggested
are (1) "master" is just a convention and indeed non-negligible
number of kernel.org trees have "test" and "release" instead
without "master"; (2) I'd really really really want to avoid
teaching get_sha1_basic() C-level about .git/remotes/$origin
file, even though that function is more of a UI level than the
rest of the really core C-level routines.
But if I were forced to choose between the above 2, I would
probably pick defaulting to "master".
The reason I would like to avoid .git/remotes/$origin is because
it is designed to be Porcelainish thing. The underlying C-level
git-fetch-pack never sees it; instead the information fed to
C-level is prepared by the upper layer using that file. As far
as I understand, Cogito does not understand it either, except
that it ships with bash completion code that reads from
filenames there.
^ permalink raw reply
* Re: efficient cloning
From: Jeff King @ 2006-03-21 9:19 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q1sgpet.fsf@assigned-by-dhcp.cox.net>
On Tue, Mar 21, 2006 at 12:42:02AM -0800, Junio C Hamano wrote:
> The reason I would like to avoid .git/remotes/$origin is because
> it is designed to be Porcelainish thing. The underlying C-level
> git-fetch-pack never sees it; instead the information fed to
> C-level is prepared by the upper layer using that file. As far
> as I understand, Cogito does not understand it either, except
> that it ships with bash completion code that reads from
> filenames there.
Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
(or later)? Then the core looks for:
(current order, .git/refs, etc)
.git/refs/remotes/foo
.git/refs/remotes/foo/HEAD
The porcelain can take care of managing the contents of HEAD. If there
is no HEAD in the directory, then it cannot be looked up by 'foo'
('foo/remote-branch' must be used instead).
-Peff
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 9:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060321091916.GA17125@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
> (or later)? Then the core looks for:
> (current order, .git/refs, etc)
> .git/refs/remotes/foo
> .git/refs/remotes/foo/HEAD
> The porcelain can take care of managing the contents of HEAD. If there
> is no HEAD in the directory, then it cannot be looked up by 'foo'
> ('foo/remote-branch' must be used instead).
Yup, earlier I mentioned that possibility, and it does not seem
too painful. On top of the "next", here is what is needed.
-- >8 --
[PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote. clone needs to be
told about this convention as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_name.c | 23 ++++++++++++-----------
1 files changed, 12 insertions(+), 11 deletions(-)
c51d13692d4e451c755dd7da3521c5db395df192
diff --git a/sha1_name.c b/sha1_name.c
index 74c479c..3adaec3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -235,18 +235,21 @@ static int ambiguous_path(const char *pa
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
- static const char *prefix[] = {
- "",
- "refs",
- "refs/tags",
- "refs/heads",
- "refs/remotes",
+ static const char *fmt[] = {
+ "/%.*s",
+ "refs/%.*s",
+ "refs/tags/%.*s",
+ "refs/heads/%.*s",
+ "refs/remotes/%.*s",
+ "refs/remotes/%.*s/HEAD",
NULL
};
const char **p;
const char *warning = "warning: refname '%.*s' is ambiguous.\n";
char *pathname;
int already_found = 0;
+ unsigned char *this_result;
+ unsigned char sha1_from_ref[20];
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
@@ -255,11 +258,9 @@ static int get_sha1_basic(const char *st
if (ambiguous_path(str, len))
return -1;
- for (p = prefix; *p; p++) {
- unsigned char sha1_from_ref[20];
- unsigned char *this_result =
- already_found ? sha1_from_ref : sha1;
- pathname = git_path("%s/%.*s", *p, len, str);
+ for (p = fmt; *p; p++) {
+ this_result = already_found ? sha1_from_ref : sha1;
+ pathname = git_path(*p, len, str);
if (!read_ref(pathname, this_result)) {
if (warn_ambiguous_refs) {
if (already_found &&
--
1.2.4.gf1250
^ permalink raw reply related
* Re: efficient cloning
From: Petr Baudis @ 2006-03-21 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7z4f7x3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Mar 21, 2006 at 10:45:12AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jeff King <peff@peff.net> writes:
>
> > Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
> > (or later)? Then the core looks for:
> > (current order, .git/refs, etc)
> > .git/refs/remotes/foo
> > .git/refs/remotes/foo/HEAD
> > The porcelain can take care of managing the contents of HEAD. If there
> > is no HEAD in the directory, then it cannot be looked up by 'foo'
> > ('foo/remote-branch' must be used instead).
>
> Yup, earlier I mentioned that possibility, and it does not seem
> too painful. On top of the "next", here is what is needed.
>
> -- >8 --
> [PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
>
> This implements the suggestion by Jeff King to use
> refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
> the primary branch head of a tracked remote. clone needs to be
> told about this convention as well.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Excellent, yes, that's what I've meant. I'm happy now. :)
Thanks,
--
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
* Bad merging with stgit or git
From: Mauro Carvalho Chehab @ 2006-03-21 19:34 UTC (permalink / raw)
To: Git List; +Cc: Linus Torvalds
I have a -git tree that generated a really bad result when committed by
Linus, generating a really bad history log. My tree is located at:
kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.
I'll try to make a brief from what's happened:
According to him:
"
...
In particular, commit e338b736f1aee59b757130ffdc778538b7db18d6 is crap,
crap, CRAP.
It's "Merging Linus tree", but it's not a merge at all: you have just
applied the _patch_ to merge the changes in my tree, but you haven't
actually told git to do so.
I don't know how/why you did that, but it's totally bogus, and I refuse
to
pull from that tree. That's a 5000+ line diff, affecting about 180
files!
...
"
After a further analysis, it seemed that a merge conflict were badly
solved. It is showing this message to Linus:
diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
AuthorDate: Fri Mar 10 01:30:04 2006 -0300
Commit: Mauro Carvalho Chehab <mchehab@infradead.org>
CommitDate: Fri Mar 10 01:30:04 2006 -0300
Merging Linus tree
:100644 100644 be5ae600f5337dbb14daa8d4cace110486e14f79
81bc51369f59a413108fd8b150c3090541ba49f8 M
Documentation/feature-removal-schedule.txt
:100644 100644 75205391b335f85c9b8a599d0d3b4c0dd1a8b41b
fc99075e0af47f0b73a2ae2dfb7d19920c604dea M
Documentation/kernel-parameters.txt
:100644 100644 9006063e73691da7b68449955a135f7c9317e2cd
da677f829f7689966bf09aeda6d89fc4b6a876d1 M arch/alpha/kernel/irq.c
For me, those tree last lines, don't appear. Instead, it just shows,
with git-show:
diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
Date: Fri Mar 10 01:30:04 2006 -0300
Merging Linus tree
and a diff file, with:
179 files changed, 1274 insertions(+), 785 deletions(-)
With git-cat-file, it shows:
$ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6
tree b233a18f740a2883e4863506175f671d821f1e5e
parent cb31c70cdf1ac7034bed5f83d543f4888c39888a
author Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
committer Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
Merging Linus tree
It shouldn't have any conflicts here for Linus, since those patches came
from his tree.
My current procedure is:
branch origin - Linus tree replica
branch work - my stgit main tree
branch work-fixes - my stgit tree for bug fixes
branch master - patches to current kernel
branch devel - patches to next kernel
All patches are generated against work branch, with stgit.
Branch work-fixes receives patches by using:
stg pick <sha>@work
Before commiting to kernel.org, I do:
at origin:
git pull linus_tree
at master:
git pull . origin
git pull . work-fixes
at devel:
git pull . origin
git pull . work
My environment is:
Stacked GIT 0.8.1
git version 1.2.4.gfd662
Python version 2.4.2 (#2, Jan 30 2006, 18:33:58)
[GCC 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1)]
Any ideas?
^ 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