Jeff King writes:
> diff --git a/cache.h b/cache.h
> index e493563..070169a 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -344,6 +344,7 @@ static inline enum object_type object_type(unsigned int
> mode)
> #define GIT_DIR_ENVIRONMENT "GIT_DIR"
> #define GIT_NAMESPACE_ENVIRONMENT "GIT_NAMESPACE"
>
Am 3/8/2013 8:15, schrieb Jeff King:
> --- a/cache.h
> +++ b/cache.h
> @@ -344,6 +344,7 @@ static inline enum object_type object_type(unsigned int
> mode)
> #define GIT_DIR_ENVIRONMENT "GIT_DIR"
> #define GIT_NAMESPACE_ENVIRONMENT "GIT_NAMESPACE"
> #define GIT_WORK_TREE_ENVIRONMENT "GIT_WORK_TR
If an explicit GIT_DIR is given without a working tree, we
implicitly assume that the current working directory should
be used as the working tree. E.g.,:
GIT_DIR=/some/repo.git git status
would compare against the cwd.
Unfortunately, we fool this rule for sub-invocations of git
by setting GIT
On 08.03.13 01:04, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index d6dd3df..6a5ba11 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -1158,6 +1158,8 @@ int cmd_status(int argc, const char **argv, const char
>> *p
Am 3/8/2013 0:19, schrieb Pete Wyckoff:
> +# When the p4 client Root is a symlink, make sure chdir() does not use
> +# getcwd() to convert it to a physical path.
> +test_expect_failure 'p4 client root symlink should stay symbolic' '
> + physical="$TRASH_DIRECTORY/physical" &&
> + symbolic="
On Thu, Mar 07, 2013 at 10:27:04PM -0800, Junio C Hamano wrote:
> The $GIT_BARE idea sounds very sensible to me.
Unfortunately, it is not quite as simple as that. I just wrote up the
patch, and it turns out that we are foiled by how core.bare is treated.
If it is true, the repo is definitely bare
The $GIT_BARE idea sounds very sensible to me.
Jeff King wrote:
>On Thu, Mar 07, 2013 at 05:47:45PM -0500, Mark Lodato wrote:
>
>> It seems that the fallback bare repository detection in the absence
>of
>> core.bare fails for aliases.
>
>This triggered some deja vu for me, so I went digging. A
On Thu, Mar 07, 2013 at 05:47:45PM -0500, Mark Lodato wrote:
> It seems that the fallback bare repository detection in the absence of
> core.bare fails for aliases.
This triggered some deja vu for me, so I went digging. And indeed, this
has been a bug since at least 2008. This patch (which never
On 03/07/13 20:51, Junio C Hamano wrote:
> But it is equally broken to behave as if there is nothing wrong in
> the incomplete magic ":(top" that is not closed, isn't it?
Ah, yea, I did notice that, but then I saw a few lines below:
if (*copyfrom == ')')
copyfrom++;
which is exp
Andrew Wong writes:
> On 3/7/13, Junio C Hamano wrote:
>> This did not error out for me, though.
>>
>> $ cd t && git ls-files ":(top"
>
> No error message at all? Hm, maybe in your case, the byte after the
> end of string happens to be '\0' and the loop ended by chance?
>
> git doesn't crash
On 3/7/13, Junio C Hamano wrote:
> This did not error out for me, though.
>
> $ cd t && git ls-files ":(top"
No error message at all? Hm, maybe in your case, the byte after the
end of string happens to be '\0' and the loop ended by chance?
git doesn't crash for me, but it generates this erro
Torsten Bögershausen writes:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index d6dd3df..6a5ba11 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1158,6 +1158,8 @@ int cmd_status(int argc, const char **argv, const char
> *prefix)
> unsigned char sha1[20];
> stat
Andrew Wong writes:
> On 3/7/13, Junio C Hamano wrote:
>> The parser that goes past the end of the string may be a bug worth
>> fixing, but is this patch sufficient to diagnose such an input as an
>> error?
>
> Yea, the patch should fix the passing end of string too. The parser
> was going past
Eric Chamberland writes:
> 1) git tag --delete-tags-to-danglings-and-unnamed-banches
>
> This would be able to remove all tags that refers to commits which are
> on branches that are no more referenced by any branch name. This is
> happening when you tag something, then "git rebase". Your tag w
From: Miklós Fazekas
The generic chdir() helper sets the PWD environment
variable, as that is what is used by p4 to know its
current working directory. Normally the shell would
do this, but in git-p4, we must do it by hand.
However, when the path contains a symbolic link,
os.getcwd() will retur
This test fails when the p4 client root includes
a symlink. It complains:
Path /vol/bar/projects/foo/... is not under client root /p/foo
and dumps a traceback.
Signed-off-by: Pete Wyckoff
---
t/t9808-git-p4-chdir.sh | 27 +++
1 file changed, 27 insertions(+)
diff
This adds a test for the fix in bf1d68f (git-p4: use absolute
directory for PWD env var, 2011-12-09). It is necessary to
set PWD to an absolute path so that p4 can find files referenced
by non-absolute paths, like the value of the P4CONFIG environment
variable.
P4 does not open files directly; it
Miklós pointed out in
http://thread.gmane.org/gmane.comp.version-control.git/214915
that when the p4 client root included a symlink, bad things
happen. It is fixable, but inconvenient, to use an absolute path
in one's p4 client. It's not too hard to be smarter about this
in git-p4.
Thanks
A release candidate Git v1.8.2-rc3 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
3fe30d85cea78a388d61ba79fe3a106fca41cfbe git-1.8.2.rc3.tar.gz
4b378cf6129fa4c9355436b93a69
On 3/7/13, Junio C Hamano wrote:
> The parser that goes past the end of the string may be a bug worth
> fixing, but is this patch sufficient to diagnose such an input as an
> error?
Yea, the patch should fix the passing end of string too. The parser
was going past end of string because the nextat
On 11.02.13 03:56, Duy Nguyen wrote:
> On Mon, Feb 11, 2013 at 3:16 AM, Junio C Hamano wrote:
>> The other "lstat()" experiment was a very interesting one, but this
>> is not yet an interesting experiment to see where in the "ignore"
>> codepath we are spending times.
>>
>> We know that we can tel
> From: Thomas Rast
>
> wor...@alum.mit.edu (Dale R. Worley) writes:
> [...snip...]
>
> Isn't that just a very long-winded way of restating what Junio said
> earlier:
>
> > > It was suggested to make it apply the first-parent diff and record
> > > the result, I think. If that were an acceptabl
Hi,
Short story:
we are now using *annotated* tags in a way that we would need to manage
(remove) them easily. It would be usefull to have one of the folowing in
"git tag":
1) git tag --delete-tags-to-danglings-and-unnamed-banches
Thi
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrew Wong writes:
> The previous code was assuming length ends at either `)` or `,`, and was
> not handling the case where strcspn returns length due to end of string.
> So specifying ":(top" as pathspec will cause the loop to go pass the end
> of string.
Thanks.
The parser that goes past the
Lukas Fleischer writes:
> These slightly improve the reading flow by making it obvious that a list
> follows.
>
> Signed-off-by: Lukas Fleischer
Perhaps.
The earlier message says "contains X ref(s)" while the later one
says "requires this/these X ref(s)". Do we want to make them
consistent, t
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Aguilar writes:
> I would prefer to treat this as a bugfix rather than introducing
> a new set of configuration knobs if possible. It really does
> seem like a correction.
>
> Users that want the traditional behavior can get that by
> configuring a custom mergetool.p4merge.cmd, so we're n
On Thu, Mar 7, 2013 at 11:10 AM, Junio C Hamano wrote:
> Kevin Bracey writes:
>
>> On 07/03/2013 09:23, Junio C Hamano wrote:
>>> If p4merge GUI labels one side clearly as "theirs" and the other
>>> "ours", and the way we feed the inputs to it makes the side that is
>>> actually "ours" appear in
Kevin Bracey writes:
> On 07/03/2013 09:23, Junio C Hamano wrote:
>> If p4merge GUI labels one side clearly as "theirs" and the other
>> "ours", and the way we feed the inputs to it makes the side that is
>> actually "ours" appear in p4merge GUI labelled as "theirs", then I
>> do not think backwa
On Thu, Mar 07, 2013 at 10:49:09AM +0100, Daniel Bratell wrote:
> Den 2013-03-06 19:12:05 skrev Heiko Voigt :
>
> >On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote:
> >>A submodule change can be merged, but only if the merge is a
> >>"fast-forward" which I think is a fair demand, but
On Thu, Mar 07, 2013 at 10:40:46AM -0800, Junio C Hamano wrote:
> Where we differ is if such information loss is a good thing to have.
>
> We could say "both sides added, identically" is auto-resolved when
> you use the zealous option, and do so regardless of how the merge
> conflicts are presente
Heiko Voigt wrote:
> This can be used to read configuration values directly from gits
> database.
>
> Signed-off-by: Heiko Voigt
> ---
> .gitignore | 1 +
> Makefile | 1 +
> cache.h| 1 +
> config.c | 47
Sparse issues the following warnings:
line-log.c:17:6: warning: symbol 'range_set_grow' was not declared. Should
it be static?
line-log.c:25:6: warning: symbol 'range_set_init' was not declared. Should
it be static?
line-log.c:33:6: warning: symbol 'range_set_release' was not declar
Jeff King writes:
> I'm not sure I agree. In this output (which does the zealous
> simplification, the splitting, and arbitrarily assigns deleted preimage
> to the first of the split hunks):
>
> 1234ACE789
>
> I do not see the promotion of C to "already resolved, you cannot tell if
> it was rea
git rev-list A^! --not B provides wrong answer if all commits in the
range A..B had the same commit times and there are more then 8 of them.
This commits fixes the logic in still_interesting function to prevent
this error.
Signed-off-by: Kacper Kornet
---
revision.c | 2 +-
1 file changed, 1 ins
On 07/03/2013 09:23, Junio C Hamano wrote:
If p4merge GUI labels one side clearly as "theirs" and the other
"ours", and the way we feed the inputs to it makes the side that is
actually "ours" appear in p4merge GUI labelled as "theirs", then I do
not think backward compatibility argument does no
Junio C Hamano writes:
> You could make it "1234789", and that is
> technically correct (what there were in the shared original for the
> conflicted part is 5 and then 6), but the representation pretends
> that it knows more than there actually is information, which may be
> somewhat misleading.
On Thu, Mar 07, 2013 at 09:26:05AM -0800, Junio C Hamano wrote:
> Without thinking about it too deeply,...
>
> I think the "RCS merge" _could_ show it as "1234ACE789"
> without losing any information (as it is already discarding what was
> in the original in the part that is affected by the confl
Greg Price writes:
> On Wed, Mar 06, 2013 at 09:10:57AM -0800, Junio C Hamano wrote:
>> I do not know if mentioning what -A does in the description for -u
>> (and vice versa) makes it easier to understand or more confusing
>> (not rhetorical: I suspect some may find it easier and others not).
>>
Thomas Rast writes:
> I still think that the _right_ solution is first redoing the merge on
> its original parents and then seeing how the actual merge differs from
> that.
I think that is what was suggested in
http://article.gmane.org/gmane.comp.version-control.git/198316
> Perhaps a new
Jeff King writes:
> I was also curious whether it would the diff3/zealous combination would
> trigger any weird corner cases. In particular, I wanted to know how the
> example you gave in that commit of:
>
> postimage#1: 1234ABCDE789
> |/
> | /
> prei
The previous code was assuming length ends at either `)` or `,`, and was
not handling the case where strcspn returns length due to end of string.
So specifying ":(top" as pathspec will cause the loop to go pass the end
of string.
Signed-off-by: Andrew Wong
---
setup.c | 6 --
1 file changed,
>
> I think I tried adding the ^{} syntax, but I don't think it works on
> remote repos. Or I couldn't get the right syntax.
>
indeed, it doesn't work on fetch, but it could be used somewhere between the
fetch and the commit-tree to move from the ref to the associated commit
>
> Latest pat
On Thu, Mar 7, 2013 at 3:15 PM, Jeremy Rosen wrote:
>> >
>> > Ok, I can understand that you don't want to import tags for
>> > namespace reason, but in that case shouldn't
>> > git subtree add refuse to create a subtree when the tag isn't a
>> > commit
>>
>> It shouldn't and tries not to, but is l
> >
> > Ok, I can understand that you don't want to import tags for
> > namespace reason, but in that case shouldn't
> > git subtree add refuse to create a subtree when the tag isn't a
> > commit
>
> It shouldn't and tries not to, but is limited in it's ability to
> identify if a refspec points to
On Thu, Mar 7, 2013 at 12:50 PM, Jeremy Rosen wrote:
>> >>
>> >> Git subtree ignores tags from the remote repo.
>> >>
>> >
>> > is that a design decision or a case of "not implemented yet"
>>
>> I'm not sure. If you imported all the tags from all your subtrees
>> repos, you could easily end up wit
> >>
> >> Git subtree ignores tags from the remote repo.
> >>
> >
> > is that a design decision or a case of "not implemented yet"
>
> I'm not sure. If you imported all the tags from all your subtrees
> repos, you could easily end up with duplicate tags from different
> repos. They could be namesp
On Thu, Mar 7, 2013 at 11:05 AM, Jeremy Rosen wrote:
>>
>> Hi Jérémy,
>>
>> Git subtree ignores tags from the remote repo.
>>
>
> is that a design decision or a case of "not implemented yet"
I'm not sure. If you imported all the tags from all your subtrees
repos, you could easily end up with dupl
Currently this is cosmetic change - the merges are ignored, becuase the methods
(lookup_svn_merge, find_rev_before, find_rev_after) are failing on comparing
text with number.
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was add
>
> Hi Jérémy,
>
> Git subtree ignores tags from the remote repo.
>
is that a design decision or a case of "not implemented yet"
> To follow a project in a subdirectory I would use git-subtree add
> selecting a branch, not a tag, from the other repo. Then use
> git-subtree pull to keep yoursel
On Thu, Mar 7, 2013 at 10:25 AM, Jeremy Rosen wrote:
> Hello everybody
>
>
> I am trying to use git-subtree to follow a subproject but I have a couple of
> problems and I am not sure if I am doing something wrong
>
> Basically I am trying to use a tag on the subproject as my "base" for the
> sub
Junio,
On Wed, Mar 06, 2013 at 09:47:53AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > Intro
> > -
>
> Drop this. We know the beginning part is "intro" already ;-)
:)
> > Subject: föö bar
> >
> > encoding
> >
> > Subject: =?UTF-8?q?=20f=C3=B6=C3=B6?=
> >
(adding Sam to the Cc:, I rely on him for SVN merge knowledge)
Jan Pešta wrote:
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a
Hello everybody
I am trying to use git-subtree to follow a subproject but I have a couple of
problems and I am not sure if I am doing something wrong
Basically I am trying to use a tag on the subproject as my "base" for the
subproject but subtree doesn't seem to handle that properly
my firs
Recently I have observed very strange failures in "git rebase" that cause it to
fail to work automatically in situations where it should trivially be able to
do so.
In case it matter, here's my setup: git 1.8.2.rc2.4.g7799588 (i.e. git.git
master branch) on Mac OS X. The repos clone is on a HFS
On Wed, Mar 06, 2013 at 09:10:57AM -0800, Junio C Hamano wrote:
> I do not know if mentioning what -A does in the description for -u
> (and vice versa) makes it easier to understand or more confusing
> (not rhetorical: I suspect some may find it easier and others not).
>
> But "and the default beh
Am 3/7/2013 9:48, schrieb Thomas Rast:
> wor...@alum.mit.edu (Dale R. Worley) writes:
> [...snip...]
>
> Isn't that just a very long-winded way of restating what Junio said
> earlier:
>
>>> It was suggested to make it apply the first-parent diff and record
>>> the result, I think. If that were a
On 07/03/2013 04:23, David Aguilar wrote:
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey wrote:
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
I think the reasoning behind these patches is good.
How do we feel about this duplication?
Bad.
Should we make a common
Den 2013-03-06 19:12:05 skrev Heiko Voigt :
On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote:
I can phrase this in two ways and I'll start with the short way:
Why does a merge of a git submodule use as merge-base the commit that
was
active in the merge-base of the parent repo,
On Thu, Mar 07, 2013 at 09:36:06AM +0100, Miklós Fazekas wrote:
> Sorry for the late turnaround here is an improved version. Now chdir
> has an optional argument client_path, if it's true then we don't do
> os.getcwd. I think that my first patch is also valid too - when the
> path is absolute no ne
wor...@alum.mit.edu (Dale R. Worley) writes:
[...snip...]
Isn't that just a very long-winded way of restating what Junio said
earlier:
> > It was suggested to make it apply the first-parent diff and record
> > the result, I think. If that were an acceptable approach (I didn't
> > think about it
On Thu, 7 Mar 2013 00:01:31 -0800 (PST)
Aleksey Rozhkov wrote:
> The page http://git-scm.com/book/ru/
> Введение-Первоначальная-настройка-Git contains incorrect link "next"
> Now this link to the page
> http://git-scm.com/book/ru/Введение-Как-получить-помощь? , but this
> page does not exist
I
Sorry for the late turnaround here is an improved version. Now chdir
has an optional argument client_path, if it's true then we don't do
os.getcwd. I think that my first patch is also valid too - when the
path is absolute no need for getcwd no matter what is the context,
when it's relative we have
On Wed, Mar 06, 2013 at 01:32:28PM -0800, Junio C Hamano wrote:
> > We show "both sides added, either identically or differently" as
> > noteworthy events, but the patched code pushes "both sides added
> > identically" case outside the conflicting hunk, as if what was added
> > relative to the com
65 matches
Mail list logo
