* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-20 22:53 UTC (permalink / raw)
To: Junio C Hamano, Wesley J. Landaker; +Cc: git, Björn Steinbrink
In-Reply-To: <7vpr8hlow9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> > d) in mercurial, pull/push are symmetric, but fetch means pull+merge
Ugh. I can see how they arrived at hg-pull == git-fetch, but why on
earth was the logical next step hg-fetch == git-pull?!
</aside>
> > I would love to see this change, not because I get confused about pull/fetch
> > (it honestly only took a few days to get used to), but because having
> > push/pull be symmetric just is so much more conceptually pure / easier
> > explain to co-workers / separation between orthogonal operations /
> > satisfying to my inner perfectionist / etc.
>
> Is making "pull" a symmetric opposite of "push" the ultimate goal?
>
> Or is making (or rather "keeping") "pull" useful more important?
>
> It is not even an attitude that values philosophy over utility.
>
> Fundamentally, pull and push cannot be symmetric because nobody is sitting
> in front of the repository you are pushing into (that is what a "push" is;
> you push from outside the repository---otherwise you would be "pull"ing
> from inside it in the other direction), but you know you are sitting in
> the repository, ready to resolve potential conflicts, when you say "pull".
Well, I'd rather not argue the little semantic details, but I think
with the changes to disallow pushing into HEAD, push and fetch are as
symmetric as it gets. Both are exactly and only about transmitting
refs with their associated commits to the other side. Which one you
pick only depends on which side you sit on.
OTOH pull is about merging. And we can repeat the "pull = fetch +
merge" mantra to ourselves all we like, having pull as "the opposite
of push" is conceptually much easier to understand and thus far easier
to explain to new users.
> And you are doing this for what gain? The only thing I can think of is
> "People who deliberately set 'pull.merge = yes' can no longer blame us for
> pull not being the opposite of push." I do not consider it as a gain.
>
> I do not buy "People who set 'pull.merge = yes' now understand why pull
> touches their work tree, because they did it themselves" either.
[...]
> But I do not know what to say when people say "push cannot update the work
> tree, so let's make pull not to update the work tree by default---it will
> make it much less useful so we will fix that regression with yet another
> configuration option".
There would not be a configuration option.
Really, the whole goal would be to make pull the opposite of push. No
exceptions, and most certainly no little loopholes to escape into the
merging behaviour by default. The current 'git pull' behaviour would
either be obtained through a new command, or through an explicit
switch.
> I would be much more sympathetic if the suggested approach were to make
> "push" more symmetric to "pull", or at least attempt to allow it to be, by
> giving it an option to update the associated work tree when it can [*1*].
[...]
> *1* Obviously you cannot do this most of the time _if_ the work tree has
> an interactive user sitting in front of it, but in a repository that never
> allows a non-ff push, with a work tree that is never updated except by
> such a push, can reasonably be maintained to give an illusion of push
> being an opposite of pull by fast forwarding the work tree when the push
> updates HEAD.
Well, that reminds me of
http://thread.gmane.org/gmane.comp.version-control.git/110251
but was not really what I was aiming at.
> It's not even funny.
It was an RFC, not a joke ;-)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Joe Perches @ 2009-10-20 22:48 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <40aa078e0910201529m338ef3d1o4fa1a31c3dcc2a20@mail.gmail.com>
On Wed, 2009-10-21 at 00:29 +0200, Erik Faye-Lund wrote:
> On Wed, Oct 21, 2009 at 12:12 AM, Joe Perches <joe@perches.com> wrote:
> > I typo cut/pasted an invalid email address,
> > neglecting to copy the trailing ">".
> > was: "Name <addr.org"
> > needed: "Name <addr.org>"
> > Anyone have suggestions on how to get
> > git-send-email.perl to notify and abort
> > sending on more invalid address styles?
>
> Something along these lines? Of course, the error message is, uhm,
> less than helpful :)
>
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -787,6 +787,10 @@ sub is_rfc2047_quoted {
> sub sanitize_address
> {
> my ($recipient) = @_;
> + if ($recipient =~ m/.*<[^>]*$/) {
> + die "EEK!"
> + }
> +
Maybe this? Seems to work.
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..52ddd9e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -374,15 +374,18 @@ my ($repoauthor, $repocommitter);
# Verify the user input
foreach my $entry (@to) {
- die "Comma in --to entry: $entry'\n" unless $entry !~ m/,/;
+ die "Comma in --to entry: '$entry'\n" unless $entry !~ m/,/;
+ die "Invalid --to entry: '$entry'\n" unless $entry !~ m/.*<[^>]*$/;
}
foreach my $entry (@initial_cc) {
- die "Comma in --cc entry: $entry'\n" unless $entry !~ m/,/;
+ die "Comma in --cc entry: '$entry'\n" unless $entry !~ m/,/;
+ die "Invalid --cc entry: '$entry'\n" unless $entry !~ m/.*<[^>]*$/;
}
foreach my $entry (@bcclist) {
- die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
+ die "Comma in --bcclist entry: '$entry'\n" unless $entry !~ m/,/;
+ die "Invalid --bcclist entry: '$entry'\n" unless $entry !~ m/.*<[^>]*$/;
}
sub parse_address_line {
^ permalink raw reply related
* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-20 22:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Bjrn Steinbrink
In-Reply-To: <20091021064243.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Thomas Rast <trast@student.ethz.ch>
> > 1. git-fetch gets options --merge/-m and --rebase that make it behave
> > like (current) git-pull, but requiring explicit arguments.
> > git-pull gets a new option --merge (-m) that only enforces presence
> > of arguments.
> >
> > 2. git-pull refuses to do any work unless given either --merge or
> > --rebase. Deprecation warnings for this start at the same time as
> > (1.).
> >
> > 3. git-pull becomes a synonym for git-fetch.
> >
> > 4. git-fetch gives deprecation warnings that point the user to
> > git-pull instead.
>
> Sorry, but I don't understand what's the improvement in the end
> result.
>
> I started reading your problem description and I thought you are
> fixing your item 'a) pull/push are not symmetric' by deprecating
> pull, to advertize fetch/push. Then asymmetry of push/pull stops
> being an issue.
>
> But it seems that eventually you will keep git-push and git-pull
> (because git-fetch gets deprecated); you have push/pull that are
> not symmetric.
By the time I get to that step, new-pull is current-fetch. So by that
time, push/pull *are* supposedly symmetric.
(Only deprecating pull never occurred to me, but then I really think
the strong association between them makes it worth keeping pull as the
opposite of push.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: ident hash usage question
From: Junio C Hamano @ 2009-10-20 22:30 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <76c5b8580910201514sc44f1cag222cf8a3710c875@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
>> If the project is already arranged to be compiled with decent automation,
>> I do not think you need any change to the workflow.
>>
>> You would have a version.cc file with
>>
>> static char program_version[] = "My Program " VERSION_STRING;
>>
>> in it, and teach the build procedure how to compile and link this file.
>> Something like:
>>
>> version.o: version.cc
>> $(CXX) -o $@ -DVERSION_STRING=\""$(git describe HEAD)"\" $?
>>
>
> Please, correct me if I'm mistaken and forgive me if I'm not correct
> in using C++ terms.
>
> Your solution proposes to have a version file which will carry the
> info about last state the program was built from.
> But as I understand in case of static linking the executable will get
> only obj files from a library, which are necessary and everything
> irrelevant will be thrown away by linker.
I am not sure what you mean by "static linking" anymore. Usually the word
means that everything you tell the linker to link to the executable is
linked, together with objects from libraries. The resulting executable is
usable on its own and it does not change behaviour regardless of which
version of dynamic libraries you depend on happen to be installed on the
target system (because by definition a statically linked executable does
not depend on dynamic libraries---that is the whole point of static
linking).
So as long as you make sure version.o is linked to the final executable,
you will be fine. One way to do so might be to have
printf("Program version: %s", program_version);
at the beginning of main() ;-)
If your product ships as one main executable _dynamically_ linked with two
dynamic libraries, and all three components are built from the source
material under your source control, obviously you would need to make sure
that the above version.o or some equivalent of what embeds output from
"git describe HEAD" are linked to the main executable and to the two
libraries, but the idea is the same.
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Erik Faye-Lund @ 2009-10-20 22:29 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <1256076767.2029.59.camel@Joe-Laptop.home>
On Wed, Oct 21, 2009 at 12:12 AM, Joe Perches <joe@perches.com> wrote:
> I typo cut/pasted an invalid email address,
> neglecting to copy the trailing ">".
>
> was: "Name <addr.org"
> needed: "Name <addr.org>"
>
> Anyone have suggestions on how to get
> git-send-email.perl to notify and abort
> sending on more invalid address styles?
Something along these lines? Of course, the error message is, uhm,
less than helpful :)
--->8---
diff --git a/git-send-email.perl b/git-send-email.perl
index f5ba4e7..83f5e80 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -787,6 +787,10 @@ sub is_rfc2047_quoted {
sub sanitize_address
{
my ($recipient) = @_;
+ if ($recipient =~ m/.*<[^>]*$/) {
+ die "EEK!"
+ }
+
my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
if (not $recipient_name) {
--
Erik "kusma" Faye-Lund
^ permalink raw reply related
* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 22:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Eugene Sajine
In-Reply-To: <81b0412b0910201343r4ff49f9fnbdd9260dcf682416@mail.gmail.com>
>> How is that? It seams to me that git log <path> will show only commits
>> where <path> was changed/committed? Considering the fact that I've got
>> the initial path from the blob, i should get the exact commit history
>> (or last commit in my example) for the file(s) (Files if renaming
>> occurred without content change).
>
> The blob is present in each commit since it was introduced. Except
> when your project contains only that one blob, isn't the state of
> the other parts of an interest?
>
I would question this statement. It seems to me that hash of the file
content is logged only for the commit when it was touched.
Therefore there is very limited amount of actual commits where the
same hash can be met.
Thanks,
Eugene
^ permalink raw reply
* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Eugene Sajine
In-Reply-To: <7veioxn6ee.fsf@alter.siamese.dyndns.org>
> If the project is already arranged to be compiled with decent automation,
> I do not think you need any change to the workflow.
>
> You would have a version.cc file with
>
> static char program_version[] = "My Program " VERSION_STRING;
>
> in it, and teach the build procedure how to compile and link this file.
> Something like:
>
> version.o: version.cc
> $(CXX) -o $@ -DVERSION_STRING=\""$(git describe HEAD)"\" $?
>
Please, correct me if I'm mistaken and forgive me if I'm not correct
in using C++ terms.
Your solution proposes to have a version file which will carry the
info about last state the program was built from.
But as I understand in case of static linking the executable will get
only obj files from a library, which are necessary and everything
irrelevant will be thrown away by linker. In this circumstances the
program comparing two executable will not notice any differences
between let's say existing production and new development version of
the executable. In case of several libraries linked this gets even
worse. That's what their basis is for keywords expansion use.
If there is no other solution in VCS terms how to understand which
particular version of file has got linked to the executable except
keywords expansion, then I'm talking about the way of reducing the
amount of keywords expanded to a minimum - 1.
If we can agree on this, then it seems that having the content/blob
hash in the file $Id$ is enough to get any other relevant info about
the file.
At least by hash you can find the path added/modified. When the path
is on hands you can easily realize the history for the file. It seems
to me that using content hash will provide unique results enough to
make conclusions, because the probability of having two files with
same hash but different content is too low, and only scenario is to
get the same hash is to get the absolute copy of the file, but such
file existence is questionable...
OTOH, Alex was right that there are situation where this is not
working as expected from the first run:
If the file was modified its blob hash is going to change, but there
will be no entry with letter A in the log. So, if
$ git log --no-abbrev --raw --all | grep "SHA-1 A"
Returns empty string then, we should do that without "A".
As I understand this *second* run should always return:
1. only one entry if this is latest hash - one path. Goal reached.
2. two entries if there was a change afterwards - One path. Goal reached
3. three entries if rename was committed separately and then renamed
file was changed - two paths. Enough to make conclusion about the
files.
In any case the goal is to get the path as correct as possible and
then proceed with matching and other stuff.
Thanks,
Eugene
^ permalink raw reply
* git-send-email.perl defect: address missing trailing > accepted
From: Joe Perches @ 2009-10-20 22:12 UTC (permalink / raw)
To: git
I typo cut/pasted an invalid email address,
neglecting to copy the trailing ">".
was: "Name <addr.org"
needed: "Name <addr.org>"
Anyone have suggestions on how to get
git-send-email.perl to notify and abort
sending on more invalid address styles?
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Junio C Hamano @ 2009-10-20 22:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Sverre Rabbelier, Git List
In-Reply-To: <alpine.DEB.1.00.0910202153160.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 20 Oct 2009, Junio C Hamano wrote:
>
>> Sverre Rabbelier <srabbelier@gmail.com> writes:
>>
>> >> Or am I worrying too much?
>> >
>> > No, I think your concerns are valid, we should go with (2) and DTRT.
>> > Does the updated patch address your concerns? If so I can send a new
>> > version.
>>
>> Assuming the internal blame algorithm correctly works with such an
>> input, I'd be happier with an approach to allow users to tell the
>> difference. The --porcelain output was designed to be extensible, and it
>> might make sense to show the "this line is incomplete" as a separate
>> bit, though.
>
> Sorry, you lost me. If, say, line 614 is the last line that does not end
> in a new line, if I ask for it to be blamed, I want to know who is
> responsible for the current form of line 614.
>
> Not whether the line ends in a new line or not.
Yeah, I know.
I was primarily worried about making the output format into something
Porcelains (that read from --porcelain format) cannot reconstruct the
original text from.
See Message-ID: <7viqe9n72w.fsf@alter.siamese.dyndns.org> for a revised
suggestion.
^ permalink raw reply
* [PATCH] receive-pack: run "gc --auto" and optionally "update-server-info"
From: Junio C Hamano @ 2009-10-20 21:56 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <alpine.LFD.2.00.0910201706430.21460@xanadu.home>
Introduce two new configuration variables, receive.autogc (defaults to
true) and receive.updateserverinfo (defaults to false). When these are
set, receive-pack runs "gc --auto" and "update-server-info" respectively
after it finishes receiving data from "git push" and updating refs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Nicolas Pitre <nico@fluxnic.net> writes:
> On Tue, 20 Oct 2009, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@fluxnic.net> writes:
>>
>> > Still... Hopefully this is going to become redundant information in the
>> > future with the eventual deployment of smart protocol over HTTP. So I
>> > think that as a config option being off by default this is a good
>> > compromize. Site administrators can turn it on by default in
>> > /etc/gitconfig.
>>
>> Ok, something like this?
>
> Looks fine to me, except...
Everything you said sounded sensible. Thanks.
Documentation/config.txt | 9 +++++++++
builtin-receive-pack.c | 18 ++++++++++++++++++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cd17814..ba6ed10 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1320,6 +1320,11 @@ rebase.stat::
Whether to show a diffstat of what changed upstream since the last
rebase. False by default.
+receive.autogc::
+ By default, git-receive-pack will run "git-gc --auto" after
+ receiving data from git-push and updating refs. You can stop
+ it by setting this variable to false.
+
receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
@@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::
even if that push is forced. This configuration variable is
set when initializing a shared repository.
+receive.updateserverinfo::
+ If set to true, git-receive-pack will run git-update-server-info
+ after receiving data from git-push and updating refs.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index b771fe9..92173ac 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
static int report_status;
static int prefer_ofs_delta = 1;
+static int auto_update_server_info;
+static int auto_gc = 1;
static const char *head_name;
static char *capabilities_to_send;
@@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (strcmp(var, "receive.updateserverinfo") == 0) {
+ auto_update_server_info = git_config_bool(var, value);
+ return 0;
+ }
+
+ if (strcmp(var, "receive.autogc") == 0) {
+ auto_gc = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
@@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
report(unpack_status);
run_receive_hook(post_receive_hook);
run_update_post_hook(commands);
+ if (auto_gc) {
+ const char *argv_gc_auto[] = { "gc", "--auto", NULL };
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ }
+ if (auto_update_server_info)
+ update_server_info(0);
}
return 0;
}
--
1.6.5.1.107.gba912
^ permalink raw reply related
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-20 21:46 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: Thomas Rast, git, Björn Steinbrink
In-Reply-To: <200910201359.30880.wjl@icecavern.net>
"Wesley J. Landaker" <wjl@icecavern.net> writes:
> On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote:
>> Especially on IRC, we see many people who are some combination of
>> misunderstanding, misusing or overusing git-pull. I figure this is
>> the result of several factors, notably
>>
>> a) pull/push are not symmetric,
>>
>> b) guides/tutorials recommend pull for situations where they
>> shouldn't,
>>
>> c) people blindly fire commands at git.
>
> This may be minor, but also:
>
> d) in mercurial, pull/push are symmetric, but fetch means pull+merge
>
>> As you probably guessed by now, here is an idea for a very aggressive
>> transition plan to address (a) in four phases:
>
> I would love to see this change, not because I get confused about pull/fetch
> (it honestly only took a few days to get used to), but because having
> push/pull be symmetric just is so much more conceptually pure / easier
> explain to co-workers / separation between orthogonal operations /
> satisfying to my inner perfectionist / etc.
Is making "pull" a symmetric opposite of "push" the ultimate goal?
Or is making (or rather "keeping") "pull" useful more important?
It is not even an attitude that values philosophy over utility.
Fundamentally, pull and push cannot be symmetric because nobody is sitting
in front of the repository you are pushing into (that is what a "push" is;
you push from outside the repository---otherwise you would be "pull"ing
from inside it in the other direction), but you know you are sitting in
the repository, ready to resolve potential conflicts, when you say "pull".
Your elaborate scheme to make "pull" into "fetch" and to force everybody
to set a configuration variable to make it "pull" again sounds like a
mindless mental masturbation to me. People who leave "pull.merge = no"
will always have to say "pull --merge" or "pull --rebase", so you cannot
even argue you are not forcing but giving them a choice.
And you are doing this for what gain? The only thing I can think of is
"People who deliberately set 'pull.merge = yes' can no longer blame us for
pull not being the opposite of push." I do not consider it as a gain.
I do not buy "People who set 'pull.merge = yes' now understand why pull
touches their work tree, because they did it themselves" either. People
blindly copy other people's configuration from random web pages without
understanding. Besides, the next thing they will ask is "Why is there
pull.merge but no push.merge? Wasn't push an opposite of pull?" and you
are back to square one.
I would be much more sympathetic if the suggested approach were to make
"push" more symmetric to "pull", or at least attempt to allow it to be, by
giving it an option to update the associated work tree when it can [*1*].
But I do not know what to say when people say "push cannot update the work
tree, so let's make pull not to update the work tree by default---it will
make it much less useful so we will fix that regression with yet another
configuration option". It's not even funny.
[Footnote]
*1* Obviously you cannot do this most of the time _if_ the work tree has
an interactive user sitting in front of it, but in a repository that never
allows a non-ff push, with a work tree that is never updated except by
such a push, can reasonably be maintained to give an illusion of push
being an opposite of pull by fast forwarding the work tree when the push
updates HEAD.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Nanako Shiraishi @ 2009-10-20 21:42 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Bjrn Steinbrink
In-Reply-To: <200910201947.50423.trast@student.ethz.ch>
Quoting Thomas Rast <trast@student.ethz.ch>
> Especially on IRC, we see many people who are some combination of
> misunderstanding, misusing or overusing git-pull. I figure this is
> the result of several factors, notably
>
> a) pull/push are not symmetric,
>
> b) guides/tutorials recommend pull for situations where they
> shouldn't,
>
> c) people blindly fire commands at git.
>
> While the latter two are probably hopeless, I find (a) rather
> annoying. It breaks everyone's intuition of git-pull when they first
> see it. (I know that BK has a pull that also merges, but I gather
> from the manual [never used it] that you cannot do the equivalent of
> git-fetch in BK.)
>
> As you probably guessed by now, here is an idea for a very aggressive
> transition plan to address (a) in four phases:
>
> 1. git-fetch gets options --merge/-m and --rebase that make it behave
> like (current) git-pull, but requiring explicit arguments.
> git-pull gets a new option --merge (-m) that only enforces presence
> of arguments.
>
> 2. git-pull refuses to do any work unless given either --merge or
> --rebase. Deprecation warnings for this start at the same time as
> (1.).
>
> 3. git-pull becomes a synonym for git-fetch.
>
> 4. git-fetch gives deprecation warnings that point the user to
> git-pull instead.
>
> (1.) is probably harmless and could be put into any particular
> release. (2.) obviously breaks everyone's favourite script and needs
> to fall on a major release. (3.) should be delayed significantly from
> (2.) to allow time to expose such breakage, and similarly (4.) should
> be delayed after (3.) (or just ignored, but in any case git-pull would
> become the preferred spelling).
Sorry, but I don't understand what's the improvement in the end
result.
I started reading your problem description and I thought you are
fixing your item 'a) pull/push are not symmetric' by deprecating
pull, to advertize fetch/push. Then asymmetry of push/pull stops
being an issue.
But it seems that eventually you will keep git-push and git-pull
(because git-fetch gets deprecated); you have push/pull that are
not symmetric.
What's the point of this change then?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Git rebase using "wrong" commit
From: Junio C Hamano @ 2009-10-20 21:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: Philip Allison, git, Thomas Adam
In-Reply-To: <200910201521.05526.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Note that there is no real reason to rebase continually unless you
> want to kick out flawed topics or old versions of branches. For
> example, git.git only rebases 'next' immediately after a release.
> Furthermore, even if you go for the 'pu' model which is rebuilt all
> the time, you can automate this with a script. There is one in the
> 'todo' branch of git.git, called PU.
>
> (I myself just use a list of topics I want merged, and a simple 'git
> merge $topic' loop.)
I do not use PU nor RB from todo these days, by the way. I instead
rebuild my branches with Reintegrate (also from todo).
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Eric Wong @ 2009-10-20 21:16 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1256006523-5493-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> This series adds support for converting SVN merges - in the two
> popular formats, SVK and SVN 1.5+, into git parents.
Thanks Sam,
There's a couple of whitespace issues with lines being too long (using 8
character wide tabs). Otherwise I'm happy to Ack and get them out for
more testing/exposure; especially since I'm unlikely to exercise the
functionality myself[1] and doesn't appear to break anything.
Thanks again.
[1] - I've been finding fewer and fewer reasons to interact with SVN
at all as time goes by, a good thing for sure :)
--
Eric Wong
^ permalink raw reply
* Re: git gc and kernel.org
From: Nicolas Pitre @ 2009-10-20 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7v63a9n5i6.fsf@alter.siamese.dyndns.org>
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > Still... Hopefully this is going to become redundant information in the
> > future with the eventual deployment of smart protocol over HTTP. So I
> > think that as a config option being off by default this is a good
> > compromize. Site administrators can turn it on by default in
> > /etc/gitconfig.
>
> Ok, something like this?
Looks fine to me, except...
> +receive.autogc::
> + If set to true, git-receive-pack will run "git-gc --auto"
> + after receiving data from git-push and updating refs.
While I was arguing for automatic git-update-server-info to be off by
default, I however think that this one might be worth turning on by
default. Most of the time I expect people simply don't log into the
server where they push stuff and the kernel.org episode certainly shows
this as being a worthwhile thing to do, and contrary to
update-server-info this is likely to always be so even in the future.
> @@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
> report(unpack_status);
> run_receive_hook(post_receive_hook);
> run_update_post_hook(commands);
> + if (auto_update_server_info)
> + update_server_info(0);
> + if (auto_gc) {
> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
> + }
If git-update-server-info is listing packs, shouldn't it be run after
git-gc and not before?
Nicolas
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Junio C Hamano @ 2009-10-20 21:11 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Thomas Rast, git
In-Reply-To: <BLU0-SMTP97AA2287062D9A104101C8AEC00@phx.gbl>
Sean Estabrooks <seanlkml@sympatico.ca> writes:
>> -test_expect_success 'pulling into void using master:master' '
>> - mkdir cloned-uho &&
>> - (
>> - cd cloned-uho &&
>> - git init &&
>> - git pull .. master:master
>> - ) &&
>> - test -f file &&
>> - test -f cloned-uho/file &&
>> - test_cmp file cloned-uho/file
>> -
>> -
>> test_expect_success 'test . as a remote' '
>>
>> git branch copy master &&
>> --
>>
>
> Instead of removing this test it should be modified or replaced
> with a test that ensures the new functionality operates correctly.
> In this case that would mean checking that using a full refspec
> errors out.
Shouldn't "git pull .. master" still work in this case, too? So this test
will probably become two tests, one for "git pull .. master:master" that
correctly fails, and the other for "git pull .. master" to still work as
expected.
^ permalink raw reply
* Re: git gc and kernel.org
From: Junio C Hamano @ 2009-10-20 21:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <alpine.LFD.2.00.0910201442480.21460@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> Still... Hopefully this is going to become redundant information in the
> future with the eventual deployment of smart protocol over HTTP. So I
> think that as a config option being off by default this is a good
> compromize. Site administrators can turn it on by default in
> /etc/gitconfig.
Ok, something like this?
Documentation/config.txt | 8 ++++++++
builtin-receive-pack.c | 18 ++++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cd17814..2d3b4f5 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1320,6 +1320,10 @@ rebase.stat::
Whether to show a diffstat of what changed upstream since the last
rebase. False by default.
+receive.autogc::
+ If set to true, git-receive-pack will run "git-gc --auto"
+ after receiving data from git-push and updating refs.
+
receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
@@ -1355,6 +1359,10 @@ receive.denyNonFastForwards::
even if that push is forced. This configuration variable is
set when initializing a shared repository.
+receive.updateserverinfo::
+ If set to true, git-receive-pack will run git-update-server-info
+ after receiving data from git-push and updating refs.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index b771fe9..6573226 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
static int report_status;
static int prefer_ofs_delta = 1;
+static int auto_update_server_info;
+static int auto_gc;
static const char *head_name;
static char *capabilities_to_send;
@@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (strcmp(var, "receive.updateserverinfo") == 0) {
+ auto_update_server_info = git_config_bool(var, value);
+ return 0;
+ }
+
+ if (strcmp(var, "receive.autogc") == 0) {
+ auto_gc = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
@@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
report(unpack_status);
run_receive_hook(post_receive_hook);
run_update_post_hook(commands);
+ if (auto_update_server_info)
+ update_server_info(0);
+ if (auto_gc) {
+ const char *argv_gc_auto[] = { "gc", "--auto", NULL };
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ }
}
return 0;
}
^ permalink raw reply related
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-20 20:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Andy Isaacson, git, Alex Riesen
In-Reply-To: <alpine.LFD.2.00.0910201538180.21460@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> I didn't spend the time needed to think about this issue and your
> proposed fix yet. However I think that using sizeof(delta_head)-1
> makes the code a bit confusing. At this point i'd use:
>
> int size = sizeof(delta_head) - 1;
>
> and use that variable instead just like it is done in
> unpack_compressed_entry() to have the same code pattern.
Sounds good. Here is a reroll with a bit more explanation.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 20 Oct 2009 12:40:02 -0700
Subject: [PATCH] Fix "corrupt input stream" check while reading from packfiles
An ealier "fix" made us break out of the loop when we get Z_BUF_ERROR back
from inflate(), and either the input stream still had some data to
consume, or we have already got the full output we expected.
This is the same kind of mistake as we corrected with 456cdf6 (Fix loose
object uncompression check., 2007-03-19); it is valid for inflate() to
produce full output before it consumes the input stream fully; e.g.
immediately before reading the end of stream marker.
Instead, detect corrupt input stream by feeding the input as long as
inflate() wants to without detecting a real error, and giving it an output
buffer that is one byte longer than necessary. If it touches the extra
byte, we know that the input stream is corrupt; otherwise inflate() will
notice the broken input stream by itself.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_file.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4cc8939..f0907b8 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1344,7 +1344,8 @@ unsigned long get_size_from_delta(struct packed_git *p,
off_t curpos)
{
const unsigned char *data;
- unsigned char delta_head[20], *in;
+ unsigned char delta_head[21], *in;
+ unsigned long expected_size = sizeof(delta_head) - 1;
z_stream stream;
int st;
@@ -1357,13 +1358,14 @@ unsigned long get_size_from_delta(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
- if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
- break;
+ if (!stream.avail_out)
+ break; /* the payload is larger than it should be! */
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
- stream.total_out < sizeof(delta_head));
+ stream.total_out < expected_size);
git_inflate_end(&stream);
- if ((st != Z_STREAM_END) && stream.total_out != sizeof(delta_head)) {
+ if ((st != Z_STREAM_END) &&
+ stream.total_out != expected_size) {
error("delta data unpack-initial failed");
return 0;
}
@@ -1589,15 +1591,15 @@ static void *unpack_compressed_entry(struct packed_git *p,
buffer[size] = 0;
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size;
+ stream.avail_out = size + 1;
git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
- if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
- break;
+ if (!stream.avail_out)
+ break; /* the payload is larger than it should be! */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
--
1.6.5.1.107.gba912
^ permalink raw reply related
* Re: git fsck not identifying corrupted packs
From: Alex Riesen @ 2009-10-20 20:49 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Matthieu Moy, Johannes Schindelin, Johannes Sixt,
Sergio Callegari, git
In-Reply-To: <alpine.LFD.2.00.0910201437240.21460@xanadu.home>
On Tue, Oct 20, 2009 at 20:39, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 19 Oct 2009, Junio C Hamano wrote:
>
>> Actually, I changed my mind. I do not think this so big that we need to
>> wait for a major version bump. Why not shoot for 1.6.6?
>
> Agreed. With a prominent note in the release notes to point people at
> it when they don't read release notes and complain that fsck suddenly
> became very slow after they upgraded.
I have a feeling that it either wont be noticed at all (i.e., I have run fsck
with something other than --full only one time in my whole bash history,
and never shown it otherwise to anyone else), or people will immediately
like it ("Oh, finallly! Now that feels like it is doing something!" :)
^ permalink raw reply
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 20:43 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910201330r45cf625k3a41b5b9e24b3e01@mail.gmail.com>
On Tue, Oct 20, 2009 at 22:30, Eugene Sajine <euguess@gmail.com> wrote:
> One of my friends said that git is not working for their development
> model... C++ development with static linking across the board, where
> they need to see exactly which version of the file has got to the
> executable. Roughly, they are using CVS' keywords and revision numbers
> and a script wich matches them between two versions of the
> executables.
As soon as your friend understand, that a commit describes the complete
state of the repository on the moment of commit, he/she will notice that
the commit allows to find each what content each file in the product
had at the moment of compilation and linking (assuming they weren't
compiling uncommitted tree, which RCS/CVS/SVN/Perforce mindset
tends to encourage).
> I've got curious if Git can support it and how it can be done with
> minimal changes to workflow.
Depends on workflow, I afraid. And I personally wouldn't bother.
>>> # little script or regexp here (don’t have it)
>>>
>>> Does it make sense?
>>
>> Not much. You'll always get a long list of commits which didn't
>> change the damned blob. And you have absolutely no way
>> to find out exactly which of the commits have produced
>> the blob you're looking at (because you decided to do away
>> with the information).
>
> How is that? It seams to me that git log <path> will show only commits
> where <path> was changed/committed? Considering the fact that I've got
> the initial path from the blob, i should get the exact commit history
> (or last commit in my example) for the file(s) (Files if renaming
> occurred without content change).
The blob is present in each commit since it was introduced. Except
when your project contains only that one blob, isn't the state of
the other parts of an interest?
^ permalink raw reply
* Re: ident hash usage question
From: Junio C Hamano @ 2009-10-20 20:43 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Alex Riesen, git
In-Reply-To: <76c5b8580910201330r45cf625k3a41b5b9e24b3e01@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> One of my friends said that git is not working for their development
> model... C++ development with static linking across the board, where
> they need to see exactly which version of the file has got to the
> executable. Roughly, they are using CVS' keywords and revision numbers
> and a script wich matches them between two versions of the
> executables.
>
> I've got curious if Git can support it and how it can be done with
> minimal changes to workflow.
If the project is already arranged to be compiled with decent automation,
I do not think you need any change to the workflow.
You would have a version.cc file with
static char program_version[] = "My Program " VERSION_STRING;
in it, and teach the build procedure how to compile and link this file.
Something like:
version.o: version.cc
$(CXX) -o $@ -DVERSION_STRING=\""$(git describe HEAD)"\" $?
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Nicolas Pitre @ 2009-10-20 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Andy Isaacson, git, Alex Riesen
In-Reply-To: <7vpr8hn9ly.fsf@alter.siamese.dyndns.org>
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> Perhaps it would be as simple as this?
>
> We deliberately give one byte more than what we expect to see and error
> out when we do get that extra byte filled.
>
> sha1_file.c | 17 +++++++++--------
> 1 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 4cc8939..8c9f392 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1344,7 +1344,7 @@ unsigned long get_size_from_delta(struct packed_git *p,
> off_t curpos)
> {
> const unsigned char *data;
> - unsigned char delta_head[20], *in;
> + unsigned char delta_head[21], *in;
I didn't spend the time needed to think about this issue and your
proposed fix yet. However I think that using sizeof(delta_head)-1
makes the code a bit confusing. At this point i'd use:
int size = sizeof(delta_head) - 1;
and use that variable instead just like it is done in
unpack_compressed_entry() to have the same code pattern.
Nicolas
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Nicolas Pitre @ 2009-10-20 18:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Johannes Sixt,
Sergio Callegari, git
In-Reply-To: <7vfx9esgvt.fsf@alter.siamese.dyndns.org>
On Mon, 19 Oct 2009, Junio C Hamano wrote:
> Actually, I changed my mind. I do not think this so big that we need to
> wait for a major version bump. Why not shoot for 1.6.6?
Agreed. With a prominent note in the release notes to point people at
it when they don't read release notes and complain that fsck suddenly
became very slow after they upgraded.
Nicolas
^ permalink raw reply
* Re: git gc and kernel.org
From: Nicolas Pitre @ 2009-10-20 18:46 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git, H. Peter Anvin, ftpadmin
In-Reply-To: <200910201054.48315.johan@herland.net>
On Tue, 20 Oct 2009, Johan Herland wrote:
> On Tuesday 20 October 2009, Junio C Hamano wrote:
> > At one point, update-server-info used to compute a lot more than what we
> > currently compute and it made some sense to oppose against it on
> > performance ground.
> >
> > But these days it only lists the refs and packs and does nothing else;
> > the performance impact should be immeasurable and it adds only two files
> > to the repository. It cannot be a big deal, unless you oppose to http
> > transport on a non-technical ground.
>
> FYI, update-server-info takes ~0.7 seconds in a repo with one pack and
> ~50000 refs, so I guess it's acceptable to enable it by default, even in
> those kinds of repos.
Still... Hopefully this is going to become redundant information in the
future with the eventual deployment of smart protocol over HTTP. So I
think that as a config option being off by default this is a good
compromize. Site administrators can turn it on by default in
/etc/gitconfig.
Nicolas
^ permalink raw reply
* [PATCH] git-clone.txt: Fix grammar and formatting
From: Björn Gustavsson @ 2009-10-20 20:38 UTC (permalink / raw)
To: git; +Cc: gitster
Add the missing definite article ("the") in several places.
Change "note to..." to "note for...", since "note to" means that
that the note is addressed to someone (source: Google search).
Change "progressbar" to "progress bar" (source: Wikipedia).
Format git commands, options, and file names consistently using
back quotes (i.e. a fixed font in the resulting HTML document).
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
I am not a native English speaker, so if my attempted corrections
of the grammar is wrong, please correct me!
Documentation/git-clone.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 5ebcba1..7e7d9fc 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -39,7 +39,7 @@ OPTIONS
--local::
-l::
When the repository to clone from is on a local machine,
- this flag bypasses normal "git aware" transport
+ this flag bypasses the normal "git aware" transport
mechanism and clones the repository by making a copy of
HEAD and everything under objects and refs directories.
The files under `.git/objects/` directory are hardlinked
@@ -60,7 +60,7 @@ OPTIONS
-s::
When the repository to clone is on the local machine,
instead of using hard links, automatically setup
- .git/objects/info/alternates to share the objects
+ `.git/objects/info/alternates` to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+
@@ -69,7 +69,7 @@ it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as 'git-commit')
+These objects may be removed by normal git operations (such as `git commit`)
which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
@@ -86,13 +86,13 @@ objects from the source repository into a pack in the cloned repository.
--reference <repository>::
If the reference repository is on the local machine,
- automatically setup .git/objects/info/alternates to
+ automatically setup `.git/objects/info/alternates` to
obtain objects from the reference repository. Using
an already existing repository as an alternate will
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
+
-*NOTE*: see NOTE to --shared option.
+*NOTE*: see the NOTE for the `--shared` option.
--quiet::
-q::
@@ -101,7 +101,7 @@ objects from the source repository into a pack in the cloned repository.
--verbose::
-v::
- Display the progressbar, even in case the standard output is not
+ Display the progress bar, even in case the standard output is not
a terminal.
--no-checkout::
@@ -121,17 +121,17 @@ objects from the source repository into a pack in the cloned repository.
configuration variables are created.
--mirror::
- Set up a mirror of the remote repository. This implies --bare.
+ Set up a mirror of the remote repository. This implies `--bare`.
--origin <name>::
-o <name>::
- Instead of using the remote name 'origin' to keep track
- of the upstream repository, use <name>.
+ Instead of using the remote name `origin` to keep track
+ of the upstream repository, use `<name>`.
--branch <name>::
-b <name>::
Instead of pointing the newly created HEAD to the branch pointed
- to by the cloned repository's HEAD, point to <name> branch
+ to by the cloned repository's HEAD, point to `<name>` branch
instead. In a non-bare repository, this is the branch that will
be checked out.
@@ -158,7 +158,7 @@ objects from the source repository into a pack in the cloned repository.
--recursive::
After the clone is created, initialize all submodules within,
using their default settings. This is equivalent to running
- 'git submodule update --init --recursive' immediately after
+ `git submodule update --init --recursive` immediately after
the clone is finished. This option is ignored if the cloned
repository does not have a worktree/checkout (i.e. if any of
`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
@@ -171,8 +171,8 @@ objects from the source repository into a pack in the cloned repository.
<directory>::
The name of a new directory to clone into. The "humanish"
part of the source repository is used if no directory is
- explicitly given ("repo" for "/path/to/repo.git" and "foo"
- for "host.xz:foo/.git"). Cloning into an existing directory
+ explicitly given (`repo` for `/path/to/repo.git` and `foo`
+ for `host.xz:foo/.git`). Cloning into an existing directory
is only allowed if the directory is empty.
:git-clone: 1
--
1.6.5.1.2.g310c
^ 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