* [RFC] Teach git-branch howto rename a branch
From: Lars Hjemli @ 2006-11-24 23:03 UTC (permalink / raw)
To: git
This adds a '--rename' option to git branch. If specified, branch
creation becomes branch renaming.
With a single branchname, the current branch is renamed and .git/HEAD is
updated.
With two branchnames, the second name is renamed to the first.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-branch.c | 117 +++++++++++++++++++++++++++++++++++------------------
1 files changed, 77 insertions(+), 40 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index f14d814..e714569 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -11,7 +11,7 @@
#include "builtin.h"
static const char builtin_branch_usage[] =
-"git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | [-r | -a] [-v] [--abbrev=<length>] ";
+"git-branch (-d | -D) <branchname> | [-l] [-f] [--rename] <branchname> [<start-point>] | [-r | -a] [-v] [--abbrev=<length>] ";
static const char *head;
@@ -36,47 +36,55 @@ static int in_merge_bases(const unsigned
return ret;
}
-static void delete_branches(int argc, const char **argv, int force)
+static void delete_branch(const char *branch, int force, struct commit *head_rev)
{
- struct commit *rev, *head_rev;
- unsigned char sha1[20];
+ struct commit *rev;
char *name;
- int i;
+ unsigned char sha1[20];
- head_rev = lookup_commit_reference(head_sha1);
- for (i = 0; i < argc; i++) {
- if (!strcmp(head, argv[i]))
- die("Cannot delete the branch you are currently on.");
-
- name = xstrdup(mkpath("refs/heads/%s", argv[i]));
- if (!resolve_ref(name, sha1, 1, NULL))
- die("Branch '%s' not found.", argv[i]);
-
- rev = lookup_commit_reference(sha1);
- if (!rev || !head_rev)
- die("Couldn't look up commit objects.");
-
- /* This checks whether the merge bases of branch and
- * HEAD contains branch -- which means that the HEAD
- * contains everything in both.
- */
-
- if (!force &&
- !in_merge_bases(sha1, rev, head_rev)) {
- fprintf(stderr,
- "The branch '%s' is not a strict subset of your current HEAD.\n"
- "If you are sure you want to delete it, run 'git branch -D %s'.\n",
- argv[i], argv[i]);
- exit(1);
- }
+ if (!strcmp(head, branch))
+ die("Cannot delete the branch you are currently on.");
+
+ name = xstrdup(mkpath("refs/heads/%s", branch));
+ if (!resolve_ref(name, sha1, 1, NULL))
+ die("Branch '%s' not found.", branch);
+
+ rev = lookup_commit_reference(sha1);
+ if (!rev)
+ die("Couldn't look up commit objects for %s", branch);
+
+ /* This checks whether the merge bases of branch and
+ * HEAD contains branch -- which means that the HEAD
+ * contains everything in both.
+ */
+
+ if (head_rev && !force &&
+ !in_merge_bases(sha1, rev, head_rev)) {
+ fprintf(stderr,
+ "The branch '%s' is not a strict subset of your current HEAD.\n"
+ "If you are sure you want to delete it, run 'git branch -D %s'.\n",
+ branch, branch);
+ exit(1);
+ }
- if (delete_ref(name, sha1))
- printf("Error deleting branch '%s'\n", argv[i]);
- else
- printf("Deleted branch %s.\n", argv[i]);
+ if (delete_ref(name, sha1))
+ printf("Error deleting branch '%s'\n", branch);
+ else
+ printf("Deleted branch %s.\n", branch);
- free(name);
- }
+ free(name);
+}
+
+static void delete_branches(int argc, const char **argv, int force)
+{
+ struct commit *head_rev;
+ int i;
+
+ head_rev = lookup_commit_reference(head_sha1);
+ if (!head_rev)
+ die("Couldn't look up commit object for current HEAD.");
+ for (i = 0; i < argc; i++)
+ delete_branch(argv[i], force, head_rev);
}
#define REF_UNKNOWN_TYPE 0x00
@@ -200,15 +208,18 @@ static void print_ref_list(int kinds, in
free_ref_list(&ref_list);
}
-static void create_branch(const char *name, const char *start,
+static char *create_branch(const char *name, const char *start,
int force, int reflog)
{
struct ref_lock *lock;
struct commit *commit;
unsigned char sha1[20];
- char ref[PATH_MAX], msg[PATH_MAX + 20];
+ char *ref, msg[PATH_MAX + 20];
+ int reflen;
- snprintf(ref, sizeof ref, "refs/heads/%s", name);
+ reflen = strlen(name) + 12;
+ ref = xmalloc(reflen+1);
+ snprintf(ref, reflen, "refs/heads/%s", name);
if (check_ref_format(ref))
die("'%s' is not a valid branch name.", name);
@@ -235,12 +246,30 @@ static void create_branch(const char *na
if (write_ref_sha1(lock, sha1, msg) < 0)
die("Failed to write ref: %s.", strerror(errno));
+ return ref;
+}
+
+static void rename_branch(const char *newname, const char *oldname, int force, int reflog)
+{
+ char ref[PATH_MAX];
+
+ snprintf(ref, sizeof ref, "refs/heads/%s", oldname);
+ if (check_ref_format(ref))
+ die("'%s' is not a valid branch name.", oldname);
+
+ newname = create_branch(newname, oldname, force, reflog);
+ if (!strcmp(oldname, head)) {
+ create_symref("HEAD", newname);
+ head = newname + 11;
+ }
+ delete_branch(oldname, force, NULL);
}
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, force_delete = 0, force_create = 0;
int verbose = 0, abbrev = DEFAULT_ABBREV;
+ int rename = 0;
int reflog = 0;
int kinds = REF_LOCAL_BRANCH;
int i;
@@ -269,6 +298,10 @@ int cmd_branch(int argc, const char **ar
force_create = 1;
continue;
}
+ if (!strcmp(arg, "--rename")) {
+ rename = 1;
+ continue;
+ }
if (!strcmp(arg, "-r")) {
kinds = REF_REMOTE_BRANCH;
continue;
@@ -303,6 +336,10 @@ int cmd_branch(int argc, const char **ar
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
print_ref_list(kinds, verbose, abbrev);
+ else if (rename && (i == argc - 1))
+ rename_branch(argv[i], head, force_create, reflog);
+ else if (rename && (i == argc - 2))
+ rename_branch(argv[i], argv[i + 1], force_create, reflog);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
--
1.4.4
^ permalink raw reply related
* Re: [PATCH] gitweb: Use git-show-ref instead of git-peek-remote
From: Jakub Narebski @ 2006-11-24 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcwoa3mx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Use "git show-ref --dereference" instead of "git peek-remote ." in
It should be
Use "git show-ref --dereference" instead of "git peek-remote <project>"
>> git_get_references. git-show-ref is faster than git-peek-remote; even
>> faster is reading info/refs file (if it exists), but the information
>> in info/refs can be stale.
>
> More importantly, it is for dumb protocol transports, not for gitweb.
Yes, but if it is there, why not make use of it? Especially that it
is used only (I think) for refs markers, and not for anything important.
On the other side a bit of performance here doesn't matter much.
> You forgot to mention that you fixed the last place that
> directly used "$GIT" to invoke the command, bypassing sub
> git_cmd. That is a consistency clean-up worth mentioning.
This is not fix, this is change of style. The style was to use
git peek-remote $projectroot/$project
instead of equivalent
git --git-dir=$projectroot/$project peek-remote .
We don't have this choice with git-show-ref.
On the other hand that makes all command invocation (except the one
used for getting git core version) pass through git_cmd() subroutine.
>> git-show-ref is available since v1.4.4; the output format is slightly
>> different than git-peek-remote output format.
>
>> - if ($line =~ m/^([0-9a-fA-F]{40})\trefs\/($type\/?[^\^]+)/) {
>> + if ($line =~ m/^([0-9a-fA-F]{40}) refs\/($type\/?[^\^]+)/) {
>
> I would rather do:
>
> m|^([0-9a-f]{40})\srefs/($type/?[^^]+)|
>
> which would catch both space and tab.
Feel free to do that (one nitpick: is [^^] more readable than [^\^]?).
Should I resend the patch?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] gitweb: Use git-show-ref instead of git-peek-remote
From: Junio C Hamano @ 2006-11-24 22:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11644056823095-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Use "git show-ref --dereference" instead of "git peek-remote ." in
> git_get_references. git-show-ref is faster than git-peek-remote; even
> faster is reading info/refs file (if it exists), but the information
> in info/refs can be stale.
More importantly, it is for dumb protocol transports, not for gitweb.
You forgot to mention that you fixed the last place that
directly used "$GIT" to invoke the command, bypassing sub
git_cmd. That is a consistency clean-up worth mentioning.
> git-show-ref is available since v1.4.4; the output format is slightly
> different than git-peek-remote output format.
> - if ($line =~ m/^([0-9a-fA-F]{40})\trefs\/($type\/?[^\^]+)/) {
> + if ($line =~ m/^([0-9a-fA-F]{40}) refs\/($type\/?[^\^]+)/) {
I would rather do:
m|^([0-9a-f]{40})\srefs/($type/?[^^]+)|
which would catch both space and tab.
^ permalink raw reply
* Re: git-svn: why fetching files is so slow
From: Eric Wong @ 2006-11-24 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pazu
In-Reply-To: <7vy7q0a85p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Pazu <pazu@pazu.com.br> wrote:
> >> Eric Wong <normalperson <at> yhbt.net> writes:
> >>
> >> > git-svn transfers full files, and not deltas. I'll hopefully have a
> >> > chance to look into improving the situation for slow links this weekend.
> >>
> >> Yes, but why would that make fetching the first revision slower? In this
> >> situation, both svn and git-svn would have to fetch full files. Maybe git-svn
> >> isn't using gzip compression or http pipelining?
> >
> > Even for the initial transfer, the tree is bundled into one big delta
> > (at least over https).
>
> Do you mean that "one big delta" saves duplicates across copies
> inside the tree (e.g. svn tags and branches can be expressed as
> a mostly identical copies of each other), or do you mean "one
> full file at a time" requests are killing us, compared to a such
> single transfer of "one big delta"?
One full file at a time requests are definitely killing us (over slow
links, at least). I'm not sure how/if duplicates inside a requested
tree are optimized on the server side.
--
^ permalink raw reply
* [PATCH] gitweb: Use git-show-ref instead of git-peek-remote
From: Jakub Narebski @ 2006-11-24 22:01 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Use "git show-ref --dereference" instead of "git peek-remote ." in
git_get_references. git-show-ref is faster than git-peek-remote; even
faster is reading info/refs file (if it exists), but the information
in info/refs can be stale.
git-show-ref is available since v1.4.4; the output format is slightly
different than git-peek-remote output format.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f06cd3e..290751f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1154,14 +1154,15 @@ sub git_get_last_activity {
sub git_get_references {
my $type = shift || "";
my %refs;
- # 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
- # c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
- open my $fd, "-|", $GIT, "peek-remote", "$projectroot/$project/"
+ # 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
+ # c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
+ open my $fd, "-|", git_cmd(), "show-ref", "--dereference",
+ ($type ? ("--", "refs/$type") : ()) # use -- <pattern> if $type
or return;
while (my $line = <$fd>) {
chomp $line;
- if ($line =~ m/^([0-9a-fA-F]{40})\trefs\/($type\/?[^\^]+)/) {
+ if ($line =~ m/^([0-9a-fA-F]{40}) refs\/($type\/?[^\^]+)/) {
if (defined $refs{$1}) {
push @{$refs{$1}}, $2;
} else {
--
1.4.4.1
^ permalink raw reply related
* [PATCH] gitweb: Replace SPC with also in tag comment
From: Jakub Narebski @ 2006-11-24 21:25 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Commit messages had SPC replaced with entity;
make it so also in tag message (tag comment).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 53214b0..f06cd3e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2924,8 +2924,8 @@ sub git_tag {
print "<div class=\"page_body\">";
my $comment = $tag{'comment'};
foreach my $line (@$comment) {
- chomp($line);
- print esc_html($line) . "<br/>\n";
+ chomp $line;
+ print esc_html($line, -nbsp=>1) . "<br/>\n";
}
print "</div>\n";
git_footer_html();
--
1.4.4.1
^ permalink raw reply related
* Re: Show remote branches on gitweb
From: Jakub Narebski @ 2006-11-24 20:56 UTC (permalink / raw)
To: git
In-Reply-To: <ek7jsp$j83$1@sea.gmane.org>
Jakub Narebski wrote:
> Pazu wrote:
>
>> Is there any way to do it? I'm using git-svn to track a remote subversion
>> repository, and it would be very nice to browse the history for a remote branch
>> for which I didn't start a local branch yet.
>
> Planned, not implemented yet.
The problem is that to implement it _well_ we have to get remotes, both
$GIT_DIR/remotes and config remote.xxx, info. And the latter (config
remotes info) needs config parsing, something we lack.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn: why fetching files is so slow
From: Junio C Hamano @ 2006-11-24 20:42 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Pazu
In-Reply-To: <20061124203320.GA21654@soma>
Eric Wong <normalperson@yhbt.net> writes:
> Pazu <pazu@pazu.com.br> wrote:
>> Eric Wong <normalperson <at> yhbt.net> writes:
>>
>> > git-svn transfers full files, and not deltas. I'll hopefully have a
>> > chance to look into improving the situation for slow links this weekend.
>>
>> Yes, but why would that make fetching the first revision slower? In this
>> situation, both svn and git-svn would have to fetch full files. Maybe git-svn
>> isn't using gzip compression or http pipelining?
>
> Even for the initial transfer, the tree is bundled into one big delta
> (at least over https).
Do you mean that "one big delta" saves duplicates across copies
inside the tree (e.g. svn tags and branches can be expressed as
a mostly identical copies of each other), or do you mean "one
full file at a time" requests are killing us, compared to a such
single transfer of "one big delta"?
^ permalink raw reply
* Re: git-svn: why fetching files is so slow
From: Eric Wong @ 2006-11-24 20:33 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <loom.20061124T202153-512@post.gmane.org>
Pazu <pazu@pazu.com.br> wrote:
> Eric Wong <normalperson <at> yhbt.net> writes:
>
> > git-svn transfers full files, and not deltas. I'll hopefully have a
> > chance to look into improving the situation for slow links this weekend.
>
> Yes, but why would that make fetching the first revision slower? In this
> situation, both svn and git-svn would have to fetch full files. Maybe git-svn
> isn't using gzip compression or http pipelining?
Even for the initial transfer, the tree is bundled into one big delta
(at least over https).
--
^ permalink raw reply
* Re: [PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.
From: Junio C Hamano @ 2006-11-24 20:28 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87k61kubya.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> A better fix may be to only fetch tags that point to commits that we
> are downloading, but git-clone doesn't have support for following
> tags. This will happen automatically on the next git-fetch though.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
All five patches look sane. Thanks.
The last one made me go "Huh?" at first, but it indeed is an
improvement. It wouldn't make much sense to "shallow clone" by
two commits near the tip of the 'master' branch from Linus's
kernel, and then having to "shallow clone" all of his tags down
to v2.6.12-rc2, each with two commit depths limit.
I however think a better "fix" is not to use shallow "clone" but
shallowly fetch branches you are interested in into an empty
repository for such a use scenario. Just like making two-depth
shallow copy of all the old tags do not help when the user is
interested in the recent history of the tip of the 'master'
branch, it does not help much to get near the tip of all other
branches with a uniform depth when one particular branch from a
remote repository is of interest. I can imagine that somebody
who fully follows the 'master' branch from git.git repository
from time to time wants to take a peek at near the tip of 'pu'
(perhaps because the 'shallow clone' topic is interesting) or
wants to fetch near the tip of Jakub's gitweb work to see what
area is still being improved, and shallowly fetching them into a
repository that has full history of my 'master' would be a
useful way to do so, provided if 'pu' and/or Jakub's tree have
deep enough histories since 'master' that the benefit of saved
bandwidth and disk usage outweighs the complexity of "shallow".
I haven't tried these usage scenarios myself. I wonder if a
shallow "clone" with non-uniform depths from possible more than
one repository work sensibly?
^ permalink raw reply
* Re: Show remote branches on gitweb
From: Jakub Narebski @ 2006-11-24 20:17 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20061124T210559-701@post.gmane.org>
Pazu wrote:
> Is there any way to do it? I'm using git-svn to track a remote subversion
> repository, and it would be very nice to browse the history for a remote branch
> for which I didn't start a local branch yet.
Planned, not implemented yet.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Show remote branches on gitweb
From: Pazu @ 2006-11-24 20:06 UTC (permalink / raw)
To: git
Is there any way to do it? I'm using git-svn to track a remote subversion
repository, and it would be very nice to browse the history for a remote branch
for which I didn't start a local branch yet.
-- Pazu
^ permalink raw reply
* Re: git-svn: why fetching files is so slow
From: Pazu @ 2006-11-24 19:28 UTC (permalink / raw)
To: git
In-Reply-To: <20061124191609.GA32506@localdomain>
Eric Wong <normalperson <at> yhbt.net> writes:
> git-svn transfers full files, and not deltas. I'll hopefully have a
> chance to look into improving the situation for slow links this weekend.
Yes, but why would that make fetching the first revision slower? In this
situation, both svn and git-svn would have to fetch full files. Maybe git-svn
isn't using gzip compression or http pipelining?
-- Pazu
^ permalink raw reply
* Re: git-svn: why fetching files is so slow
From: Eric Wong @ 2006-11-24 19:16 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <loom.20061124T143148-286@post.gmane.org>
Pazu <pazu@pazu.com.br> wrote:
> ... compared to the standalone svn client. I'm working with repositories over
> the internet, using not-so-fast links, but still, a svn checkout takes somewhere
> around 5 to 10 minutes, while git-svn fetch takes at least 10 times that just to
> fetch the initial revision. Later fetches also take *a lot* more time than a svn
> update would.
git-svn transfers full files, and not deltas. I'll hopefully have a
chance to look into improving the situation for slow links this weekend.
--
^ permalink raw reply
* Re: git-svn: why fetching files is so slow
From: Seth Falcon @ 2006-11-24 17:10 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20061124T143148-286@post.gmane.org>
Pazu <pazu@pazu.com.br> writes:
> ... compared to the standalone svn client. I'm working with repositories over
> the internet, using not-so-fast links, but still, a svn checkout takes somewhere
> around 5 to 10 minutes, while git-svn fetch takes at least 10 times that just to
> fetch the initial revision. Later fetches also take *a lot* more time than a svn
> update would.
[warning: I _think_ this is how it works, but not 100% sure]
When you use git-svn to fetch from an svn repository, you make a
separate request for each commit that occurred on the remote svn
repos. When you use the svn client, it only needs to compute and
download one delta .
If you are not already using the Perl SVN bindings (you will need to
build svn from source), you should give them a try. They are much
faster.
My experience has often been the opposite, but I think that is because
I work with an svn repository where I track a directory that has many
many subdirs. The svn working copy traversal is so slow that even
with the extra network overhead, git + git-svn ends up being faster
for fetch (and much faster for any local operation).
^ permalink raw reply
* Re: Pull and fetch
From: J. Bruce Fields @ 2006-11-24 16:11 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20061123203950.5d47421f@paolo-desktop>
On Thu, Nov 23, 2006 at 08:39:50PM +0100, Paolo Ciarrocchi wrote:
> I'm still reading git tutorial.txt and I'm again confused.
>
> A more cautious Alice might wish to examine Bob's changes before
> pulling them. She can do this by creating a temporary branch just
> for the purpose of studying Bob's changes:
>
> -------------------------------------
> $ git fetch /home/bob/myrepo master:bob-incoming
> -------------------------------------
>
> which fetches the changes from Bob's master branch into a new branch
> named bob-incoming. (Unlike git pull, git fetch just fetches a copy
> of Bob's line of development without doing any merging). Then
>
> -------------------------------------
> $ git log -p master..bob-incoming
> -------------------------------------
>
> shows a list of all the changes that Bob made since he branched from
> Alice's master branch.
>
> OK, make sense. So let's try with an experiment:
Your experiment is quite different from what's described above; you're
fetching into an *empty* repository, instead of fetching a branch that
diverged from the work in the repository:
> paolo@paolo-desktop:~/test$ git-init-db
> defaulting to local storage area
> paolo@paolo-desktop:~/test$ git fetch ../git master:testbranch
> warning: no common commits
and you're running "pull" with a syntax that has so far only been
introduced for "fetch":
> paolo@paolo-desktop:~/test$ git pull ../git master:testbranchpull
By its nature a tutorial tends to follow a narrow path, and not offer
much explanation of what will happen if you stray from that path.
That said, I agree that the treatment of pull and fetch here could be
better. And the ref:ref syntax for pull may be an obvious enough thing
to try that we should document it here. Just as long as we keep it
short....
^ permalink raw reply
* Re: [PATCH 0/5] Shallow clone fixes
From: Jakub Narebski @ 2006-11-24 15:43 UTC (permalink / raw)
To: git
In-Reply-To: <8764d4vqno.fsf@wine.dyndns.org>
Alexandre Julliard wrote:
> This series fixes a number of small problems in the shallow clone
> support in pu. After that it seems to work fairly well for me.
Could you make the rest of patches in series be reply to (directly or
indirectly) to the introductory message? Thanks in advance.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/4] Series short description
From: Catalin Marinas @ 2006-11-24 15:37 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20061123230721.9769.38403.stgit@gandelf.nowhere.earth>
On 23/11/06, Yann Dirson <ydirson@altern.org> wrote:
> The following adds a --patch flag to "stg refresh". I mainly needed it to
> edit the log message in patches down the stack, but with some work it could
> be used to record changes in another file and come back.
>
> That would require to pop patches with --keep,
pop_patches(keep=True) allows this (I already added it to your patch).
This option actually applies the reverse of the patch between the
current index and the bottom of the last patch to be popped. If it
fails, it doesn't affect the current tree and reports an error.
> and if we ask to only record
> a subset of the changes, we would need to implement "push --keep" first.
The "push --keep" is a bit more complicated to implement since it
would usually have to generate commits (pop doesn't need to) since
usually the base of the pushed patches might have changed (especially
with the refresh --patch). It is even more complicated if the changes
you want to preserve affect a file modified by the pushed patches.
A solution I see is to generate a temporary diff, push the patches you
want and fold this temporary diff (the diff can be temporarily written
to a local file so that you don't lose them in case of an error or
Ctrl-C). If the push fails (conflicts) or the diff no longer applies,
just undo the push and re-apply the diff. There is no way to simply
check whether all the patches apply (git-apply --check) since you
can't generate a single diff for all the pushed patches (which might
not be in the committed order).
--
^ permalink raw reply
* [PATCH 0/5] Shallow clone fixes
From: Alexandre Julliard @ 2006-11-24 14:57 UTC (permalink / raw)
To: git
This series fixes a number of small problems in the shallow clone
support in pu. After that it seems to work fairly well for me.
The one remaining problem I see is that a git-fetch to deepen the tree
doesn't take into account the commits that the client already has. For
instance, on the Wine tree, a "git-clone --depth 1" downloads 4655
objects, and a "git-clone --depth 2" downloads 4660, so I'd expect
that after the depth 1 clone a "git-fetch --depth 2" would only have
to download 5 objects, but currently it downloads 4650 again.
--
Alexandre Julliard
^ permalink raw reply
* Re: [PATCH] Add -v and --abbrev options to git-branch
From: Lars Hjemli @ 2006-11-24 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <ek6u2s$at4$1@sea.gmane.org>
On 11/24/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Isn't what git-show-ref is about? Or git-for-each-ref?
Yes, there seem to be some overlap in functionality here :-)
The thing with git-branch is that it shows me which branch I'm
currently on, someting neither git-show-ref nor git-for-each-ref does.
And the "starred" branch, combined with hash and commit subject is
very useful for me (It reminds me where I am, and where I have been,
and what i did there....)
Finally, git-for-each-ref is more like plumbing, I wanted someting a
little more userfriendly
--
^ permalink raw reply
* [PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.
From: Alexandre Julliard @ 2006-11-24 15:00 UTC (permalink / raw)
To: git
A better fix may be to only fetch tags that point to commits that we
are downloading, but git-clone doesn't have support for following
tags. This will happen automatically on the next git-fetch though.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
fetch-pack.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index bb310b6..80979b8 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -342,7 +342,8 @@ static void filter_refs(struct ref **ref
if (!memcmp(ref->name, "refs/", 5) &&
check_ref_format(ref->name + 5))
; /* trash */
- else if (fetch_all) {
+ else if (fetch_all &&
+ (!depth || strncmp(ref->name, "refs/tags/", 10) )) {
*newtail = ref;
ref->next = NULL;
newtail = &ref->next;
--
1.4.4.1.ga335e
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 2/5] upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
From: Alexandre Julliard @ 2006-11-24 14:58 UTC (permalink / raw)
To: git
A commit may have been put on the shallow list, and then reached from
another branch and marked NOT_SHALLOW without being removed from the
list.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
upload-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index d5b4750..d4a7b62 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -565,7 +565,7 @@ static void receive_needs(void)
SHALLOW, NOT_SHALLOW);
while (result) {
struct object *object = &result->item->object;
- if (!(object->flags & CLIENT_SHALLOW)) {
+ if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
packet_write(1, "shallow %s",
sha1_to_hex(object->sha1));
register_shallow(object->sha1);
--
1.4.4.1.ga335e
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 3/5] get_shallow_commits: Avoid memory leak if a commit has been reached already.
From: Alexandre Julliard @ 2006-11-24 14:58 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
shallow.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/shallow.c b/shallow.c
index 2db1dc4..3d53d17 100644
--- a/shallow.c
+++ b/shallow.c
@@ -60,7 +60,9 @@ struct commit_list *get_shallow_commits(
commit = NULL;
continue;
}
- commit->util = xcalloc(1, sizeof(int));
+ if (!commit->util)
+ commit->util = xmalloc(sizeof(int));
+ *(int *)commit->util = 0;
cur_depth = 0;
} else {
commit = (struct commit *)
--
1.4.4.1.ga335e
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 4/5] git-fetch: Reset shallow_depth before auto-following tags.
From: Alexandre Julliard @ 2006-11-24 14:59 UTC (permalink / raw)
To: git
Otherwise fetching the tags could also fetch commits up to the
specified depth, which isn't the expected behavior.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
git-fetch.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 0b1e6d1..f0645d9 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -461,6 +461,8 @@ case "$no_tags$tags" in
case "$taglist" in
'') ;;
?*)
+ # do not deepen a shallow tree when following tags
+ shallow_depth=
fetch_main "$taglist" ;;
esac
esac
--
1.4.4.1.ga335e
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 1/5] fetch-pack: Properly remove the shallow file when it becomes empty.
From: Alexandre Julliard @ 2006-11-24 14:58 UTC (permalink / raw)
To: git
The code was unlinking the lock file instead.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
fetch-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index d00573d..bb310b6 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -700,7 +700,7 @@ int main(int argc, char **argv)
fd = hold_lock_file_for_update(&lock, shallow, 1);
if (!write_shallow_commits(fd, 0)) {
- unlink(lock.filename);
+ unlink(shallow);
rollback_lock_file(&lock);
} else {
close(fd);
--
1.4.4.1.ga335e
--
Alexandre Julliard
^ permalink raw reply related
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