* Re: [PATCH] git-send-email.perl: expand filename of aliasesfile
From: Matthieu Moy @ 2011-09-28 13:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong
In-Reply-To: <20110928131307.GB12586@laptop>
Cord Seele <cowose@googlemail.com> writes:
> - open my $fh, '<', $file or die "opening $file: $!\n";
> + open my $fh, '<', glob($file) or die "opening $file: $!\n";
That'd be cleaner to use
git config --path sendemail.aliasesfile
to let Git do the right expansion, in a way consistant with other places
of Git.
In practice, that would imply adding %config_path_settings like the
existing %config_bool_settings, and add config_path to Git.pm (again,
similarly to config_bool).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-28 13:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Philip Oakley, Eric Raible, Michael J Gruber,
Carlos Martín Nieto, vra5107, git
In-Reply-To: <7vpqiltsky.fsf@alter.siamese.dyndns.org>
On Wed, Sep 28, 2011 at 00:32, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Tue, Sep 27, 2011 at 11:28:14PM +0000, Michael Witten wrote:
>>
>>> With "git commit --no-parent", you would be altering the current
>>> branch head, which means you are potentially leaving as a dangling
>>> commit the commit to which that branch head originally pointed.
>>> I.e., it is about as dangerous as "git reset --hard <new_root_commit>",
>>> something for which we do NOT provide any protection.
>>
>> Didn't I already mention that example? And then say that I think the
>> lack of protection there has been the source of a lot of confusion and
>> hardship?
>>
>> Repeating the problems of "git reset" does not seem like a good idea to
>> me. Especially not with a command like "commit", which is usually very
>> safe.
>>
>> That being said, I did say in my last email that one option would be for
>> the documentation to be very clear about leaving the old history
>> dangling. That at least keeps clueless people from stumbling into using
>> the option accidentally.
>
> Both of you are right and I agree "commit --root" is a bad idea (I can
> change my mind ;-). Especially it is rare (and I would even say it should
> be discouraged) to create a new root commit in a repository that already
> has history, we should try to make it _very_ hard to lose history by
> mistake, even though that means creating a new root commit has to be done
> as a multi-step process (e.g. "checkout --orphan" to dissociate the new
> state from the current history and then "commit").
>
> Thanks for a bit of sanity.
Well, I think Jeff already proferred a solution. We could have:
git commit --no-parent
act like:
git branch -d
in that it would require a "--force" when the commit to which the
current branch head points would be left dangling. In fact, we
could go one step further:
git commit --no-parent
should require "--force" unless there exists another branch head
that points to the exact same commit as the current branch head; this
would tacitly enforce the notion that a new branch should be created
prior to the use of "--no-parent".
^ permalink raw reply
* [PATCH] git-send-email.perl: expand filename of aliasesfile
From: Cord Seele @ 2011-09-28 13:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong
Allow config variable sendemail.aliasesfile to contain a tilde, i.e.
make ~/.mutt/aliases work.
Signed-off-by: Cord Seele <cowose@gmail.com>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..b50b35f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -481,7 +481,7 @@ my %parse_alias = (
if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
foreach my $file (@alias_files) {
- open my $fh, '<', $file or die "opening $file: $!\n";
+ open my $fh, '<', glob($file) or die "opening $file: $!\n";
$parse_alias{$aliasfiletype}->($fh);
close $fh;
}
--
1.7.6.4.dirty
-- Cord
^ permalink raw reply related
* Re: subversion-perl missing
From: Jakub Narebski @ 2011-09-28 12:59 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: Christian Couder, git
In-Reply-To: <4E82F18E.9080304@gjlay.de>
On Wed, 28 Sep 2011, Georg-Johann Lay wrote:
> Jakub Narebski schrieb:
>> Georg-Johann Lay writes:
>>> Christian Couder schrieb:
>>>> On Mon, Sep 26, 2011 at 1:48 PM, Georg-Johann Lay <spam@spam.com> wrote:
>>>>> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
>>>>> that in subversion.tigris.org, so that I am stuck and need some hints on how to
>>>>> proceed.
>>>>
>>>> Perhaps you can try to install this module from CPAN:
>>>>
>>>> http://search.cpan.org/~mschwern/Alien-SVN-v1.6.12.1/
>>>>
>>>> or from it's github repo:
>>>>
>>>> https://github.com/schwern/alien-svn
>>>
>>> thanks for that hint.
>>>
>>> After getting that piece of software, running ./Build.PL and ./Build I just
>>> don't know what to do next. The README doesn't say anything about how to use
>>> the built modules or how to do an install.
>>
>> If you don't have admin privileges on the box, the best solution would
>> be to use local::lib[1] to install Perl modules in your home directory
>> for you (#perl IRC channel on FreeNode, or perlmonks are really helpful).
>>
>> I really recommend it, together with cpanm[2] (which can configure
>> local::lib for you, via --local-lib option), though the latter is not
>> necessary.
>>
>> [1]: http://search.cpan.org/~apeiron/local-lib-1.008004/lib/local/lib.pm
>> [2]: http://search.cpan.org/~miyagawa/App-cpanminus-1.4008/bin/cpanm
>>
>>
>> If you have admin privileges, I think the best solution would be
>> either find repository which has subversion-perl that matches your
>> version of Subversion, or compile subversion-perl from a source
>> package... though this might be more difficult, it has advantage of
>> being in package management.
>>
>>> As git-svn complains
>>>
>>> ...Can't locate SVN/Core.pm in @INC (@INC contains: ...
>>>
>>> and
>>>
>>> schwern-alien-svn-9298884>find . -name 'Core.pm'
>>> ./src/subversion/subversion/bindings/swig/perl/native/Core.pm
>>> ./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
>>>
>>> the question is how to do the final trick of telling git how to use Core.pm
>>> (and which of the two?) and do the connexion between git and alien-svn.
>>>
>>> Sorry for the noob questions, never used perl or git before...
>>
>> You have to install subversion-perl somewhere, not only build it.
>
> Unfortunately, that package comes without hints on doing that.
>
> As far as I understand, alien-svn comes with SVN sources which it uses for its
> own perl packages to provide svn stuff to perl, but don't install/build new svn
> version.
Step by step instruction.
1. Follow instructions on local::lib manpage
http://search.cpan.org/perldoc?local::lib
c.f. http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
2. (Optional). Follow instructions on cpanm manpage, e.g. http://cpanmin.us
or http://search.cpan.org/perldoc?cpanm
3. Install Alien::SVN from CPAN using 'cpan' client or 'cpanm', e.g.
$ cpanm Alien::SVN
Now you are able to install Perl modules in your home directory.
--
Jakub Narebski
Poland
^ permalink raw reply
* RE: Lack of detached signatures
From: Joseph Parmelee @ 2011-09-28 12:36 UTC (permalink / raw)
To: Carlos Martín Nieto
Cc: Olsen, Alan R, Michael Witten, Junio C Hamano,
git@vger.kernel.org
In-Reply-To: <1317195719.30267.4.camel@bee.lab.cmartin.tk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3778 bytes --]
On Wed, 28 Sep 2011, Carlos Martín Nieto wrote:
> On Wed, 2011-09-28 at 04:17 +0000, Olsen, Alan R wrote:
>> [Sorry for the top posting. Outlook is evil.]
>>
>> Detached signatures are created with gpg, not git.
>
> Git delegates all the signing business to gpg.
>
>>
>> What I would like to see in git would be signed commits. I have looked
>
> Every single commit? That sounds very heavy. You might want to look at
> signed pushes (signed push certificates), which were discussed in the
> list some time the kernel.org intrusion.
>
> Due to the way git calculates the hash for each object, signing a tag
> means that you also sign every single commit up to that point (with all
> their tree and blob objects).
>
>> at what it would take to make it work, but I don't have all the
>> details worked out. (Certain merges and cherry-picks would not work
>> very well.)
>
> This is precisely because of the cryptographic hash that is used to make
> sure that history doesn't get changed.
>
> cmn
>
>>
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten
>> Sent: Tuesday, September 27, 2011 5:08 PM
>> To: Junio C Hamano
>> Cc: Joseph Parmelee; git@vger.kernel.org
>> Subject: Re: Lack of detached signatures
>>
>> On Wed, Sep 28, 2011 at 00:03, Junio C Hamano <gitster@pobox.com> wrote:
>>> Joseph Parmelee <jparmele@wildbear.com> writes:
>>>
>>>> Under the present circumstances, and particularly considering the
>>>> sensitivity of the git code itself, I would suggest that you implement
>>>> signed detached digital signatures on all release tarballs.
>>>
>>> Well, signed tags are essentially detached signatures. People can verify
>>> tarballs against them if they wanted to, although it is a bit cumbersome.
>>
>> Aren't tarballs used to get git on machines that don't yet have git?
>> --
>> 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
>> NrybX?v^)?{.n+?\x17?}?z&j:+v\azZ++zfh~iz\x1ew?&)?^[f
>
>
>
There is confusion here between the repository and the tarball. Once you
have produced the tarball there is NO cryptographic protection against
forgeries unless you sign it with GPG. That is my point: either produce
signatures with the tarballs, or don't provide them at all and force users
to clone the repository. Git itself provides internal crytopgraphic
protection with its commit tags.
The stability of the head depends on the policies followed by the developers
and cannot be known by users not intimately involved in the development. In
any event if there is a tarball most users assume that it represents a more
stable state of the repository than the head and they will tend to use it,
even if they already have a version of the code, instead of cloning the
repository directly.
Git, and its signing key, are high-value targets for the bad guys, even
higher than the kernel itself. I hope you will give just a moment's thought
to the damage that will be done if bad guys succeed in a DNS poisoning
attack and succeed in passing off a phony git tarball with a back door in
the git code itself to a major code project. Any code produced in a
repository using that phony version of git can then itself be corrupted.
It is only because kernel.org exercised due diligence in the production of
tags and signatures on all their tarballs that the kernel code itself
withstood their recent intrusion. I suspect that their signing key was not
so lucky and needs to be changed. The situation now is really dangerous
with various important projects scattered about, including git, which are
being operated without proper consideration of security.
^ permalink raw reply
* [PATCH v3] send-email: auth plain/login fix
From: Zbigniew Jędrzejewski-Szmek @ 2011-09-28 10:26 UTC (permalink / raw)
To: gitster, joe, git; +Cc: Zbigniew Jędrzejewski-Szmek
In-Reply-To: <m3fwjjp69m.fsf@localhost.localdomain>
git send-email was not authenticating properly when communicating over
TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
e.g. the standard server setup under debian with exim4 and probably
everywhere where system accounts are used.
The problem (only?) exists when libauthen-sasl-cyrus-perl
(Authen::SASL::Cyrus) is installed. Importing Authen::SASL::Perl
makes Authen::SASL use the perl implementation which works
better.
The solution is based on this forum thread:
http://www.perlmonks.org/?node_id=904354.
This patch is tested by sending it :)
Before:
Net::SMTP>>> Net::SMTP(2.31)
Net::SMTP>>> Net::Cmd(2.29)
Net::SMTP>>> Exporter(5.64_01)
Net::SMTP>>> IO::Socket::INET(1.31)
Net::SMTP>>> IO::Socket(1.31)
Net::SMTP>>> IO::Handle(1.28)
...
Net::SMTP=GLOB(0x238f668)>>> STARTTLS
Net::SMTP=GLOB(0x238f668)<<< 220 2.0.0 Ready to start TLS
Net::SMTP::SSL=GLOB(0x238f668)>>> EHLO localhost.localdomain
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-yyy.yyy.yyy Hello xxx.xxx [xxx.xxx.xxx.xxx], pleased to meet you
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-PIPELINING
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-8BITMIME
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-SIZE 80000000
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-DSN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH=LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-DELIVERBY
Net::SMTP::SSL=GLOB(0x238f668)<<< 250 HELP
Password:
Net::SMTP::SSL=GLOB(0x238f668)>>> AUTH
Net::SMTP::SSL=GLOB(0x238f668)<<< 501 5.5.2 AUTH mechanism must be specified
5.5.2 AUTH mechanism must be specified
After:
Net::SMTP=GLOB(0x1ac4a60)>>> STARTTLS
Net::SMTP=GLOB(0x1ac4a60)<<< 220 2.0.0 Ready to start TLS
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> EHLO localhost.localdomain
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-yyy.yyy.yyy Hello xxx.xxx [xxx.xxx.xxx.xxx], pleased to meet you
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-PIPELINING
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-8BITMIME
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-SIZE 80000000
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-DSN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-AUTH=LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-AUTH LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-DELIVERBY
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250 HELP
Password:
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> AUTH LOGIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 334 VXNlcm5hbWU6
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> emJ5c3plaw==
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 334 UGFzc3dvcmQ6
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> dGVzdA==
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 535 5.7.0 authentication failed
5.7.0 authentication failed
The password is incorrect in this snippet, but the protocol works correctly.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
v3: - the import is performed only if it will be used, and failure is ignored
git-send-email.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 37dfbe7..dbc435a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1098,6 +1098,10 @@ X-Mailer: git-send-email $gitversion
}
if (defined $smtp_authuser) {
+ eval {
+ require Authen::SASL;
+ Authen::SASL->import(qw(Perl));
+ };
if (!defined $smtp_authpass) {
--
1.7.6
^ permalink raw reply related
* Re: subversion-perl missing
From: Georg-Johann Lay @ 2011-09-28 10:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Christian Couder, git
In-Reply-To: <m3k48vp6l7.fsf@localhost.localdomain>
Jakub Narebski schrieb:
> Georg-Johann Lay writes:
>> Christian Couder schrieb:
>>> On Mon, Sep 26, 2011 at 1:48 PM, Georg-Johann Lay <spam@spam.com> wrote:
>
>>>> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
>>>> that in subversion.tigris.org, so that I am stuck and need some hints on how to
>>>> proceed.
>>> Perhaps you can try to install this module from CPAN:
>>>
>>> http://search.cpan.org/~mschwern/Alien-SVN-v1.6.12.1/
>>>
>>> or from it's github repo:
>>>
>>> https://github.com/schwern/alien-svn
>> Hi Christian,
>>
>> thanks for that hint.
>>
>> After getting that piece of software, running ./Build.PL and ./Build I just
>> don't know what to do next. The README doesn't say anything about how to use
>> the built modules or how to do an install.
>
> If you don't have admin privileges on the box, the best solution would
> be to use local::lib[1] to install Perl modules in your home directory
> for you (#perl IRC channel on FreeNode, or perlmonks are really helpful).
>
> I really recommend it, together with cpanm[2] (which can configure
> local::lib for you, via --local-lib option), though the latter is not
> necessary.
>
> [1]: http://search.cpan.org/~apeiron/local-lib-1.008004/lib/local/lib.pm
> [2]: http://search.cpan.org/~miyagawa/App-cpanminus-1.4008/bin/cpanm
>
>
> If you have admin privileges, I think the best solution would be
> either find repository which has subversion-perl that matches your
> version of Subversion, or compile subversion-perl from a source
> package... though this might be more difficult, it has advantage of
> being in package management.
>
>> As git-svn complains
>>
>> ...Can't locate SVN/Core.pm in @INC (@INC contains: ...
>>
>> and
>>
>> schwern-alien-svn-9298884>find . -name 'Core.pm'
>> ./src/subversion/subversion/bindings/swig/perl/native/Core.pm
>> ./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
>>
>> the question is how to do the final trick of telling git how to use Core.pm
>> (and which of the two?) and do the connexion between git and alien-svn.
>>
>> Sorry for the noob questions, never used perl or git before...
>
> You have to install subversion-perl somewhere, not only build it.
Unfortunately, that package comes without hints on doing that.
As far as I understand, alien-svn comes with SVN sources which it uses for its
own perl packages to provide svn stuff to perl, but don't install/build new svn
version.
> Though you could fiddle with PERL5LIB (which is PATH-like environmtne
> find . -name '*.pm'
./src/subversion/subversion/bindings/swig/perl/native/Delta.pm
./src/subversion/subversion/bindings/swig/perl/native/Base.pm
./src/subversion/subversion/bindings/swig/perl/native/Ra.pm
./src/subversion/subversion/bindings/swig/perl/native/Repos.pm
./src/subversion/subversion/bindings/swig/perl/native/Core.pm
./src/subversion/subversion/bindings/swig/perl/native/Wc.pm
./src/subversion/subversion/bindings/swig/perl/native/Client.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Delta.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Base.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Ra.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Repos.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Wc.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Client.pm
./src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Fs.pm
./src/subversion/subversion/bindings/swig/perl/native/Fs.pm
./inc/My/SVN/Builder.pm
./lib/Alien/SVN.pm
./blib/lib/Alien/SVN.pm
and so I added the paths to PERL5LIB:
export PERL5LIB=\
<alien-svn>/blib/lib/Alien\
:<alien-svn>/src/subversion/subversion/bindings/swig/perl/native/blib/lib\
:<alien-svn>/src/subversion/subversion/bindings/swig/perl/native
where "." is the source directory of alien-svn and where the ./Build.PL and
./Build scripts ran.
Running git-svn with that complains
Can't locate loadable object for module SVN::_Core in @INC (@INC contains:
...
<alien-svn>/blib/lib/Alien
<alien-svn>/src/subversion/subversion/bindings/swig/perl/native/blib/lib
<alien-svn>/src/subversion/subversion/bindings/swig/perl/native
...) at
<alien-svn>/src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Base.pm
line 59
BEGIN failed--compilation aborted at
<alien-svn>/src/subversion/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm
line 5.
Compilation failed in require at /usr/local/libexec/git-core/git-svn line 42.
git-svn:42 is mumbling about some problems:
sub _req_svn {
require SVN::Core; # use()-ing this causes segfaults for me... *shrug*
Or is there needed even more like a _Core.pm? alien-svn should build it,
doesn't it?
> variable to specify where to search for Perl modules) to make Perl
> find your built but not installed Alien::SVN.
How do I install that?
Sorry for all these question. Admin left the company some weeks ago and I am
struggling to get this to work somehow between my everyday work...
^ permalink raw reply
* Re: [PATCH] parse-options: deprecate OPT_BOOLEAN
From: Miles Bader @ 2011-09-28 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <7v39fhv8se.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As a first step to remedy this, introduce a true boolean OPT_BOOL(), and
> rename OPT_BOOLEAN() to OPT_COUNTUP().
Hmm ... "OPT_COUNTED"?
-miles
--
values of β will give rise to dom!
^ permalink raw reply
* Branch annotations [Re: Annotated branch ≈ annotated tag?]
From: Michael J Gruber @ 2011-09-28 8:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Andrew Ardill, Jeff King, Junio C Hamano, git
In-Reply-To: <4E82D52B.9020709@alum.mit.edu>
I'm not tied to a particular implementation (not even mine), but we
should think through the concept before baking something in. That was my
impetus for throwing in a (half-baked) notes based solution before a
config based is baked^Wset in stone ;)
For me, commit annotations as currently implemented (notes) have the
following positives:
* easy ui (add/edit/copy)
* easy scripting (-F/-m)
* can be shared *if I want* (by pushing refspec; note that share=backup
as well as share=publish, depending on where I push to); ui could be
somewhat better
* multiple sources possible
* is versioned (ui could be better, e.g. git notes log)
For branch annotations, I would want to have all of the above. Depending
on the use case, I want to treat branch annotations as purely local (but
may still want to push them to backup) or share and publish them. I
might be interested in their history or not, etc. In addition, we would
want to have the obvious:
* git branch -m moves annotation
* git branch --list --younameit shows annotation
* etc.
If we agree that we want the above properties (and that is a big if)
then using notes seem very natural. [Having to rewrite an annotated tag
object at each branch head change appears unnatural.] They should
probably live in a separate default tree (one per remote for remote
branches), and the actual mechanics (virtual objects, real objects,
textconvcache like...) is not dictated by those requirements.
Note though that we might be interested in annotating more general names
than just refnames, e.g. paths, or names like "description". Since tags
should be immutable, adding notes to a tag seems not much different from
annotating the referenced commit, but it is different in concept and
could be treated differently (as tag notes would be in a separate tree
from the commit notes tree).
So, if we want to keep that path open (annotate more general names), a
mapping from names to notes becomes mandatory. Again, that does not
dictate a specific implementation.
Michael
^ permalink raw reply
* [PATCH] git-completion: offer remotes for 'git remote update'
From: Auke Schrijnen @ 2011-09-28 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <7v8vp9trvu.fsf@alter.siamese.dyndns.org>
Completion for 'git remote update' only offers configured remote
groups. This is fine if one uses remote groups but there is no
completion without those groups.
Add all remotes to the completion when no configured groups are found.
Signed-off-by: Auke Schrijnen <auke@schrijnen.nl>
---
contrib/completion/git-completion.bash | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8648a36..12058bf 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2298,7 +2298,11 @@ _git_remote ()
i="${i#remotes.}"
c="$c ${i/ */}"
done
- __gitcomp "$c"
+ if [ -z "$c" ]; then
+ __gitcomp "$(__git_remotes)"
+ else
+ __gitcomp "$c"
+ fi
;;
*)
COMPREPLY=()
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH] git-completion: offer remotes for 'git remote update'
From: Auke Schrijnen @ 2011-09-28 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8vp9trvu.fsf@alter.siamese.dyndns.org>
On Tue, 27 Sep 2011 17:47:17 -0700, Junio C Hamano wrote:
> Auke Schrijnen <auke@schrijnen.nl> writes:
>
>> Completion for 'git remote update' only offers configured remote
>> groups.
>
> I have this suspicion that it might even be a feature. I am a bad
> person
> to make the judgement, as I do not use the "grouping" feature at all.
>
> If you throw in individual remotes that are not grouped in the mix,
> the
> users of "git remote update" auto-completion, who have been happily
> relying on seeing only the configured groups, suddenly will start
> seeing
> many individual repositories offered, cluttering the available
> choices.
> Besides, if you want to fetch from a single source, why not use "git
> fetch" directly?
>
> Back when "git fetch" didn't allow fetching from multiple
> repositories in
> one go, "remote update" was written as a wrapper for the explicit
> purpose
> of fetching from more than one remote by defining remote groups.
> Since
> late 2009, "git fetch" can update from multiple remotes itself, and I
> suspect "git remote update" outlived its usefulness in some sense,
> but
> that is a tangent.
I see your point and obviously i'm also not using the grouping feature.
I could just use git fetch but i'm so used to type 'git remote
update'... So i'll cook another patch.
Auke
^ permalink raw reply
* Re: Annotated branch ≈ annotated tag?
From: Michael Haggerty @ 2011-09-28 8:04 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Jeff King, Michael J Gruber, Junio C Hamano, git
In-Reply-To: <CAH5451nT2Z6mBPkK4B2EgJAoMpf32bcc=7UqhTDnsw4-_hJwJw@mail.gmail.com>
On 09/28/2011 09:12 AM, Andrew Ardill wrote:
> On 28 September 2011 14:23, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> [snip]
>>
>> [1] If the retention of annotation history were considered a
>> requirement, the annotation object could record as a "parent" the object
>> name of the annotation object that it is succeeding. But I don't think
>> that this is a good idea; it would make branches too heavyweight and
>> every branch update would be recorded permanently, both of which are
>> contrary to the git philosophy.
>
> If this was required, a better way would be to update the parent object only
> if the description changed. You would then have a nice little DAG that
> records changes to the description and could be used in 3-way merges etc.
> You would of course get lots of 'dead' annotation objects pointing to the
> previous change, however that shouldn't be too much of an issue.
>
> At this point, however, I ask how is an annotation object any different to
> placing an annotation file in our repository. Perhaps there is no difference,
> except that one is a convention and the other is provided.
Yes, if history is being preserved, then the annotation objects would
not be much different than storing a file in the repository. But even
then, there are differences:
- A branch annotation would be separate from the source code and not
appear in the working tree, which seems more appropriate for metadata.
- git and other tools would know where to find the annotation instead of
having to configure whether a particular project uses annotations and if
so where to find them. This would make it easier to use the annotations
in git workflow like the generation of pull requests.
- The merge rules for annotations would be different than those for
other files.
But I believe that branch annotation history should *not* be retained,
so storing the annotations in the source tree is not even an option
(except perhaps in another artificial branch used only for annotations).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael J Gruber @ 2011-09-28 8:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Witten, Carlos Martín Nieto, vra5107, git
In-Reply-To: <7v39fhyk21.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 27.09.2011 19:25:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> It seems like a more logical approach would be instead for "git
>> commit" to take a "--root" option that would create a new root commit
>> based on the current index and then point the current branch head to
>> the new root commit. Thus:
>>
>> $ git checkout -b new_branch old_branch
>> $ # Manipulate or not
>> $ git commit --root
>>
>> That's how people think.
>
> This may indeed be an improvement. I suspect that we'd need to think about
> it a bit more, but it feels right (perhaps introduce this new option,
> deprecate --orphan from the checkout, and then eventually remove it
> sometime in 1.8.0 timeframe).
>
>>>> The index and the working tree are adjusted as if you had previously run
>>>> "git checkout <start_point>". This allows you to start a new history
>>>> -that records a set of paths similar to <start_point> by easily running
>>>> +that records a set of paths similar to <start_point> by just running
>>>> "git commit -a" to make the root commit.
>>>
>>> "similar" is an understatement here, maybe "as in"?
>
> I do not think "as in" is an improvement. It completely ignores the
> "Manipulate or not" part in the above, and "similar" was very much an
I do not see that part in the above. If you really "just run git commit
-a" after git branch --orphan you get the same tree.
> attempt to say "you do not have to commit it right away, but start from
> the state and commit a deviation of it".
^ permalink raw reply
* Re: "Resetting" a repository
From: Roddie Grant @ 2011-09-28 7:52 UTC (permalink / raw)
To: git
In-Reply-To: <861uv27y6k.fsf@red.stonehenge.com>
On 27/09/2011 17:22, Randal L. Schwartz wrote:
>>>>>> "gitlist" == gitlist<gitlist@myword.co.uk> writes:
>
> gitlist> I have a project with a test repository and a live repository (and a
> gitlist> development repository).
>
> You haven't mentioned what kind of access you have to the two repos.
> Are they both bare remote repos? Or can you just rsync one over the
> other?
Both repos are on the same virtual server. I normally use ssh for git,
but have full access to the server. Both repos are not bare. The test
repos is for the customer to test new stuff and the live repos is for
the world to see the site (it's all for a website).
The development repos is on my laptop, but it's the test and live repos
I want to get back in step with each other.
Thanks
Roddie Grant
^ permalink raw reply
* Signed push progress?
From: Robin H. Johnson @ 2011-09-28 7:50 UTC (permalink / raw)
To: Git Mailing List
I haven't seen anything about the status of signed push since earlier in
the month, even the what's cooking report marked it as stalled.
While I'd previously noted my concerns re the use of SHA1, that's not
presently a solvable problems, whereas signed-push does improve security
today.
Additionally, in the ever ongoing discussion about Gentoo's conversion
from CVS to Git (we're very close now), we've decided that the signed
pushes will provide better security than our plan of previous plan of
using signed notes, so we'd like to see signed pushes succeed.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* RE: Lack of detached signatures
From: Carlos Martín Nieto @ 2011-09-28 7:41 UTC (permalink / raw)
To: Olsen, Alan R
Cc: Michael Witten, Junio C Hamano, Joseph Parmelee,
git@vger.kernel.org
In-Reply-To: <4B2793BF110AAB47AB0EE7B90897038516F63A7C@ORSMSX101.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
On Wed, 2011-09-28 at 04:17 +0000, Olsen, Alan R wrote:
> [Sorry for the top posting. Outlook is evil.]
>
> Detached signatures are created with gpg, not git.
Git delegates all the signing business to gpg.
>
> What I would like to see in git would be signed commits. I have looked
Every single commit? That sounds very heavy. You might want to look at
signed pushes (signed push certificates), which were discussed in the
list some time the kernel.org intrusion.
Due to the way git calculates the hash for each object, signing a tag
means that you also sign every single commit up to that point (with all
their tree and blob objects).
> at what it would take to make it work, but I don't have all the
> details worked out. (Certain merges and cherry-picks would not work
> very well.)
This is precisely because of the cryptographic hash that is used to make
sure that history doesn't get changed.
cmn
>
> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten
> Sent: Tuesday, September 27, 2011 5:08 PM
> To: Junio C Hamano
> Cc: Joseph Parmelee; git@vger.kernel.org
> Subject: Re: Lack of detached signatures
>
> On Wed, Sep 28, 2011 at 00:03, Junio C Hamano <gitster@pobox.com> wrote:
> > Joseph Parmelee <jparmele@wildbear.com> writes:
> >
> >> Under the present circumstances, and particularly considering the
> >> sensitivity of the git code itself, I would suggest that you implement
> >> signed detached digital signatures on all release tarballs.
> >
> > Well, signed tags are essentially detached signatures. People can verify
> > tarballs against them if they wanted to, although it is a bit cumbersome.
>
> Aren't tarballs used to get git on machines that don't yet have git?
> --
> 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
> NrybXǧv^){.n+ا\x17ܨ}Ơz&j:+v\azZ++zfh~iz\x1ew?&)ߢ^[f
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Annotated branch ≈ annotated tag?
From: Andrew Ardill @ 2011-09-28 7:12 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jeff King, Michael J Gruber, Junio C Hamano, git
In-Reply-To: <4E82A13B.2080509@alum.mit.edu>
On 28 September 2011 14:23, Michael Haggerty <mhagger@alum.mit.edu> wrote:
[snip]
>
> [1] If the retention of annotation history were considered a
> requirement, the annotation object could record as a "parent" the object
> name of the annotation object that it is succeeding. But I don't think
> that this is a good idea; it would make branches too heavyweight and
> every branch update would be recorded permanently, both of which are
> contrary to the git philosophy.
If this was required, a better way would be to update the parent object only
if the description changed. You would then have a nice little DAG that
records changes to the description and could be used in 3-way merges etc.
You would of course get lots of 'dead' annotation objects pointing to the
previous change, however that shouldn't be too much of an issue.
At this point, however, I ask how is an annotation object any different to
placing an annotation file in our repository. Perhaps there is no difference,
except that one is a convention and the other is provided.
Regards,
Andrew
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-28 4:37 UTC (permalink / raw)
To: Jay Soffian
Cc: Junio C Hamano, Michael J Gruber, Carlos Martín Nieto,
vra5107, git
In-Reply-To: <CAG+J_DxzcuYiffm6XVX-RQSxeMwy4Yi7CdhCdddAN=xRyJ2b5Q@mail.gmail.com>
On Wed, Sep 28, 2011 at 04:04, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Tue, Sep 27, 2011 at 1:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael Witten <mfwitten@gmail.com> writes:
>>
>>> It seems like a more logical approach would be instead for "git
>>> commit" to take a "--root" option that would create a new root commit
>>> based on the current index and then point the current branch head to
>>> the new root commit. Thus:
>>>
>>> $ git checkout -b new_branch old_branch
>>> $ # Manipulate or not
>>> $ git commit --root
>>>
>>> That's how people think.
>>
>> This may indeed be an improvement. I suspect that we'd need to think about
>> it a bit more, but it feels right (perhaps introduce this new option,
>> deprecate --orphan from the checkout, and then eventually remove it
>> sometime in 1.8.0 timeframe).
>
> Hrm, create new_branch just so you can immediately clobber its SHA1
> with the new commit that has no parents. That doesn't seem quite
> right.
The point is that users think about 2 things:
* I need to create a root commit.
* I need a branch head to point to that root commit,
and I probably want a new branch head to do that.
My goal is to match the way people think; nobody thinks about the SHA1
when doing this task, and everybody thinks about creating a new branch
head.
More to the point, how is it better that "checkout --orphan" sets up
the working tree and index when the user is just going to obliterate
them or alter them significantly?
> Imagine you use "git commit --root" by accident while on
> master, then you have to dig into your reflog?
What's wrong with, say, "git reset --hard ORIG_HEAD"? (note that
ORIG_HEAD is already something understood by git).
> But it's close. Maybe:
>
> $ git commit --new-root-branch=<name>
>
> Which creates <name> with the index as its sole commit and switches
> you to that branch? That doesn't feel quite right either.
The "git commit" command shouldn't be canoodling the branch layer so intimately.
In fact, that's why I dislike:
git checkout --orphan <branch_head>
The "--orphan" flag was no doubt added to "git checkout" because of
there already existed:
git checkout -b <branch_head>
However, that is only available as a convenience (that is, a hack) for:
git branch <branch_head>
git checkout <branch_head>
It seems to be an even larger hack that "git checkout" as been given
so much control over setting the stage for not only the creation of a
branch head, but also the nature of the ancestry of the *next* commit.
^ permalink raw reply
* Annotated branch ≈ annotated tag?
From: Michael Haggerty @ 2011-09-28 4:23 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Junio C Hamano, git
In-Reply-To: <20110927215843.GE5176@sigill.intra.peff.net>
On 09/27/2011 11:58 PM, Jeff King wrote:
> On Sat, Sep 24, 2011 at 04:42:18PM +0200, Michael J Gruber wrote:
>> I really think the only issue is remote refnames. As Junio points out,
>> they are local by nature. OTOH, you typically use a non-renaming refspec
>> which puts them under refs/remotes/foo/bar with "bar" being the same
>> name as the local one on the remote, foo something you have chosen. So,
>> teaching the code that the note for
>
> If they are local by nature, is it worth putting them into a notes tree
> at all? That provides versioning and backup. But I wonder if it is worth
> the hassle, when one could just put them in the config.
I don't think that branch descriptions should be local-only. They would
be a good way to share information with others about work in progress.
It seems to me that an annotated branch is very much like an (unsigned)
annotated tag, except that it is movable and disposable like a normal
branch. What would be the ramifications of using an annotated-tag-like
object to record metainformation about a branch? (Let's just call it an
"annotation object" for this discussion.)
* The branch would point not at a commit but at an annotation object
that points at a commit.
* Obviously, a new annotation object would have to be written every time
the branch is updated.
* Presumably, by default, the old description would be copied from the
old annotation object to the new one; the committer would be set to
those of the user doing the update.
* The old annotation object would become unreachable after every
branch update, though locally it would still be reachable via the
branch's reflog [1].
* Creating a new branch from an annotated branch should perhaps open an
editor to allow the user to set a new comment. If the user deletes the
whole comment in the editor, then an unannotated branch is created
instead of an annotated branch.
* We would need rules for merging annotation objects:
* There is no such thing as a fast-forward merge to an annotated
branch, because the merged-from branch, even if annotated, can never
have the merged-to annotation object in its history. So proceed to the
following rules.
* If both branches are unannotated, then the result should be an
unannotated branch (like today).
* If both branches have the same comment, the comment should be
carried over to the result without prompting.
* If the merge-to branch is annotated and the merge-from branch is
not, keep the merge-to branch's annotation.
* If the merge-to branch is unannotated and the merge-from branch is
annotated, the result should be a conflict. This cannot be resolved
automatically because there are two likely scenarios:
* A remote branch is being merged into a remote-tracking branch. In
this case somebody upstream probably added a comment to the branch, and
one would like to preserve this comment in a local annotated branch.
* A feature branch is being merged back to mainline. In such a case
one would *not* like to carry over the branch annotation (which
presumably describes the feature that was developed on the branch),
though it would often be convenient to integrate the merged-from branch
annotation into the log message of the merge commit.
I'm not sure how to let the user distinguish between the two cases
above, but it probably involves $EDITOR.
* If the merge-to branch and the merge-from branch have conflicting
annotations, there are two possibilities much like in the previous case.
* Annotated tag objects include the name of the tag that is being
annotated. Annotated branch objects should *not* include this
information, because it does not carry across from one repo to another
when branches are renamed. (Perhaps the presence/absence of the tag
name could be what distinguishes an (unmovable) annotated tag object
from a (movable) annotated branch object.)
It would even be possible to allow signatures in the annotated objects;
these could play the role of push certificates. Whenever a signed
annotated branch is updated, the signature would go away (it would
probably be too cumbersome to prompt the user to generate it a new
signature for every branch update). It should be easy to add a
signature to an existing annotated or unannotated branch (writing a new
annotation object, of course).
ISTM that the semantics would be very close to what is desired, and
would satisfy a few needs: a place to describe work-in-progress in a
sharable way, branch descriptions that can be used for constructing pull
requests and merge commit messages, and (optionally) a way to implement
signed pushes. It would surely be a lot of work to implement, but being
based on annotated tags would mean that a lot of code, documentation,
and training would be common to the two concepts.
Michael
[1] If the retention of annotation history were considered a
requirement, the annotation object could record as a "parent" the object
name of the annotation object that it is succeeding. But I don't think
that this is a good idea; it would make branches too heavyweight and
every branch update would be recorded permanently, both of which are
contrary to the git philosophy.
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] parse-options: deprecate OPT_BOOLEAN
From: Junio C Hamano @ 2011-09-28 4:22 UTC (permalink / raw)
To: Jeff King; +Cc: git, Pierre Habouzit
In-Reply-To: <20110928035809.GC10662@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Sep 27, 2011 at 04:56:49PM -0700, Junio C Hamano wrote:
>
>> It is natural to expect that an option defined with OPT_BOOLEAN() could be
>> used in this way:
>> [...]
>> to easily tell three cases apart:
>>
>> - There is no mention of the `--option` on the command line;
>> - The variable is positively set with `--option`; or
>> - The variable is explicitly negated with `--no-option`.
>>
>> Unfortunately, this is not the case. OPT_BOOLEAN() increments the variable
>> every time `--option` is given, and resets it to zero when `--no-option`
>> is given.
>
> Yes, please. I remember being bitten by this at one point. Your
> transition plan makes sense to me.
The best part of it is that this leaves many small bite-sized tasks, one
"struct option" per patch, most of which can be done by people who are not
uber experts in Git internals ;-).
> Can OPT_UYN be folded into this, as well?
Perhaps, but I would prefer to keep this simple at least during the first
pass of eradicating OPT_BOOLEAN and OPTION_BOOLEAN. After that is done, we
may want to tackle OPT_UYN() that uses 2 for "unset", which feels a tad
unnatural. It has only one user---even if it turns out that it was a
mistake, the damage would be relatively limited to fix it.
^ permalink raw reply
* RE: Lack of detached signatures
From: Olsen, Alan R @ 2011-09-28 4:17 UTC (permalink / raw)
To: Michael Witten, Junio C Hamano; +Cc: Joseph Parmelee, git@vger.kernel.org
In-Reply-To: <CAMOZ1Bs2HW6e3V6sayVSm0NhC=0e5129ZR8YSGuZPnJw9H9TEA@mail.gmail.com>
[Sorry for the top posting. Outlook is evil.]
Detached signatures are created with gpg, not git.
What I would like to see in git would be signed commits. I have looked at what it would take to make it work, but I don't have all the details worked out. (Certain merges and cherry-picks would not work very well.)
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten
Sent: Tuesday, September 27, 2011 5:08 PM
To: Junio C Hamano
Cc: Joseph Parmelee; git@vger.kernel.org
Subject: Re: Lack of detached signatures
On Wed, Sep 28, 2011 at 00:03, Junio C Hamano <gitster@pobox.com> wrote:
> Joseph Parmelee <jparmele@wildbear.com> writes:
>
>> Under the present circumstances, and particularly considering the
>> sensitivity of the git code itself, I would suggest that you implement
>> signed detached digital signatures on all release tarballs.
>
> Well, signed tags are essentially detached signatures. People can verify
> tarballs against them if they wanted to, although it is a bit cumbersome.
Aren't tarballs used to get git on machines that don't yet have git?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Jay Soffian @ 2011-09-28 4:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Witten, Michael J Gruber, Carlos Martín Nieto,
vra5107, git
In-Reply-To: <7v39fhyk21.fsf@alter.siamese.dyndns.org>
On Tue, Sep 27, 2011 at 1:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> It seems like a more logical approach would be instead for "git
>> commit" to take a "--root" option that would create a new root commit
>> based on the current index and then point the current branch head to
>> the new root commit. Thus:
>>
>> $ git checkout -b new_branch old_branch
>> $ # Manipulate or not
>> $ git commit --root
>>
>> That's how people think.
>
> This may indeed be an improvement. I suspect that we'd need to think about
> it a bit more, but it feels right (perhaps introduce this new option,
> deprecate --orphan from the checkout, and then eventually remove it
> sometime in 1.8.0 timeframe).
Hrm, create new_branch just so you can immediately clobber its SHA1
with the new commit that has no parents. That doesn't seem quite
right. Imagine you use "git commit --root" by accident while on
master, then you have to dig into your reflog?
But it's close. Maybe:
$ git commit --new-root-branch=<name>
Which creates <name> with the index as its sole commit and switches
you to that branch? That doesn't feel quite right either.
</thinking out loud>
j.
^ permalink raw reply
* Re: emacs as mergetool
From: Vijay Lakshminarayanan @ 2011-09-28 4:03 UTC (permalink / raw)
To: thomas; +Cc: git
In-Reply-To: <201109261821.28382.thomas@koch.ro>
Thomas Koch <thomas@koch.ro> writes:
> Hi,
>
> would you be so kind and give an emacs newbie (and vim refugee) a hint about
> using emacs as mergetool?
>
> - Which one? ediff vs. emerge (I don't bother learning, just give me the best)
> - I'd like to have a setup, where I can run mergetool with different options
> to
> - connect to a running emacs server
> - run emacs in X
> - or in the terminal (default)
> - Is it possible to resolve all conflicting files in one session instead of
> having emacs called again for every file?
> - Do you know a tutorial on emacs as a mergetool?
http://www.emacswiki.org/emacs/EmergeDiff works for me.
> Thank you,
>
> Thomas Koch, http://www.koch.ro
--
Cheers
~vijay
^ permalink raw reply
* Re: [PATCH] parse-options: deprecate OPT_BOOLEAN
From: Jeff King @ 2011-09-28 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <7v39fhv8se.fsf@alter.siamese.dyndns.org>
On Tue, Sep 27, 2011 at 04:56:49PM -0700, Junio C Hamano wrote:
> It is natural to expect that an option defined with OPT_BOOLEAN() could be
> used in this way:
> [...]
> to easily tell three cases apart:
>
> - There is no mention of the `--option` on the command line;
> - The variable is positively set with `--option`; or
> - The variable is explicitly negated with `--no-option`.
>
> Unfortunately, this is not the case. OPT_BOOLEAN() increments the variable
> every time `--option` is given, and resets it to zero when `--no-option`
> is given.
Yes, please. I remember being bitten by this at one point. Your
transition plan makes sense to me.
Can OPT_UYN be folded into this, as well?
-Peff
^ permalink raw reply
* Re: [PATCH] notes_merge_commit(): do not pass temporary buffer to other function
From: Junio C Hamano @ 2011-09-28 3:10 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Johan Herland
In-Reply-To: <4E828B6C.1010707@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> diff --git notes-merge.c notes-merge.c
>>> index e1aaf43..baaf31f 100644
>>> --- notes-merge.c
>>> +++ notes-merge.c
>>
>> It is Ok to play with -p0 yourself but please don't do that in the public.
>
> Sorry; I had set diff.noprefix=true, not realizing that it would affect
> things like "git format-patch". It also confused emacs' magit mode, and
> probably some other tools. It's now set permanently back to false.
Thanks.
It is nothing catastrophic (I applied it with "am -p0 -s3c" just fine),
but everybody here sends -p1 format, so...
^ 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