* Re: [1.8.0] Provide proper remote ref namespaces
From: Jeff King @ 2011-02-07 20:19 UTC (permalink / raw)
To: Johan Herland
Cc: git, Matthieu Moy, Dmitry Potapov, Junio C Hamano,
Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102070958.11551.johan@herland.net>
On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:
> > 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).
>
> Whoa, we use the "ambiguous" term differently here. In this whole thread I
> have used "ambiguous" exclusively about when the same (shorthand) tag name
> point to _different_ things. As long as they point to the same thing, there
> is no ambiguity, IMHO.
Sorry, I should have been more clear. I meant "ambiguous by the current
code's definition", meaning "we would still need to use your new
ambiguity definition to resolve this situation".
IOW, I think we are on the same page.
> This is the same technique we use when talking about branch names: On this
> mailing list, nobody is confused when I refer to 'maint', 'master', 'next'
> and 'pu'. Still, in our own work repos (at least in mine), these branches
> are actually called "refs/remotes/origin/<name>" (commonly referred to by
> their shorthands "origin/<name>"). Here we are, juggling the same kind of
> namespaces that I propose for tags, and it seems to work well without
> causing much confusion.
Just playing devil's advocate for a moment: isn't this namespace
distinction one of the more confusing things in git for new users? That
is, I have seen new-ish git users say "OK, so I cloned from upstream.
How come I can't say "git log maint" now?" Or it used to be "how come I
can't "git checkout maint" now?" The latter is now handled by some very
specific magic in "git checkout", but in general ref lookup does not
automagically look in remotes namespaces, and it has caused some
confusion.
So here we are introducing more distinction between project-wide names
and per-remote names. I absolutely think it's the right thing to do from
a "keep it simple, orthogonal, and distributed" perspective. But we also
need to recognize we are making some common use cases more confusing. In
the case of remote-tracking branches, we ended up adding some porcelain
features to make common actions (like checking out a local branch from a
remote) more seamless. But there is still some confusion among new
users.
I'm sort of rambling as I'm not quite sure yet what this means for the
tags proposal, but a few questions I think are important to consider
are:
1. Where have we succeeded and where have we failed with making
separate-remotes / tracking branches seamless to the user (as
opposed to something like a system where
fetching from upstream fetches straight into your master branch
(which has its own problems, but would be conceptually very
simple)? Do those failures apply in this case, and if so how can we
do better?
2. Can we apply new ideas for handling separate-remote tags to the
branches case? Obviously one big proposal is searching in the
per-remote tag namespace for refs. Should we be doing the same with
heads?
-Peff
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Jeff King @ 2011-02-07 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Sebastian Pipping, Git ML
In-Reply-To: <7vhbcguytf.fsf@alter.siamese.dyndns.org>
On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:
> I actually do not mind too much myself if all commands that can take
> pathspecs consistently defaulted to "full-tree" pathspec given no
> pathspec. But if we were to go that route, everybody should join their
> voice to defend that decision when outside people say "in 1.8.0 'git grep'
> run from a subdirectory shows matches from all the irrelevant parts of the
> tree; with all the cruft its output is unreadable". I won't be the sole
> champion of such a behaviour when I do not fully believe in it.
The problem is that I don't feel comfortable writing an RFC that says
"in 1.8.0 we will default to full-tree because it is somehow better".
Because I don't think it is better; it is simply a different way of
thinking about it, and different people will have different preferences.
I think even the same people may different preferences from project to
project. For most of my projects, the scope of the repo is well-defined,
and I want full-tree semantics (e.g., I hack on a bug, go into t/ to
tweak and run the tests, and then want to "git add -u" the whole thing
when everything looks good). But I also recently worked on a gigantic
project that was split into several sub-components. I would cd 3 or 4
levels deep into the sub-component that I was working on, and I would
prefer my "git add -u" to stay in that sub-component, and my "git grep"
to look only in that sub-component.
Which implies to me that the "relative" or "full-tree" view should be a
per-repo configurable thing. But that introduces its own set of
headaches, as people may script around things like "git add", and it
would become predictable to do so only from the top-level of the working
tree.
-Peff
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Junio C Hamano @ 2011-02-07 19:40 UTC (permalink / raw)
To: Marc Branchaud
Cc: Junio C Hamano, Nicolas Pitre, Jeff King, Johan Herland, git,
Sverre Rabbelier, Nguyen Thai Ngoc Duy
In-Reply-To: <4D501983.5060508@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> Tags don't become "official" until they're published according to the
> project's process. For us git users, that means the tag appears in
> git.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can
> have all sorts of meanings, but I don't think "official" could be one of them.
I think you are essentially saying the same thing.
Think of hiding the unofficial tags to refs/private-tags by "interim
maintainer" (or public at large for that matter); they won't be published
automatically, unless the publisher decides to publish "according to the
project's process."
As I said in my message, it feels awkward to use refs/private-tags for
tags everybody uses for his or her own purpose, so by swapping the roles
of namespaces around, we would be able to use refs/tags for private ones,
and refs/remotes/origin/tags for the ones that came from upstream. But
then if you fetch/pull from a third party (including the "interim
maintainer"), it feels wasteful to get full set of tags that you have in
the origin namespace anyway replicated in refs/remotes/interim/tags.
And that is what bothers me---not the waste itself, but I have this
nagging feeling that the wasteful duplication is an indication of
something else designed wrong.
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Junio C Hamano @ 2011-02-07 19:31 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Jeff King, Matthieu Moy, Sebastian Pipping,
Michael J Gruber, Nguyen Thai Ngoc Duy, Git ML
In-Reply-To: <20110207183412.GB1900@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> _Everything_ relative to the current working directory? I can't
> imagine how would that work in practice. Could you explain what would
> the following commands do, for example, when they are relative to the
> current working directory?
>
> $ cd t
> $ git checkout next
> $ git merge somebranch
> $ git reset HEAD^
Perhaps I stated things badly. I was only talking about commands that
take pathspecs, and none of the above are relevant to this thread. You
don't check out a branch with pathspec, nor merge another branch, nor
reset the index and the HEAD pointer.
I wouldn't point out that "git checkout next -- this-file" is to check out
a file out of a commit, not to check out a branch, as I think you already
know that.
^ permalink raw reply
* [PATCH v2] pull: Document the "--[no-]recurse-submodules" options
From: Jens Lehmann @ 2011-02-07 19:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List
In-Reply-To: <20110207074157.GA2736@elie>
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>
---
Am 07.02.2011 08:41, schrieb Jonathan Nieder:
> Jens Lehmann wrote:
>> --- 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]).
>> +
>
> Is it worth mentioning that this does not (yet) automatically check
> out the new commits in submodules after a merge, or would such
> documentation be too likely to be forgotten and left stale in the
> future?
Good point, here is v2! (And I will add an updated description to the
relevant commits in my github repo, so we won't forget that later)
Documentation/fetch-options.txt | 2 +-
Documentation/git-pull.txt | 9 +++++++++
2 files changed, 10 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..b33e6be 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -84,6 +84,15 @@ 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]).
+ That might be necessary to get the data needed for merging submodule
+ commits, a feature git learned in 1.7.3. Notice that the result of a
+ merge will not be checked out in the submodule, "git submodule update"
+ has to be called afterwards to bring the work tree up to date with the
+ merge result.
+
Options related to merging
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.7.4.47.g87a200
^ permalink raw reply related
* Re: [1.8.0] Provide proper remote ref namespaces
From: Bernhard R. Link @ 2011-02-07 19:05 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre, Johan Herland
In-Reply-To: <AANLkTi=A-rh+wfg7O4KryydxVuorM8nkuGYmpbgVfVJp@mail.gmail.com>
* Dmitry Potapov <dpotapov@gmail.com> [110207 01:07]:
> 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.
>[...]
> 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 there are those "local tags", which are not to be shared with others.
Does that mean an user should always have two repositories, one with
those tags for themselves and one without those tags for each other?
And the private one should always be the one that does the push and
fetch (as issuing a a fetch in the public to get something from the
private will also get all those tags)?
> > 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.
Global tags are. Local tags are not.
And even for global tags it can be interesting to see which remote has
them, without having to manually look at all those remotes.
> IMHO, it is very confusing, especially for people whose script was
> suddenly broken by those namespaces.
Like it was when remotes where introduced?
> 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.
I'd consider it more logical to have remote tags and a config to
automatically make local copies of remote tags. (With whatever default
people consider proper).
Bernhard R. Link
^ permalink raw reply
* Re: Local copy of the repository files
From: Conrad Irwin @ 2011-02-07 19:22 UTC (permalink / raw)
To: Roberto; +Cc: git
In-Reply-To: <4D503E0D.5050105@gmail.com>
On 7 February 2011 10:46, Roberto <mrgreiner@gmail.com> wrote:
> Hi,
>
> I'm trying to make my git repository automatically make a local copy o f the
> repository files, but the appropriate command (or commands) is eluding me.
> Could somebody give me a hint (or point to the appropriate document) as of
> how to make it work?
There's a reasonably succinct guide to setting this up at
http://toroid.org/ams/git-website-howto
Conrad
^ permalink raw reply
* Re: [PATCH/RFC] commit: fix memory-leak
From: Erik Faye-Lund @ 2011-02-07 19:22 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, msysgit, blees
In-Reply-To: <vpqei7jfzq5.fsf@bauges.imag.fr>
On Mon, Feb 7, 2011 at 7:48 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> At the same time, this fixes a problem with strict-POSIX getenv
>> implementations. POSIX says "The return value from getenv() may
>> point to static data which may be overwritten by subsequent calls
>> to getenv()", so duplicating the strings is a potential bug.
> ^
> not
> ?
Indeed, thanks.
^ permalink raw reply
* Re: [PATCH/RFC] commit: fix memory-leak
From: Matthieu Moy @ 2011-02-07 18:48 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, blees
In-Reply-To: <1297104044-4684-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> At the same time, this fixes a problem with strict-POSIX getenv
> implementations. POSIX says "The return value from getenv() may
> point to static data which may be overwritten by subsequent calls
> to getenv()", so duplicating the strings is a potential bug.
^
not
?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Local copy of the repository files
From: Roberto @ 2011-02-07 18:46 UTC (permalink / raw)
To: git
Hi,
I'm trying to make my git repository automatically make a local copy o f
the repository files, but the appropriate command (or commands) is
eluding me. Could somebody give me a hint (or point to the appropriate
document) as of how to make it work?
In more details, what I need:
When one of our developers does commit/push his work to the
server/repository, I need the files to be automatically copied/updated
to a plain local folder (something like file://var/www/), so they are
viewable through a web browser. Most of those files are php. I don't
need an additional repository accessible with WebDAV, HTTP, or something
alike. Just a copy of the working files, viewable if someone opens a
browser and types the URL of our server.
I did configure a "remote" server pointing to that folder (using git
remote add test file:///var/www/), and 'git fetch test' does give me the
following output:
From file:///var/www
203a9c7..b47fab5 master -> test/master
So probably it´s working correctly. But a "git remote push" is not
updating that folder. Also, I believe that probably I'm supposed to use
a hook (probably post-update), but can't find out what exactly I should
add in there. Would appreciate any ideas here.
Note: I'm using Debian 5.0-64bits, git 1.5.6.5 (from the apt repository).
Thanks,
Roberto
--
-----------------------------------------------------
Marcos Roberto Greiner
Os otimistas acham que estamos no melhor dos mundos
Os pessimistas tem medo de que isto seja verdade
James Branch Cabell
-----------------------------------------------------
^ permalink raw reply
* [PATCH/RFC] commit: fix memory-leak
From: Erik Faye-Lund @ 2011-02-07 18:40 UTC (permalink / raw)
To: git; +Cc: msysgit, blees
The name, email and date strings are some times allocated on the
heap, but not free'd. Fix this by making sure they are allways
heap-allocated, so we can safely free the memory.
At the same time, this fixes a problem with strict-POSIX getenv
implementations. POSIX says "The return value from getenv() may
point to static data which may be overwritten by subsequent calls
to getenv()", so duplicating the strings is a potential bug.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
This was found when investigating how to fix UTF-8 support in
getenv on Windows. I introduced the xgetenv-function (that returns
a pointer that can be passed to free) because I suspect we'll find
other similar code-paths.
builtin/commit.c | 9 ++++++---
git-compat-util.h | 1 +
wrapper.c | 6 ++++++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 03cff5a..e5a649e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -465,9 +465,9 @@ static void determine_author_info(struct strbuf *author_ident)
{
char *name, *email, *date;
- name = getenv("GIT_AUTHOR_NAME");
- email = getenv("GIT_AUTHOR_EMAIL");
- date = getenv("GIT_AUTHOR_DATE");
+ name = xgetenv("GIT_AUTHOR_NAME");
+ email = xgetenv("GIT_AUTHOR_EMAIL");
+ date = xgetenv("GIT_AUTHOR_DATE");
if (use_message && !renew_authorship) {
const char *a, *lb, *rb, *eol;
@@ -507,6 +507,9 @@ static void determine_author_info(struct strbuf *author_ident)
date = force_date;
strbuf_addstr(author_ident, fmt_ident(name, email, date,
IDENT_ERROR_ON_NO_NAME));
+ free(name);
+ free(email);
+ free(date);
}
static int ends_rfc2822_footer(struct strbuf *sb)
diff --git a/git-compat-util.h b/git-compat-util.h
index d6d269f..12f111f 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -409,6 +409,7 @@ typedef void (*try_to_free_t)(size_t);
extern try_to_free_t set_try_to_free_routine(try_to_free_t);
extern char *xstrdup(const char *str);
+extern char *xgetenv(const char *name);
extern void *xmalloc(size_t size);
extern void *xmallocz(size_t size);
extern void *xmemdupz(const void *data, size_t len);
diff --git a/wrapper.c b/wrapper.c
index 8d7dd31..e6173c4 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -30,6 +30,12 @@ char *xstrdup(const char *str)
return ret;
}
+char *xgetenv(const char *name)
+{
+ char *tmp = getenv(name);
+ return tmp ? xstrdup(tmp) : NULL;
+}
+
void *xmalloc(size_t size)
{
void *ret = malloc(size);
--
1.7.4.msysgit.0
^ permalink raw reply related
* Re: "git add -u" broken in git 1.7.4?
From: SZEDER Gábor @ 2011-02-07 18:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Matthieu Moy, Sebastian Pipping, Michael J Gruber,
Nguyen Thai Ngoc Duy, Git ML
In-Reply-To: <7vhbcguytf.fsf@alter.siamese.dyndns.org>
On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Is "git add -p" broken, then? It takes pathspecs relative to the current
> > directory, but "git add -p" without arguments operates from the root,
> > not from the current subdirectory.
>
> I would say so; "add -p" was an ill-executed afterthought. The codepath
> was originally meant to be used from "-i" as the top-level interface that
> was a fully interactive way to prepare for the next commit, which is an
> operation that is inherently full-tree.
>
> There are two schools of thought in previous threads discussing full-tree
> vs current-directory-relative. I think each side has merits.
>
> If we defaulted to the current directory (i.e. "git grep"), that would
> feel more natural as it is more consistent with how tools that are not git
> aware (e.g. "GNU grep" run in the same directory) behave. A downside is
> when you are somewhere deep in a working tree, you have to know how deep
> you are and repeat "../" that many times, i.e. "git grep pattern ../../"
>
> If we defaulted to the root-level (i.e. "git diff"), you do not have that
> downside (iow, "git diff" run from a deep directory is a full tree
> operation), and you can limit the scope to the current directory by a
> single dot, i.e. "git diff .". A huge downside is that this may feel
> awkward for new people who do not yet breath git [*1*], as no other git
> aware tool would behave like this, limiting its scope to some directory
> that is higher above.
>
> In the past, I have took the third position, saying that tools that
> semantically needs to be full-tree should be full-tree (i.e. ones that
> make or format commits), and others should be relative to the current
> directory (i.e. ones that are used to inspect your progress, such as
> grep), but that is not a very understandable guideline that people can
> easily follow. If we have to choose between the two and make things
> consistent, my personal preference is to make everything relative to the
> current working directory.
_Everything_ relative to the current working directory? I can't
imagine how would that work in practice. Could you explain what would
the following commands do, for example, when they are relative to the
current working directory?
$ cd t
$ git checkout next
$ git merge somebranch
$ git reset HEAD^
Best,
Gábor
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Marc Branchaud @ 2011-02-07 16:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Jeff King, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <7vvd0xvsjc.fsf@alter.siamese.dyndns.org>
On 11-02-06 03:04 PM, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
>>> 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.
>
> I agree that we do not want refs/remotes/tags/*/that-tag-people-agree-on
> in that case. We want to store a single copy and find it there, and that
> single copy has traditionally been found in refs/tags hierarchy.
>
> I think the real issue is not necessarily that the location is shared with
> local tag namespace, but is the lack of a convenient way (or just BCP) to
> segregate what are local and what are official when transferring tags out
> of your repository. That is what discourages people from using tags for
> their personal and ephemeral use, marking some points in their own work
> with personal tags that are never intended to be published.
That may be an issue, but I don't think it's the issue in this thread.
Recall what Nicolas said:
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.
Those tags can all be properly "official" and still the problem exists.
In the "interim maintainer" case, I suggest it's not really a question of
private-vs-official tags. Folks who clone directly from the maintainer
should understand that some tags are works-in-progress. As the maintainer
role gets passed from person to person (and repo to repo), it seems more
useful to be able to distinguish work-in-progress tag vX.Y.Z as coming from
maintainer A or B, i.e. tags A/vX.Y.Z and B/vX.Y.Z. If the tags point to the
same commit then just "vX.Y.Z" resolves fine. But if the two maintainers
have different ideas of what vX.Y.Z should be, then the fully-qualified names
help to identify the differences.
Tags don't become "official" until they're published according to the
project's process. For us git users, that means the tag appears in
git.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can
have all sorts of meanings, but I don't think "official" could be one of them.
M.
^ permalink raw reply
* [PATCH] perl: Fix command_bidi_pipe() don't care about repository path
From: Masatake Osanai @ 2011-02-07 15:09 UTC (permalink / raw)
To: git, gitster; +Cc: Masatake Osanai
command_bidi_pipe must care about repo_path() in case of repository
instance.
This also fixes error on cat_blob() and hash_and_insert_object()
in case of using outside of working tree.
Signed-off-by: Masatake Osanai <unpush@gmail.com>
---
perl/Git.pm | 25 ++++++++++++++++++++-----
t/t9700/test.pl | 10 ++++++++++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 205e48a..7b2aa46 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -99,7 +99,7 @@ increase notwithstanding).
use Carp qw(carp croak); # but croak is bad - throw instead
use Error qw(:try);
-use Cwd qw(abs_path);
+use Cwd qw(abs_path cwd);
use IPC::Open2 qw(open2);
use Fcntl qw(SEEK_SET SEEK_CUR);
}
@@ -396,7 +396,16 @@ See C<command_close_bidi_pipe()> for details.
sub command_bidi_pipe {
my ($pid, $in, $out);
+ my($self) = _maybe_self(@_);
+ local %ENV = %ENV;
+ my $cwd_save = undef;
+ if ($self) {
+ shift;
+ $cwd_save = cwd();
+ _setup_git_cmd_env($self);
+ }
$pid = open2($in, $out, 'git', @_);
+ chdir($cwd_save) if $cwd_save;
return ($pid, $in, $out, join(' ', @_));
}
@@ -843,7 +852,7 @@ sub _open_hash_and_insert_object_if_needed {
($self->{hash_object_pid}, $self->{hash_object_in},
$self->{hash_object_out}, $self->{hash_object_ctx}) =
- command_bidi_pipe(qw(hash-object -w --stdin-paths --no-filters));
+ $self->command_bidi_pipe(qw(hash-object -w --stdin-paths --no-filters));
}
sub _close_hash_and_insert_object {
@@ -932,7 +941,7 @@ sub _open_cat_blob_if_needed {
($self->{cat_blob_pid}, $self->{cat_blob_in},
$self->{cat_blob_out}, $self->{cat_blob_ctx}) =
- command_bidi_pipe(qw(cat-file --batch));
+ $self->command_bidi_pipe(qw(cat-file --batch));
}
sub _close_cat_blob {
@@ -1279,6 +1288,14 @@ sub _command_common_pipe {
# for the given repository and execute the git command.
sub _cmd_exec {
my ($self, @args) = @_;
+ _setup_git_cmd_env($self);
+ _execv_git_cmd(@args);
+ die qq[exec "@args" failed: $!];
+}
+
+# set up the appropriate state for git command
+sub _setup_git_cmd_env {
+ my $self = shift;
if ($self) {
$self->repo_path() and $ENV{'GIT_DIR'} = $self->repo_path();
$self->repo_path() and $self->wc_path()
@@ -1286,8 +1303,6 @@ sub _cmd_exec {
$self->wc_path() and chdir($self->wc_path());
$self->wc_subdir() and chdir($self->wc_subdir());
}
- _execv_git_cmd(@args);
- die qq[exec "@args" failed: $!];
}
# Execute the given Git command ($_[0]) with arguments ($_[1..])
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index c15ca2d..13ba96e 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -113,6 +113,16 @@ like($last_commit, qr/^[0-9a-fA-F]{40}$/, 'rev-parse returned hash');
my $dir_commit = $r2->command_oneline('log', '-n1', '--pretty=format:%H', '.');
isnt($last_commit, $dir_commit, 'log . does not show last commit');
+# commands outside working tree
+chdir($abs_repo_dir . '/..');
+my $r3 = Git->repository(Directory => $abs_repo_dir);
+my $tmpfile3 = "$abs_repo_dir/file3.tmp";
+open TEMPFILE3, "+>$tmpfile3" or die "Can't open $tmpfile3: $!";
+is($r3->cat_blob($file1hash, \*TEMPFILE3), 15, "cat_blob(outside): size");
+close TEMPFILE3;
+unlink $tmpfile3;
+chdir($abs_repo_dir);
+
printf "1..%d\n", Test::More->builder->current_test;
my $is_passing = eval { Test::More->is_passing };
--
1.7.4
^ permalink raw reply related
* Re: git to p4 conversion
From: Endre Czirbesz @ 2011-02-07 15:07 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Vitor Antunes, git, Ian Wienand
In-Reply-To: <AANLkTikCVNoxyNezHVM=8gg6wZNzhV2eOytL952SSP3s@mail.gmail.com>
2011/2/7 Tor Arvid Lund <torarvid@gmail.com>:
> Maybe you could run "git p4 submit --verbose"? (the 'verbose' option
> might give you a clue as to what the underlying problem is)
I did that actually, just did not want to send the whole output. :)
I will investigate it further, but my boss gave a new highest priority
task for me... :(
Endre
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nicolas Pitre @ 2011-02-07 14:53 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <20110207051834.GB4748@sigill.intra.peff.net>
On Mon, 7 Feb 2011, Jeff King wrote:
> 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).
Agreed. Same tag name referring to same commit but with different tag
objects is a bit silly and trying to make that case non ambiguous is
probably going to cause more confusion anyway. If the tag object is
different then this is for most purposes a different tag.
> But more importantly, don't we sometimes care where the ref came from?
Not at the moment. Certainly not with the current flat namespace used
for tags.
> 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".
How can this matter? The same automagic on the destination ref may
still take place. Semantically you want to push v1.7.4 so nothing has
to change there, irrespective of the namespace the v1.7.4 tag comes
from. This doesn't matter today, so why would this particular case need
to change?
Nicolas
^ permalink raw reply
* Re: git to p4 conversion
From: Tor Arvid Lund @ 2011-02-07 14:13 UTC (permalink / raw)
To: Endre Czirbesz; +Cc: Vitor Antunes, git, Ian Wienand
In-Reply-To: <AANLkTimP81rVPwvpaCSgBJiZ2Jm131+Q9E-Fkj0-jZfd@mail.gmail.com>
On Mon, Feb 7, 2011 at 2:57 PM, Endre Czirbesz <endre@czirbesz.hu> wrote:
> Hi,
>
> Thanks for your patience and the detailed help.
> I forgot only one thing, that I need two separate directories... :)
>
> So, after some minor mods in git-p4 (I have some directories with
> spaces, and some files with #@*% in their names), it seems as if it
> worked, my files are in P4 depot, although I got an error message:
>
> Failed to merge in the changes.
> Patch failed at 0001 Initial commit
>
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
>
> Exception: command failed: git rebase remotes/p4/master
Maybe you could run "git p4 submit --verbose"? (the 'verbose' option
might give you a clue as to what the underlying problem is)
-- Tor Arvid
> Regards,
>
> Endre
>
^ permalink raw reply
* Re: git to p4 conversion
From: Endre Czirbesz @ 2011-02-07 13:57 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Tor Arvid Lund, git, Ian Wienand
In-Reply-To: <AANLkTimV1aRiEMa2z-H2bOvRa9H6YAyET1=hn+_O0-0u@mail.gmail.com>
Hi,
Thanks for your patience and the detailed help.
I forgot only one thing, that I need two separate directories... :)
So, after some minor mods in git-p4 (I have some directories with
spaces, and some files with #@*% in their names), it seems as if it
worked, my files are in P4 depot, although I got an error message:
Failed to merge in the changes.
Patch failed at 0001 Initial commit
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
Exception: command failed: git rebase remotes/p4/master
Regards,
Endre
^ permalink raw reply
* Re: [PATCH] cache-tree: do not cache empty trees
From: Jonathan Nieder @ 2011-02-07 12:32 UTC (permalink / raw)
To: Ilari Liusvaara
Cc: Nguyen Thai Ngoc Duy, git, Jakub Narebski, Dmitry S. Kravtsov,
Shawn Pearce
In-Reply-To: <20110207121855.GA7298@LK-Perkele-VI.localdomain>
Ilari Liusvaara wrote:
> Remember, many distros ship with old versions of Git. Debian stable
> is now at 1.7.2.3 (Squeeze became Debian 6.0) and it'll take years
> before next release. What about these?
The next Debian point release is scheduled for a month from now. :)
There will probably be more point releases after that.
^ permalink raw reply
* Re: [PATCH] cache-tree: do not cache empty trees
From: Nguyen Thai Ngoc Duy @ 2011-02-07 12:29 UTC (permalink / raw)
To: Ilari Liusvaara
Cc: Jonathan Nieder, git, Jakub Narebski, Dmitry S. Kravtsov,
Shawn Pearce
In-Reply-To: <20110207121855.GA7298@LK-Perkele-VI.localdomain>
On Mon, Feb 7, 2011 at 7:18 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Mon, Feb 07, 2011 at 04:57:13PM +0700, Nguyen Thai Ngoc Duy wrote:
>>
>> Perhaps it's not a good approach after all. What I wanted was to make
>> pre-1.8.0 tolerate empty trees created by 1.8.0. Perhaps it's better
>> to just let pre-1.8.0 refuse to work with empty trees, forcing users
>> to upgrade to 1.8.0?
>>
>> The (untested) patch below would make git refuse to create an index
>> from a tree that contains empty trees. Hmm?
>
> Remember, many distros ship with old versions of Git. Debian stable
> is now at 1.7.2.3 (Squeeze became Debian 6.0) and it'll take years
> before next release. What about these?
Waiting a few years is my best bet :P Really I don't figure out any
other way for migration. New empty trees would end up in repository
and affect all connected clients regardless version.
> Making previous versions refuse to work with empty trees isn't exactly
> trivial, as the tree parser seems to be written to be extremely
> liberal on what it accepts.
The repository _can_ contain empty trees. The main problem is index
not supporting empty trees. I only prevent index being used. If users
create new commits (including empty trees) with mktree and
commit-tree, they can also checkout without index using ls-tree and
cat-file.
--
Duy
^ permalink raw reply
* Re: [PATCH] cache-tree: do not cache empty trees
From: Ilari Liusvaara @ 2011-02-07 12:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jonathan Nieder, git, Jakub Narebski, Dmitry S. Kravtsov,
Shawn Pearce
In-Reply-To: <20110207095713.GA19653@do>
On Mon, Feb 07, 2011 at 04:57:13PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> Perhaps it's not a good approach after all. What I wanted was to make
> pre-1.8.0 tolerate empty trees created by 1.8.0. Perhaps it's better
> to just let pre-1.8.0 refuse to work with empty trees, forcing users
> to upgrade to 1.8.0?
>
> The (untested) patch below would make git refuse to create an index
> from a tree that contains empty trees. Hmm?
Remember, many distros ship with old versions of Git. Debian stable
is now at 1.7.2.3 (Squeeze became Debian 6.0) and it'll take years
before next release. What about these?
Making previous versions refuse to work with empty trees isn't exactly
trivial, as the tree parser seems to be written to be extremely
liberal on what it accepts.
-Ilari
^ permalink raw reply
* Re: git-new-workdir for filesystems without links (e.g. FAT32)?
From: Piotr Krukowiecki @ 2011-02-07 12:19 UTC (permalink / raw)
To: git
In-Reply-To: <20110206191459.GA17939@elie>
On Sun, Feb 6, 2011 at 8:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Piotr,
>
> Piotr Krukowiecki wrote:
>
>> git-new-workdir requires soft links to work, so obviously it will fail if file
>> system does not support them. Is there any other way for having multiple working
>> dirs with one repository?
>
> I assume you mean a way to share refs between repositories without
> using symlinks? Then alas, that is not implemented, though there
> is some interest. See [1] for details.
[...]
> If on the other hand you just want to share objects (not refs) between
> repositories, the GIT_OBJECT_DIRECTORY environment variable might
> help.
I need several working directories (for different branches). I wanted
to use git-new-workdir because, as I understand, I could do 'git svn
fetch' only once and then 'git rebase' for each working dir. So the
only reason was performance (network and disk).
I don't know if sharing objects is enough. If I understand correctly,
if a fetch introduces e.g. new branches, then only one working
directory will have information about them?
--
Piotrek
^ permalink raw reply
* Re: [PATCH 1.8.0] add: make "add -u" update full tree without pathspec
From: Matthieu Moy @ 2011-02-07 12:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Sebastian Pipping,
SZEDER Gábor
In-Reply-To: <7vsjw0v11p.fsf@alter.siamese.dyndns.org>
[ Your mailer did something strange with my name and email ]
Junio C Hamano <gitster@pobox.com> writes:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> 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.
>
> As long as the command takes pathspecs, it should never be tree-wide.
> Making it tree-wide when there is no pathspec is even worse.
This is against the common use in Git. As I mentionned in the other
thread, pretty much any git command taking an optional pathspec is
still tree-wide when called without argument. "git add -u" is the
exception.
> If "add -p" does not limit operation to the current directory, probably
> that is the inconsistency bug to be fixed.
Add "git log", "git status", "git commit", "git show", "git diff", and
a few others I've missed to the list of "exceptions" ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* git-svn problems with cloning
From: Piotr Krukowiecki @ 2011-02-07 11:58 UTC (permalink / raw)
To: git
Hi,
I'm trying to git-svn clone repository. I have encountered two
problems. For the the first one I have a workaround, but I'm lost with
the second.
1. I have a problem with one commit which tries to create a file name
which is not acceptable by file system (fat32). I tried to ignore this
files by using --ignore-paths, but it does not work. Am I using
ignore-paths incorrectly or do I have to find a different workaround?
(I'm thinking about using specific revisions or using filter-branch).
Here's what's happening:
$ git svn clone -s -r164508 '--ignore-paths=.*https:.*' <url>
Initialized empty Git repository in <path>/.git/
Using higher level of URL: <url> => <url>
mkdir .git/svn/refs/remotes/tags/https:: Invalid argument at
/usr/local/stow/git-1.7.4/libexec/git-core/git-svn line 3856
$ svn log -v -r164508 <url>
[...]
A /<project>/tags/https:/blahblah
$ mkdir https:
mkdir: cannot create directory `https:': Invalid argument
2. I have specified revision that do not have invalid file names in it
and it worker, but git reported error later on, I suppose due to
--ignore-paths:
$ git svn clone -s '--ignore-paths=^/branches/<list of branches>'
'--ignore-paths=^/tags/<list of tags>' -r164510:HEAD <url>
[...]
r166131 = 86085ee643d1b8ecb60f6ec3212904a24dd4d71a
(refs/remotes/<ignored branch 1>
)
[...]
r167889 = 1fdb8124d72e1bc417f7fe06051a5280675dc73b
(refs/remotes/<ignored branch 2>)
M [...]
Found merge parent (svn:mergeinfo prop):
1fdb8124d72e1bc417f7fe06051a5280675dc73b
[...]
W: Cannot find common ancestor between
689e9a85f91eb71e37ccd79063e0a5aaa37d1b74 and
5d04d29ab3c76835facade1859aed30129abecf4. Ignoring merge info.
Found merge parent (svn:mergeinfo prop):
039125717428084cdf4d38b8a98f431a9b656f1c
Couldn't find revmap for <url>/<ignored branch 3>/path
fatal: ambiguous argument
'86085ee643d1b8ecb60f6ec3212904a24dd4d71a^..1fdb8124d72e1bc417f7fe06051a5280675dc73b':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
rev-list 86085ee643d1b8ecb60f6ec3212904a24dd4d71a^..1fdb8124d72e1bc417f7fe06051a5280675dc73b:
command returned error: 128
I'm not sure how to deal with this...
--
Piotrek
^ permalink raw reply
* GREETINGS!!.2
From: Directors Dr Raymond @ 2011-02-06 23:51 UTC (permalink / raw)
Dear Friend
I am Vice Chairman, Board of Directors Dr Raymond Chien Kuo Fung,
I work with the Hang Seng Bank Hong Kong.l have a transaction of
$24,500,000 to bring to your attention if only you would be
interested, kindly respond to the below email for more details.
PLEASE, REPLY- drhraymond@yahoo.com.hk
^ 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