* Re: [PATCH] receive-pack: run "gc --auto" and optionally "update-server-info"
From: Nicolas Pitre @ 2009-10-21 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7vljj5lofb.fsf_-_@alter.siamese.dyndns.org>
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> 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>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
>
> 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
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-21 0:15 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Thomas Rast, git
In-Reply-To: <BLU0-SMTP97AA2287062D9A104101C8AEC00@phx.gbl>
On Tue, 20 Oct 2009, Sean Estabrooks wrote:
> On Tue, 20 Oct 2009 20:23:06 +0200
> Thomas Rast <trast@student.ethz.ch> wrote:
>
> Hi Thomas,
>
> > git-pull has historically accepted full fetchspecs, meaning that you
> > could do
> >
> > git pull $repo A:B
> >
> > which would simultaneously fetch the remote branch A into the local
> > branch B and merge B into HEAD. This got especially confusing if B
> > was checked out. New users variously mistook pull for fetch or read
> > that command as "merge the remote A into my B", neither of which is
> > correct.
> >
> > Since the above usage should be very rare and can be done with
> > separate calls to fetch and merge, we just disallow full fetchspecs in
> > git-pull.
>
> It is however a handy shortcut to be able to specify the full refspec
> and specify where you want the head stored locally. It seems a shame to
> throw away that functionality because of one confusing case. Wouldn't
> it be better to test of the confusing case and instead error out if the
> local refname is already checked out?
Surely, "where you want the head stored locally" is somewhere that's
information about a remote repository, and therefore under "refs/remotes/"
(or "refs/tags/" or something) and therefore not possible to be checked
out (in the "HEAD is a symref to it" sense).
I don't think it should be possible to fast-forward or create a local
branch from a remote branch while simultaneously merging it into the
currently-checked-out local branch.
Actually, I think it would be good to prohibit fetching into a new or
existing local branch, whether or not it is checked out. We'd probably
need to provide a plumbing method of doing a fetch, though, for script
environments that aren't using the normal porcelain meanings of refs/
subdirectories. (Defining a bare repo with --mirror as not having local
branches, of course)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Daniel Barkalow @ 2009-10-20 23:56 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Björn Steinbrink
In-Reply-To: <200910201947.50423.trast@student.ethz.ch>
On Tue, 20 Oct 2009, Thomas Rast wrote:
> Hi all,
>
> While everyone is busy in two other UI threads, I figured I might as
> well toss up another (probably) controversial topic.
>
> 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,
In a certain sense they are; they both update the branches local to one
repository with the data from the other repository. In this sense, fetch
is the oddity in that it doesn't update any repository's own branches, but
just the local information about other repositories' branches.
In another sense, push is unlike anything else in that it updates
something that's remote; in a third sense, pull is unique in that it can
generate a merge.
I suspect that what we've called "fetch" isn't what the people want when
they type "pull", either. And I suspect that the fundamental issue is that
the operation people are looking for is not the operation that they would
do best to use, regardless of naming. I think users are looking for
something that corresponds to "svn up", and they find "git pull"; this
isn't going to make them happy git users, but finding "git fetch" instead
is going to make them even more confused.
But I don't really know; are there IRC logs you can quote or reference
with people making the mistake you're trying to help them avoid?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Eugene Sajine
In-Reply-To: <7vbpk1lmvl.fsf@alter.siamese.dyndns.org>
> 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).
>
There seems to be no misunderstanding in the static linking - i meant
the same thing. But let me put an example:
I have a program.exe
This program.exe is built basing on two statically linked libraries
lib1.lib and lib2.lib
I'm not developing any of those libraries, but only my own code of the
program.exe
Now, somebody changed 2 files in lib1.lib and 5 files in lib2.lib. But
i don't know that they are changed because it is different CVS module
or because I'm building against latest released libs or for whatever
reason...
When i rebuild my program the build supposed to pick up changes from
the libraries I'm using and relink, that will include 7 changed obj
files.
How can i say which exactly files are changed in my new version of
executable comparing to the previous version?
Currently they can take a look at the revision number of every
particular file included into the executable, which is put there by
CVS and compare it with the production. If the version is different,
then you know which files are changed and you can get diffs on them...
They also have file path and date and other stuff expanded...
Please note, my personal goal is *to prove that git can do that
better*, with less intrusion into the code sources, not other way
around.So, while keeping the info they want to have they might get
some benefits of git. Although, i understand that there might be no
cure for this state already, you can tell me that and I will close the
topic, but I just keep hoping;)
Thanks a lot,
Eugene
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Junio C Hamano @ 2009-10-20 23:28 UTC (permalink / raw)
To: Joe Perches; +Cc: kusmabite, git
In-Reply-To: <1256079633.2029.81.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> It seems that the regex for address validation
> isn't very good and perhaps there could/should
> be a stronger validation done for each address
> entered.
The existing ones are actually already harmful. It would trigger on a
valid addresses like this, wouldn't it?
To: "Hamano, Jun" <gitster@pobox.com>
It is worse than that.
The "# Verify the user input" block is in a wrong place in the codepath.
After @to goes through this bogus "verification" step, it then is given to
expand_aliases(), which may expand to real addresses. And then they pass
through sanitize_address() before getting used.
Three implications that come from this wrong code structure are:
(1) The stricter checks you added on top of the existing bogus
verification step may prevent @to to reach expand_aliases() step,
even if the tokens in @to may expand to correct addresses by this
expand_aliases() step if they were allowed to reach here;
(2) The result from expand_aliases() is never checked.
(3) The result from sanitize_address() is not checked either.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-20 23:16 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Wesley J. Landaker, git, Björn Steinbrink
In-Reply-To: <200910210053.29794.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Well, that reminds me of
>
> http://thread.gmane.org/gmane.comp.version-control.git/110251
>
> but was not really what I was aiming at.
Actually, if that patch weren't marked as [DRY HUMOR PATCH], and if it did
not have the detachInstead option, I would have at least queued it to
'pu', if not 'next'.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-20 23:11 UTC (permalink / raw)
To: Thomas Rast; +Cc: Wesley J. Landaker, git, Björn Steinbrink
In-Reply-To: <200910210053.29794.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> ...
> There would not be a configuration option.
> ...
>> It's not even funny.
Re-read what you were responding to and notice that I was commenting on
Wesley's proposal that _is_ about a configuration variable.
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Joe Perches @ 2009-10-20 23:00 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <40aa078e0910201556h4757dbbdn853be4dd8aa920d0@mail.gmail.com>
On Wed, 2009-10-21 at 00:56 +0200, Erik Faye-Lund wrote:
> Didn't my version work for you? It worked for me.
Hi Erik.
It worked, but an unexplained die isn't great,
so I put it where the other validations are done.
It seems that the regex for address validation
isn't very good and perhaps there could/should
be a stronger validation done for each address
entered.
cheers, Joe
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Erik Faye-Lund @ 2009-10-20 22:56 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <1256078917.2029.77.camel@Joe-Laptop.home>
On Wed, Oct 21, 2009 at 12:48 AM, Joe Perches <joe@perches.com> wrote:
>> Something along these lines? Of course, the error message is, uhm,
>> less than helpful :)
>
> Maybe this? Seems to work.
>
Didn't my version work for you? It worked for me.
I find it a bit cleaner to make it a part of the address-sanitizion,
since that needs to be performed for all addresses. I might miss
something vital, though. I don't really speak perl all that well ;)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* 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
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