* Re: [1.8.0] Provide proper remote ref namespaces
From: Jeff King @ 2011-02-07 5:18 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <alpine.LFD.2.00.1102051449420.12104@xanadu.home>
On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote:
> > The latter seems like a regression for the common case of fetching from
> > two upstreams. E.g., I usually pull from Junio, getting
> > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I
> > pull from him, getting remotes/spearce/v1.7.0, which he previously
> > fetched from Junio. Under the current code, I can still do "git show
> > v1.7.0"; under the scheme described above I now have to say
> > "origin/v1.7.0" to disambiguate.
>
> Let's suppose that both tags are identical, as in your scenario above
> they would be, then there is no need to call for any ambiguity in that
> case.
Agreed, but...
> > The real issue, I think, is that we are claiming ambiguity even though
> > those tags almost certainly point to the same sha1. When handling
> > ambiguous tags, should we perhaps check to see if all of the ambiguities
> > point to the same sha1, and in that case, just pick one at random?
>
> If they're identical then there is no randomness. If they refer to
> different tag objects, even if those tag objects do refer to the same
> commit object, then I'd say there is an ambiguity only if the tag object
> content matters i.e. when displaying the tag content.
My gut feeling is that they should point to the same tag object, for the
sake of simplicity (if you are re-tagging a commit under the same name,
wouldn't I want to know?) and efficiency (we can detect non-ambiguity
just by looking at the sha1 values without opening objects).
But more importantly, don't we sometimes care where the ref came from?
If I say "git push remote v1.7.4" we do some automagic on the
destination side of the refspec based on the fact that the source ref
was found in the refs/tags hierarchy. In the case we're talking about,
all of the ambiguous refs would presumably also be coming from
refs/remotes/*/tags/, so they would be functionally equivalent. But I
wanted to point it out because:
1. It is an additional equivalent requirement for two refs to not be
ambiguous. They must have the same sha1, _and_ they must have the
same "type".
2. I couldn't think of any other cases where the actual refname might
matter and this would break. But I wanted to bring it up explicitly
in case somebody else can think of one.
-Peff
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Jeff King @ 2011-02-07 5:11 UTC (permalink / raw)
To: Johan Herland
Cc: Matthieu Moy, git, Dmitry Potapov, Junio C Hamano,
Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102070451.37370.johan@herland.net>
On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote:
> > Take the example of the interim maintainer cited somewhere else in
> > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4
> > tag, and on my side, I do not want to end up having
> > shawn/junio/v1.7.4, especially if this means that people fetching from
> > me would end up with a me/shawn/junio/v1.7.4 ...
>
> You won't end up with "shawn/junio/v1.7.4". When Shawn fetches from Junio,
> what he actually gets is "refs/remotes/junio/tags/v1.7.4" ("junio/v1.7.4" is
> a shorthand; "v1.7.4" is an even better shorthand).
But keep in mind that this proposal will have to live alongside repos
that are using older versions of git. So Shawn might very well have
refs/tags/v1.7.4 from Junio if he is using (or has ever used) pre-1.8.0
git.
No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have
to gracefully handle the case of ambiguous duplicate tags (that happen
to point to the same thing).
Which I think you are implying here:
> Next, you should never pull from Shawn's work repo, but rather from the repo
> he has published. In that repo he will typically have pushed the "v1.7.4"
> tag (as described above). When you pull from Shawn's public repo, you will
> get the "v1.7.4" tag at "refs/remotes/shawn/tags/v1.7.4" (but "v1.7.4" is an
> unambigious shorthand).
But I wanted to point it out explicitly.
-Peff
^ permalink raw reply
* Re: [idea] Re: separate .git dir and the working tree
From: Mike Gant @ 2011-02-07 4:57 UTC (permalink / raw)
To: Nicolas Sebrecht, git; +Cc: redstun, Jonathan Nieder
In-Reply-To: <20110206105510.GA14195@vidovic>
On Sun, Feb 06, 2011 at 11:55:10AM +0100, Nicolas Sebrecht wrote:
> The 05/02/11, Mike Gant wrote:
>
> > So does anyone use Mutt? And do they know a recipe to move the sender
> > address to the cc list? If not, I'll figure it out.
>
> g (group answer).
>
Thanks. I knew about L (list reply) and g (group reply). L only replies
to the list address, git@vger.kernel.org, in this case. Certainly, g is
the closest behavior as long as it is acceptable to have the sender name
in the To: header along with the list address (as in this response).
On the other hand, if it is only acceptable to have the list address in
the To: header and all others in the cc list then I don't know of any
command to do that.
-Mike
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-07 3:51 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <vpqtyggk9i2.fsf@bauges.imag.fr>
On Monday 07 February 2011, Matthieu Moy wrote:
> Johan Herland <johan@herland.net> writes:
> >> For tags, it's clearly different. If I have origin/v1.7.4, I don't see
> >> much reason to have _also_ v1.7.4 as a local tag. And if I have only
> >> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
> >> it will get origin/origin/v1.7.4, and so on.
> >
> > Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in
> > the origin remote, so there's no point in trying to push it back. On
> > the other hand, if you have v1.7.4 locally (but not origin/v1.7.4),
> > you should (assuming this is intended to be a public tag) consider
> > pushing it to the "origin" remote, thus causing origin/v1.7.4 to
> > appear in your repo.
>
> (I made a bad choice by repeating "origin" several times)
>
> What happens if I pull from "remoteA" and then push to "remoteB"?
So, when you pull from "remoteA", you get
"refs/remotes/remoteA/tags/v1.7.4", but since it is unambiguous, you can
refer to it by "v1.7.4" instead.
When you push to "remoteB", you would say "git push remoteB tag v1.7.4", and
it would resolve "v1.7.4" (via "refs/remotes/remoteA/tags/v1.7.4") into the
appropriate SHA-1, and then push the "v1.7.4" tag to the remote.
You have to separate the namespace from the name itself. For instance, if I
run "git push remoteB tag v1.7.4", it resolves "v1.7.4" into
refs/tags/v1.7.4, but that doesn't mean that I end up with
"refs/tags/refs/tags/v1.7.4" in the "remoteB" repo.
> Take the example of the interim maintainer cited somewhere else in
> this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4
> tag, and on my side, I do not want to end up having
> shawn/junio/v1.7.4, especially if this means that people fetching from
> me would end up with a me/shawn/junio/v1.7.4 ...
You won't end up with "shawn/junio/v1.7.4". When Shawn fetches from Junio,
what he actually gets is "refs/remotes/junio/tags/v1.7.4" ("junio/v1.7.4" is
a shorthand; "v1.7.4" is an even better shorthand).
Next, you should never pull from Shawn's work repo, but rather from the repo
he has published. In that repo he will typically have pushed the "v1.7.4"
tag (as described above). When you pull from Shawn's public repo, you will
get the "v1.7.4" tag at "refs/remotes/shawn/tags/v1.7.4" (but "v1.7.4" is an
unambigious shorthand).
Even if you _were_ to pull directly from Shawn's work repo, you would not
get the "shawn/junio/v1.7.4" mess you fear, simply because when you fetch
from a repo, the refs inside that repo's "refs/remotes" are not fetched.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nicolas Pitre @ 2011-02-07 3:47 UTC (permalink / raw)
To: Johan Herland
Cc: Dmitry Potapov, git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy
In-Reply-To: <201102070429.05033.johan@herland.net>
On Mon, 7 Feb 2011, Johan Herland wrote:
> In practice, this discussion boils down to whether we should use
>
> remote.origin.fetch = refs/tags/*:refs/remotes/origin/tags/*
> or
> remote.origin.fetch = refs/tags/*:refs/tags/*
>
> as the default refspec for tags.
It clearly should be (and should have been from the start) the former
one.
> AFAICS, we both agree that whichever
> refspec is chosen by default, it should be possible for the user to (fairly
> easily) override, and use the other refspec instead.
Indeed.
And as you propose, the _usage_ of tags should largely be unchanged as
in most cases there won't be any ambiguity, and therefore using "git log
v1.7.0" will just work even if the v1.7.0 tag is actually
refs/remotes/origin/tags/v1.7.0.
So I hardly see what it is that people are unhappy about in this
proposal.
Nicolas
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-07 3:35 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Nicolas Pitre, Nguyen Thai Ngoc Duy, Jeff King,
Sverre Rabbelier, Junio C Hamano
(resend without HTML part; I apologize for the inconvenience)
On Monday 07 February 2011, Dmitry Potapov wrote:
> On Sun, Feb 06, 2011 at 11:12:51PM +0100, Johan Herland wrote:
> There are two sorts of tags:
> - local tags, which are never intended to be shared with others but used
> by users to mark some points in the working repository.
> - global tags, which are just _social_convention_ about what the current
> project considers as official versions. Without social convention, they
> make no sense.
Agreed.
> > The core of this discussion is where we want to place Git in the space
> > between "technically correct" and "socially conventional", where the
> > former means owning up to the fact that each repo really is its own
> > namespace, and there's no way around that in a proper DVCS, and the
> > latter means building social convention into our tools, thereby making
> > it harder to deal with the few unconventional cases (like my two
> > semi-related repos case).
>
> Tags like words are social convention, which are used for communication
> between people participated in a project. But accordingly to you, it
> seems somehow "technically correct" to invent their own words in Humpty
> Dumpty's ways:
>
> 'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it
> means just what I choose it to mean — neither more nor less.'
>
> I am afraid you got the wrong idea about "proper DVCS", because DVCS
> does not imply that there is no social convention. It just means that
> there is no single authority that dictates everything. Like with words,
> there is no single authority that assigns meaning to new words, but
> that does not mean that you cannot just say "When I use a word... "
> if you want to be understood by others.
I think there is a misunderstanding in my use of the phrase "technically
correct". I use it to merely state what is a theoretical truth: In a DVCS
world there is no single authority that dictates the meaning of a tag name.
I do not mean that "technically correct" is inherently _better_ than the
alternative (maybe "theoretically true" is a better phrase). I certainly do
NOT mean that the Humpty Dumpty approach is somehow more desirable than
following project conventions. To the contrary, I very much _support_ the
idea of project-wide tags. I'm merely stating that the technical facts of a
DVCS makes it _theoretically_ impossible to enforce project-wide agreement
on tag names.
Of course, in _practice_ we use project-wide tags without problems all the
time. And they obviously form a _semantic_ namespace that spans the entire
project. I don't disagree with you here.
Where we disagree is whether Git should base its tag refs on the
_theoretically_true_ model, or on the _common_practice_ model. Of course,
the real solution lies somewhere in between the two extremes:
I propose that even though we base Git on the theoretical DVCS truths, we
try very hard to make it Just Work (tm) in the common case (especially
making sure that existing use cases are preserved as much as possible).
As I understand your view (I do apologize if I somehow misrepresent it), you
want Git to assume that the common practice of one semantic namespace is
followed. Furthermore, you also want to enforce that practice where
possible, while still improving the handling of the uncommon (but
theoretically inevitable) case (warning and presumably guiding the user when
a tag conflict occurs).
> > AFAICS, my proposal does not harm the common case (unambiguous tags are
> > still interpreted unambiguously, even if they may exist in multiple
> > namespaces), while it _does_ help the uncommon case (by allowing
> > ambiguous tags to co-exist in the same repo).
>
> It hurts the common case in a few ways:
> 1. It breaks existing user scripts
Yes, but that was sort of in the pretext of this thread ;)
Seriously, though, we should of course try to keep as many scripts as
possible working smoothly. For instance, existing remotes will not be
updated, so everything should keep working for them. It shall also be
possible to use old-style refspecs when creating new remotes, meaning that
whatever scripts depend on the old-style refspecs can be upgraded at
leisure. We could even add a config variable choosing between old-style
(default) and new-style refspecs.
With this in place, I believe the user script breakage will be minimal. If
there is still significant breakage, we should reconsider the relevant part
of the proposal.
> 2. It complicates things for users (as Matthieu wrote above).
I guess this depends on your POV. Fundamentally, I do NOT want to change how
people refer to tags. I only want to provide them the possibility of doing
so when ambiguity is present.
> 3. git fetch cannot report a tag clash if it happens
Yes it can: For each tag fetched from the remote, if resolving its shorthand
name ("v1.7.4") results in ambiguity (i.e. there exists a conflicting tag
elsewhere in this repo), then warn the user about this conflict, and explain
how to refer to each tag candidate using the full ref name. Also explain how
the user may resolve the ambiguity by creating a local tag
("refs/tags/v1.7.4") pointing to the preferred target.
> I believe that the right interface when the common case is simple, but
> an uncommon case is still possible to handle. I don't think that
> currently git meets this criterion, but making tag namespaces based on
> the remote name strikes me as a really bad idea. Tags are attributes of
> a project and not particular remote.
Yes they are (in pratice), and no they aren't (in theory). See above.
> > My proposal tries very hard to present a single namespace
> > _semantically_ to the user in the common case (when tags are
> > unambiguous). I'd even go as far as proposing that "git tag -l" should
> > by default list only a single shortened tag name in the cases where
> > there are multiple unambiguous alternatives.
>
> IMHO, it is very confusing, especially for people whose script was
> suddenly broken by those namespaces.
I believe script breakage can be minimized. See above.
> > Alternatively, I'd suggest a compromise (already mentioned elsewhere in
> > this thread) where we add a config variable tags.preferredRemote
> > (defaults to "origin") which allows you to directly select which
> > namespace you consider official. You could even implement this as
> > physically copying
> > refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.
>
> It seems you do not understand the problem that I am trying to say all
> way along: there is more than one repo from which I fetch tags, and
> because they are belong to the same project, they should be in the same
> namespace.
>
> So, IMHO, the proper solution should be ability to specify the desired
> namespace for any remote repository, like this:
>
> remote.<name>.tagNameSpace = foo
Interesting. I'm not sure what "foo" means in this context. Would I use it
like this?:
remote.origin.tagNameSpace = refs/tags
(to place origin's tags in refs/tags/*)
If so, what's the difference between this option, and using this?:
remote.origin.fetch = refs/tags/*:refs/tags/*
> So, those who want to have many namespaces should be able to that
> easily, but forcing multiple namespaces on those who have a single
> namespace semantically is simple wrong. Not to mention that it breaks
> existing scripts for no good reason.
In practice, this discussion boils down to whether we should use
remote.origin.fetch = refs/tags/*:refs/remotes/origin/tags/*
or
remote.origin.fetch = refs/tags/*:refs/tags/*
as the default refspec for tags. AFAICS, we both agree that whichever
refspec is chosen by default, it should be possible for the user to (fairly
easily) override, and use the other refspec instead.
With that, my main concern about this part of the proposal is satisfied:
Putting remote tags in separate namespaces will be easy to accomplish (if
not the default behavior).
Thanks for the feedback,
...Johan
PS: I'd be interested if you have a suggestion for how to deal with the
issue presented by Nicolas' elsewhere in this thread. Quoting:
The extraordinary misfeature of the tag namespace at the moment comes
from the fact that whenever you add a remote repo to fetch, and do fetch
it, then your flat tag namespace gets polluted with all the tags the
remote might have. If you decide to delete some of those remote
branches, the tags that came with it are still there and
indistinguishable from other tags making it a real pain to sort out.
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] cache-tree: do not cache empty trees
From: Nguyen Thai Ngoc Duy @ 2011-02-07 2:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Ilari Liusvaara, Jakub Narebski, Jonathan Nieder,
Dmitry S. Kravtsov, Shawn Pearce
In-Reply-To: <7v62swwq7s.fsf@alter.siamese.dyndns.org>
2011/2/7 Junio C Hamano <gitster@pobox.com>:
>> diff --git a/cache-tree.c b/cache-tree.c
>> index f755590..03732ad 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -621,9 +621,18 @@ static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
>> struct tree *subtree = lookup_tree(entry.sha1);
>> if (!subtree->object.parsed)
>> parse_tree(subtree);
>> + if (!hashcmp(entry.sha1, (unsigned char *)EMPTY_TREE_SHA1_BIN)) {
>> + warning("empty tree detected! Will be removed in new commits");
>> + cnt = -1;
>> + break;
>> + }
>
> You shouldn't need the cast (if you did, then hashcmp() macro should be
> fixed so that you don't need to).
Or perhaps EMPTY_TREE_SHA1_BIN should be casted to const unsigned char
*. That would eliminate 4 typecastings elsewhere.
> I don't think warning() is warranted for an operation you introduced to
> keep the internal data structure consistent.
Worse. I don't think users know an empty tree is added or removed.
diff-tree does not show it (or should not, I haven't tested).
> Should this comparison done after we parsed the subtree, or should we be
> doing that before it?
>
> If you are adding this new check to a point where we have already parsed
> the subtree object, don't you have a better and cheaper way to detect if
> the subtree is empty than the 20-byte comparision, namely, perhaps by
> looking at subtree->size?
OK before is better.
--
Duy
^ permalink raw reply
* [PATCH 1.8.0] add: make "add -u" update full tree without pathspec
From: Nguyễn Thái Ngọc Duy @ 2011-02-07 2:27 UTC (permalink / raw)
To: git, Junio C Hamano, Sebastian Pipping, SZEDER Gábor,
Matthieu Moy
Cc: Nguyễn Thái Ngọc Duy
When -u was introduced in dfdac5d (git-add -u: match the index with
working tree., 2007-04-20), "add -u" (without pathspec) added
everything. Shortly after, 2ed2c22 (git-add -u paths... now works from
subdirectory, 2007-08-16) broke it while fixing something related.
This makes -u (and -A) inconsistent with some other options, namely -p.
It's been four years since the unintentional breakage and people are
probably used to "git add -u" updating only current directory. Perhaps
it's time to bring the original behavior back? Current behavior can
always be achieved with "git add -u ."
Migration plan:
I'm bad at this. Can we start with a patch that warns users to do "git
add -u ." when they do "git add -u"? Hopefully they would have their
fingers retraied by the time the behavior is changed in 1.8.0.
PS. What about -A?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
2011/2/7 Sebastian Pipping <webmaster@hartwork.org>:
>> git add -u was tree-wide when it was introduced in dfdac5d (git-add
>> -u: match the index with working tree., 2007-04-20), but 2ed2c22
>> (git-add -u paths... now works from subdirectory, 2007-08-16) broke it
>> while fixing something related.
>
> So my memory didn't fool me. Thanks for digging this out.
>
> Can we have tree-wide "git add -u" back, please?
Yup yup I like it too (and wanted the original behavior sometimes, even
though I didn't know it was original behavior).
Pulling Junio in for -A. It seems closely related to -u. In fact I revert
one line from 1e5f764 (builtin-add.c: optimize -A option and "git add ."
- 2008-07-22) but not fully understand why it was changed.
builtin/add.c | 7 +++++--
t/t2200-add-update.sh | 13 +++++++------
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 12b964e..f1f8b5a 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -389,7 +389,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
die("-A and -u are mutually incompatible");
if (!show_only && ignore_missing)
die("Option --ignore-missing can only be used together with --dry-run");
- if ((addremove || take_worktree_changes) && !argc) {
+ if (addremove && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
@@ -412,7 +412,10 @@ int cmd_add(int argc, const char **argv, const char *prefix)
fprintf(stderr, "Maybe you wanted to say 'git add .'?\n");
return 0;
}
- pathspec = validate_pathspec(argc, argv, prefix);
+ if (take_worktree_changes && !argc)
+ pathspec = NULL;
+ else
+ pathspec = validate_pathspec(argc, argv, prefix);
if (read_cache() < 0)
die("index file corrupt");
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index 0692427..2201242 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -69,15 +69,16 @@ test_expect_success 'cache tree has not been corrupted' '
test_expect_success 'update from a subdirectory' '
(
cd dir1 &&
- echo more >sub2 &&
+ echo more >>sub2 &&
git add -u sub2
- )
-'
-
-test_expect_success 'change gets noticed' '
-
+ ) &&
test "$(git diff-files --name-status dir1)" = ""
+'
+test_expect_success 'update without args from subdir' '
+ echo more >>top &&
+ ( cd dir1 && git add -u ) &&
+ test "$(git diff-files --name-status top)" = ""
'
test_expect_success SYMLINKS 'replace a file with a symlink' '
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* Re: [PATCH 1/8] git-p4: test script
From: Junio C Hamano @ 2011-02-07 2:22 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20110205225105.GB30963@arf.padd.com>
Pete Wyckoff <pw@padd.com> writes:
> Add a basic test script for git-p4.
>
> Signed-off-by: Pete Wyckoff <pw@padd.com>
> ---
> t/t9800-git-p4.sh | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 62 insertions(+), 0 deletions(-)
> create mode 100755 t/t9800-git-p4.sh
>
> diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
> new file mode 100755
> index 0000000..f4956b7
> --- /dev/null
> +++ b/t/t9800-git-p4.sh
> @@ -0,0 +1,62 @@
> +#!/bin/sh
> +
> +test_description='git-p4 tests'
> +
> +. ./test-lib.sh
> +
> +p4 -h >/dev/null 2>&1
> +retc=$?
> +p4d -h >/dev/null 2>&1
> +retd=$?
> +if test $retc -ne 0 -o $retd -ne 0
> +then
Use of two global variables with short names makes me feel "yeek!".
(p4 -h && p4d -h) >/dev/null 2>/dev/null ||
{
...
test_done
}
> +GITP4=$GIT_BUILD_DIR/contrib/fast-import/git-p4
> +P4DPORT=10669
> +
> +db="$TRASH_DIRECTORY/db"
> +cli="$TRASH_DIRECTORY/cli"
> +git="$TRASH_DIRECTORY/git"
> +
> +test_debug 'echo p4d -q -d -r "$db" -p $P4DPORT'
> +test_expect_success setup '
> + mkdir -p "$db" &&
> + p4d -q -d -r "$db" -p $P4DPORT &&
> + # wait for it to finish its initialization
> + sleep 1 &&
Is there a guarantee that "1" is sufficiently long for everybody?
Otherwise this will be a flaky test that sometimes passes and sometimes
doesn't, which we try to avoid.
If the answer is "empirically 1 second is sufficient for 99.9% of people",
then I would have to guess that it is 0.8 second too long for majority of
people, in which case I would like to see us try harder to make it both
reliable and efficient.
Isn't there a "noop" command a client can issue against a working server
that fails when the server is not ready (or waits until the server becomes
ready)?
^ permalink raw reply
* Re: [PATCH] cache-tree: do not cache empty trees
From: Junio C Hamano @ 2011-02-07 2:09 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Ilari Liusvaara, Jakub Narebski, Jonathan Nieder,
Dmitry S. Kravtsov, Shawn Pearce
In-Reply-To: <1296914835-808-1-git-send-email-pclouds@gmail.com>
> diff --git a/cache-tree.c b/cache-tree.c
> index f755590..03732ad 100644
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -621,9 +621,18 @@ static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
> struct tree *subtree = lookup_tree(entry.sha1);
> if (!subtree->object.parsed)
> parse_tree(subtree);
> + if (!hashcmp(entry.sha1, (unsigned char *)EMPTY_TREE_SHA1_BIN)) {
> + warning("empty tree detected! Will be removed in new commits");
> + cnt = -1;
> + break;
> + }
You shouldn't need the cast (if you did, then hashcmp() macro should be
fixed so that you don't need to).
I don't think warning() is warranted for an operation you introduced to
keep the internal data structure consistent.
Should this comparison done after we parsed the subtree, or should we be
doing that before it?
If you are adding this new check to a point where we have already parsed
the subtree object, don't you have a better and cheaper way to detect if
the subtree is empty than the 20-byte comparision, namely, perhaps by
looking at subtree->size?
^ permalink raw reply
* Re: [PATCH] Add support for merging from upstream by default.
From: Junio C Hamano @ 2011-02-07 1:59 UTC (permalink / raw)
To: Jared Hance; +Cc: git
In-Reply-To: <1296912681-4161-1-git-send-email-jaredhance@gmail.com>
Jared Hance <jaredhance@gmail.com> writes:
> Adds the option merge.defaultupstream to add support for merging from the
> upstream branch by default. The upstream branch is found using
> branch.[name].upstream.
> ---
Sign off?
The patch (rather your code before getting handed to your MUA) seems
severely whitespace damaged.
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 42fff38..596febe 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -37,7 +37,7 @@ struct strategy {
> };
>
> static const char * const builtin_merge_usage[] = {
> - "git merge [options] <remote>...",
> + "git merge [options] [<remote>...]",
> "git merge [options] <msg> HEAD <remote>",
> NULL
> };
> @@ -58,6 +58,8 @@ static int option_renormalize;
> static int verbosity;
> static int allow_rerere_auto;
> static int abort_current_merge;
> +static int default_upstream;
> +static const char *upstream_branch;
>
> static struct strategy all_strategy[] = {
> { "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
> @@ -519,8 +521,15 @@ static int git_merge_config(const char *k, const char *v, void *cb)
> builtin_merge_usage, 0);
> free(buf);
> }
> -
> - if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
> + else if(branch && !prefixcmp(k, "branch.") &&
> + !prefixcmp(k + 7, branch) &&
> + !strcmp(k + 7 + strlen(branch), ".upstream")) {
> + return git_config_string(&upstream_branch, k, v);
> + }
Shouldn't this be inside a single large if block that is guarded by
if (branch && !prefixcmp(k, "branch.") && !prefixcmp(k + 7, branch))
with a small refactoring of the existing code in git_merge_config(), the
first if statement? It probably is a good idea to hand that off to a
small helper function as well, i.e. the first if statement in
git_merge_config() becomes something like:
status = per_branch_config(k, v, cb);
if (status <= 0)
return status;
and then a new helper function is defined right in front of it, perhaps
static int per_branch_config(const char *k, const char *v, void *cb)
{
const char *variable;
if (!branch || prefixcmp(k, "branch.")
|| prefixcmp(k + 7, branch))
return 1; /* ignore me */
variable = k + 7 + strlen(branch);
if (strcmp(variable, ".mergeoptions")) {
...
return 0; /* done */
}
if (strcmp(variable, ".upstream")) {
...
return 0; /* or -1 if you see an error */
}
return 1; /* not what I handle */
}
^ permalink raw reply
* Re: [PATCH] bundle: Use OFS_DELTA in bundle files
From: Nicolas Pitre @ 2011-02-07 1:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <1296953933-8474-1-git-send-email-spearce@spearce.org>
On Sat, 5 Feb 2011, Shawn O. Pearce wrote:
> git-bundle first appeared in 2e0afafe ("Add git-bundle") in Feb 2007,
> and first shipped in Git 1.5.1.
>
> However, OFS_DELTA is an even earlier invention, coming about in
> eb32d236 ("introduce delta objects with offset to base") in Sep 2006,
> and first shipped in Git 1.4.4.5.
>
> OFS_DELTA is smaller, about 3.2%-5% smaller, and is typically faster
> to access than REF_DELTA because the exact location of the delta base
> is available after parsing the object header. Since all bundle aware
> versions of Git are also OFS_DELTA aware, just make it the default.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> bundle.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/bundle.c b/bundle.c
> index 65ea26b..f48fd7d 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -200,7 +200,7 @@ int create_bundle(struct bundle_header *header, const char *path,
> int bundle_fd = -1;
> int bundle_to_stdout;
> const char **argv_boundary = xmalloc((argc + 4) * sizeof(const char *));
> - const char **argv_pack = xmalloc(5 * sizeof(const char *));
> + const char **argv_pack = xmalloc(6 * sizeof(const char *));
> int i, ref_count = 0;
> char buffer[1024];
> struct rev_info revs;
> @@ -346,7 +346,8 @@ int create_bundle(struct bundle_header *header, const char *path,
> argv_pack[1] = "--all-progress-implied";
> argv_pack[2] = "--stdout";
> argv_pack[3] = "--thin";
> - argv_pack[4] = NULL;
> + argv_pack[4] = "--delta-base-offset";
> + argv_pack[5] = NULL;
> memset(&rls, 0, sizeof(rls));
> rls.argv = argv_pack;
> rls.in = -1;
> --
> 1.7.4.rc3.268.g2af8b
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-07 0:14 UTC (permalink / raw)
To: Johan Herland
Cc: git, Matthieu Moy, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102070022.51403.johan@herland.net>
On Mon, Feb 07, 2011 at 12:22:51AM +0100, Johan Herland wrote:
>
> As Nicolas mentioned elsewhere in the thread, having separate tag namespaces
> does not prevent us from also warning about ambiguous tag names on fetch.
> With separate namespaces, you could probably implement such a warning more
> easily as a hook, instead of hacking the fetch code directly.
Since when we started to handle the common case by forcing each user to
write some hook (BTW, which one?), while having an uncommon case as the
default? It makes no sense. And Nicolas suggested something different --
always warn on fetch, which means there will be warnings in your case
where you have two projects in one repo.
Dmitry
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-07 0:07 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102062312.51655.johan@herland.net>
On Sun, Feb 06, 2011 at 11:12:51PM +0100, Johan Herland wrote:
>
> Yes, technically git 1.7.4 is a myth. However, by convention, we all agree
> what "v1.7.4" points to, and nobody seriously believe they can get away with
> pointing "v1.7.4" somewhere else.
There are two sorts of tags:
- local tags, which are never intended to be shared with others but used
by users to mark some points in the working repository.
- global tags, which are just _social_convention_ about what the current
project considers as official versions. Without social convention, they
make no sense.
> The core of this discussion is where we want to place Git in the space
> between "technically correct" and "socially conventional", where the former
> means owning up to the fact that each repo really is its own namespace, and
> there's no way around that in a proper DVCS, and the latter means building
> social convention into our tools, thereby making it harder to deal with the
> few unconventional cases (like my two semi-related repos case).
Tags like words are social convention, which are used for communication
between people participated in a project. But accordingly to you, it
seems somehow "technically correct" to invent their own words in Humpty
Dumpty's ways:
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it
means just what I choose it to mean — neither more nor less.'
I am afraid you got the wrong idea about "proper DVCS", because DVCS
does not imply that there is no social convention. It just means that
there is no single authority that dictates everything. Like with words,
there is no single authority that assigns meaning to new words, but
that does not mean that you cannot just say "When I use a word... "
if you want to be understood by others.
>
> AFAICS, my proposal does not harm the common case (unambiguous tags are
> still interpreted unambiguously, even if they may exist in multiple
> namespaces), while it _does_ help the uncommon case (by allowing ambiguous
> tags to co-exist in the same repo).
It hurts the common case in a few ways:
1. It breaks existing user scripts
2. It complicates things for users (as Matthieu wrote above).
3. git fetch cannot report a tag clash if it happens
>
> Granted, if we leave all tags in a single namespace, I can still work around
> this by manually futzing with the configured refspecs to create ad hoc
> namespaces. But I _really_ hate it when I'm forced to hack around the tool,
> because the tool thinks it "knows better".
I believe that the right interface when the common case is simple, but
an uncommon case is still possible to handle. I don't think that
currently git meets this criterion, but making tag namespaces based on
the remote name strikes me as a really bad idea. Tags are attributes of
a project and not particular remote.
>
> > But, IMHO, it is a myth that having different
> > namespaces solves the problem, because in _most_ cases, you really want
> > to have a single namespace _semantically_, so you can communicate with
> > other people using this tag name.
>
> My proposal tries very hard to present a single namespace _semantically_ to
> the user in the common case (when tags are unambiguous). I'd even go as far
> as proposing that "git tag -l" should by default list only a single
> shortened tag name in the cases where there are multiple unambiguous
> alternatives.
IMHO, it is very confusing, especially for people whose script was
suddenly broken by those namespaces.
>
> Alternatively, I'd suggest a compromise (already mentioned elsewhere in this
> thread) where we add a config variable tags.preferredRemote (defaults to
> "origin") which allows you to directly select which namespace you consider
> official. You could even implement this as physically copying
> refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.
It seems you do not understand the problem that I am trying to say all
way along: there is more than one repo from which I fetch tags, and
because they are belong to the same project, they should be in the same
namespace.
So, IMHO, the proper solution should be ability to specify the desired
namespace for any remote repository, like this:
remote.<name>.tagNameSpace = foo
So, those who want to have many namespaces should be able to that
easily, but forcing multiple namespaces on those who have a single
namespace semantically is simple wrong. Not to mention that it breaks
existing scripts for no good reason.
>
> > > In that case it would be wrong of gitk to display "v1.0". Instead it
> > > should_ display a longer, unambiguous name, e.g. "origin/v1.0".
> >
> > But it is still ambiguous because my "origin" may be different from
> > yours origin. It is only unambiguous when it look at it _locally_ but
> > that makes it completely useless for communication with other people.
> > One project should have only one version with the same tag regardless
> > where it came from.
>
> Again, you are setting "technical correctness" up against "social
> convention". Technically, _any_ ref name whatsoever is repo-specific and
> "completely useless for communication with other people". The only thing we
> can communicate unambiguously is SHA-1 object names. However, social
> conventions compel us to name our refs unambiguously and to use common sense
> when communicating, so that - in practice - everybody in the project knows
> exactly what is meant by "v1.0".
Public tags are purely social convention. If there is no convention,
they are completely meaningless, and we can use only SHA-1. Thus
speaking about technical correctness of tags makes no sense.
Dmitry
^ permalink raw reply
* Re: [PATCH] Support different branch layouts in git-p4
From: Ian Wienand @ 2011-02-07 0:05 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: git@vger.kernel.org
In-Reply-To: <AANLkTi=ozDk9SqYaYWKHXSjVChV-93-88F_LUCwfSiDc@mail.gmail.com>
Thanks for taking a look
On 04/02/11 16:37, Tor Arvid Lund wrote:
> For starters, I don't think that I like git-p4 being taught to solve
> problems that seem to be caused by a poor/unfortunate perforce layout.
I do think this //depot/project/branch type layout is pretty typical,
although I admit I don't have a lot of experience with alternative p4
setups.
> A solution which I think would work well for everyone, is if files
> would be placed according to the right-hand patterns in the
> client-spec.
I did consider this at first. My only issue is that it is a bit
confusing to use the client spec for filtering (and in this case
re-writing), but not for actually selecting the depots to clone, which
I still need to replicate on the command line. However that is a much
larger change.
What do you think of this one?
In this case, my client view is
//depot/project/branch/... //client/branch/project/...
//depot/project2/branch/... //client/branch/project2/...
and my git directory layout ends up as
branch/project/...
branch/project2/...
-i
---
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..eb9620c 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -878,6 +878,7 @@ class P4Sync(Command):
self.cloneExclude = []
self.useClientSpec = False
self.clientSpecDirs = []
+ self.clientName = None
if gitConfig("git-p4.syncFromOrigin") == "false":
self.syncWithOrigin = False
@@ -910,6 +911,22 @@ class P4Sync(Command):
return files
def stripRepoPath(self, path, prefixes):
+ if self.useClientSpec:
+
+ # if using the client spec, we use the output directory
+ # specified in the client. For example, a view
+ # //depot/foo/branch/... //client/branch/foo/...
+ # will end up putting all foo/branch files into
+ # branch/foo/
+ for val in self.clientSpecDirs:
+ if path.startswith(val[0]):
+ # replace the depot path with the client path
+ path = path.replace(val[0], val[1][1])
+ # now strip out the client (//client/...)
+ path = re.sub("^(//[^/]+/)", '', path)
+ # the rest is all path
+ return path
+
if self.keepRepoPath:
prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
@@ -1032,7 +1049,7 @@ class P4Sync(Command):
includeFile = True
for val in self.clientSpecDirs:
if f['path'].startswith(val[0]):
- if val[1] <= 0:
+ if val[1][0] <= 0:
includeFile = False
break
@@ -1474,20 +1491,36 @@ class P4Sync(Command):
temp = {}
for entry in specList:
for k,v in entry.iteritems():
+ if k.startswith("Client"):
+ self.clientName = v
+
if k.startswith("View"):
if v.startswith('"'):
start = 1
else:
start = 0
index = v.find("...")
+
+ # save the "client view"; i.e the RHS of the view
+ # line that tells the client where to put the
+ # files for this view.
+ cv = v[index+4:] # +4 to remove previous '... '
+ cv_index = cv.find("...")
+ cv=cv[:cv_index]
+
+ # now save the view; +index means included, -index
+ # means it should be filtered out.
v = v[start:index]
if v.startswith("-"):
v = v[1:]
- temp[v] = -len(v)
+ include = -len(v)
else:
- temp[v] = len(v)
+ include = len(v)
+
+ temp[v] = (include, cv)
+
self.clientSpecDirs = temp.items()
- self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
+ self.clientSpecDirs.sort( lambda x, y: abs( y[1][0] ) - abs( x[1][0] ) )
def run(self, args):
self.depotPaths = []
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index 49b3359..e09da44 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -191,6 +191,11 @@ git-p4.useclientspec
git config [--global] git-p4.useclientspec false
+The P4CLIENT environment variable should be correctly set for p4 to be
+able to find the relevant client. This client spec will be used to
+both filter the files cloned by git and set the directory layout as
+specified in the client (this implies --keep-path style semantics).
+
Implementation Details...
=========================
^ permalink raw reply related
* Re: [1.8.0] Provide proper remote ref namespaces
From: Matthieu Moy @ 2011-02-06 23:51 UTC (permalink / raw)
To: Johan Herland
Cc: git, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102070022.51403.johan@herland.net>
Johan Herland <johan@herland.net> writes:
>> For tags, it's clearly different. If I have origin/v1.7.4, I don't see
>> much reason to have _also_ v1.7.4 as a local tag. And if I have only
>> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
>> it will get origin/origin/v1.7.4, and so on.
>
> Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the
> origin remote, so there's no point in trying to push it back. On the other
> hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should
> (assuming this is intended to be a public tag) consider pushing it to the
> "origin" remote, thus causing origin/v1.7.4 to appear in your repo.
(I made a bad choice by repeating "origin" several times)
What happens if I pull from "remoteA" and then push to "remoteB"?
With branches, I'd create a local "master" from remoteA/master, and
then push my local "master" as "master" on remoteB. People looking at
my repository remoteB won't notice where it's comming from because it
had to be local for me at some point.
With tags, we probably don't want to force people to explicitely
create local tags to be able to push them.
Take the example of the interim maintainer cited somewhere else in
this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4
tag, and on my side, I do not want to end up having
shawn/junio/v1.7.4, especially if this means that people fetching from
me would end up with a me/shawn/junio/v1.7.4 ...
> As Nicolas mentioned elsewhere in the thread, having separate tag namespaces
> does not prevent us from also warning about ambiguous tag names on
> fetch.
It does not "prevent", but I think it makes it a mis-feature. Distinct
namespaces (as opposed to warning/errors on duplicate at fetch time)
are useful when the same short name can refer to several things (like
v1.7.4 Vs gitgui-v1.7.4 (which doesn't exist yet), and then it's not
a problem to have twice the same short name.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Sebastian Pipping @ 2011-02-06 23:49 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Matthieu Moy, Jeff King, Git ML
In-Reply-To: <20110206231914.GA8147@neumann>
On 02/07/11 00:19, SZEDER Gábor wrote:
> And others are bitten by it every once in a while. Yes, myself
> included ;) Maybe this is also one of those things that might be
> reconsidered for 1.8.0?
>
>>> Could it be it has been working from anywhere before?
>>
>> Can you post an example where Git 1.7.4 and a previous version behave
>> differently? Up to now, I see difference between your expectations and
>> what Git does, but not between new and old versions.
>
> git add -u was tree-wide when it was introduced in dfdac5d (git-add
> -u: match the index with working tree., 2007-04-20), but 2ed2c22
> (git-add -u paths... now works from subdirectory, 2007-08-16) broke it
> while fixing something related.
So my memory didn't fool me. Thanks for digging this out.
Can we have tree-wide "git add -u" back, please?
Thanks,
Sebastian
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-06 23:22 UTC (permalink / raw)
To: git
Cc: Matthieu Moy, Dmitry Potapov, Junio C Hamano, Sverre Rabbelier,
Jeff King, Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <vpqaai8oqkc.fsf@bauges.imag.fr>
(resend without HTML part; I apologize for the inconvenience)
On Sunday 06 February 2011, Matthieu Moy wrote:
> Johan Herland <johan@herland.net> writes:
> > I don't see how the separate namespaces cause problems here. Also, I
> > don't know what you're proposing instead, or indeed what other
> > organization of tags would lead to less confusion.
>
> I'm not against the idea, but one drawback of the separate namespace
> is that it introduces complexity for the user. In the common case,
> where the user may fetch the same tag from various sources, there
> will still be several refs (probably listed by "git tag" ?), and this
> may confuse the user.
If the user is confused by putting remote tags in separate namespaces, then
the user is likely also confused by the current practice of putting remote
_branches_ in separate namespaces. My point is that by strictly delineating
the boundaries between what is local and what belongs to a given remote, I
hope we could help some newbies past the local vs. remote confusion that
often manifests itself when migrating from a centralized VCS to a DVCS.
> Another question is what happens when you push. With branches,
> fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY.
> This asymetry between push and pull works well because most of the
> time, if we have a origin/XXX branch, we also have XXX (with
> origin/XXX as upstream).
I look at it differently: "fetch" is for information discovery (i.e. "I want
to know what's happened on the remote"), while pull/push is about making
real changes to local/remote branches.
> For tags, it's clearly different. If I have origin/v1.7.4, I don't see
> much reason to have _also_ v1.7.4 as a local tag. And if I have only
> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
> it will get origin/origin/v1.7.4, and so on.
Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the
origin remote, so there's no point in trying to push it back. On the other
hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should
(assuming this is intended to be a public tag) consider pushing it to the
"origin" remote, thus causing origin/v1.7.4 to appear in your repo.
> So, my feeling is that the "separate namespace" should not be
> automatic.
>
> For example, today, git.git repo contains tags like v1.7.4 and others
> like gitgui-0.13.0, which is clearly a handmade namespace, where a
> real namespace would be better. That would make a lot of sence to me
> if Junio had something like
>
> [remote "git-gui"]
> url = ...
> fetch = +refs/heads/*:refs/remotes/git-gui/*
> fetch = +refs/tags/*:refs/tags/remotes/git-gui/*
>
> or whatever other syntax, so that git-gui's tags be automatically
> fetched into the right namespace (with no warning in case of
> duplicate).
>
> But OTOH, I don't want to have several namespaces in my git repo even
> if I configure several remotes to fetch from. In this case, duplicate
> tags are just redundancy if they point to the same object, and a real
> conflict I want to know about immediately otherwise.
As Nicolas mentioned elsewhere in the thread, having separate tag namespaces
does not prevent us from also warning about ambiguous tag names on fetch.
With separate namespaces, you could probably implement such a warning more
easily as a hook, instead of hacking the fetch code directly.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: SZEDER Gábor @ 2011-02-06 23:19 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sebastian Pipping, Jeff King, Git ML
In-Reply-To: <vpq1v3kopn3.fsf@bauges.imag.fr>
On Sun, Feb 06, 2011 at 09:48:48PM +0100, Matthieu Moy wrote:
> Sebastian Pipping <webmaster@hartwork.org> writes:
> > Is that behavior needed to be as is or could you change it to work from
> > everywhere?
>
> I consider it as a design bug that "add -u" is not tree-wide, but it's
> not easy to change the existing behavior without breaking expectations
> of people used to the current behavior.
And others are bitten by it every once in a while. Yes, myself
included ;) Maybe this is also one of those things that might be
reconsidered for 1.8.0?
> > Could it be it has been working from anywhere before?
>
> Can you post an example where Git 1.7.4 and a previous version behave
> differently? Up to now, I see difference between your expectations and
> what Git does, but not between new and old versions.
git add -u was tree-wide when it was introduced in dfdac5d (git-add
-u: match the index with working tree., 2007-04-20), but 2ed2c22
(git-add -u paths... now works from subdirectory, 2007-08-16) broke it
while fixing something related.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] git-gui: instead of defaulting to home directory use working directory
From: Pat Thoyts @ 2011-02-06 23:01 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Pat Thoyts, Jens Lehmann, git
In-Reply-To: <20110206172244.GC47941@book.hvoigt.net>
All three patches are fine - thank you.
git-gui: instead of defaulting to home directory use working directory
git-gui: scroll down to default selection for push dialog
git gui: keep selected branch when remote is changed in push dialog
all applied.
^ permalink raw reply
* Re: [PATCH] git pull: Remove option handling done by fetch
From: Jens Lehmann @ 2011-02-06 22:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List
In-Reply-To: <20110206220939.GC17210@elie>
Am 06.02.2011 23:09, schrieb Jonathan Nieder:
> Jens Lehmann wrote:
>> Am 06.02.2011 21:45, schrieb Junio C Hamano:
>>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>>>> Yes, but isn't that exactly what the pull man-page says? Quote:
>>>> "Options meant for git pull itself and the underlying git merge
>>>> must be given before the options meant for git fetch."
>>>
>>> Yes, it says that, and I think that was a weasely way to say "the command
>>> line parser in git-pull is broken".
> [...]
>> (CCed Jonathan, as he is the author of the lines I quoted)
>
> They're from Junio. :) See v1.5.4.5~26 (git-pull documentation: warn
> about the option order, 2008-03-10).
And I thought I could trust "git blame -M -C" ... ;-)
> I also agree that (1) it would be very nice to find a way to fix this
> and (2) until then, it seems best as a general principle not to
> regress in those odd cases where we sort of fixed it.
>
> In other words, if we were adding --recurse-submodules today, I'd
> agree that it should be treated like other fetch options, but we
> already added the option and some people/scripts might be used to
> the added flexibility, no?
Ok, even though that option was added only two months ago, somebody
could already use it. So that leaves option two:
1) Drop the patch I proposed
2) Document "--[no-]recurse-submodules" as " as "git pull" options
(And then I can later pass the same option to "git merge", which is
much better than the solutions I came up with ;-)
Maybe something like this?
-------------8<--------------
Subject: [PATCH] pull: Document the "--[no-]recurse-submodules" options
In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options
"--[no-]recurse-submodules" had been added to git-pull.sh. But they were
not documented as the pull options they now are, so let's fix that.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Documentation/fetch-options.txt | 2 +-
Documentation/git-pull.txt | 4 ++++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 695696d..ab0dbfc 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -64,11 +64,11 @@ ifndef::git-pull[]
downloaded. The default behavior for a remote may be
specified with the remote.<name>.tagopt setting. See
linkgit:git-config[1].
-endif::git-pull[]
--[no-]recurse-submodules::
This option controls if new commits of all populated submodules should
be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
+endif::git-pull[]
ifndef::git-pull[]
--submodule-prefix=<path>::
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 3046691..7d0f601 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -84,6 +84,10 @@ must be given before the options meant for 'git fetch'.
--verbose::
Pass --verbose to git-fetch and git-merge.
+--[no-]recurse-submodules::
+ This option controls if new commits of all populated submodules should
+ be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
+
Options related to merging
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.7.4.31.g5ae186.dirty
^ permalink raw reply related
* Re: [PATCH] more portable absolute dir check in Git.pm
From: Erik Faye-Lund @ 2011-02-06 22:32 UTC (permalink / raw)
To: rkitover; +Cc: git
In-Reply-To: <4D4D7890.3020906@io.com>
On Sat, Feb 5, 2011 at 5:19 PM, Rafael Kitover <rkitover@io.com> wrote:
> I was trying to get msysGit to work with activeperl. I'm not sure how far I
> got, I will revisit this problem in the future, but here is a patch.
>
> It removes a problematic make fragment that doesn't work on nmake (and
> probably dmake as well.) As well as a better absolute dir check in Git.pm .
>
Please read Documentation/SubmittingPatches. In particlar:
- We use inline patches on the mailing-list. git send-email can send
these for you.
- Your patch lacks a sign-off.
Other than that, interesting. But I think the make_frag-changes needs
an explanation.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-06 22:12 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <AANLkTi=gd5iu0i=ggqJC++N_rL+nU6RO9PNw=jMpT0NH@mail.gmail.com>
On Sunday 06 February 2011, Dmitry Potapov wrote:
> On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote:
> > In practice, there is almost always one namespace (i.e. your repo
> > belongs to_ only one project with project-wide unique tags). However,
> > in any distributed_ system, the only-one-namespace is fundamentally a
> > myth.
>
> By your logic git 1.7.4 is a myth, because I have not specified from
> what repository I pull it.
Yes, technically git 1.7.4 is a myth. However, by convention, we all agree
what "v1.7.4" points to, and nobody seriously believe they can get away with
pointing "v1.7.4" somewhere else.
The core of this discussion is where we want to place Git in the space
between "technically correct" and "socially conventional", where the former
means owning up to the fact that each repo really is its own namespace, and
there's no way around that in a proper DVCS, and the latter means building
social convention into our tools, thereby making it harder to deal with the
few unconventional cases (like my two semi-related repos case).
AFAICS, my proposal does not harm the common case (unambiguous tags are
still interpreted unambiguously, even if they may exist in multiple
namespaces), while it _does_ help the uncommon case (by allowing ambiguous
tags to co-exist in the same repo).
Granted, if we leave all tags in a single namespace, I can still work around
this by manually futzing with the configured refspecs to create ad hoc
namespaces. But I _really_ hate it when I'm forced to hack around the tool,
because the tool thinks it "knows better".
> But, IMHO, it is a myth that having different
> namespaces solves the problem, because in _most_ cases, you really want
> to have a single namespace _semantically_, so you can communicate with
> other people using this tag name.
My proposal tries very hard to present a single namespace _semantically_ to
the user in the common case (when tags are unambiguous). I'd even go as far
as proposing that "git tag -l" should by default list only a single
shortened tag name in the cases where there are multiple unambiguous
alternatives.
Alternatively, I'd suggest a compromise (already mentioned elsewhere in this
thread) where we add a config variable tags.preferredRemote (defaults to
"origin") which allows you to directly select which namespace you consider
official. You could even implement this as physically copying
refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.
> > In that case it would be wrong of gitk to display "v1.0". Instead it
> > should_ display a longer, unambiguous name, e.g. "origin/v1.0".
>
> But it is still ambiguous because my "origin" may be different from
> yours origin. It is only unambiguous when it look at it _locally_ but
> that makes it completely useless for communication with other people.
> One project should have only one version with the same tag regardless
> where it came from.
Again, you are setting "technical correctness" up against "social
convention". Technically, _any_ ref name whatsoever is repo-specific and
"completely useless for communication with other people". The only thing we
can communicate unambiguously is SHA-1 object names. However, social
conventions compel us to name our refs unambiguously and to use common sense
when communicating, so that - in practice - everybody in the project knows
exactly what is meant by "v1.0".
It seems our opinions differ on whether Git should try to _force_ this
social convention on you, or rather stick to technical correctness (with a
bias towards conventional behavior as long as there no ambiguities).
> I agree in your use case of semi-related projects you need separate
> namespaces. But I don't think it is how most people use git. It may
> be nice to have an option that will make tag namespace separate, but
> I do not think it should be default. Not until, it is widely tested.
Well, this _is_ the thread for discussing things "we would have done
differently if we were writing Git from scratch". ;)
Still, you have yet to convince me exactly _what_ will in practice be
horribly and user-visibly broken by this proposal. AFAICS, all the common
use cases today will still work well with this proposal.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] git pull: Remove option handling done by fetch
From: Jonathan Nieder @ 2011-02-06 22:09 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List
In-Reply-To: <4D4F19D0.2000408@web.de>
Jens Lehmann wrote:
> Am 06.02.2011 21:45, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> Yes, but isn't that exactly what the pull man-page says? Quote:
>>> "Options meant for git pull itself and the underlying git merge
>>> must be given before the options meant for git fetch."
>>
>> Yes, it says that, and I think that was a weasely way to say "the command
>> line parser in git-pull is broken".
[...]
> (CCed Jonathan, as he is the author of the lines I quoted)
They're from Junio. :) See v1.5.4.5~26 (git-pull documentation: warn
about the option order, 2008-03-10).
I also agree that (1) it would be very nice to find a way to fix this
and (2) until then, it seems best as a general principle not to
regress in those odd cases where we sort of fixed it.
In other words, if we were adding --recurse-submodules today, I'd
agree that it should be treated like other fetch options, but we
already added the option and some people/scripts might be used to
the added flexibility, no?
^ permalink raw reply
* Re: [PATCH 2/2] git-p4: Add copy detection support
From: Pete Wyckoff @ 2011-02-06 22:05 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <AANLkTi=Awi6d77QcbbZ2rDTv6LpP+qjsReJ5=4NyhUBz@mail.gmail.com>
vitor.hda@gmail.com wrote on Sun, 06 Feb 2011 17:25 +0000:
> Hi Pete,
>
> On Sun, Feb 6, 2011 at 12:25 AM, Pete Wyckoff <pw@padd.com> wrote:
> > You can use integrate -t to force the filetype even if the file
> > already existed, and skip the whole execbit change.
>
> (Copying help text:
> The -t flag makes the source file's filetype propagate to the target
> file. Normally, the target file retains its previous filetype.
> Newly branched files always use the source file's filetype. The
> filetype can still be changed before 'p4 submit' with 'p4 reopen'.
> )
>
> Since in git we're only considering newly branched files, I think in
> this case "-t" will not add anything. In fact, what is being done here
> is detecting exec bit changes from source to target files - we're not
> trying to force P4 to use the source's exec bit. Do you agree?
That sounds fine to me. The code seemed to indicate that
sometimes the destination file exists.
> + elif modifier == "C":
> + src, dest = diff['src'], diff['dst']
> + p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
> + if diff['src_sha1'] != diff['dst_sha1']:
> + p4_system("edit \"%s\"" % (dest))
> + if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
> + filesToChangeExecBit[dest] = diff['dst_mode']
> + os.unlink(dest)
> + editedFiles.add(dest)
If you're happy the dest never exists, you may be able to get rid
of the edit step and the mode-change check entirely. As long as
you've tested this, you're the expert here. The change makes
sense overall.
-- Pete
^ 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