* Re: [PATCH 1/2] git-p4: Improve rename detection support.
From: Vitor Antunes @ 2011-02-06 12:39 UTC (permalink / raw)
To: Pete Wyckoff
In-Reply-To: <20110206002113.GA31245@arf.padd.com>
Hi Pete,
On Sun, Feb 6, 2011 at 12:21 AM, Pete Wyckoff <pw@padd.com> wrote:
> The comparisons confuse me. detectRenames != "false" > 0 ?
> How about just detectRenames == "true"?
The "> 0" was for the length check. I somehow (*feeling embarrassed*)
misplaced that code...
> You could rename the existing self.detectRename to add an "s" so
> it all makes a bit more sense.
>
> if not self.detectRenames:
> # not explicitly set, check the config variable
> b = gitConfig("git-p4.detectRenames")
> if b == "true":
> self.detectRenames = "-M"
>
> if self.detectRenames:
> diffOpts = "-M"
> else:
> diffOpts = ""
Seems like a better idea. I kind of like the original code to set
diffOpts, so I would prefer to keep it. What do you think of (didn't
test it):
if not self.detectRenames:
# If not explicitly set check the config variable
self.detectRenames =
gitConfig("git-p4.detectRenames").lower() == "true"
diffOpts = ("", "-M")[self.detectRenames]
>> diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (diffOpts, id, id))
>> filesToAdd = set()
>> filesToDelete = set()
>> @@ -640,7 +646,8 @@ class P4Submit(Command):
>> elif modifier == "R":
>> src, dest = diff['src'], diff['dst']
>> p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
>> - p4_system("edit \"%s\"" % (dest))
>> + if diff['src_sha1'] != diff['dst_sha1']:
>> + p4_system("edit \"%s\"" % (dest))
>> if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
>> filesToChangeExecBit[dest] = diff['dst_mode']
>> os.unlink(dest)
>
> If you rename the file and also cause its perms to change (say
> add +x), does it still work if dest is not open?
This is a very good point. I will also open the file for edit when
there is a mode change.
Thanks!
--
Vitor Antunes
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-06 17:28 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102061711.45460.johan@herland.net>
On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote:
> On Sunday 06 February 2011, Dmitry Potapov wrote:
> > On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote:
> > >_
> > >
> > > As long as they point to the same object, there's no ambiguity, and
> > > when you_ simply refer to tag "foo" (without specifying namespace) it
> > > all works, like_ today. (Read footnote [2] of my proposal for more
> > > details on handling_ ambiguity in tag names.)
> >_
> > I see no reason to create different namespaces, because semantically
> > there is only one namespace.
>_
> In practice, there is almost always one namespace (i.e. your repo belongs to_
> only one project with project-wide unique tags). However, in any distributed_
> system, the only-one-namespace is fundamentally a myth.
By your logic git 1.7.4 is a myth, because I have not specified from
what repository I pull it. But, IMHO, it is a myth that having different
namespaces solves the problem, because in _most_ cases, you really want
to have a single namespace _semantically_, so you can communicate with
other people using this tag name. In your case of semi-related projects,
it should be two namespaces, because there are _two_ different projects
(even if they share a lot of common history). How do I know that they
are different? Because they have different release schedulers, and v1.0
means different for each of them.
> > To me, the proper handling ambiguity means that when I do "git fetch" I
> > immediately see warning about tag clashes. So, I agree with you that
> > current behavior is not good, but I disagree with you about having many
> > namespaces, because it postpones detection of the conflict until I try
> > to use. And well, git may detect ambiguity when I say "git show v1.0",
> > but if I look at my branch in gitk and see "v1.0" and may say to someone
> > that I use "v1.0" but that person looks at his tree and sees "v1.0" as
> > something different.
>_
> In that case it would be wrong of gitk to display "v1.0". Instead it should_
> display a longer, unambiguous name, e.g. "origin/v1.0".
But it is still ambiguous because my "origin" may be different from
yours origin. It is only unambiguous when it look at it _locally_ but
that makes it completely useless for communication with other people.
One project should have only one version with the same tag regardless
where it came from.
I agree in your use case of semi-related projects you need separate
namespaces. But I don't think it is how most people use git. It may
be nice to have an option that will make tag namespace separate, but
I do not think it should be default. Not until, it is widely tested.
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] git-p4: Add copy detection support
From: Vitor Antunes @ 2011-02-06 17:25 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20110206002547.GB31245@arf.padd.com>
Hi Pete,
On Sun, Feb 6, 2011 at 12:25 AM, Pete Wyckoff <pw@padd.com> wrote:
> You can use integrate -t to force the filetype even if the file
> already existed, and skip the whole execbit change.
(Copying help text:
The -t flag makes the source file's filetype propagate to the target
file. Normally, the target file retains its previous filetype.
Newly branched files always use the source file's filetype. The
filetype can still be changed before 'p4 submit' with 'p4 reopen'.
)
Since in git we're only considering newly branched files, I think in
this case "-t" will not add anything. In fact, what is being done here
is detecting exec bit changes from source to target files - we're not
trying to force P4 to use the source's exec bit. Do you agree?
Kind regards,
--
Vitor Antunes
^ permalink raw reply
* [PATCH] git-gui: instead of defaulting to home directory use working directory
From: Heiko Voigt @ 2011-02-06 17:22 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Jens Lehmann, git
When starting git gui in a non-git directory it presents the user a
dialog which asks to create, clone or open a repository. The filedialogs
used to choose the path(s) would always default to the home directory of
the user. This patch changes this behavior and uses the current working
directory in which git gui was started as default.
This is useful in various cases. First being that the user starts the
gui in some directory and can go search to create, open or clone a
repository from there. Another use case is that tools like filemanager
context menues can transport a natural default when selected from a
folder.
Users who like to have their home folder as a default can fall back on
starting git gui with its working directory set to the home folder.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
lib/choose_repository.tcl | 14 +++-----------
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index fae1192..657f7d5 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -214,14 +214,6 @@ constructor pick {} {
}
}
-proc _home {} {
- if {[catch {set h $::env(HOME)}]
- || ![file isdirectory $h]} {
- set h .
- }
- return $h
-}
-
method _center {} {
set nx [winfo reqwidth $top]
set ny [winfo reqheight $top]
@@ -420,7 +412,7 @@ method _new_local_path {} {
if {$local_path ne {}} {
set p [file dirname $local_path]
} else {
- set p [_home]
+ set p [pwd]
}
set p [tk_chooseDirectory \
@@ -541,7 +533,7 @@ method _open_origin {} {
if {$origin_url ne {} && [file isdirectory $origin_url]} {
set p $origin_url
} else {
- set p [_home]
+ set p [pwd]
}
set p [tk_chooseDirectory \
@@ -1042,7 +1034,7 @@ method _open_local_path {} {
if {$local_path ne {}} {
set p $local_path
} else {
- set p [_home]
+ set p [pwd]
}
set p [tk_chooseDirectory \
--
1.7.4.34.gd2cb1
^ permalink raw reply related
* [PATCH] git-gui: scroll down to default selection for push dialog
From: Heiko Voigt @ 2011-02-06 17:04 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Jens Lehmann, git
If the list of remote/local branches is very long its inconvenient
to scroll down and find the selected branch. This patch makes the
widget automatically scroll down so its shown on the top.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Note: Please also apply with 'git am -p2'
git-gui/lib/transport.tcl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/lib/transport.tcl b/git-gui/lib/transport.tcl
index e4e1add..6478efa 100644
--- a/git-gui/lib/transport.tcl
+++ b/git-gui/lib/transport.tcl
@@ -211,6 +211,7 @@ proc do_push_anywhere {} {
$w.source.l insert end $h
if {$h eq $current_branch} {
$w.source.l select set end
+ $w.source.l yview end
}
}
pack $w.source.l -side left -fill both -expand 1
--
1.7.4.34.gd2cb1
^ permalink raw reply related
* [PATCH] git gui: keep selected branch when remote is changed in push dialog
From: Heiko Voigt @ 2011-02-06 17:01 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Jens Lehmann, git
The selection of the branch to be pushed would be cleared when
the remote was changed. This seems to be dependent on the fact that
the selected content in the combobox was exported to the clipboard. It
was only apparent when using the new ttk widget.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Note: This patch was created inside the official git repo but should
apply cleanly to git-gui's master using 'git am -p2'
git-gui/lib/transport.tcl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/transport.tcl b/git-gui/lib/transport.tcl
index 49155c7..e4e1add 100644
--- a/git-gui/lib/transport.tcl
+++ b/git-gui/lib/transport.tcl
@@ -223,7 +223,9 @@ proc do_push_anywhere {} {
-value remote \
-variable push_urltype
if {$use_ttk} {
- ttk::combobox $w.dest.remote_m -textvariable push_remote \
+ ttk::combobox $w.dest.remote_m -state readonly \
+ -exportselection false \
+ -textvariable push_remote \
-values $all_remotes
} else {
eval tk_optionMenu $w.dest.remote_m push_remote $all_remotes
--
1.7.4.34.gd2cb1
^ permalink raw reply related
* Re: ignoring file modes completely
From: Rafael Kitover @ 2011-02-06 16:14 UTC (permalink / raw)
To: git
In-Reply-To: <4D4EC3FD.5010000@io.com>
On 2/6/2011 10:53 AM, Rafael Kitover wrote:
> On 2/6/2011 8:14 AM, Michael J Gruber wrote:
>> Rafael Kitover venit, vidit, dixit 05.02.2011 20:28:
>>> On 2/5/2011 11:58 AM, Andreas Ericsson wrote:
>>>> On 02/05/2011 05:09 PM, Rafael Kitover wrote:
>>>>> On 2/5/2011 11:03 AM, Jared Hance wrote:
>>>>>> On Sat, 2011-02-05 at 10:24 -0500, Rafael Kitover wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I found the core.filemode option, which ignores executable bits,
>>>>>>> but I
>>>>>>> need an option to ignore all mode differences, and such an option
>>>>>>> does
>>>>>>> not seem to exist.
>>>>>>
>>>>>> The only mode tracked by Git is the executable bit, so this shouldn't
>>>>>> even be an issue. Are you sure the executable bit isn't the problem?
>>>>>>
>>>>> $ git config --global core.filemode
>>>>> false
>>>>>
>>>>> Output of "git diff HEAD" :
>>>>>
>>>>> diff --git a/Makefile.PL b/Makefile.PL
>>>>> old mode 100755
>>>>> new mode 100644
>>>>> diff --git a/t/02ads.t b/t/02ads.t
>>>>> old mode 100755
>>>>> new mode 100644
>>>>> diff --git a/t/02cxn.t b/t/02cxn.t
>>>>> old mode 100755
>>>>> new mode 100644
>>>>> diff --git a/t/04os.t b/t/04os.t
>>>>> old mode 100755
>>>>> new mode 100644
>>>>
>>>> Those are all executable bit diffs.
>>>>
>>>
>>> Ok, but I have core.filemode set to "false" as I showed, why does this
>>> happen then?
>>
>> I can't confirm this on linux with current git. What are your versions?
>> Do you have a minimal example (starting from git init)?
>
> This is msysGit:
>
> $ git --version
> git version 1.7.3.1
>
> I can't replicate this with just "git init" and a file, it seems to
> happen when I use "git cpan-init" in Cygwin then look at the repo in
> msysGit.
Actually, I can replicate this in Cygwin git:
$ git --version
git version 1.7.3.3
$ cd ~/src
$ mkdir test-repo
$ cd test-repo
$ git init
$ touch README
$ git add README
$ git commit -a -m'test commit'
$ git diff HEAD
$ chmod +x README
$ git diff HEAD
diff --git a/README b/README
old mode 100644
new mode 100755
$ git config --global core.filemode
false
The way the executable bit works seems to be different between Cygwin
and msys, but in either case core.filemode seems to not be working properly.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-06 16:11 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <AANLkTikmD8qZOE+hi1=aeeVJx2qQpzdm0tV1mLsx1tfB@mail.gmail.com>
On Sunday 06 February 2011, Dmitry Potapov wrote:
> On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote:
> >_
> >
> > As long as they point to the same object, there's no ambiguity, and
> > when you_ simply refer to tag "foo" (without specifying namespace) it
> > all works, like_ today. (Read footnote [2] of my proposal for more
> > details on handling_ ambiguity in tag names.)
>
> I see no reason to create different namespaces, because semantically
> there is only one namespace.
In practice, there is almost always one namespace (i.e. your repo belongs to
only one project with project-wide unique tags). However, in any distributed
system, the only-one-namespace is fundamentally a myth. Sure, it's a
convenient myth, and one that we - with good reason - strive towards
fulfilling, but there are situations (described earlier in this thread)
where the myth is busted. In those situations, I think the _least_ confusing
thing we can do for our users is to handle all remote refs consistently, and
allow them to discover/investigate the remote tags as they would other
remote refs.
> > However, when the remote tags point to different objects (i.e. the
> > uncommon_ case), there is an ambiguity, and we should deal with that
> > ambiguity_ properly, instead of silently adopting one of them
> > arbitrarily.
>
> To me, the proper handling ambiguity means that when I do "git fetch" I
> immediately see warning about tag clashes. So, I agree with you that
> current behavior is not good, but I disagree with you about having many
> namespaces, because it postpones detection of the conflict until I try
> to use. And well, git may detect ambiguity when I say "git show v1.0",
> but if I look at my branch in gitk and see "v1.0" and may say to someone
> that I use "v1.0" but that person looks at his tree and sees "v1.0" as
> something different.
In that case it would be wrong of gitk to display "v1.0". Instead it should
display a longer, unambiguous name, e.g. "origin/v1.0".
> So, if there is two different tags with the same name, it is better to
> report the problem as soon as possible, i.e. during "git fetch", and
> then there is no reason to have separate namespaces for tags.
Yes, that is an alternative solution for tags. I guess it comes down to a
question of how much special treatment we want to give tags. I'd rather have
consistency between how tags and other remote refs are handled.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: ignoring file modes completely
From: Rafael Kitover @ 2011-02-06 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <4D4E9EAC.4030508@drmicha.warpmail.net>
On 2/6/2011 8:14 AM, Michael J Gruber wrote:
> Rafael Kitover venit, vidit, dixit 05.02.2011 20:28:
>> On 2/5/2011 11:58 AM, Andreas Ericsson wrote:
>>> On 02/05/2011 05:09 PM, Rafael Kitover wrote:
>>>> On 2/5/2011 11:03 AM, Jared Hance wrote:
>>>>> On Sat, 2011-02-05 at 10:24 -0500, Rafael Kitover wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I found the core.filemode option, which ignores executable bits, but I
>>>>>> need an option to ignore all mode differences, and such an option does
>>>>>> not seem to exist.
>>>>>
>>>>> The only mode tracked by Git is the executable bit, so this shouldn't
>>>>> even be an issue. Are you sure the executable bit isn't the problem?
>>>>>
>>>> $ git config --global core.filemode
>>>> false
>>>>
>>>> Output of "git diff HEAD" :
>>>>
>>>> diff --git a/Makefile.PL b/Makefile.PL
>>>> old mode 100755
>>>> new mode 100644
>>>> diff --git a/t/02ads.t b/t/02ads.t
>>>> old mode 100755
>>>> new mode 100644
>>>> diff --git a/t/02cxn.t b/t/02cxn.t
>>>> old mode 100755
>>>> new mode 100644
>>>> diff --git a/t/04os.t b/t/04os.t
>>>> old mode 100755
>>>> new mode 100644
>>>
>>> Those are all executable bit diffs.
>>>
>>
>> Ok, but I have core.filemode set to "false" as I showed, why does this
>> happen then?
>
> I can't confirm this on linux with current git. What are your versions?
> Do you have a minimal example (starting from git init)?
This is msysGit:
$ git --version
git version 1.7.3.1
I can't replicate this with just "git init" and a file, it seems to
happen when I use "git cpan-init" in Cygwin then look at the repo in
msysGit.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-06 15:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johan Herland, git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy
In-Reply-To: <alpine.LFD.2.00.1102060900570.12104@xanadu.home>
On Sun, Feb 06, 2011 at 09:09:26AM -0500, Nicolas Pitre wrote:
> On Sun, 6 Feb 2011, Dmitry Potapov wrote:
>_
> > To me, the proper handling ambiguity means that when I do "git fetch" I
> > immediately see warning about tag clashes.
>_
> Fair enough.
>_
> > So, I agree with you that
> > current behavior is not good, but I disagree with you about having many
> > namespaces, because it postpones detection of the conflict until I try
> > to use.
>_
> No. The later does not prevent the former.
But what if I really have two semi-related projects that I want to fetch
into the same repository as Johan suggested? In this case, I want to
have separate namespaces and no warning when I fetch.
>_
> Of course there is a reason. What if your fetch brings in hundreds of_
> tags (this is common for some projects) and then you want to remove that_
> fetched branch from your repository? How do you determine which tag_
> came from that remote repository and which tags are to be kept? Without_
> a separate namespace this is practically impossible.
Well, I see your use case now. Maybe the right solution is add an option
that will tell whether to fetch tags into separate namespace or not, and
later based on experiences, we can decide whether we want to change the
default to have separate namespaces for tags.
Dmitry
^ permalink raw reply
* [PATCH] send-email: add 'specify-author' option
From: Felipe Contreras @ 2011-02-06 14:44 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
From: Felipe Contreras <felipe.contreras@gmail.com>
Always specify the author of the commit in the body of the message, even
if the committer is the author.
This is useful if the 'From' header is mangled by some mail server.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-send-email.txt | 4 ++++
git-send-email.perl | 7 ++++++-
t/t9001-send-email.sh | 12 ++++++++++++
3 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 7ec9dab..5895835 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -125,6 +125,10 @@ The --to option must be repeated for each user you want on the to list.
+
Note that no attempts whatsoever are made to validate the encoding.
+--specify-author::
+ Always specify the author of the commit in the body of the message,
+ even if the committer is the author. This is useful if the 'From'
+ header is mangled by some mail server.
Sending
~~~~~~~
diff --git a/git-send-email.perl b/git-send-email.perl
index 76565de..30f27ff 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -57,6 +57,8 @@ git send-email [options] <file | directory | rev-list options >
--annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
--8bit-encoding <str> * Encoding to assume 8bit mails if undeclared
+ --specify-author * Always specify the author of the commit in
+ the body of the message.
Sending:
--envelope-sender <str> * Email envelope sender.
@@ -198,6 +200,7 @@ my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
my ($validate, $confirm);
my (@suppress_cc);
my ($auto_8bit_encoding);
+my ($specify_author);
my ($debug_net_smtp) = 0; # Net::SMTP, see send_message()
@@ -210,6 +213,7 @@ my %config_bool_settings = (
"signedoffbycc" => [\$signed_off_by_cc, undef],
"signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
"validate" => [\$validate, 1],
+ "specifyauthor" => [\$specify_author, undef],
);
my %config_settings = (
@@ -311,6 +315,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"format-patch!" => \$format_patch,
"8bit-encoding=s" => \$auto_8bit_encoding,
"force" => \$force,
+ "specify-author!" => \$specify_author,
);
unless ($rc) {
@@ -1285,7 +1290,7 @@ foreach my $t (@files) {
$subject = quote_rfc2047($subject, $auto_8bit_encoding);
}
- if (defined $author and $author ne $sender) {
+ if (defined $author and ($author ne $sender or $specify_author)) {
$message = "From: $author\n\n$message";
if (defined $author_encoding) {
if ($has_content_type) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 579ddb7..66d2541 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -280,6 +280,18 @@ test_expect_success $PREREQ 'Author From: not in message body' '
! grep "From: A <author@example.com>" msgbody1
'
+test_expect_success $PREREQ 'Author From: in message body (forced)' '
+ clean_fake_sendmail &&
+ git send-email \
+ --from="A <author@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --specify-author \
+ $patches &&
+ sed "1,/^\$/d" < msgtxt1 > msgbody1 &&
+ grep "From: A <author@example.com>" msgbody1
+'
+
test_expect_success $PREREQ 'allow long lines with --no-validate' '
git send-email \
--from="Example <nobody@example.com>" \
--
1.7.4.1.gf4271.dirty
^ permalink raw reply related
* git-new-workdir for filesystems without links (e.g. FAT32)?
From: Piotr Krukowiecki @ 2011-02-06 14:20 UTC (permalink / raw)
To: git
Hi,
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?
Since git-new-workdir just uses soft links it should be possible to implement it
natively in git. Maybe there some patches for this?
I need it because I'm using FAT32 on my dual-boot computer to share data between
windows and linux.
Thanks,
--
Piotr Krukowiecki
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nicolas Pitre @ 2011-02-06 14:09 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johan Herland, git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy
In-Reply-To: <AANLkTikmD8qZOE+hi1=aeeVJx2qQpzdm0tV1mLsx1tfB@mail.gmail.com>
On Sun, 6 Feb 2011, Dmitry Potapov wrote:
> To me, the proper handling ambiguity means that when I do "git fetch" I
> immediately see warning about tag clashes.
Fair enough.
> So, I agree with you that
> current behavior is not good, but I disagree with you about having many
> namespaces, because it postpones detection of the conflict until I try
> to use.
No. The later does not prevent the former.
> And well, git may detect ambiguity when I say "git show v1.0",
> but if I look at my branch in gitk and see "v1.0" and may say to someone
> that I use "v1.0" but that person looks at his tree and sees "v1.0" as
> something different.
If gitk is smart enough to see that two tags have the same name then it
should scope them so they are not ambiguous anymore, unless of course
they are referring to the same thing in which case they are not
ambiguous from the start.
> So, if there is two different tags with the same name, it is better to
> report the problem as soon as possible, i.e. during "git fetch", and
> then there is no reason to have separate namespaces for tags.
Of course there is a reason. What if your fetch brings in hundreds of
tags (this is common for some projects) and then you want to remove that
fetched branch from your repository? How do you determine which tag
came from that remote repository and which tags are to be kept? Without
a separate namespace this is practically impossible.
Nicolas
^ permalink raw reply
* Re: ignoring file modes completely
From: Michael J Gruber @ 2011-02-06 13:14 UTC (permalink / raw)
To: rkitover; +Cc: git, Andreas Ericsson, jaredhance
In-Reply-To: <4D4DA4C1.5050501@io.com>
Rafael Kitover venit, vidit, dixit 05.02.2011 20:28:
> On 2/5/2011 11:58 AM, Andreas Ericsson wrote:
>> On 02/05/2011 05:09 PM, Rafael Kitover wrote:
>>> On 2/5/2011 11:03 AM, Jared Hance wrote:
>>>> On Sat, 2011-02-05 at 10:24 -0500, Rafael Kitover wrote:
>>>>> Hello,
>>>>>
>>>>> I found the core.filemode option, which ignores executable bits, but I
>>>>> need an option to ignore all mode differences, and such an option does
>>>>> not seem to exist.
>>>>
>>>> The only mode tracked by Git is the executable bit, so this shouldn't
>>>> even be an issue. Are you sure the executable bit isn't the problem?
>>>>
>>> $ git config --global core.filemode
>>> false
>>>
>>> Output of "git diff HEAD" :
>>>
>>> diff --git a/Makefile.PL b/Makefile.PL
>>> old mode 100755
>>> new mode 100644
>>> diff --git a/t/02ads.t b/t/02ads.t
>>> old mode 100755
>>> new mode 100644
>>> diff --git a/t/02cxn.t b/t/02cxn.t
>>> old mode 100755
>>> new mode 100644
>>> diff --git a/t/04os.t b/t/04os.t
>>> old mode 100755
>>> new mode 100644
>>
>> Those are all executable bit diffs.
>>
>
> Ok, but I have core.filemode set to "false" as I showed, why does this
> happen then?
I can't confirm this on linux with current git. What are your versions?
Do you have a minimal example (starting from git init)?
Michael
BTW: Leaving out helpful folks from cc does not help... I should not
have to re-add them by hand.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-06 12:03 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102060104.37146.johan@herland.net>
On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote:
>_
> As long as they point to the same object, there's no ambiguity, and when you_
> simply refer to tag "foo" (without specifying namespace) it all works, like_
> today. (Read footnote [2] of my proposal for more details on handling_
> ambiguity in tag names.)
I see no reason to create different namespaces, because semantically
there is only one namespace.
> However, when the remote tags point to different objects (i.e. the uncommon_
> case), there is an ambiguity, and we should deal with that ambiguity_
> properly, instead of silently adopting one of them arbitrarily.
To me, the proper handling ambiguity means that when I do "git fetch" I
immediately see warning about tag clashes. So, I agree with you that
current behavior is not good, but I disagree with you about having many
namespaces, because it postpones detection of the conflict until I try
to use. And well, git may detect ambiguity when I say "git show v1.0",
but if I look at my branch in gitk and see "v1.0" and may say to someone
that I use "v1.0" but that person looks at his tree and sees "v1.0" as
something different.
So, if there is two different tags with the same name, it is better to
report the problem as soon as possible, i.e. during "git fetch", and
then there is no reason to have separate namespaces for tags.
Dmitry
^ permalink raw reply
* [idea] Re: separate .git dir and the working tree
From: Nicolas Sebrecht @ 2011-02-06 10:55 UTC (permalink / raw)
To: git, redstun, Jonathan Nieder; +Cc: Nicolas Sebrecht
In-Reply-To: <20110206004013.GB13594@mg1>
The 05/02/11, Mike Gant wrote:
> So does anyone use Mutt? And do they know a recipe to move the sender
> address to the cc list? If not, I'll figure it out.
g (group answer).
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [idea] separate .git dir and the working tree
From: Konstantin Khomoutov @ 2011-02-06 10:49 UTC (permalink / raw)
To: Jared Hance; +Cc: Mike Gant, git, redstun, Jonathan Nieder
In-Reply-To: <1296954015.4048.0.camel@localhost.localdomain>
On Sat, Feb 05, 2011 at 08:00:15PM -0500, Jared Hance wrote:
> > > My apologies, but I didn't see a cc list in the original. Please
> > > explain.
> > Never mind, I think I understand.
> > So does anyone use Mutt? And do they know a recipe to move the sender
> > address to the cc list? If not, I'll figure it out.
> When I used Mutt, if I remember correctly, L did the job (list reply).
Also "g" is "group reply" -- it simply replies to all e-mails mentioned
in the mail which is being replied to.
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Jeff King @ 2011-02-06 5:13 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: Git ML
In-Reply-To: <4D4DEDC4.4080708@hartwork.org>
On Sun, Feb 06, 2011 at 01:39:32AM +0100, Sebastian Pipping wrote:
> I just ran into case where
>
> git add -u
>
> repetedly did not update the index. In contrast, picking stuff using
>
> git add -p
>
> works just fine.
>
> Could it be "git add -u" is broken in git 1.7.4?
It could be. However, I can think of one such case where you might see
that behavior. "git add -u" operates from the current subdirectory,
whereas "git add -p" operates from the top of the project tree (yes,
this inconsistency confusing, but it's not as serious as "git add -u
doesn't work").
You can demonstrate it with:
mkdir repo && cd repo && git init
mkdir subdir && echo content >file
git add . && git commit -m base
echo more >>file
mkdir subdir && cd subdir
git add -u
git status ;# still not staged for commit
git add -p ;# finds it
Might you have been in a subdirectory of the project when you saw this
behavior?
-Peff
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Nguyen Thai Ngoc Duy @ 2011-02-06 4:42 UTC (permalink / raw)
To: thomas; +Cc: Jakub Narebski, git
In-Reply-To: <201102051931.10979.thomas@koch.ro>
On Sun, Feb 6, 2011 at 1:31 AM, Thomas Koch <thomas@koch.ro> wrote:
> Jakub Narebski:
>> there is (supposedly) problem when checking out such tree (see email
>> referenced above) with an old git.
> Proposal:
>
(Elaborate the "handle" part from your first item)
- Teach diff machinery about empty trees. At least diff-tree should
show empty tree addition/removal. diff-index and diff-files can learn
later when index supports empty trees.
- Teach merge empty trees.
> - Implement the possibility to checkout/read/handle empty directories as soon
> as possible, even in the next 1.7.x release.
> - Don't implement the possibility to create/commit empty directories yet.
> - Implement the possibility to checkin empty directories next year, but allow
> it only, if the user knows that this breaks backwards compatibility of the
> repo. (Generate warning and require --commit-empty-directories option)
--
Duy
^ permalink raw reply
* Re: [idea] separate .git dir and the working tree
From: Jared Hance @ 2011-02-06 1:00 UTC (permalink / raw)
To: Mike Gant; +Cc: git, redstun, Jonathan Nieder
In-Reply-To: <20110206004013.GB13594@mg1>
On Sat, 2011-02-05 at 17:40 -0700, Mike Gant wrote:
> On Sat, Feb 05, 2011 at 05:20:09PM -0700, Mike Gant wrote:
> > On Sat, Feb 05, 2011 at 07:27:08AM -0600, Jonathan Nieder wrote:
> > > (restoring cc list; please do not cull cc's)
> >
> > My apologies, but I didn't see a cc list in the original. Please
> > explain.
> >
> > -Mike
>
> Never mind, I think I understand.
>
> So does anyone use Mutt? And do they know a recipe to move the sender
> address to the cc list? If not, I'll figure it out.
>
> Thanks,
> -Mike
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
When I used Mutt, if I remember correctly, L did the job (list reply).
^ permalink raw reply
* [PATCH] bundle: Use OFS_DELTA in bundle files
From: Shawn O. Pearce @ 2011-02-06 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-bundle first appeared in 2e0afafe ("Add git-bundle") in Feb 2007,
and first shipped in Git 1.5.1.
However, OFS_DELTA is an even earlier invention, coming about in
eb32d236 ("introduce delta objects with offset to base") in Sep 2006,
and first shipped in Git 1.4.4.5.
OFS_DELTA is smaller, about 3.2%-5% smaller, and is typically faster
to access than REF_DELTA because the exact location of the delta base
is available after parsing the object header. Since all bundle aware
versions of Git are also OFS_DELTA aware, just make it the default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
bundle.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65ea26b..f48fd7d 100644
--- a/bundle.c
+++ b/bundle.c
@@ -200,7 +200,7 @@ int create_bundle(struct bundle_header *header, const char *path,
int bundle_fd = -1;
int bundle_to_stdout;
const char **argv_boundary = xmalloc((argc + 4) * sizeof(const char *));
- const char **argv_pack = xmalloc(5 * sizeof(const char *));
+ const char **argv_pack = xmalloc(6 * sizeof(const char *));
int i, ref_count = 0;
char buffer[1024];
struct rev_info revs;
@@ -346,7 +346,8 @@ int create_bundle(struct bundle_header *header, const char *path,
argv_pack[1] = "--all-progress-implied";
argv_pack[2] = "--stdout";
argv_pack[3] = "--thin";
- argv_pack[4] = NULL;
+ argv_pack[4] = "--delta-base-offset";
+ argv_pack[5] = NULL;
memset(&rls, 0, sizeof(rls));
rls.argv = argv_pack;
rls.in = -1;
--
1.7.4.rc3.268.g2af8b
^ permalink raw reply related
* Re: [idea] separate .git dir and the working tree
From: Mike Gant @ 2011-02-06 0:40 UTC (permalink / raw)
To: git; +Cc: redstun, Jonathan Nieder
In-Reply-To: <20110206002009.GA13594@mg1>
On Sat, Feb 05, 2011 at 05:20:09PM -0700, Mike Gant wrote:
> On Sat, Feb 05, 2011 at 07:27:08AM -0600, Jonathan Nieder wrote:
> > (restoring cc list; please do not cull cc's)
>
> My apologies, but I didn't see a cc list in the original. Please
> explain.
>
> -Mike
Never mind, I think I understand.
So does anyone use Mutt? And do they know a recipe to move the sender
address to the cc list? If not, I'll figure it out.
Thanks,
-Mike
^ permalink raw reply
* "git add -u" broken in git 1.7.4?
From: Sebastian Pipping @ 2011-02-06 0:39 UTC (permalink / raw)
To: Git ML
Hello!
I just ran into case where
git add -u
repetedly did not update the index. In contrast, picking stuff using
git add -p
works just fine.
Could it be "git add -u" is broken in git 1.7.4?
Best,
Sebastian
^ permalink raw reply
* Re: [PATCH 2/2] git-p4: Add copy detection support
From: Pete Wyckoff @ 2011-02-06 0:25 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <1296429563-18390-2-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Sun, 30 Jan 2011 23:19 +0000:
> Add new config options:
> git-p4.detectCopies - Enable copy detection.
> git-p4.detectCopiesHarder - Find copies harder.
> The detectCopies option should be set to a true/false value.
> The detectCopiesHarder option should be set to true/false value.
> P4Submit can now process diff-tree C status and integrate files accordingly.
> ---
[..]
> + detectCopies = gitConfig("git-p4.detectCopies")
> + if len(detectCopies) and detectCopies.lower() != "false" > 0:
> + diffOpts += " -C"
> +
> + detectCopiesHarder = gitConfig("git-p4.detectCopiesHarder")
> + if len(detectCopiesHarder) > 0 and detectCopiesHarder.lower() != "false":
> + diffOpts += " --find-copies-harder"
> +
I like it, but same weirdness with != > 0.
> + elif modifier == "C":
> + src, dest = diff['src'], diff['dst']
> + p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
> + if diff['src_sha1'] != diff['dst_sha1']:
> + p4_system("edit \"%s\"" % (dest))
> + if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
> + filesToChangeExecBit[dest] = diff['dst_mode']
> + os.unlink(dest)
> + editedFiles.add(dest)
You can use integrate -t to force the filetype even if the file
already existed, and skip the whole execbit change.
-- Pete
^ permalink raw reply
* Re: [PATCH 1/2] git-p4: Improve rename detection support.
From: Pete Wyckoff @ 2011-02-06 0:21 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <1296429563-18390-1-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Sun, 30 Jan 2011 23:19 +0000:
> Only open files for edit after integrating if the SHA1 of source and destination
> differ from each other.
> Add git config option detectRenames to allow permanent rename detection. This
> options should be set to a true/false value.
I like the idea.
> def applyCommit(self, id):
> print "Applying %s" % (read_pipe("git log --max-count=1 --pretty=oneline %s" % id))
> - diffOpts = ("", "-M")[self.detectRename]
> +
> + detectRenames = gitConfig("git-p4.detectRenames")
> + if len(detectRenames) and detectRenames.lower() != "false" > 0:
> + diffOpts = "-M"
> + else:
> + diffOpts = ("", "-M")[self.detectRename]
The comparisons confuse me. detectRenames != "false" > 0 ?
How about just detectRenames == "true"?
You could rename the existing self.detectRename to add an "s" so
it all makes a bit more sense.
if not self.detectRenames:
# not explicitly set, check the config variable
b = gitConfig("git-p4.detectRenames")
if b == "true":
self.detectRenames = "-M"
if self.detectRenames:
diffOpts = "-M"
else:
diffOpts = ""
> diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (diffOpts, id, id))
> filesToAdd = set()
> filesToDelete = set()
> @@ -640,7 +646,8 @@ class P4Submit(Command):
> elif modifier == "R":
> src, dest = diff['src'], diff['dst']
> p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
> - p4_system("edit \"%s\"" % (dest))
> + if diff['src_sha1'] != diff['dst_sha1']:
> + p4_system("edit \"%s\"" % (dest))
> if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
> filesToChangeExecBit[dest] = diff['dst_mode']
> os.unlink(dest)
If you rename the file and also cause its perms to change (say
add +x), does it still work if dest is not open?
-- Pete
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox