* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-22 0:47 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1BtOkwVbC3RyJVQb7K1DRMnJf3_omn7zrkzoE48Ayu7HBg@mail.gmail.com>
On 21 August 2011 17:07, Michael Witten <mfwitten@gmail.com> wrote:
> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>>>> <hilco.wijbenga@gmail.com> wrote:
>>>>>> Isn't a branch simply a way to track changes separately?
>>>>>
>>>>> Well, what does that mean, really? You can certainly use branches to
>>>>> help you achieve that goal.
>>>>
>>>> It means my commits are chained together separate from, say, master.
>>>
>>> Well, that's not what a git branch provides in general.
>>
>> Er, so what *does* a Git branch provide then?
>
> I think my other replies (including the link) repeat myself quite enough.
>
> A branch is just a pointer. That's it.
>
> Quit saying `branch' to yourself. Start saying `pointer' or
> `reference' or `commit label' or even `special tag'.
:-) Again, we are going in circles. I *know* a branch is just a
pointer. So what? To me, that's just the implementation. Why is that
relevant? What am I missing?
>>>> I feel like we're talking in circles. I get (and even agree with) what
>>>> you're saying but I don't see how it changes the concept of a branch.
>>>>
>>>> In any case, what I'm more interested in is knowing whether we can
>>>> (optionally) add state (i.e. untracked/ignored files and unstaged
>>>> changes) to a branch.
>>>
>>> No, because a branch doesn't IN ANY WAY provide the structure for that
>>> kind of thing.
>>
>> Obviously, we'd need to expand that structure.
>>
>> I tried (ab)using git stash to get what I want but it ignores
>> untracked/ignored files (not a big surprise, of course). It seems the
>> functionality is almost there. If I could just combine git checkout
>> with git stash (and have it work with untracked/ignored files) in a
>> script or alias, I'd be a happy camper. I'll have to give it some more
>> thought.
>
> This cobbling together of git's components for this purpose is
> actually a fairly frequent story on this list. Either git does indeed
> need something more substantial as a `branch', or people (meaning you)
> need to change the way they think (and I'm not sure which solution
> would be best, honestly).
I don't think that changing the way I think would be very effective. I
still have to get my work done. And I don't want build artifacts from
one "pointer" ;-) leak into the working directory of another "pointer"
just because I changed "pointers". (I'm sorry, "pointer" just doesn't
work for me.)
How is this normally resolved? What do the Linux kernel developers do
when changing or creating a branch? Do they do some sort of "clean"
first?
And I'm getting quite close with "git ls-files -io --exclude-standard
--directory". :-) The cobbling-together-of-components approach looks
promising. ;-)
> If there is a change, then what is currently called a `branch' should
> be renamed explicitly to `pointer' or a `reference' or something like
> that.
Quite possibly but it seems to me that this is too low level. I think
there are already too many places where Git's implementation leaks
into its API. E.g., anything explicitly related to the index.
>>> Of course, you could use what git calls a 'branch' in
>>> order to implement what you imply is a 'branch', but git's concept of
>>> a branch and your concept of a branch are not at all the same concept
>>> (which is why the term 'branch' is so unfortunate).
>>
>> You've completely lost me. You may very well be right but all I see is
>> that you're pointing out how branches are implemented in Git.
>
> That last sentence and your earlier sentence:
>
>> Obviously, we'd need to expand that structure.
>
> vindicate everything I've said about the choice of nomenclature. The
> term `branch' is a TERRIBLE choice.
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-22 1:53 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi0jZT_HCEV8UDzEOQeuCcDeqxoKGUEk3bJm=O2eJSHfkg@mail.gmail.com>
On 21 August 2011 17:47, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> And I'm getting quite close with "git ls-files -io --exclude-standard
> --directory". :-) The cobbling-together-of-components approach looks
> promising. ;-)
Wow, it looks like this sort functionality is already available in
Git. I just cloned the Git repo and git stash now has (in master) two
new options: -u|--include-untracked and -a|--all. It looks like my
wish is about to come true. :-)
^ permalink raw reply
* Re: Branches & directories
From: Michael Witten @ 2011-08-22 2:05 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi0jZT_HCEV8UDzEOQeuCcDeqxoKGUEk3bJm=O2eJSHfkg@mail.gmail.com>
On Mon, Aug 22, 2011 at 00:47, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> On 21 August 2011 17:07, Michael Witten <mfwitten@gmail.com> wrote:
>> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>> On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
>>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>>>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>>>>> <hilco.wijbenga@gmail.com> wrote:
>>>>>>> Isn't a branch simply a way to track changes separately?
>>>>>>
>>>>>> Well, what does that mean, really? You can certainly use branches to
>>>>>> help you achieve that goal.
>>>>>
>>>>> It means my commits are chained together separate from, say, master.
>>>>
>>>> Well, that's not what a git branch provides in general.
>>>
>>> Er, so what *does* a Git branch provide then?
>>
>> I think my other replies (including the link) repeat myself quite enough.
>>
>> A branch is just a pointer. That's it.
>>
>> Quit saying `branch' to yourself. Start saying `pointer' or
>> `reference' or `commit label' or even `special tag'.
>
> :-) Again, we are going in circles. I *know* a branch is just a
> pointer. So what? To me, that's just the implementation. Why is that
> relevant? What am I missing?
You're missing (or, rather, ignoring) the fact that what is called a
`branch' in git is exactly what is intended to be called a `branch' in
git; it is not merely an incomplete or weak implementation of
something.
You're probably also missing the fact that I'm simply arguing the
point that the term `branch' was a TERRIBLE choice, and your remarks
and confusion have confirmed that. Other than that, most of what I'm
saying has very little relevance to what you're trying to do; I was
following a philosophical tangent inspired by this thread.
>>>>> I feel like we're talking in circles. I get (and even agree with) what
>>>>> you're saying but I don't see how it changes the concept of a branch.
>>>>>
>>>>> In any case, what I'm more interested in is knowing whether we can
>>>>> (optionally) add state (i.e. untracked/ignored files and unstaged
>>>>> changes) to a branch.
>>>>
>>>> No, because a branch doesn't IN ANY WAY provide the structure for that
>>>> kind of thing.
>>>
>>> Obviously, we'd need to expand that structure.
>>>
>>> I tried (ab)using git stash to get what I want but it ignores
>>> untracked/ignored files (not a big surprise, of course). It seems the
>>> functionality is almost there. If I could just combine git checkout
>>> with git stash (and have it work with untracked/ignored files) in a
>>> script or alias, I'd be a happy camper. I'll have to give it some more
>>> thought.
>>
>> This cobbling together of git's components for this purpose is
>> actually a fairly frequent story on this list. Either git does indeed
>> need something more substantial as a `branch', or people (meaning you)
>> need to change the way they think (and I'm not sure which solution
>> would be best, honestly).
>
> I don't think that changing the way I think would be very effective. I
> still have to get my work done. And I don't want build artifacts from
> one "pointer" ;-) leak into the working directory of another "pointer"
> just because I changed "pointers". (I'm sorry, "pointer" just doesn't
> work for me.)
It doesn't make any sense to say `artifacts from one "pointer"'. You
are now, unfortunately, just using the term `pointer' like the term
`branch'; you are refusing to let go of the concept that the word
`branch' alone has seared into your brain.
As has been my entire point: You have been corrupted by the wrong
choice of words.
> How is this normally resolved? What do the Linux kernel developers do
> when changing or creating a branch? Do they do some sort of "clean"
> first?
Perhaps `git clean' would be of use to you.
> And I'm getting quite close with "git ls-files -io --exclude-standard
> --directory". :-) The cobbling-together-of-components approach looks
> promising. ;-)
Hence what I said earlier:
Of course, you could use what git calls a 'branch' in order
to implement what you imply is a 'branch', but git's concept
of a branch and your concept of a branch are not at all the
same concept (which is why the term 'branch' is so
unfortunate).
However, please note that your solution is not completing the
implementation of branches in git, but rather using git's branches to
implement something entirely different (and which you think should be
called `branches'). The terminology is the key point in the confusion.
I dare say, had git's branches been instead called `pointers' or the
like, then you would have just gone about the business of implementing
your `branches' on top of them without thinking twice.
>> If there is a change, then what is currently called a `branch' should
>> be renamed explicitly to `pointer' or a `reference' or something like
>> that.
>
> Quite possibly but it seems to me that this is too low level. I think
> there are already too many places where Git's implementation leaks
> into its API. E.g., anything explicitly related to the index.
Git's power is its simple conceptual basis, and what you are calling
low-level is in fact just the ability to deal within the language of
those simple concepts.
Git's weakness is that the most public interface shoehorns that simple
conceptual basis into not just a more automated system, but into a
weaker model that works well most of the time, yet fails and even
corrupts the mind of the user when it comes to more interesting
scenarios.
What you call a leaky abstraction is not the `low-level' conceptual
basis peeking through innappropriately. Rather, it is the falling
apart of the shoddy `higher-level' facade.
>>>> Of course, you could use what git calls a 'branch' in
>>>> order to implement what you imply is a 'branch', but git's concept of
>>>> a branch and your concept of a branch are not at all the same concept
>>>> (which is why the term 'branch' is so unfortunate).
>>>
>>> You've completely lost me. You may very well be right but all I see is
>>> that you're pointing out how branches are implemented in Git.
>>
>> That last sentence and your earlier sentence:
>>
>>> Obviously, we'd need to expand that structure.
>>
>> vindicate everything I've said about the choice of nomenclature. The
>> term `branch' is a TERRIBLE choice.
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-22 2:13 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1Bu5pPeviyZD-e6aHbv-+tSaBDyyKb5vHA132K_3=1gD-g@mail.gmail.com>
On 21 August 2011 19:05, Michael Witten <mfwitten@gmail.com> wrote:
> On Mon, Aug 22, 2011 at 00:47, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> On 21 August 2011 17:07, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>>> On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
>>>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>>>>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>>>>>> <hilco.wijbenga@gmail.com> wrote:
>>>>>>>> Isn't a branch simply a way to track changes separately?
>>>>>>>
>>>>>>> Well, what does that mean, really? You can certainly use branches to
>>>>>>> help you achieve that goal.
>>>>>>
>>>>>> It means my commits are chained together separate from, say, master.
>>>>>
>>>>> Well, that's not what a git branch provides in general.
>>>>
>>>> Er, so what *does* a Git branch provide then?
>>>
>>> I think my other replies (including the link) repeat myself quite enough.
>>>
>>> A branch is just a pointer. That's it.
>>>
>>> Quit saying `branch' to yourself. Start saying `pointer' or
>>> `reference' or `commit label' or even `special tag'.
>>
>> :-) Again, we are going in circles. I *know* a branch is just a
>> pointer. So what? To me, that's just the implementation. Why is that
>> relevant? What am I missing?
>
> You're missing (or, rather, ignoring) the fact that what is called a
> `branch' in git is exactly what is intended to be called a `branch' in
> git; it is not merely an incomplete or weak implementation of
> something.
>
> You're probably also missing the fact that I'm simply arguing the
> point that the term `branch' was a TERRIBLE choice, and your remarks
> and confusion have confirmed that. Other than that, most of what I'm
> saying has very little relevance to what you're trying to do; I was
> following a philosophical tangent inspired by this thread.
>
>>>>>> I feel like we're talking in circles. I get (and even agree with) what
>>>>>> you're saying but I don't see how it changes the concept of a branch.
>>>>>>
>>>>>> In any case, what I'm more interested in is knowing whether we can
>>>>>> (optionally) add state (i.e. untracked/ignored files and unstaged
>>>>>> changes) to a branch.
>>>>>
>>>>> No, because a branch doesn't IN ANY WAY provide the structure for that
>>>>> kind of thing.
>>>>
>>>> Obviously, we'd need to expand that structure.
>>>>
>>>> I tried (ab)using git stash to get what I want but it ignores
>>>> untracked/ignored files (not a big surprise, of course). It seems the
>>>> functionality is almost there. If I could just combine git checkout
>>>> with git stash (and have it work with untracked/ignored files) in a
>>>> script or alias, I'd be a happy camper. I'll have to give it some more
>>>> thought.
>>>
>>> This cobbling together of git's components for this purpose is
>>> actually a fairly frequent story on this list. Either git does indeed
>>> need something more substantial as a `branch', or people (meaning you)
>>> need to change the way they think (and I'm not sure which solution
>>> would be best, honestly).
>>
>> I don't think that changing the way I think would be very effective. I
>> still have to get my work done. And I don't want build artifacts from
>> one "pointer" ;-) leak into the working directory of another "pointer"
>> just because I changed "pointers". (I'm sorry, "pointer" just doesn't
>> work for me.)
>
> It doesn't make any sense to say `artifacts from one "pointer"'. You
> are now, unfortunately, just using the term `pointer' like the term
> `branch'; you are refusing to let go of the concept that the word
> `branch' alone has seared into your brain.
>
> As has been my entire point: You have been corrupted by the wrong
> choice of words.
>
>> How is this normally resolved? What do the Linux kernel developers do
>> when changing or creating a branch? Do they do some sort of "clean"
>> first?
>
> Perhaps `git clean' would be of use to you.
>
>> And I'm getting quite close with "git ls-files -io --exclude-standard
>> --directory". :-) The cobbling-together-of-components approach looks
>> promising. ;-)
>
> Hence what I said earlier:
>
> Of course, you could use what git calls a 'branch' in order
> to implement what you imply is a 'branch', but git's concept
> of a branch and your concept of a branch are not at all the
> same concept (which is why the term 'branch' is so
> unfortunate).
>
> However, please note that your solution is not completing the
> implementation of branches in git, but rather using git's branches to
> implement something entirely different (and which you think should be
> called `branches'). The terminology is the key point in the confusion.
> I dare say, had git's branches been instead called `pointers' or the
> like, then you would have just gone about the business of implementing
> your `branches' on top of them without thinking twice.
>
>>> If there is a change, then what is currently called a `branch' should
>>> be renamed explicitly to `pointer' or a `reference' or something like
>>> that.
>>
>> Quite possibly but it seems to me that this is too low level. I think
>> there are already too many places where Git's implementation leaks
>> into its API. E.g., anything explicitly related to the index.
>
> Git's power is its simple conceptual basis, and what you are calling
> low-level is in fact just the ability to deal within the language of
> those simple concepts.
>
> Git's weakness is that the most public interface shoehorns that simple
> conceptual basis into not just a more automated system, but into a
> weaker model that works well most of the time, yet fails and even
> corrupts the mind of the user when it comes to more interesting
> scenarios.
>
> What you call a leaky abstraction is not the `low-level' conceptual
> basis peeking through innappropriately. Rather, it is the falling
> apart of the shoddy `higher-level' facade.
>
>>>>> Of course, you could use what git calls a 'branch' in
>>>>> order to implement what you imply is a 'branch', but git's concept of
>>>>> a branch and your concept of a branch are not at all the same concept
>>>>> (which is why the term 'branch' is so unfortunate).
>>>>
>>>> You've completely lost me. You may very well be right but all I see is
>>>> that you're pointing out how branches are implemented in Git.
>>>
>>> That last sentence and your earlier sentence:
>>>
>>>> Obviously, we'd need to expand that structure.
>>>
>>> vindicate everything I've said about the choice of nomenclature. The
>>> term `branch' is a TERRIBLE choice.
Thanks for sticking it out. :-) That all makes sense. I think it's all
pretty clear now.
^ permalink raw reply
* [PATCH] git-svn: Destroy the cache when we fail to read it
From: Jason Gross @ 2011-08-22 2:17 UTC (permalink / raw)
To: git; +Cc: Jason Gross, Jonathan Nieder
Previously, we would fail fatally when trying to fetch changes with
mergeinfo on a 32 bit machine, when the repository previously had
fetched changes with mergeinfo on a 64 bit machine.
This fixes bug 618875 (which is also 587650, 635097). Much of the code
was written by Jonathan Nieder <jrnieder@gmail.com> with suggestions
from Steffen Mueller <smueller@cpan.org> (see
http://lists.debian.org/debian-perl/2011/05/msg00023.html and
http://lists.debian.org/debian-perl/2011/05/msg00026.html).
Signed-off-by: Jason Gross <jgross@mit.edu>
Cc: Jonathan Nieder <jrnieder@gmail.com>
---
git-svn.perl | 59 +++++++++++++++++++++++++++++++++++----------------------
1 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 89f83fd..78ccdc8 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1680,7 +1680,7 @@ use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
$_use_svnsync_props $no_reuse_existing $_minimize_url
$_use_log_author $_add_author_from $_localtime/;
use Carp qw/croak/;
-use File::Path qw/mkpath/;
+use File::Path qw/mkpath rmtree/;
use File::Copy qw/copy/;
use IPC::Open3;
use Memoize; # core since 5.8.0, Jul 2002
@@ -3198,28 +3198,41 @@ sub has_no_changes {
$memoized = 1;
my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
- mkpath([$cache_path]) unless -d $cache_path;
-
- tie my %lookup_svn_merge_cache => 'Memoize::Storable',
- "$cache_path/lookup_svn_merge.db", 'nstore';
- memoize 'lookup_svn_merge',
- SCALAR_CACHE => 'FAULT',
- LIST_CACHE => ['HASH' => \%lookup_svn_merge_cache],
- ;
-
- tie my %check_cherry_pick_cache => 'Memoize::Storable',
- "$cache_path/check_cherry_pick.db", 'nstore';
- memoize 'check_cherry_pick',
- SCALAR_CACHE => 'FAULT',
- LIST_CACHE => ['HASH' => \%check_cherry_pick_cache],
- ;
-
- tie my %has_no_changes_cache => 'Memoize::Storable',
- "$cache_path/has_no_changes.db", 'nstore';
- memoize 'has_no_changes',
- SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
- LIST_CACHE => 'FAULT',
- ;
+ my $do_memoization = sub {
+ mkpath([$cache_path]) unless -d $cache_path;
+
+ tie my %lookup_svn_merge_cache => 'Memoize::Storable',
+ "$cache_path/lookup_svn_merge.db", 'nstore';
+ memoize 'lookup_svn_merge',
+ SCALAR_CACHE => 'FAULT',
+ LIST_CACHE => ['HASH' => \%lookup_svn_merge_cache],
+ ;
+
+ tie my %check_cherry_pick_cache => 'Memoize::Storable',
+ "$cache_path/check_cherry_pick.db", 'nstore';
+ memoize 'check_cherry_pick',
+ SCALAR_CACHE => 'FAULT',
+ LIST_CACHE => ['HASH' => \%check_cherry_pick_cache],
+ ;
+
+ tie my %has_no_changes_cache => 'Memoize::Storable',
+ "$cache_path/has_no_changes.db", 'nstore';
+ memoize 'has_no_changes',
+ SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
+ LIST_CACHE => 'FAULT',
+ ;
+ };
+
+ if (not eval {
+ $do_memoization->();
+ 1;
+ }) {
+ my $err = $@ || "Zombie error"; # "Zombie error" to catch clobbered $@ in buggy destructors
+ die $err unless -d $cache_path;
+ print STDERR "Discarding cache and trying again ($@)\n";
+ rmtree([$cache_path]);
+ $do_memoization->();
+ }
}
sub unmemoize_svn_mergeinfo_functions {
--
1.7.2.3
^ permalink raw reply related
* Re: Merge after directory rename ?
From: Michael Witten @ 2011-08-22 2:19 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <j2s83l$eqg$1@dough.gmane.org>
2011/8/22 Marcin Wiśnicki <mwisnicki@gmail.com>:
> On Sun, 21 Aug 2011 23:53:34 +0000, Michael Witten wrote:
>> Importantly, note that I used only file names in my example,
>> specifically:
>>
>> 5. [master] rename dir1/file3 to dir3/file3
>>
>> rather than mirroring your example by writing:
>>
>> 5. [master] rename dir1 to dir3
>>
>> This is because git fundamentally tracks content, and paths are just one
>> kind of content associated with another blob of content. Consequently,
>
> I know it tracks content, yet it puts effort to detect file renames.
> I want it to also detect directory renames, detecting it should be quite
> easy.
>
>> git really knows next to nothing about directories, so it's not too
>> surprising that git doesn't bother finding such a DIRECTORY rename
>> anyway (at most, git would detect a FILE rename, and your FILE
>> `dir1/file2' has nothing to do with, say, the FILE `dir1/file1' being
>> renamed `dir2/file1').
>>
>> Still, some command line switches could be useful to help the user
>> express to git what should be going on in a case such as yours.
>
> I would prefer it to be fully automatic :)
I assume the smiley is tongue-in-cheek; however, in case it is not: It
can't be automatic in general; did my examples mean nothing?
> Or at least detect/warn about tree conflict.
Did my examples mean nothing?
> Directory renames can happen quite frequently when working with Java/C#
> and it is unreasonable to expect that lazy user will have to keep track of
> it manually (with huge number of files it's impossible).
Git doesn't know anything about Java/C#; that's the point.
In general, the user could make use of switches (as suggested). In
particular, perhaps there are merge hooks or merge drivers that could
be used or implemented for allowing a more environment-specific
handling of merges, a la GNU's ChangeLog merge driver:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
Also, see the configuration section of `git help merge'. Also look at
the tool `git mergetool'.
^ permalink raw reply
* (very minor) should git-gui 'unset TERM' before spawning 'git push'
From: Sitaram Chamarty @ 2011-08-22 2:30 UTC (permalink / raw)
To: Git Mailing List
I'm seeing ugly ^[[K (Escape - left bracket - K; ANSI codes for erase
to end of line?) in the graphical output box on a push.
I tried to trace the code and could only find it under mingw. My C-fu
must be much worse than I thought...
Anyway it happens on a purely Fedora 15 setup with the simplest
possible file:// URL for the remote. And it goes away if I 'unset
TERM' first, too.
--
Sitaram
^ permalink raw reply
* Re: Branches & directories
From: Kyle Moffett @ 2011-08-22 3:01 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Michael Witten, Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi0dL2qNMksuY_=gyGSRsfr6e9AmzgJUNB=jEz85sjuiUw@mail.gmail.com>
On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> Thanks for sticking it out. :-) That all makes sense. I think it's all
> pretty clear now.
It's worth mentioning that in most cases you DON'T want to delete untracked and
ignored files when switching branches.
For example, when I'm doing kernel development, I will frequently do this:
$ git checkout -b my-new-feature origin/master
[...hack hack hack...]
$ make -j16 && make install && reboot
[...find unrelated bug...]
$ git checkout -b my-new-bugfix origin/master
[...fix the bug...]
$ make -j16 && make install && reboot
$ git commit -m 'I fixed this bug'
$ git checkout my-new-feature
$ git rebase my-new-bugfix
$ make -j16 && make install && reboot
To avoid wasting time I don't want to completely rebuild the kernel each
and every time I switch branches, I just want to rebuild the files that
changed when I switched. The way GIT works lets me do that quite
easily, and the kernel Makefiles detect the changed files and rebuild
the minimum amount necessary.
GIT's behavior when you switch between branches is effectively the
same as applying a patch generated by diffing between the two
branches. Any files which would not be changed are left alone, their
timestamps completely unchanged.
It sounds like Eclipse is simply not detecting changes to your working
tree by outside programs, and as a result it's not rebuilding files and
indexes the way that it should.
Obviously the easiest way to work around that issue is "git clean",
which has options to select all untracked files or just ignored ones.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH 1/2] clone: allow to clone from .git file
From: Nguyen Thai Ngoc Duy @ 2011-08-22 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h66y4s5.fsf@alter.siamese.dyndns.org>
2011/8/22 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> + else if (S_ISREG(st.st_mode) && st.st_size > 8) {
>> + /* Despite the name read_gitfile_gently can be
>> + cruel on non .git file, check for signature
>> + ourselves */
>
> Didn't somebody add "is this '.git' thing a valid git metadirectory?" API
> quite recently for exactly this?
>
You mean resolve_gitdir() in abc0682 (rev-parse: add option
--resolve-git-dir <path> - 2011-08-15)? That function would barf on a
bundle file. I'm not aware of any other functions.
--
Duy
^ permalink raw reply
* Re: [PATCH] git-svn: Destroy the cache when we fail to read it
From: Jason Gross @ 2011-08-22 4:04 UTC (permalink / raw)
To: git; +Cc: Jason Gross, Jonathan Nieder
In-Reply-To: <1313979422-21286-1-git-send-email-jgross@mit.edu>
Oops, the bug numbers I gave were debian bug ids, not git bug ids.
The "This fixes bug ..." sentence should either be removed from the
commit message before this commit is merged, or the numbers should be
replaced with the appropriate git bug numbers.
-Jason
On Sun, Aug 21, 2011 at 10:17 PM, Jason Gross <jgross@mit.edu> wrote:
>
> Previously, we would fail fatally when trying to fetch changes with
> mergeinfo on a 32 bit machine, when the repository previously had
> fetched changes with mergeinfo on a 64 bit machine.
>
> This fixes bug 618875 (which is also 587650, 635097). Much of the code
> was written by Jonathan Nieder <jrnieder@gmail.com> with suggestions
> from Steffen Mueller <smueller@cpan.org> (see
> http://lists.debian.org/debian-perl/2011/05/msg00023.html and
> http://lists.debian.org/debian-perl/2011/05/msg00026.html).
>
> Signed-off-by: Jason Gross <jgross@mit.edu>
> Cc: Jonathan Nieder <jrnieder@gmail.com>
> ---
> git-svn.perl | 59 +++++++++++++++++++++++++++++++++++----------------------
> 1 files changed, 36 insertions(+), 23 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 89f83fd..78ccdc8 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1680,7 +1680,7 @@ use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
> $_use_svnsync_props $no_reuse_existing $_minimize_url
> $_use_log_author $_add_author_from $_localtime/;
> use Carp qw/croak/;
> -use File::Path qw/mkpath/;
> +use File::Path qw/mkpath rmtree/;
> use File::Copy qw/copy/;
> use IPC::Open3;
> use Memoize; # core since 5.8.0, Jul 2002
> @@ -3198,28 +3198,41 @@ sub has_no_changes {
> $memoized = 1;
>
> my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
> - mkpath([$cache_path]) unless -d $cache_path;
> -
> - tie my %lookup_svn_merge_cache => 'Memoize::Storable',
> - "$cache_path/lookup_svn_merge.db", 'nstore';
> - memoize 'lookup_svn_merge',
> - SCALAR_CACHE => 'FAULT',
> - LIST_CACHE => ['HASH' => \%lookup_svn_merge_cache],
> - ;
> -
> - tie my %check_cherry_pick_cache => 'Memoize::Storable',
> - "$cache_path/check_cherry_pick.db", 'nstore';
> - memoize 'check_cherry_pick',
> - SCALAR_CACHE => 'FAULT',
> - LIST_CACHE => ['HASH' => \%check_cherry_pick_cache],
> - ;
> -
> - tie my %has_no_changes_cache => 'Memoize::Storable',
> - "$cache_path/has_no_changes.db", 'nstore';
> - memoize 'has_no_changes',
> - SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
> - LIST_CACHE => 'FAULT',
> - ;
> + my $do_memoization = sub {
> + mkpath([$cache_path]) unless -d $cache_path;
> +
> + tie my %lookup_svn_merge_cache => 'Memoize::Storable',
> + "$cache_path/lookup_svn_merge.db", 'nstore';
> + memoize 'lookup_svn_merge',
> + SCALAR_CACHE => 'FAULT',
> + LIST_CACHE => ['HASH' => \%lookup_svn_merge_cache],
> + ;
> +
> + tie my %check_cherry_pick_cache => 'Memoize::Storable',
> + "$cache_path/check_cherry_pick.db", 'nstore';
> + memoize 'check_cherry_pick',
> + SCALAR_CACHE => 'FAULT',
> + LIST_CACHE => ['HASH' => \%check_cherry_pick_cache],
> + ;
> +
> + tie my %has_no_changes_cache => 'Memoize::Storable',
> + "$cache_path/has_no_changes.db", 'nstore';
> + memoize 'has_no_changes',
> + SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
> + LIST_CACHE => 'FAULT',
> + ;
> + };
> +
> + if (not eval {
> + $do_memoization->();
> + 1;
> + }) {
> + my $err = $@ || "Zombie error"; # "Zombie error" to catch clobbered $@ in buggy destructors
> + die $err unless -d $cache_path;
> + print STDERR "Discarding cache and trying again ($@)\n";
> + rmtree([$cache_path]);
> + $do_memoization->();
> + }
> }
>
> sub unmemoize_svn_mergeinfo_functions {
> --
> 1.7.2.3
>
^ permalink raw reply
* [PATCH] Add tests for handling corrupted caches
From: Jason Gross @ 2011-08-22 4:10 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Jason Gross
In-Reply-To: <1313979422-21286-1-git-send-email-jgross@mit.edu>
There might be a more straightforward way to generate an svn repository
with mergeinfo, but I'm not very familiar with svn.
Signed-off-by: Jason Gross <jgross@mit.edu>
---
t/t9160-git-svn-caches.sh | 59 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
create mode 100755 t/t9160-git-svn-caches.sh
diff --git a/t/t9160-git-svn-caches.sh b/t/t9160-git-svn-caches.sh
new file mode 100755
index 0000000..bba437a
--- /dev/null
+++ b/t/t9160-git-svn-caches.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+
+test_description='git svn handling of .git/svn/.caches'
+
+. ./lib-git-svn.sh
+
+say 'define NO_SVN_TESTS to skip git svn tests'
+
+test_expect_success 'initialize source svn repo' '
+ svn_cmd mkdir -m x "$svnrepo"/trunk "$svnrepo"/branches &&
+ svn_cmd co "$svnrepo" "$SVN_TREE"
+'
+
+test_expect_success 'make a change that gives mergeinfo' '
+ (
+ cd "$SVN_TREE" &&
+ touch trunk/foo &&
+ svn_cmd add trunk/foo &&
+ svn_cmd commit -m "foo" &&
+ svn_cmd up &&
+ svn_cmd cp trunk branches/1
+ svn_cmd commit -m "make branch" &&
+ svn_cmd up &&
+ touch branches/1/bar &&
+ svn_cmd add branches/1/bar &&
+ svn_cmd commit -m bar &&
+ svn_cmd up &&
+ cd trunk &&
+ svn_cmd merge ../branches/1 &&
+ svn_cmd commit -m merge &&
+ svn_cmd up
+ )
+'
+
+test_expect_success 'clone svn repo and corrupt .caches' '
+ git svn init "$svnrepo" -T trunk -b branches &&
+ git svn fetch &&
+ echo corrupted > .git/svn/.caches/lookup_svn_merge.db
+'
+
+test_expect_success 'make another change that generates mergeinfo' '
+ (
+ cd "$SVN_TREE" &&
+ touch branches/1/baz &&
+ svn_cmd commit -m baz &&
+ svn_cmd up &&
+ cd trunk &&
+ svn_cmd merge ../branches/1 &&
+ svn_cmd commit -m merge2 &&
+ svn_cmd up
+ ) &&
+ rm -rf "$SVN_TREE"
+'
+
+test_expect_success 'fetch change with mergeinfo with a corrupted cache' '
+ git svn fetch
+'
+
+test_done
--
1.7.6.558.g4b2f
^ permalink raw reply related
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-22 5:36 UTC (permalink / raw)
To: Kyle Moffett
Cc: Michael Witten, Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAGZ=bqK7H3zc8LK7EP8+uV8DpWW+czK2POfceGtcBF8Vmkhkow@mail.gmail.com>
On 21 August 2011 20:01, Kyle Moffett <kyle@moffetthome.net> wrote:
> On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> Thanks for sticking it out. :-) That all makes sense. I think it's all
>> pretty clear now.
>
> It's worth mentioning that in most cases you DON'T want to delete untracked and
> ignored files when switching branches.
For the record, I don't want them deleted but replaced with the
artifacts in the other branch. A bit wasteful but it saves a lot of
build time.
> For example, when I'm doing kernel development, I will frequently do this:
>
> $ git checkout -b my-new-feature origin/master
> [...hack hack hack...]
> $ make -j16 && make install && reboot
> [...find unrelated bug...]
> $ git checkout -b my-new-bugfix origin/master
> [...fix the bug...]
> $ make -j16 && make install && reboot
> $ git commit -m 'I fixed this bug'
> $ git checkout my-new-feature
> $ git rebase my-new-bugfix
> $ make -j16 && make install && reboot
>
> To avoid wasting time I don't want to completely rebuild the kernel each
> and every time I switch branches, I just want to rebuild the files that
> changed when I switched. The way GIT works lets me do that quite
> easily, and the kernel Makefiles detect the changed files and rebuild
> the minimum amount necessary.
>
> GIT's behavior when you switch between branches is effectively the
> same as applying a patch generated by diffing between the two
> branches. Any files which would not be changed are left alone, their
> timestamps completely unchanged.
For small changes that makes perfect sense. I'm at a stage where APIs
are still evolving and changing an API means rebuilding lots of code.
I'd like to avoid that.
> It sounds like Eclipse is simply not detecting changes to your working
> tree by outside programs, and as a result it's not rebuilding files and
> indexes the way that it should.
While Eclipse isn't great at detecting such changes, this isn't really
an Eclipse problem. It's just that lots of things are still changing
and that leads to lots of building.
> Obviously the easiest way to work around that issue is "git clean",
> which has options to select all untracked files or just ignored ones.
As I mentioned above, I don't want to *delete* untracked/ignored
files, I just want them to stick to the branch I was working on. So if
I change to a different branch I get the appropriate build artifacts.
Something like: git stash --everything "All artifacts for
this-branch." && git checkout other-branch && git stash apply
stash-for-other-branch.
^ permalink raw reply
* [Git 1.7.6.557.gcee4] git stash
From: Hilco Wijbenga @ 2011-08-22 6:01 UTC (permalink / raw)
To: David Caldwell; +Cc: Git Users
Hi David,
I noticed your very timely change to git stash in the current master
branch. I tried it but it doesn't behave as I was expecting/hoping.
hilco@centaur ~/tmp/repo repo$ git --version
git version 1.7.6.557.gcee4
hilco@centaur ~/tmp/repo repo$ git init
Initialized empty Git repository in /home/hilco/tmp/repo/.git/
hilco@centaur ~/tmp/repo repo (master #)$ cat >>.gitignore <<- EOF
> *.ignore
> ignore-dir/
> EOF
hilco@centaur ~/tmp/repo repo (master #%)$ mkdir src
hilco@centaur ~/tmp/repo repo (master #%)$ touch file.txt src/code.txt
hilco@centaur ~/tmp/repo repo (master #%)$ git add -A .
hilco@centaur ~/tmp/repo repo (master #)$ git commit -m '1'
[master (root-commit) 0fb4106] 1
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
create mode 100644 file.txt
create mode 100644 src/code.txt
hilco@centaur ~/tmp/repo repo (master)$ touch file-a.ignore src/file-b.ignore
hilco@centaur ~/tmp/repo repo (master %)$ echo "hello">src/code.txt
hilco@centaur ~/tmp/repo repo (master *%)$ mkdir ignore-dir
hilco@centaur ~/tmp/repo repo (master *%)$ touch
ignore-dir/{file.ignore,file.txt}
hilco@centaur ~/tmp/repo repo (master *%)$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: src/code.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# file-a.ignore
# ignore-dir/
# src/file-b.ignore
no changes added to commit (use "git add" and/or "git commit -a")
hilco@centaur ~/tmp/repo repo (master *%)$ git stash --no-keep-index --all
Saved working directory and index state WIP on master: 0fb4106 1
HEAD is now at 0fb4106 1
Not removing ignore-dir/
hilco@centaur ~/tmp/repo repo (master $%)$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ignore-dir/
nothing added to commit but untracked files present (use "git add" to track)
So it quite explicitly states "Not removing ignore-dir/". How do I
make sure it also stashes the ignore-dir directory?
Cheers,
Hilco
^ permalink raw reply
* Re: [PATCH v2 5/5] Use kwset in grep
From: Paolo Bonzini @ 2011-08-22 6:39 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, dpotapov, Junio C Hamano
In-Reply-To: <20110820224218.GF2199@fredrik-Q430-Q530>
On 08/21/2011 12:42 AM, Fredrik Kuivinen wrote:
> + if (opt->regflags& REG_ICASE || p->ignore_case) {
> + static char trans[256];
> + int i;
> + for (i = 0; i< 256; i++)
> + trans[i] = tolower(i);
> + p->kws = kwsalloc(trans);
> + } else {
> + p->kws = kwsalloc(NULL);
> + }
Of course, this makes absolutely no sense for MB_CUR_MAX > 1. It's
worth mentioning that grep instead uses a loop with
mbrtowc/towlower/wcrtomb. This in turn will remove the need for the
complex kwset code. :)
The "mbtolower" code" dates to after the license change, but I wrote it
and I give permission to use it under GPLv2. See commits 70e23616 and
30af8050 in the GNU grep repository.
Should still be good enough for most uses, so I'll give my
Acked-by: Paolo Bonzini <bonzini@gnu.org>
Paolo
^ permalink raw reply
* [PATCH v3 0/5] Support threshold in copy/rename detection
From: Vitor Antunes @ 2011-08-22 8:33 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
Make detectCopiesHarder use "git config --bool".
Include Pete Wyckoff's patches to test cases.
Vitor Antunes (5):
git-p4: Allow setting rename/copy detection threshold
git-p4: Add description of rename/copy detection options
git-p4: Add test case for rename detection
git-p4: Add test case for copy detection
git-p4: Process detectCopiesHarder with --bool
contrib/fast-import/git-p4 | 15 +++--
contrib/fast-import/git-p4.txt | 25 +++++++
t/t9800-git-p4.sh | 136 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 171 insertions(+), 5 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH v3 1/5] git-p4: Allow setting rename/copy detection threshold
From: Vitor Antunes @ 2011-08-22 8:33 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314001989-29017-1-git-send-email-vitor.hda@gmail.com>
Copy and rename detection arguments (-C and -M) allow setting a threshold value
for the similarity ratio. If the similarity is below this threshold the rename
or copy is ignored and the file is added as new.
This patch allows setting git-p4.detectRenames and git-p4.detectCopies options
to an integer value to set the respective threshold.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6b9de9e..29a5390f 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -774,15 +774,20 @@ class P4Submit(Command, P4UserMap):
if not self.detectRenames:
# If not explicitly set check the config variable
- self.detectRenames = gitConfig("git-p4.detectRenames").lower() == "true"
+ self.detectRenames = gitConfig("git-p4.detectRenames")
- if self.detectRenames:
+ if self.detectRenames.lower() == "false" or self.detectRenames == "":
+ diffOpts = ""
+ elif self.detectRenames.lower() == "true":
diffOpts = "-M"
else:
- diffOpts = ""
+ diffOpts = "-M%s" % self.detectRenames
- if gitConfig("git-p4.detectCopies").lower() == "true":
+ detectCopies = gitConfig("git-p4.detectCopies")
+ if detectCopies.lower() == "true":
diffOpts += " -C"
+ elif detectCopies != "" and detectCopies.lower() != "false":
+ diffOpts += " -C%s" % detectCopies
if gitConfig("git-p4.detectCopiesHarder").lower() == "true":
diffOpts += " --find-copies-harder"
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 2/5] git-p4: Add description of rename/copy detection options
From: Vitor Antunes @ 2011-08-22 8:33 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314001989-29017-1-git-send-email-vitor.hda@gmail.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4.txt | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index caa4bb3..2ffbccc 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -232,6 +232,31 @@ git-p4.skipUserNameCheck
When submitting, git-p4 checks that the git commits are authored by the current
p4 user, and warns if they are not. This disables the check.
+git-p4.detectRenames
+
+Detect renames when submitting changes to Perforce server. Will enable -M git
+argument. Can be optionally set to a number representing the threshold
+percentage value of the rename detection.
+
+ git config [--global] git-p4.detectRenames true
+ git config [--global] git-p4.detectRenames 50
+
+git-p4.detectCopies
+
+Detect copies when submitting changes to Perforce server. Will enable -C git
+argument. Can be optionally set to a number representing the threshold
+percentage value of the copy detection.
+
+ git config [--global] git-p4.detectCopies true
+ git config [--global] git-p4.detectCopies 80
+
+git-p4.detectCopiesHarder
+
+Detect copies even between files that did not change when submitting changes to
+Perforce server. Will enable --find-copies-harder git argument.
+
+ git config [--global] git-p4.detectCopies true
+
Implementation Details...
=========================
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 3/5] git-p4: Add test case for rename detection
From: Vitor Antunes @ 2011-08-22 8:33 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314001989-29017-1-git-send-email-vitor.hda@gmail.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9800-git-p4.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index 97ec975..5a5fd0f 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -269,6 +269,59 @@ test_expect_success 'initial import time from top change time' '
test $p4time = $gittime
'
+# Rename a file and confirm that rename is not detected in P4.
+# Rename the new file again with detectRenames option enabled and confirm that
+# this is detected in P4.
+# Rename the new file again adding an extra line, configure a big threshold in
+# detectRenames and confirm that rename is not detected in P4.
+# Repeat, this time with a smaller threshold and confirm that the rename is
+# detected in P4.
+test_expect_success 'detect renames' '
+ "$GITP4" clone --dest="$git" //depot@all &&
+ test_when_finished cleanup_git &&
+ cd "$git" &&
+ git config git-p4.skipSubmitEditCheck true &&
+
+ git mv file1 file4 &&
+ git commit -a -m "Rename file1 to file4" &&
+ git diff-tree -r -M HEAD &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file4 &&
+ ! p4 filelog //depot/file4 | grep -q "branch from" &&
+
+ git mv file4 file5 &&
+ git commit -a -m "Rename file4 to file5" &&
+ git diff-tree -r -M HEAD &&
+ git config git-p4.detectRenames true &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file5 &&
+ p4 filelog //depot/file5 | grep -q "branch from //depot/file4" &&
+
+ git mv file5 file6 &&
+ echo update >>file6 &&
+ git add file6 &&
+ git commit -a -m "Rename file5 to file6 with changes" &&
+ git diff-tree -r -M HEAD &&
+ level=$(git diff-tree -r -M HEAD | sed 1d | cut -f1 | cut -d" " -f5 | sed "s/R0*//") &&
+ test -n "$level" && test "$level" -gt 0 && test "$level" -lt 98 &&
+ git config git-p4.detectRenames $((level + 2)) &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file6 &&
+ ! p4 filelog //depot/file6 | grep -q "branch from" &&
+
+ git mv file6 file7 &&
+ echo update >>file7 &&
+ git add file7 &&
+ git commit -a -m "Rename file6 to file7 with changes" &&
+ git diff-tree -r -M HEAD &&
+ level=$(git diff-tree -r -M HEAD | sed 1d | cut -f1 | cut -d" " -f5 | sed "s/R0*//") &&
+ test -n "$level" && test "$level" -gt 2 && test "$level" -lt 100 &&
+ git config git-p4.detectRenames $((level - 2)) &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file7 &&
+ p4 filelog //depot/file7 | grep -q "branch from //depot/file6"
+'
+
test_expect_success 'shutdown' '
pid=`pgrep -f p4d` &&
test -n "$pid" &&
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 4/5] git-p4: Add test case for copy detection
From: Vitor Antunes @ 2011-08-22 8:33 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314001989-29017-1-git-send-email-vitor.hda@gmail.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9800-git-p4.sh | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index 5a5fd0f..9d4d4bf 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -322,6 +322,89 @@ test_expect_success 'detect renames' '
p4 filelog //depot/file7 | grep -q "branch from //depot/file6"
'
+# Copy a file and confirm that copy is not detected in P4.
+# Copy a file with detectCopies option enabled and confirm that copy is not
+# detected in P4.
+# Modify and copy a file with detectCopies option enabled and confirm that copy
+# is detected in P4.
+# Copy a file with detectCopies and detectCopiesHarder options enabled and
+# confirm that copy is detected in P4.
+# Modify and copy a file, configure a bigger threshold in detectCopies and
+# confirm that copy is not detected in P4.
+# Modify and copy a file, configure a smaller threshold in detectCopies and
+# confirm that copy is detected in P4.
+test_expect_success 'detect copies' '
+ "$GITP4" clone --dest="$git" //depot@all &&
+ test_when_finished cleanup_git &&
+ cd "$git" &&
+ git config git-p4.skipSubmitEditCheck true &&
+
+ cp file2 file8 &&
+ git add file8 &&
+ git commit -a -m "Copy file2 to file8" &&
+ git diff-tree -r -C HEAD &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file8 &&
+ ! p4 filelog //depot/file8 | grep -q "branch from" &&
+
+ cp file2 file9 &&
+ git add file9 &&
+ git commit -a -m "Copy file2 to file9" &&
+ git diff-tree -r -C HEAD &&
+ git config git-p4.detectCopies true &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file9 &&
+ ! p4 filelog //depot/file9 | grep -q "branch from" &&
+
+ echo "file2" >>file2 &&
+ cp file2 file10 &&
+ git add file2 file10 &&
+ git commit -a -m "Modify and copy file2 to file10" &&
+ git diff-tree -r -C HEAD &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file10 &&
+ p4 filelog //depot/file10 | grep -q "branch from //depot/file" &&
+
+ cp file2 file11 &&
+ git add file11 &&
+ git commit -a -m "Copy file2 to file11" &&
+ git diff-tree -r -C --find-copies-harder HEAD &&
+ src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) &&
+ test "$src" = file10 &&
+ git config git-p4.detectCopiesHarder true &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file11 &&
+ p4 filelog //depot/file11 | grep -q "branch from //depot/file" &&
+
+ cp file2 file12 &&
+ echo "some text" >>file12 &&
+ git add file12 &&
+ git commit -a -m "Copy file2 to file12 with changes" &&
+ git diff-tree -r -C --find-copies-harder HEAD &&
+ level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d" " -f5 | sed "s/C0*//") &&
+ test -n "$level" && test "$level" -gt 0 && test "$level" -lt 98 &&
+ src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) &&
+ test "$src" = file10 &&
+ git config git-p4.detectCopies $((level + 2)) &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file12 &&
+ ! p4 filelog //depot/file12 | grep -q "branch from" &&
+
+ cp file2 file13 &&
+ echo "different text" >>file13 &&
+ git add file13 &&
+ git commit -a -m "Copy file2 to file13 with changes" &&
+ git diff-tree -r -C --find-copies-harder HEAD &&
+ level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d" " -f5 | sed "s/C0*//") &&
+ test -n "$level" && test "$level" -gt 2 && test "$level" -lt 100 &&
+ src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) &&
+ test "$src" = file10 &&
+ git config git-p4.detectCopies $((level - 2)) &&
+ "$GITP4" submit &&
+ p4 filelog //depot/file13 &&
+ p4 filelog //depot/file13 | grep -q "branch from //depot/file"
+'
+
test_expect_success 'shutdown' '
pid=`pgrep -f p4d` &&
test -n "$pid" &&
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 5/5] git-p4: Process detectCopiesHarder with --bool
From: Vitor Antunes @ 2011-08-22 8:33 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Tor Arvid Lund, Vitor Antunes
In-Reply-To: <1314001989-29017-1-git-send-email-vitor.hda@gmail.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 29a5390f..0db3e72 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -789,7 +789,7 @@ class P4Submit(Command, P4UserMap):
elif detectCopies != "" and detectCopies.lower() != "false":
diffOpts += " -C%s" % detectCopies
- if gitConfig("git-p4.detectCopiesHarder").lower() == "true":
+ if gitConfig("git-p4.detectCopiesHarder", "--bool") == "true":
diffOpts += " --find-copies-harder"
diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (diffOpts, id, id))
--
1.7.5.4
^ permalink raw reply related
* Re: Merge after directory rename ?
From: Marcin Wiśnicki @ 2011-08-22 8:49 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <CAMOZ1Bsb7UxYOFpRWh47+130upfD9_E=CMQtZd1NyUWPwWiW4A@mail.gmail.com>
2011/8/22 Michael Witten <mfwitten@gmail.com>:
> I assume the smiley is tongue-in-cheek; however, in case it is not: It
> can't be automatic in general; did my examples mean nothing?
>
>> Or at least detect/warn about tree conflict.
>
> Did my examples mean nothing?
Well kind of. Your example was different because you have created dir1
independently on branch1 and master in which case automatic rename
wouldn't be expected. If you would've created dir1 before branching
and renamed dir1 to dir3 (renamed all files under dir1) then I would
expect a rename while merging.
The exact behaviour of merging branch1 to master I want is:
let base = $(git merge-base master branch1)
for each {modified,added,deleted} file in $base..branch1:
let dir = $(dirname $file)
if $dir exists in master:
if $dir existed in $base: [1]
proceed
else: # both branches independently introduced same directory
tree conflict
else: # no $dir in master
if $dir existed in $base:
if all $dir/* files in $base..master were renamed to $newdir/*:
rename $file [s/$dir/$newdir/]
else: # $dir was removed
tree conflict
else:
proceed # simple addition
Where "$dir exists" means that a file with path of matching prefix exists.
By default tree conflict should be ignored (proceed with merge as
today) but user should be able to make it fatal.
[1] It would be better if instead of comparing two trees it would
analyze each commit independently to detect shadowed renames:
(dir1=>dir2 then new dir1) => still rename.
>
>> Directory renames can happen quite frequently when working with Java/C#
>> and it is unreasonable to expect that lazy user will have to keep track of
>> it manually (with huge number of files it's impossible).
>
> Git doesn't know anything about Java/C#; that's the point.
And it shouldn't. Renames can happen with anything, I'm just pointing
out that they are quite frequent in Java/C#.
You might as well have a C project and rename directory "src" to
"sources" and, when merging branch created from before that, expect to
get automatic s/src/sources/.
> In general, the user could make use of switches (as suggested). In
> particular, perhaps there are merge hooks or merge drivers that could
> be used or implemented for allowing a more environment-specific
> handling of merges, a la GNU's ChangeLog merge driver:
> Also, see the configuration section of `git help merge'. Also look at
> the tool `git mergetool'.
>
Merge drivers are file type specific, mergetool is used to resolve
conflicts after merge and I don't see a pre-merge hook :(
^ permalink raw reply
* Re: git svn --stdlayout 's little quirk.
From: Michael J Gruber @ 2011-08-22 9:01 UTC (permalink / raw)
To: htl10; +Cc: Eric Wong, madduck, git
In-Reply-To: <1313919482.36626.YahooMailClassic@web29501.mail.ird.yahoo.com>
Hin-Tak Leung venit, vidit, dixit 21.08.2011 11:38:
> --- On Sat, 20/8/11, Eric Wong <normalperson@yhbt.net> wrote:
>
>>> I think I found a small bug in git 1.7.6. Having
>> "trunk" at the end of
>>> the url in combination of --stdlayout is wrong, but it
>> looks like that
>>> git-svn tries to cope, but doesn't go try far enough:
>>>
>>> Doing this:
>>> ----------------
>>> git svn clone --stdlayout http://quick-settings.googlecode.com/svn/trunk/
>> android-quick-settings
>>
>> --stdlayout expects the "root" path of the code you're
>> interested
>> in (not necessarily the SVN repository root, but in this
>> case they
>> could be the same).
>>
>> Try the following instead:
>>
>> git svn clone --stdlayout \
>> http://quick-settings.googlecode.com/svn
>> android-quick-settings
>
> I know this is the correct way - what I meant was that, having "trunk" at the end is wrong but git-svn appears to try to correct it automatically, but haven't quite succceeded.
It is not trying to do that at all. git-svn is trying to figure out what
the "base path" is in an svn repo which possibly hosts multiple repos,
and that is what the message reports.
Michael
^ permalink raw reply
* [PATCH v2 1/1] clone: replace relative paths in the alternates
From: Hui Wang @ 2011-08-22 9:05 UTC (permalink / raw)
To: gitster, git
In-Reply-To: <1314003957-9455-1-git-send-email-jason77.wang@gmail.com>
When we clone a local source repository to a new local destination
repository without "--shared" option, if source repository has
relative path in the alternates, the clone will fail.
The root cause is when cloning local source repository to local
destination repository, the alternates of the source repository
will be copied to the destination repository, the relative path in
the alternates is source repository to base repository rather than
destination repository to base repository, so the destination
repository get a wrong relative path in the alternates, this will
cause errors when refer to base repository in the destination
repository.
To fix it, adding a function update_alt_rel_path() to replace all
relative paths to absolute paths in the alternates of the destination
repository before destination repository use those paths to look for
the base repository.
Signed-off-by: Hui Wang <jason77.wang@gmail.com>
---
builtin/clone.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
cache.h | 1 +
sha1_file.c | 11 +++++++++++
3 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 7663bc2..7b5e603 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -286,6 +286,50 @@ static void copy_or_link_directory(struct strbuf *src, struct strbuf *dest)
closedir(dir);
}
+/*
+ * This function is called by clone_local() of clone.c
+ * If alternates in the src_repo (source repository) has relative path,
+ * call this function will replace the relative path to absolute path
+ * in the des_repo (destination repository) alternates.
+ */
+static void update_alt_rel_path(const char *src_repo)
+{
+ int need_update = 0;
+ FILE *ifp;
+ struct strbuf istr = STRBUF_INIT;
+ struct strbuf ostr = STRBUF_INIT;
+
+ ifp = fopen(git_path("objects/info/alternates"), "r");
+ if (!ifp)
+ return;
+
+ while (strbuf_getline(&istr, ifp, '\n') != EOF) {
+ /* comment line, empty line or absolute path line */
+ if (istr.buf[0] == '#' || istr.len == 0 || is_absolute_path(istr.buf)) {
+ strbuf_add(&ostr, istr.buf, istr.len);
+ strbuf_add(&ostr, "\n", 1);
+ } else {
+ char *abs_path, abs_buf[PATH_MAX];
+ int len;
+
+ abs_path = mkpath("%s/objects/%s", src_repo, istr.buf);
+ normalize_path_copy(abs_buf, abs_path);
+ len = strlen(abs_buf);
+ strbuf_add(&ostr, abs_buf, len);
+ strbuf_add(&ostr, "\n", 1);
+ need_update = 1;
+ }
+ }
+
+ fclose(ifp);
+
+ if (need_update)
+ update_alternates_file_content(ostr.buf);
+
+ strbuf_release(&istr);
+ strbuf_release(&ostr);
+}
+
static const struct ref *clone_local(const char *src_repo,
const char *dest_repo)
{
@@ -303,8 +347,9 @@ static const struct ref *clone_local(const char *src_repo,
copy_or_link_directory(&src, &dest);
strbuf_release(&src);
strbuf_release(&dest);
- }
+ update_alt_rel_path(src_repo);
+ }
remote = remote_get(src_repo);
transport = transport_get(remote, src_repo);
ret = transport_get_remote_refs(transport);
diff --git a/cache.h b/cache.h
index fcf4501..d81c0f0 100644
--- a/cache.h
+++ b/cache.h
@@ -913,6 +913,7 @@ extern struct alternate_object_database {
} *alt_odb_list;
extern void prepare_alt_odb(void);
extern void add_to_alternates_file(const char *reference);
+extern void update_alternates_file_content(const char *content);
typedef int alt_odb_fn(struct alternate_object_database *, void *);
extern void foreach_alt_odb(alt_odb_fn, void*);
diff --git a/sha1_file.c b/sha1_file.c
index d5616dc..dae7bf6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -388,6 +388,17 @@ void add_to_alternates_file(const char *reference)
link_alt_odb_entries(alt, alt + strlen(alt), '\n', NULL, 0);
}
+void update_alternates_file_content(const char *content)
+{
+ struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
+ int fd = hold_lock_file_for_update(lock, git_path("objects/info/alternates"), LOCK_DIE_ON_ERROR);
+ write_or_die(fd, content, strlen(content));
+ if (commit_lock_file(lock))
+ die("could not close alternates file");
+ if (alt_odb_tail)
+ link_alt_odb_entries(content, content + strlen(content), '\n', NULL, 0);
+}
+
void foreach_alt_odb(alt_odb_fn fn, void *cb)
{
struct alternate_object_database *ent;
--
1.7.6
^ permalink raw reply related
* [PATCH v2 0/1] git-clone: fix relative path problem in the alternates
From: Hui Wang @ 2011-08-22 9:05 UTC (permalink / raw)
To: gitster, git
Hi Junio,
In the V2 version, i use strbuf_xxxx() to help to parse alternates file
and change relative paths to absolute paths according to your suggestion,
now the strbuf operations are safer.
When updating new content to the lockfile, i choose to write whole content at
one time instead of update it line by line. The reason is:
1. we will conditionally update the lockfile, if original alternates doesn't
include relative path, we don't need to update the lockfile. This logic can't
easily be handled line by line.
2. current git system only provides add_to_alternates_file()in the sha1_file.c
to update lockfile, this function can add a line to lockfile but can't empty
and write lockfile, we need to add a similar function to empty and write to
lockfile, and we must guarantee the first line update will call this function,
then remaining update line call add_to_alternates_file(), this logic is a
little complicated comparing to update whole content at one time.
3. current existing add_to_alternates_file() will unconditionally append
"/objects" at each new added line, that need us to parse and remove
"/objects" from each line read out from source alternates, this is a little
bit complicated.
If we choose update lockfile at one time, we can add a new function to
implement this requirement and overcome all above complexity.
Hui Wang (1):
clone: replace relative paths in the alternates
builtin/clone.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
cache.h | 1 +
sha1_file.c | 11 +++++++++++
^ permalink raw reply
* [PATCH] Do not use C++-style comments
From: Michael Haggerty @ 2011-08-22 10:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johan Herland, Michael Haggerty
Detected by "gcc -std=iso9899:1990 ...". This patch applies against
"maint".
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
notes.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notes.c b/notes.c
index f6ce848..93e9868 100644
--- a/notes.c
+++ b/notes.c
@@ -1105,7 +1105,7 @@ int remove_note(struct notes_tree *t, const unsigned char *object_sha1)
hashcpy(l.key_sha1, object_sha1);
hashclr(l.val_sha1);
note_tree_remove(t, t->root, 0, &l);
- if (is_null_sha1(l.val_sha1)) // no note was removed
+ if (is_null_sha1(l.val_sha1)) /* no note was removed */
return 1;
t->dirty = 1;
return 0;
--
1.7.6.8.gd2879
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox