* [PATCH 4/4] Bomb out when --ack and --sign are both passed to "refresh".
From: Yann Dirson @ 2006-11-23 23:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <20061123230721.9769.38403.stgit@gandelf.nowhere.earth>
Old behaviour was silently ignoring --ack, which could be confusing.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/refresh.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/refresh.py b/stgit/commands/refresh.py
index ea0fe6f..aa5ff78 100644
--- a/stgit/commands/refresh.py
+++ b/stgit/commands/refresh.py
@@ -107,6 +107,8 @@ def func(parser, options, args):
if options.sign:
sign_str = 'Signed-off-by'
+ if options.ack:
+ raise CmdException, '--ack and --sign were both specified'
elif options.ack:
sign_str = 'Acked-by'
^ permalink raw reply related
* [PATCH 3/4] Optimize stg goto in the pop case.
From: Yann Dirson @ 2006-11-23 23:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <20061123230721.9769.38403.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/goto.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 1b62d1c..e129b8d 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -45,11 +45,11 @@ def func(parser, options, args):
check_head_top_equal()
applied = crt_series.get_applied()
- applied.reverse()
unapplied = crt_series.get_unapplied()
patch = args[0]
if patch in applied:
+ applied.reverse()
patches = applied[:applied.index(patch)]
pop_patches(patches)
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Martin Langhoff (CatalystIT) @ 2006-11-23 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkm1ix7b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> writes:
>
>>This is in scalar context, and that's safe to rely on.
>
>
> If it were in scalar context I would agree fully. That
> behaviour is documented. But my point is that it is in void
> context, and I did not find document specifying what should
> happen.
Sorry! What I meant to say is: void context is always equivalent to
scalar context.
cheers,
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Yann Dirson @ 2006-11-23 23:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061122034056.GB23856@spearce.org>
On Tue, Nov 21, 2006 at 10:40:56PM -0500, Shawn Pearce wrote:
> Yet we still want to be able to efficiently perform operations like
> "git bisect" within the scope of that submodule, to help narrow down
> a particular bug that is within that submodule. To do that we need
> the commit chain (all 10,000 of those commits) in the submodule.
> To get those we really need a commit-ish and not a tree-ish, as
> going from a tree-ish to a commit-ish is not only not unique but
> is also pretty infeasible to do (you need to scan *every* commit).
We don't need to have commits in the tree for this. We'll just have
submodule commits which are not attached to a supermodule commit, and we
can access the whole submodule history through the submodule .git/HEAD,
just like we do for a standard git project.
Or do I miss something else ?
Best regards,
--
^ permalink raw reply
* Re: [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Peter Baumann @ 2006-11-23 23:34 UTC (permalink / raw)
To: git
In-Reply-To: <7virh5khrc.fsf@assigned-by-dhcp.cox.net>
On 2006-11-23, Junio C Hamano <junkio@cox.net> wrote:
> Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
> writes:
>
>> This allows one to see the root commit as a diff in commands like git-log,
>> git-show and git-whatchanged. It also modifies git-diff-tree to act as --root
>> was specified on the commandline. The default is set to true.
>>
>> Signed-off-by: Peter Baumann <Peter.B.Baumannn@stud.informatik.uni-erlangen.de>
>> ---
>> I'm not sure if making core.showroot acting on git-diff-tree is the
>> right thing to do. Please check first bevore applying.
>
> I agree that this "use --root by default" belongs to Porcelain
> layer, not the plumbing. We would probably want to do this in
> the same way as we do the color in diff.c::git_diff_ui_config().
>
Sorry, but I don't understand. The color handling doesn't look any different
to me than the handling of the other config entrys. Did I miss something?
Peter
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Andy Whitcroft @ 2006-11-23 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vejrtiwqd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> and --use-immingled-remote can be used to get the original behaviour;
>> it is also implied by --bare.
>
> What's immingled?
Had me reaching for the dictionary too. Seems to mean the same as
intermingled which would be my choice ...
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Petr Baudis @ 2006-11-23 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejrtiwqd.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 24, 2006 at 12:12:10AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > and --use-immingled-remote can be used to get the original behaviour;
> > it is also implied by --bare.
>
> What's immingled?
One dictionary says
Immingle \Im*min"gle\, v. t.
To mingle; to mix; to unite; to blend. [R.] --Thomson.
but perhaps it's too much an obscure word... better suggestions
welcomed.
> > We get confused, frustrated and data-losing users *daily* on #git now
> > because git-clone still produces the crippled repositories having the
> > remote and local heads freely mixed together.
> >
> > Signed-off-by: Petr Baudis <pasky@suse.cz>
>
> Being strongly opinionated, not giving enough credit for the
> evolutionary process behind the history and venting frustration
> in the proposed commit log message is never a good strategy to
> get the patch applied.
Yes, sorry, the last days were a bit tiring to me.
I'm not sure what evolutionary process should I describe, though...
> Even though I fully agree that use-separate-remotes should be
> the default, to the point that I do not think we do not even
> need a backward compatibility option. People who want to use
> traditional layout for simple one-remote-branch-only project
> would not suffer anyway because 'origin' still means origin in
> the new layout (refs/remotes/origin/HEAD).
I don't know, we still at least need to keep the functionality for
--bare.
> We would need to update the tutorials to match this,though. I
> think it talks about the traditional layout and say 'See, now
> you can run "ls .git/refs/heads/{master,origin}"' or something
> like that.
Oops, yes. I can try to go through the tutorials during tomorrow or the
next week...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: J. Bruce Fields @ 2006-11-23 23:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061123234203.GN7201@pasky.or.cz>
On Fri, Nov 24, 2006 at 12:42:03AM +0100, Petr Baudis wrote:
> On Fri, Nov 24, 2006 at 12:12:10AM CET, Junio C Hamano wrote:
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > and --use-immingled-remote can be used to get the original behaviour;
> > > it is also implied by --bare.
> >
> > What's immingled?
>
> One dictionary says
>
> Immingle \Im*min"gle\, v. t.
> To mingle; to mix; to unite; to blend. [R.] --Thomson.
>
> but perhaps it's too much an obscure word... better suggestions
> welcomed.
commingled? legacy? flat?
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Martin Langhoff @ 2006-11-23 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff (CatalystIT), git
In-Reply-To: <7vlkm1ix7b.fsf@assigned-by-dhcp.cox.net>
On 11/24/06, Junio C Hamano <junkio@cox.net> wrote:
> It is more about HTTP proxying and it is my understanding that
> response to CONNECT method request has that empty line after the
> successful (2xx) response line and zero or more response
> headers. The code is still wrong; it does not have a loop to
> discard the potential response headers that come before the
> empty line the code we are discussing discards.
You are right. It should be something along the lines of
# discard headers until first blank line
while (<$s> ne '') {
# nothing
}
that is, assuming we can just ignore headers happily.
cheers,
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Junio C Hamano @ 2006-11-24 0:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061123234203.GN7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> Even though I fully agree that use-separate-remotes should be
>> the default, to the point that I think we do not even
>> need a backward compatibility option. People who want to use
>> traditional layout for simple one-remote-branch-only project
>> would not suffer anyway because 'origin' still means origin in
>> the new layout (refs/remotes/origin/HEAD).
>
> I don't know, we still at least need to keep the functionality for
> --bare.
I agree --bare should continue to be a "snapshot mirror"; I am
not advocating for the removal of the internal implementation
detail such as $use_separate_remote variable.
However, I think having one sane behaviour is the right thing to
do for a clone that prepares a repository with a working tree
(including the one made with -n option, which only means "do not
do the check-out immediately after cloning" for such a
repository).
The traditional layout is slightly simpler for a project with
the simplest needs (that is, a single upstream repository that
has a single 'master' branch), but I do think even that is not
an advantage anymore.
With the separate-remote layout, git-fetch would still fetch and
update the "origin" (although that is now remotes/origin/master
which is pointed at by remotes/origin/HEAD) and the user can
still refer to it with "origin". Commands "git-pull origin",
"git-pull . origin", and "git-merge origin" all will continue to
work the same way as before for such a project as in the
traditional layout, and that is why I think we do not need
backward compatibility flag in this case.
^ permalink raw reply
* Re: [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Junio C Hamano @ 2006-11-24 0:18 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrnemcc0b.ncc.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
>>> I'm not sure if making core.showroot acting on git-diff-tree is the
>>> right thing to do. Please check first bevore applying.
>>
>> I agree that this "use --root by default" belongs to Porcelain
>> layer, not the plumbing. We would probably want to do this in
>> the same way as we do the color in diff.c::git_diff_ui_config().
>>
> Sorry, but I don't understand. The color handling doesn't look any different
> to me than the handling of the other config entrys. Did I miss something?
"git-diff-tree --color HEAD" (with explicit command line
instruction to color it) still colours its output, but "[diff]
color = auto" in ~/.gitconfig would not affect the coloring.
Hence, "git-diff-tree HEAD" with the configuration entry gives
monochrome.
"git diff HEAD" on the other hand looks at '[diff] color = auto"
and will color its output without being told on the command
line.
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Junio C Hamano @ 2006-11-24 0:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, iarenuno
In-Reply-To: <46a038f90611231552x3e33eec4w7863ce6a1da5781b@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 11/24/06, Junio C Hamano <junkio@cox.net> wrote:
>> It is more about HTTP proxying and it is my understanding that
>> response to CONNECT method request has that empty line after the
>> successful (2xx) response line and zero or more response
>> headers. The code is still wrong; it does not have a loop to
>> discard the potential response headers that come before the
>> empty line the code we are discussing discards.
>
> You are right. It should be something along the lines of
>
> # discard headers until first blank line
> while (<$s> ne '') {
> # nothing
> }
>
> that is, assuming we can just ignore headers happily.
Yes, or "1 while (<$s> ne '')" which is listed as an example for
a kosher way to use a constant to express no-op in void context ;-).
=head2 No-ops
X<no-op> X<nop>
Perl doesn't officially have a no-op operator, but the bare constants
C<0> and C<1> are special-cased to not produce a warning in a void
context, so you can for example safely do
1 while foo();
^ permalink raw reply
* Re: [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Junio C Hamano @ 2006-11-24 1:30 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <7vejrthf2y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
> writes:
>
>> Sorry, but I don't understand. The color handling doesn't look any different
>> to me than the handling of the other config entrys. Did I miss something?
>
> "git-diff-tree --color HEAD" (with explicit command line
> instruction to color it) still colours its output, but "[diff]
> color = auto" in ~/.gitconfig would not affect the coloring.
> Hence, "git-diff-tree HEAD" with the configuration entry gives
> monochrome.
>
> "git diff HEAD" on the other hand looks at '[diff] color = auto"
> and will color its output without being told on the command
> line.
Since this is about "log" family that deals with revision
structure, how about....
-- >8 --
[PATCH] config option log.showroot to show the diff of root commits
From: Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
This allows one to see a root commit as a diff in commands like git-log,
git-show and git-whatchanged.
Signed-off-by: Peter Baumann <Peter.B.Baumannn@stud.informatik.uni-erlangen.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/config.txt | 6 ++++++
builtin-log.c | 20 ++++++++++++++++----
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9d3c71c..9090762 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -219,6 +219,12 @@ i18n.commitEncoding::
browser (and possibly at other places in the future or in other
porcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
+log.showroot::
+ If true, the initial commit will be shown as a big creation event.
+ This is equivalent to a diff against an empty tree.
+ Tools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which
+ normally hide the root commit will now show it. True by default.
+
merge.summary::
Whether to include summaries of merged commits in newly created
merge commit messages. False by default.
diff --git a/builtin-log.c b/builtin-log.c
index fedb013..7acf5d3 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -13,6 +13,8 @@
#include <time.h>
#include <sys/time.h>
+static int default_show_root = 1;
+
/* this is in builtin-diff.c */
void add_head(struct rev_info *revs);
@@ -22,6 +24,7 @@ static void cmd_log_init(int argc, const
rev->abbrev = DEFAULT_ABBREV;
rev->commit_format = CMIT_FMT_DEFAULT;
rev->verbose_header = 1;
+ rev->show_root_diff = default_show_root;
argc = setup_revisions(argc, argv, rev, "HEAD");
if (rev->diffopt.pickaxe || rev->diffopt.filter)
rev->always_show_header = 0;
@@ -44,11 +47,20 @@ static int cmd_log_walk(struct rev_info
return 0;
}
+static int git_log_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "log.showroot")) {
+ default_show_root = git_config_bool(var, value);
+ return 0;
+ }
+ return git_diff_ui_config(var, value);
+}
+
int cmd_whatchanged(int argc, const char **argv, const char *prefix)
{
struct rev_info rev;
- git_config(git_diff_ui_config);
+ git_config(git_log_config);
init_revisions(&rev, prefix);
rev.diff = 1;
rev.diffopt.recursive = 1;
@@ -63,7 +75,7 @@ int cmd_show(int argc, const char **argv
{
struct rev_info rev;
- git_config(git_diff_ui_config);
+ git_config(git_log_config);
init_revisions(&rev, prefix);
rev.diff = 1;
rev.diffopt.recursive = 1;
@@ -80,7 +92,7 @@ int cmd_log(int argc, const char **argv,
{
struct rev_info rev;
- git_config(git_diff_ui_config);
+ git_config(git_log_config);
init_revisions(&rev, prefix);
rev.always_show_header = 1;
cmd_log_init(argc, argv, prefix, &rev);
@@ -109,7 +121,7 @@ static int git_format_config(const char
if (!strcmp(var, "diff.color")) {
return 0;
}
- return git_diff_ui_config(var, value);
+ return git_log_config(var, value);
}
--
1.4.4.1.g77614
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Jeff King @ 2006-11-24 1:42 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90611231552x3e33eec4w7863ce6a1da5781b@mail.gmail.com>
On Fri, Nov 24, 2006 at 12:52:13PM +1300, Martin Langhoff wrote:
> You are right. It should be something along the lines of
>
> # discard headers until first blank line
> while (<$s> ne '') {
> # nothing
> }
>
> that is, assuming we can just ignore headers happily.
That code won't work; the value of a blank line will actually be "\n"
(or "\r\n"). So you probably want:
while (<$s>) {
chomp; chomp;
last unless $_;
}
or perhaps more readably:
while (<$s>) {
last if $_ eq "\n" || $_ eq "\r\n";
}
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Junio C Hamano @ 2006-11-24 2:54 UTC (permalink / raw)
To: Jeff King; +Cc: Martin Langhoff, git
In-Reply-To: <20061124014205.GA19515@sigio.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 24, 2006 at 12:52:13PM +1300, Martin Langhoff wrote:
>
>> You are right. It should be something along the lines of
>>
>> # discard headers until first blank line
>> while (<$s> ne '') {
>> # nothing
>> }
>>
>> that is, assuming we can just ignore headers happily.
>
> That code won't work; the value of a blank line will actually be "\n"
> (or "\r\n").
Good point. For an HTTP proxy the kosher line termination would
indeed be "\r\n".
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Christian Couder @ 2006-11-24 4:48 UTC (permalink / raw)
To: Inaki Arenaza; +Cc: git
In-Reply-To: <11642344172790-git-send-email-iarenuno@eteo.mondragon.edu>
Inaki Arenaza wrote:
[...]
>
> + my ($s, $rep);
> + if($proxyhost) {
> +
> + # Use a HTTP Proxy. Only works for HTTP proxies that
> + # don't require user authentication
> + #
> + # See: http://www.ietf.org/rfc/rfc2817.txt
> +
> + $s = IO::Socket::INET->new(PeerHost => $proxyhost, PeerPort =>
> $proxyport); + die "Socket to $proxyhost: $!\n" unless defined $s;
> + $s->write("CONNECT $serv:$port HTTP/1.1\r\nHost:
> $serv:$port\r\n\r\n") + or die "Write to
> $proxyhost: $!\n";
> + $s->flush();
> +
> + $rep = <$s>;
> +
> + # The answer should loook like 'HTTP/1.x 2yy ....'
> + if(!($rep =~ m#^HTTP/1\.. 2[0-9][0-9]#)) {
> + die "Proxy connect: $rep\n";
> + }
> + # Skip the empty line of the proxy server output
> + <$s>;
> + } else {
> + my $s = IO::Socket::INET->new(PeerHost => $serv, PeerPort => $port);
It seems that "my " should not be in the above line.
> + die "Socket to $serv: $!\n" unless defined $s;
> + }
> +
> $s->write("BEGIN AUTH REQUEST\n$repo\n$user\n$pass\nEND AUTH
> REQUEST\n") or die "Write to $serv: $!\n";
> $s->flush();
Regards,
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Junio C Hamano @ 2006-11-24 5:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vlkm1hf57.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I agree --bare should continue to be a "snapshot mirror"; I am
> not advocating for the removal of the internal implementation
> detail such as $use_separate_remote variable.
>
> However, I think having one sane behaviour is the right thing to
> do for a clone that prepares a repository with a working tree
> (including the one made with -n option, which only means "do not
> do the check-out immediately after cloning" for such a
> repository).
Just to let you know, I'll take the patch almost as is (even
with the --use-immingled-remote), except with a slight rewording
in the documentation to warn people that the backward
compatibility option will be removed before the next major
release.
However, this simple command fails:
$ git push $URL master
if the target repository $URL is made with use-separate-remote.
This is because 'master' matches more than one on the remote
side (heads/master and remotes/origin/master) which triggers
"Hey, that's ambiguous, make yourself clear which one you mean!"
check. This breaks t5400 test. We could "fix" the test to make
it more explicit, but that is just a workaround.
I think the send-pack/receive-pack pair needs to be taught that
an unadorned branch name 'master' never matches anything under
refs/remotes. This means that it would require an explicit
refspec heads/master:remotes/origin/master in order to pudate
refs under refs/remotes on the remote side with a push. I do
not think that is a big problem, because the normal patch-flow
for shared repository workflow is:
remote local
(fecth)
heads/master ---> remotes/origin/master ---.
| (merge)
heads/master <--- heads/master <--'
and pushing into remotes/origin/* is not a norm.
The function to fix is connect.c::match_explicit_refs() and I
_think_ making connect.c::count_refspec_match() not to consider
'foo' to match 'refs/remotes/origin/foo' (but still keeping it
to match 'refs/heads/foo' or 'refs/tags/foo') is enough to make
this happen.
This brings up two related issues. Currently we automatically
prepare "Pull: refs/heads/$branch:refs/remotes/origin/$branch"
for all branches that exists at the remote site when a clone
happens. Andy Parkins has a patch to allow a glob pattern to be
there, like this [*1*]:
Pull: refs/heads/*:refs/remotes/origin/*
which makes sense, and we might want to have this as the default
after the clone [*2*].
Another is if we might want to add "Push: " entry in the default
after the clone. I am a bit reluctant to make the default setup
too specific to CVS style "central shared repo" workflow, but
any stupid default would not suit people with truly distributed
workflow anyway, so it might be fine.
[Footnotes]
*1* I rewrote the patch because I wanted to deal with the
fallout from recent packed-refs work at the same time. So bugs
in the counter-proposal patch is mine while the credit for the
initiative and the idea goes to Andy.
*2* I think the fetch wildcarding has an issue with what remote
head to merge when used with "git pull". I think it should
use the one that is pointed at by refs/remotes/origin/HEAD,
but there is no code for that yet. Hints, hints...
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Junio C Hamano @ 2006-11-24 6:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vzmahe6qe.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> However, this simple command fails:
>
> $ git push $URL master
>
> if the target repository $URL is made with use-separate-remote.
>
> This is because 'master' matches more than one on the remote
> side (heads/master and remotes/origin/master) which triggers
> "Hey, that's ambiguous, make yourself clear which one you mean!"
> check. This breaks t5400 test. We could "fix" the test to make
> it more explicit, but that is just a workaround.
>
> I think the send-pack/receive-pack pair needs to be taught that
> an unadorned branch name 'master' never matches anything under
> refs/remotes. This means that it would require an explicit
> refspec heads/master:remotes/origin/master in order to pudate
> refs under refs/remotes on the remote side with a push.
> ...
> The function to fix is connect.c::match_explicit_refs() and I
> _think_ making connect.c::count_refspec_match() not to consider
> 'foo' to match 'refs/remotes/origin/foo' (but still keeping it
> to match 'refs/heads/foo' or 'refs/tags/foo') is enough to make
> this happen.
That is,...
-- >8 --
[PATCH] refs outside refs/{heads,tags} match less strongly.
This changes the refname matching logic used to decide which ref
is updated with git-send-pack. We used to error out when
pushing 'master' when the other end has both 'master' branch and
a tracking branch 'remotes/$name/master' but with this, 'master'
matches only 'refs/heads/master' when both and no other 'master'
exist.
Pushing 'foo' when both heads/foo and tags/foo exist at the
remote end is still considered an error and you would need to
disambiguate between them by being more explicit.
When neither heads/foo nor tags/foo exists at the remote,
pushing 'foo' when there is only remotes/origin/foo is not
ambiguous, while it still is ambiguous when there are more than
one such weaker match (remotes/origin/foo and remotes/alt/foo,
for example).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/connect.c b/connect.c
index c55a20a..b9666cc 100644
--- a/connect.c
+++ b/connect.c
@@ -174,21 +174,58 @@ static int count_refspec_match(const cha
struct ref *refs,
struct ref **matched_ref)
{
- int match;
int patlen = strlen(pattern);
+ struct ref *matched_weak = NULL;
+ struct ref *matched = NULL;
+ int weak_match = 0;
+ int match = 0;
- for (match = 0; refs; refs = refs->next) {
+ for (weak_match = match = 0; refs; refs = refs->next) {
char *name = refs->name;
int namelen = strlen(name);
+ int weak_match;
+
if (namelen < patlen ||
memcmp(name + namelen - patlen, pattern, patlen))
continue;
if (namelen != patlen && name[namelen - patlen - 1] != '/')
continue;
- match++;
- *matched_ref = refs;
+
+ /* A match is "weak" if it is with refs outside
+ * heads or tags, and did not specify the pattern
+ * in full (e.g. "refs/remotes/origin/master") or at
+ * least from the toplevel (e.g. "remotes/origin/master");
+ * otherwise "git push $URL master" would result in
+ * ambiguity between remotes/origin/master and heads/master
+ * at the remote site.
+ */
+ if (namelen != patlen &&
+ patlen != namelen - 5 &&
+ strncmp(name, "refs/heads/", 11) &&
+ strncmp(name, "refs/tags/", 10)) {
+ /* We want to catch the case where only weak
+ * matches are found and there are multiple
+ * matches, and where more than one strong
+ * matches are found, as ambiguous. One
+ * strong match with zero or more weak matches
+ * are acceptable as a unique match.
+ */
+ matched_weak = refs;
+ weak_match++;
+ }
+ else {
+ matched = refs;
+ match++;
+ }
+ }
+ if (!matched) {
+ *matched_ref = matched_weak;
+ return weak_match;
+ }
+ else {
+ *matched_ref = matched;
+ return match;
}
- return match;
}
static void link_dst_tail(struct ref *ref, struct ref ***tail)
^ permalink raw reply related
* Re: [PATCH] Increase length of function name buffer
From: Junio C Hamano @ 2006-11-24 6:47 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <7vbqmxkhpk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Andy Parkins <andyparkins@gmail.com> writes:
>
>> In xemit.c:xdl_emit_diff() a buffer for showing the function name as
>> commentary is allocated; this buffer was 40 characters. This is a bit
>> small;...
>...
> I wonder however which is easier to read, a loooong heading line
> as you do in this patch, or "...TailOfVeryLongClassName::method"
> that still fits on a single line without terminal line-wrapping.
Nah, I was stupid again.
It would give something silly like the attached patch if we do
what I suggested (notice the function header line which does not
give us anything useful).
Will apply your version as is.
---
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 07995ec..30d3df1 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -87,8 +87,10 @@ long i, char *buf, long sz, long *ll) {
(isalpha((unsigned char)*rec) || /* identifier? */
*rec == '_' || /* also identifier? */
*rec == '$')) { /* mysterious GNU diff's invention */
- if (len > sz)
+ if (len > sz) {
+ rec += len - sz;
len = sz;
+ }
while (0 < len && isspace((unsigned char)rec[len - 1]))
len--;
memcpy(buf, rec, len);
^ permalink raw reply related
* Re: git-show --stat on first commit
From: Jakub Narebski @ 2006-11-24 7:49 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611230925.07821.andyparkins@gmail.com>
Andy Parkins wrote:
> On Tuesday 2006 November 21 20:03, Jakub Narebski wrote:
>
>> We don't show patch for merges by default in git-show, so I don't
>> see why we would want to show root commit diff in git-show by default:
>> those two are very similar.
>
> $ git init-db
> $ date > file1
> $ git add file1; git commit -a -m "file1 added"
> $ date > file2
> $ git add file2; git commit -a -m "file2 added"
> $ git show --stat HEAD
> $ git show --stat HEAD^
>
> I can understand while people get confused. Two patches, both add a file.
> git-show on one of them shows a stat; on the other it doesn't.
Well, perhaps "git show --stat" should show diffstat also for root
commit, because it shows diffstat for merges (although not patch),
but not patch (which usually is huge).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Peter Baumann @ 2006-11-24 7:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmahfx6q.fsf@assigned-by-dhcp.cox.net>
On 2006-11-24, Junio C Hamano <junkio@cox.net> wrote:
>> "git-diff-tree --color HEAD" (with explicit command line
>> instruction to color it) still colours its output, but "[diff]
>> color = auto" in ~/.gitconfig would not affect the coloring.
>> Hence, "git-diff-tree HEAD" with the configuration entry gives
>> monochrome.
>>
>> "git diff HEAD" on the other hand looks at '[diff] color = auto"
>> and will color its output without being told on the command
>> line.
>
> Since this is about "log" family that deals with revision
> structure, how about....
>
> -- >8 --
> [PATCH] config option log.showroot to show the diff of root commits
[...]
Patch looks good.
One question, what's the difference between git-log -p and git-whatchanged -p?
I could only see it differ in the root commit handling.
Interesting parts marked with | as first character of the line.
git-repo-config --get log.showroot
false
git-log -p 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
commit 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:16:10 2005 -0700
Add copyright notices.
The tool interface sucks (especially "committing" information, which is just
me doing everything by hand from the command line), but I think this is in
theory actually a viable way of describing the world. So copyright it.
diff --git a/cat-file.c b/cat-file.c
index 74a0a23..d8f0121 100644
--- a/cat-file.c
+++ b/cat-file.c
@@ -1,3 +1,8 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Linus Torvalds, 2005
+ */
#include "cache.h"
int main(int argc, char **argv)
[... rest of the diff ...]
| commit e83c5163316f89bfbde7d9ab23ca2e25604af290
| Author: Linus Torvalds <torvalds@ppc970.osdl.org>
| Date: Thu Apr 7 15:13:13 2005 -0700
|
| Initial revision of "git", the information manager from hell
|
[ ... as specified in log.showroot, no diff of the root commit ...]
git-whatchanged -p 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
commit 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:16:10 2005 -0700
Add copyright notices.
The tool interface sucks (especially "committing" information, which is just
me doing everything by hand from the command line), but I think this is in
theory actually a viable way of describing the world. So copyright it.
diff --git a/cat-file.c b/cat-file.c
index 74a0a23..d8f0121 100644
--- a/cat-file.c
+++ b/cat-file.c
@@ -1,3 +1,8 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Linus Torvalds, 2005
+ */
#include "cache.h"
int main(int argc, char **argv)
[... rest of the diff ...]
|
| [ ... no commit message etc from the root commit is shown ...]
|
As you can see, the root commit isn't shown. Is this intentional?
Or is it just me not getting the different meaning of git-log and
git-whatchanged?
Setting "log.showroot = true" the output of the 2 commands is identical.
Peter
^ permalink raw reply
* Re: "stgit clean" has problems with removed generated files
From: Jakub Narebski @ 2006-11-24 8:20 UTC (permalink / raw)
To: git
In-Reply-To: <20061123192831.GL5443@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson wrote:
> On Thu, Nov 23, 2006 at 04:33:42PM +0000, Catalin Marinas wrote:
>> >fatal: Untracked working tree file 'include/asm-arm/constants.h' would be
>> >overwritten by merge.
>>
>> That's a git error and I think it is the correct behaviour. It is
>> safer to notify that a local file is overridden by a merge/switch
>> operation rather than just losing its content.
>
> Right, I do not discuss the behaviour of git here. But when I first
> encountered this issue, I was really wondering about what was
> happenning. It would be really helpful in such a case, if stgit was
> able to pinpoint the precise patch which could not be popped. It could
> also be helpful to tell when popping patches - currently it's done
> "behind my back", and I could only understand what was happenning by
> reading the code.
I think it was corrected in git, or is being corrected (meaning it is
in 'next' or in 'pu'); it being relaxing "would be overwritten by merge"
check for files which were, but are not, under version control.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Stupid Git question
From: Junio C Hamano @ 2006-11-24 8:31 UTC (permalink / raw)
To: git; +Cc: Sean Kelley
In-Reply-To: <7vac2jp0g6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>...
> The most straightforward extension of the above for ref deletion
> is to say:
>
> $ git remote-admin $REPO delete-refs refs/heads/foo refs/tags/v1.0
>
> and that would be the simplest way to implement it if we were to
> go with "git remote-admin". However, I think people would find
> it more natural if manipulation of refs were part of "git push".
>
> "git push $REPO $src:$dst" means "take what I have in $src in my
> local repository, and update the $REPO's $dst ref with that".
> So as a natural extension of that, we could make:
>
> $ git push $REPO '':$dst
>
> to mean "store nothingness in $dst" and make that a way to
> express the desire to remove $dst ref.
And here is an attempt to do so. Only lightly tested...
Whenever I say "only lightly tested", I am hoping that
interested people on the list to test it and possibly
enhance it with follow-up patches. Or at least respond
with "Hey, that sucks" or "Ok, it seems to work for your
test case but here is a breakage".
-- >8 --
[PATCH] Allow git push to delete remote ref.
This allows you to say
git send-pack $URL :refs/heads/$branch
to delete the named remote branch. The refspec $src:$dst means
replace the destination ref with the object known as $src on the
local side, so this is a natural extension to make an empty $src
mean "No object" to delete the target.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
connect.c | 11 ++++++++++-
receive-pack.c | 45 ++++++++++++++++++++++++++++++++++-----------
send-pack.c | 41 ++++++++++++++++++++++++++++++-----------
t/t5400-send-pack.sh | 10 ++++++++++
4 files changed, 84 insertions(+), 23 deletions(-)
diff --git a/connect.c b/connect.c
index b9666cc..f7edba8 100644
--- a/connect.c
+++ b/connect.c
@@ -144,6 +144,7 @@ struct refspec {
* +A:B means overwrite remote B with local A.
* +A is a shorthand for +A:A.
* A is a shorthand for A:A.
+ * :B means delete remote B.
*/
static struct refspec *parse_ref_spec(int nr_refspec, char **refspec)
{
@@ -240,6 +241,13 @@ static struct ref *try_explicit_object_n
unsigned char sha1[20];
struct ref *ref;
int len;
+
+ if (!*name) {
+ ref = xcalloc(1, sizeof(*ref) + 20);
+ strcpy(ref->name, "(delete)");
+ hashclr(ref->new_sha1);
+ return ref;
+ }
if (get_sha1(name, sha1))
return NULL;
len = strlen(name) + 1;
@@ -262,7 +270,8 @@ static int match_explicit_refs(struct re
break;
case 0:
/* The source could be in the get_sha1() format
- * not a reference name.
+ * not a reference name. :refs/other is a
+ * way to delete 'other' ref at the remote end.
*/
matched_src = try_explicit_object_name(rs[i].src);
if (matched_src)
diff --git a/receive-pack.c b/receive-pack.c
index d56898c..1a141dc 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -14,7 +14,7 @@ static int deny_non_fast_forwards = 0;
static int unpack_limit = 5000;
static int report_status;
-static char capabilities[] = "report-status";
+static char capabilities[] = " report-status delete-refs ";
static int capabilities_sent;
static int receive_pack_config(const char *var, const char *value)
@@ -113,12 +113,14 @@ static int update(struct command *cmd)
strcpy(new_hex, sha1_to_hex(new_sha1));
strcpy(old_hex, sha1_to_hex(old_sha1));
- if (!has_sha1_file(new_sha1)) {
+
+ if (!is_null_sha1(new_sha1) && !has_sha1_file(new_sha1)) {
cmd->error_string = "bad pack";
return error("unpack should have generated %s, "
"but I can't find it!", new_hex);
}
- if (deny_non_fast_forwards && !is_null_sha1(old_sha1)) {
+ if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
+ !is_null_sha1(old_sha1)) {
struct commit *old_commit, *new_commit;
struct commit_list *bases, *ent;
@@ -138,14 +140,22 @@ static int update(struct command *cmd)
return error("hook declined to update %s", name);
}
- lock = lock_any_ref_for_update(name, old_sha1);
- if (!lock) {
- cmd->error_string = "failed to lock";
- return error("failed to lock %s", name);
+ if (is_null_sha1(new_sha1)) {
+ if (delete_ref(name, old_sha1)) {
+ cmd->error_string = "failed to delete";
+ return error("failed to delete %s", name);
+ }
+ fprintf(stderr, "%s: %s -> deleted\n", name, old_hex);
+ }
+ else {
+ lock = lock_any_ref_for_update(name, old_sha1);
+ if (!lock) {
+ cmd->error_string = "failed to lock";
+ return error("failed to lock %s", name);
+ }
+ write_ref_sha1(lock, new_sha1, "push");
+ fprintf(stderr, "%s: %s -> %s\n", name, old_hex, new_hex);
}
- write_ref_sha1(lock, new_sha1, "push");
-
- fprintf(stderr, "%s: %s -> %s\n", name, old_hex, new_hex);
return 0;
}
@@ -375,6 +385,16 @@ static void report(const char *unpack_st
packet_flush(1);
}
+static int delete_only(struct command *cmd)
+{
+ while (cmd) {
+ if (!is_null_sha1(cmd->new_sha1))
+ return 0;
+ cmd = cmd->next;
+ }
+ return 1;
+}
+
int main(int argc, char **argv)
{
int i;
@@ -408,7 +428,10 @@ int main(int argc, char **argv)
read_head_info();
if (commands) {
- const char *unpack_status = unpack();
+ const char *unpack_status = NULL;
+
+ if (!delete_only(commands))
+ unpack_status = unpack();
if (!unpack_status)
execute_commands();
if (pack_lockfile)
diff --git a/send-pack.c b/send-pack.c
index 4476666..328dbbc 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -271,6 +271,7 @@ static int send_pack(int in, int out, in
int new_refs;
int ret = 0;
int ask_for_status_report = 0;
+ int allow_deleting_refs = 0;
int expect_status_report = 0;
/* No funny business with the matcher */
@@ -280,6 +281,8 @@ static int send_pack(int in, int out, in
/* Does the other end support the reporting? */
if (server_supports("report-status"))
ask_for_status_report = 1;
+ if (server_supports("delete-refs"))
+ allow_deleting_refs = 1;
/* match them up */
if (!remote_tail)
@@ -299,9 +302,19 @@ static int send_pack(int in, int out, in
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
char old_hex[60], *new_hex;
+ int delete_ref;
+
if (!ref->peer_ref)
continue;
- if (!hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
+
+ delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
+ if (delete_ref && !allow_deleting_refs) {
+ error("remote does not support deleting refs");
+ ret = -2;
+ continue;
+ }
+ if (!delete_ref &&
+ !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
if (verbose)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
@@ -321,9 +334,13 @@ static int send_pack(int in, int out, in
*
* (3) if both new and old are commit-ish, and new is a
* descendant of old, it is OK.
+ *
+ * (4) regardless of all of the above, removing :B is
+ * always allowed.
*/
if (!force_update &&
+ !delete_ref &&
!is_zero_sha1(ref->old_sha1) &&
!ref->force) {
if (!has_sha1_file(ref->old_sha1) ||
@@ -347,12 +364,8 @@ static int send_pack(int in, int out, in
}
}
hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
- if (is_zero_sha1(ref->new_sha1)) {
- error("cannot happen anymore");
- ret = -3;
- continue;
- }
- new_refs++;
+ if (!delete_ref)
+ new_refs++;
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
new_hex = sha1_to_hex(ref->new_sha1);
@@ -366,10 +379,16 @@ static int send_pack(int in, int out, in
else
packet_write(out, "%s %s %s",
old_hex, new_hex, ref->name);
- fprintf(stderr, "updating '%s'", ref->name);
- if (strcmp(ref->name, ref->peer_ref->name))
- fprintf(stderr, " using '%s'", ref->peer_ref->name);
- fprintf(stderr, "\n from %s\n to %s\n", old_hex, new_hex);
+ if (delete_ref)
+ fprintf(stderr, "deleting '%s'\n", ref->name);
+ else {
+ fprintf(stderr, "updating '%s'", ref->name);
+ if (strcmp(ref->name, ref->peer_ref->name))
+ fprintf(stderr, " using '%s'",
+ ref->peer_ref->name);
+ fprintf(stderr, "\n from %s\n to %s\n",
+ old_hex, new_hex);
+ }
}
packet_flush(out);
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 8afb899..28744b3 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -64,6 +64,16 @@ test_expect_success \
cmp victim/.git/refs/heads/master .git/refs/heads/master
'
+test_expect_success \
+ 'push can be used to delete a ref' '
+ cd victim &&
+ git branch extra master &&
+ cd .. &&
+ test -f victim/.git/refs/heads/extra &&
+ git-send-pack ./victim/.git/ :extra master &&
+ ! test -f victim/.git/refs/heads/extra
+'
+
unset GIT_CONFIG GIT_CONFIG_LOCAL
HOME=`pwd`/no-such-directory
export HOME ;# this way we force the victim/.git/config to be used.
--
1.4.4.1.g77614
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Ignacio Arenaza @ 2006-11-24 8:41 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200611240548.00840.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
>> + my $s = IO::Socket::INET->new(PeerHost => $serv, PeerPort => $port);
>
> It seems that "my " should not be in the above line.
Yup! Your right. Will send a new patch with the fixes in a few hours.
Saludos. Iñaki.
--
School of Management
Mondragon University
20560 Oñati - Spain
+34 943 718009 (ext. 225)
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Ignacio Arenaza @ 2006-11-24 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7v64d5keke.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The "I/O Operators" section talks about evaluating <$s> in a
> scalar context (i.e. "$rep = <$s>"), which we all know would
> return a single line, and in list context, which swallows
> everything up to EOF, an obvious disaster for this particular
> use. I couldn't find how it is defined to behave in a void
> context. By experiments I know this returns only one line, but
> it leaves me feeling somewhat uneasy.
This is scalar context, as we are using the implicit $_ variable as
the destination of the asignment. It seems it's not so obvious for
non-Perl speakers, so I'll use a clearer idiom :-)
Saludos. Iñaki.
--
School of Management
Mondragon University
20560 Oñati - Spain
+34 943 718009 (ext. 225)
^ 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