* Re: [PATCH] add-interactive: handle deletion of empty files
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091028005257.GA5002@sigill.intra.peff.net>
Thanks.
^ permalink raw reply
* Re: Add '--bisect' revision machinery argument
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0910271124110.31845@localhost.localdomain>
Thanks.
^ permalink raw reply
* Re: [PATCH v2] rebase -i: more graceful handling of invalid commands
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Jan Krüger
Cc: Thomas Rast, kusmabite, Git Mailing List, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <20091027155814.0de65db5@perceptron>
Thanks.
^ permalink raw reply
* Re: [PATCH] help -i: properly error out if no info viewer can be found
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20091027133134.28975.qmail@34dfe9cde77152.315fe32.mid.smarden.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Charles Bailey; +Cc: Scott Chacon, git list
In-Reply-To: <20091027230043.GA11607@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> On Tue, Oct 27, 2009 at 03:36:49PM -0700, Scott Chacon wrote:
>> p4merge is now a built-in diff/merge tool.
>> This adds p4merge to git-completion and updates
>> the documentation to mention p4merge.
>> ---
>
> I approve (but haven't had a chance to test this).
Thanks; eventually you two need Sign-off and Acked-by, then, but I sense
that an undate to address the points below is in order?
> I'm just wondering, does this work well with unixes and Mac OS X? I
> think it's recommended install practice to symlink p4v as p4merge on
> *nix, but Mac OS X needs some sort of 'launchp4merge' to be called
> IIRC, or is this something that users can just configure with
> mergetool.p4diff.path?
^ permalink raw reply
* Re: vl/git-gui topic
From: Junio C Hamano @ 2009-10-28 7:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091027182710.GF10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> * vl/git-gui (2009-10-16) 1 commit.
>> - git-gui: adjust the minimum height of diff pane for shorter screen height
>>
>> Shawn?
>
> Applied to git-gui tree.
Thanks, pulled together with bunch of other changes that looked sensible.
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Junio C Hamano @ 2009-10-28 7:17 UTC (permalink / raw)
To: Eric Wong; +Cc: Nanako Shiraishi, Junio C Hamano, Sam Vilain, git
In-Reply-To: <20091027071405.GA3236@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Thanks for the ping, I got sidetracked and forgot about this. I've
> fixed up minor formatting details, acked and pushed out Sam's changes to
> git://git.bogomips.org/git-svn along with one I small fix I originally
> sent out a bad patch for.
Thanks; pulled.
^ permalink raw reply
* Re: [PATCH 1/4] Add routines for filenames encoding <local encoding> <-> UTF-8
From: Timur Sufiev @ 2009-10-28 7:15 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0910271515270.17168@ds9.cixit.se>
>> If `i18n.filenameslocalencoding' option was set via git-config to a
>> correct <codepage> encoding, 2 things should be done:
>
> Windows supports UTF-16 file names, but need to use wchar_t APIs for fopen()
> and friends. Have you looked at any of that?
No, I didn't look towards Windows handling of Unicode, because Git under
Windows works well enough without that: I've built Git in MinGW/MSYS
environmment (using the patches we're discussing) and it handles
cyrillic filenames in Windows ANSI CP1251 codepage just as was planned:
writes filenames to tree objects in UTF-8, checks out them into working
dir in CP1251, other stuff as git-clone, git-diff, git-status, etc also
works ok. One remaining issue (offtopic here, as far as I understand) to
make TortoiseGit work with UTF-8 Git's output.
> --
> \\// Peter - http://www.softwolves.pp.se/
--
Timur Sufiev
^ permalink raw reply
* Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: Junio C Hamano @ 2009-10-28 7:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Brown, git
In-Reply-To: <20091028000511.GK10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Brown <davidb@codeaurora.org> wrote:
>> From: David Brown <davidb@quicinc.com>
>>
>> 'git commit -s' will insert a blank line before the Signed-off-by
>> line at the end of the message, unless this last line is a
>> Signed-off-by line itself. Common use has other trailing lines
>> at the ends of commit text, in the style of RFC2822 headers.
>>
>> Be more generous in considering lines to be part of this footer.
>> This may occasionally leave out the blank line for cases where
>> the commit text happens to start with a word ending in a colon,
>> but this results in less fixups than the extra blank lines with
>> Acked-by, or other custom footers.
>
> The nasty perl I use in Gerrit's commit-msg hook is a bit more
> expressive. Basically the rule is we insert a blank line before
> the new footer unless all lines in the last paragraph (so all text
> after the last "\n\n" sequence) match the regex "^[a-zA-Z0-9-]+:".
Together with your suggestion for tests, the above makes quite a lot of
sense to me.
There is one thing to be careful about.
When deciding to omit adding a new S-o-b, we deliberately check only the
last S-o-b to see if it matches what we are trying to add. This is so
that a message from you, that has my patch that was reviewed and touched
up by you with your sign-off, i.e.
S-o-b: Junio
S-o-b: Shawn
will not be prevented to have another sign-off by me, so that I can
certify that I know that your change I received from you in the patch is
kosher. IOW, this is not a "duplicate" check. The order of S-o-b:
matters as it records the flow of the patch.
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-28 7:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4ygxce6.fsf@alter.siamese.dyndns.org>
On Tue, 2009-10-27 at 23:26 -0700, Junio C Hamano wrote:
> Vietor Liu <vietor@vxwo.org> writes:
>
> > Fixes some compiler warnings:
> > imap-send.c: In function ‘ssl_socket_connect’:
> > warning: assignment discards qualifiers from pointer target type
> >
> > Signed-off-by: Vietor Liu <vietor@vxwo.org>
>
> I do not quite understand. This variable gets assigned the return values
> from TLSv1_method() or SSLv23_method(), but the copy of ssl.h I have
> declares them as:
>
> SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2 */
> SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
1. openssl-devel-1.0.0-0.10
const SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2
*/
const SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
2. http://www.openssl.org/docs/ssl/ssl.html
const SSL_METHOD *SSLv2_method(void);
Constructor for the SSLv2 SSL_METHOD structure for combined
client and server.
const SSL_METHOD *TLSv1_method(void);
Constructor for the TLSv1 SSL_METHOD structure for combined
client and server.
3. it maybe fixes warnings for other version.
^ permalink raw reply
* Re: [PATCH 0/4] Cygwin MSVC patches
From: Johannes Sixt @ 2009-10-28 6:56 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, mstormo
In-Reply-To: <4AE7410D.3030109@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> Hi Junio,
>
> I've had these patches "hanging around" in my queue, for a few
> weeks, with every intention of adding several more to fix up
> some problems... Hmm, well I haven't got to those yet, so I
> thought I may as well pass these on.
>
> [PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin
> [PATCH 2/4] Makefile: merge two Cygwin configuration sections into one
> [PATCH 3/4] Makefile: keep MSVC and Cygwin configuration separate
> [PATCH 4/4] win32: Improve the conditional inclusion of WIN32 API code
>
> I think they are all pretty safe (famous last words), but it would be
> a good idea for someone with an MSYS/MinGW installation to test them
> (particularly patch #4; it's really the only one I'm slightly worried
> about :D).
>
> With these patches, the msvc build on cygwin seems to be working fine.
What is "the msvc build on cygwin"?
Is it "git built with msvc, then run in cygwin"?
-- Hannes
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Junio C Hamano @ 2009-10-28 6:26 UTC (permalink / raw)
To: Vietor Liu; +Cc: git
In-Reply-To: <1256706591-2763-1-git-send-email-vietor@vxwo.org>
Vietor Liu <vietor@vxwo.org> writes:
> Fixes some compiler warnings:
> imap-send.c: In function ‘ssl_socket_connect’:
> warning: assignment discards qualifiers from pointer target type
>
> Signed-off-by: Vietor Liu <vietor@vxwo.org>
I do not quite understand. This variable gets assigned the return values
from TLSv1_method() or SSLv23_method(), but the copy of ssl.h I have
declares them as:
SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2 */
SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
We would need to explain this change a bit better.
> imap-send.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/imap-send.c b/imap-send.c
> index 3847fd1..10dd025 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> fprintf(stderr, "SSL requested but SSL support not compiled in\n");
> return -1;
> #else
> - SSL_METHOD *meth;
> + const SSL_METHOD *meth;
> SSL_CTX *ctx;
> int ret;
>
> --
> 1.6.5.2
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Junio C Hamano @ 2009-10-28 6:11 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20091027133040.28836.qmail@fe20635a713ff7.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Hi Junio, I suggest to apply this patch from Johannes to master.
>
> Thanks, Gerrit.
Could you help by coming up with a suitable log message?
It's a bit too much to ask me to hunt for ancient discussion to correct
the <<all the ack go here>> myself to describe what the issue was,
especially when I wasn't heavily involved in the review of the patch
itself. My impression is that the original description of the problem
and the solution in your first message does not apply to what Dscho and
you agreed to be the best solution.
>
> On Fri, Sep 04, 2009 at 11:09:36AM +0000, Gerrit Pape wrote:
>> On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
>> > -- snipsnap --
>> > [PATCH] git help -a: do not look for a repository
>>
>> Perfect, thanks.
>>
>> Acked-by: Gerrit Pape <pape@smarden.org>
>>
>> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> >
>> > ---
>> >
>> > builtin-help.c | 6 +++---
>> > 1 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/builtin-help.c b/builtin-help.c
>> > index e1eba77..719aa23 100644
>> > --- a/builtin-help.c
>> > +++ b/builtin-help.c
>> > @@ -416,9 +416,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
>> > const char *alias;
>> > load_command_list("git-", &main_cmds, &other_cmds);
>> >
>> > - setup_git_directory_gently(&nongit);
>> > - git_config(git_help_config, NULL);
>> > -
>> > argc = parse_options(argc, argv, prefix, builtin_help_options,
>> > builtin_help_usage, 0);
>> >
>> > @@ -429,6 +426,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
>> > return 0;
>> > }
>> >
>> > + setup_git_directory_gently(&nongit);
>> > + git_config(git_help_config, NULL);
>> > +
>> > if (!argv[0]) {
>> > printf("usage: %s\n\n", git_usage_string);
>> > list_common_cmds_help();
>> > --
>> > 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
>> --
>> 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] gitignore: root most patterns at the top-level directory
From: Junio C Hamano @ 2009-10-28 6:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091027011024.GA29361@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> Our gitignore doesn't use a preceding "/" to root its
> patterns in the top of the repository. This means that if
> you add a file or directory called "git" (for example)
> inside a subdirectory, it will be erroneously ignored.
>
> This patch was done mechanically with "s/^[^*]/\/&/" with
> one exception: instead of ignoring gitk-wish, we should
> gitk-git/gitk-wish (arguably, this should be done in
> gitk-git/.gitignore, but because that is a subtree merge
> from elsewhere, this is easier).
>
> Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>
> This bit Sverre while I was looking over his shoulder. I doubt it comes
> up very often, but we should probably be modeling good gitignore
> behavior. I have to admit it looks a lot uglier, though.
How does .cvsignore and .svnignore work? Don't they have the same issue,
and perhaps worse as I do not recall seeing a way to anchor a pattern to a
particular directory like we do in their .SCMignore files? And judging
from the fact that they can get away with the lack of that "feature", this
perhaps is not an issue in real life?
I am actually a bit reluctant to queue this, even though I most likely
will, and then hope that we will think of a better solution later, at
which time this file again needs to change.
For example, it crossed my mind that perhaps we can change the ignore
rules so that a non-globbing pattern is automatically anchored at the
current directly but globbing ones are recursive as before.
If we do so, there is no need to change the current .gitignore entires.
You need to spell a concrete filename as a glob pattern that matches only
one path if you want the recursive behaviour. E.g. if you have a Makefile
per subdirectory, each of which generates and includes Makefile.depend
file, you would write "Makefile.depen[d]" in the toplevel .gitignore file.
But that is a kind of incompatible change whose necessity is unproven and
has to cook and wait.
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Lachlan Deck @ 2009-10-28 5:59 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git list
In-Reply-To: <32541b130910272220p59482397wef0d51b1adf1a5bd@mail.gmail.com>
On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
> On Tue, Oct 27, 2009 at 11:00 PM, Lachlan Deck
> <lachlan.deck@gmail.com> wrote:
>> :) Sure. Essentially a project that I'm contributing to has both
>> maven poms
>> and ant/lib-based configs (with the ant ones as default for
>> eclipse .project
>> etc files). I'd like to be able to import the projects with maven
>> into
>> Eclipse to work on things but without committing back changes to
>> eclipse
>> .project/.classpath/.settings/*.
>>
>> So I'm hoping for a fairly transparent process.
>
> So which are the files you don't want to import from trunk? It
> doesn't sound like there are any... so it's getting simpler already.
There are. I've currently (as a workaround) done the following within
the main branch:
add the following to .git/info/exclude
.settings
target
.classpath
.project
The last two of these has no effect of course because .project
and .classpath files already exist -- and thus are marked as modified.
So I'm currently doing a git stash && git svn rebase && git svn
dcommit && git stash pop
I'm also wanting to exclude 'lib' folders from trunk (as these are not
needed).
> Also, can you just simply not commit any changes to the other files?
> That would be the easiest way to deal with committing back.
That's what I'm doing now I guess - but it means I can't share the
project setups (specific for maven, for example) with anyone.
> The other
> option (slightly messier) is to change them in a single commit, and
> use git rebase to move that commit out of the way when you're about to
> push your changes back into svn.
Yeah that'd be a bit of a slippery slope.
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Avery Pennarun @ 2009-10-28 5:20 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git list
In-Reply-To: <AC7B0CB1-1B14-4EAE-A6B6-D0845EACE626@gmail.com>
On Tue, Oct 27, 2009 at 11:00 PM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> :) Sure. Essentially a project that I'm contributing to has both maven poms
> and ant/lib-based configs (with the ant ones as default for eclipse .project
> etc files). I'd like to be able to import the projects with maven into
> Eclipse to work on things but without committing back changes to eclipse
> .project/.classpath/.settings/*.
>
> So I'm hoping for a fairly transparent process.
So which are the files you don't want to import from trunk? It
doesn't sound like there are any... so it's getting simpler already.
Also, can you just simply not commit any changes to the other files?
That would be the easiest way to deal with committing back. The other
option (slightly messier) is to change them in a single commit, and
use git rebase to move that commit out of the way when you're about to
push your changes back into svn.
Have fun,
Avery
^ permalink raw reply
* [PATCH] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-28 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fixes some compiler warnings:
imap-send.c: In function ‘ssl_socket_connect’:
warning: assignment discards qualifiers from pointer target type
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
imap-send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..10dd025 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
fprintf(stderr, "SSL requested but SSL support not compiled in\n");
return -1;
#else
- SSL_METHOD *meth;
+ const SSL_METHOD *meth;
SSL_CTX *ctx;
int ret;
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] gitk: Use the --submodule option for diffs
From: Paul Mackerras @ 2009-10-28 4:03 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AE70AC9.6040302@web.de>
Jens Lehmann writes:
> Instead of just showing not-quite-helpful SHA-1 pairs display the first
> lines of the corresponding commit messages in the submodule (similar to
> the output of 'git submodule summary').
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> This patch applies to 'next' and uses the new --submodule option of git
> diff to achieve a more meaningful output of submodule differences in
> gitk.
(That sentence should have been in the commit message.)
> Any objections against making this the default?
What version of git is the first to have the --submodule option?
Since it's a new option we should make gitk use it only if the
underlying git is new enough, like we do with the --textconv option.
Also, the commit message is a bit sparse; it doesn't mention that this
affects the diff display, for instance.
Paul.
^ permalink raw reply
* Re: how to split a hunk
From: Geert Bosch @ 2009-10-28 3:11 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091028022105.GE3938@debian.b2j>
On Oct 27, 2009, at 22:21, bill lam wrote:
> There are occasions where diff of a file is
>
> - aaaa
> + bbbb
> + cccc
>
> I want to add lines bbbb and cccc as separated commits, but git-add -p
> seem cannot further split this hunk. Do I have no choice but to edit
> it by hand and commit the bbbb and then edit the file to add back the
> cccc?
>
I like to use "git gui" for this. This allows you to pick individual
lines to commit. I really like the "git gui" interface for staging/
unstaging
changes and making a series of commits.
-Geert
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Lachlan Deck @ 2009-10-28 3:00 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git list
In-Reply-To: <32541b130910271616ha861d08xa4b90b822d31f0ea@mail.gmail.com>
On 28/10/2009, at 10:16 AM, Avery Pennarun wrote:
> On Tue, Oct 27, 2009 at 7:00 PM, Lachlan Deck
> <lachlan.deck@gmail.com> wrote:
>> I'm wondering if it's possible to create a branch (starting as
>> local but
>> later on pushed to svn) that essentially stays in sync with the
>> main branch
>> (svn trunk) but both (a) ignores pulling in certain paths from
>> trunk and (b)
>> provides a few extra paths of its own (some of which overlap with
>> those
>> ignored from trunk) and (c) only pushes to trunk paths that are
>> relevant for
>> trunk (i.e., not specifically ignored)?
>>
>> If someone's able to share how they'd go about setting this up
>> that'd be
>> great.
>
> This sounds like a generally scary idea. Perhaps if you described
> your problem at a higher level (what are you really trying to
> achieve?) there would be a less scary way to do it.
:) Sure. Essentially a project that I'm contributing to has both maven
poms and ant/lib-based configs (with the ant ones as default for
eclipse .project etc files). I'd like to be able to import the
projects with maven into Eclipse to work on things but without
committing back changes to eclipse .project/.classpath/.settings/*.
So I'm hoping for a fairly transparent process.
> That said, if you *really* need this... one option that comes to
> mind is:
>
> 1. extract the history from svn into git using 'git svn' as usual.
>
> 2. extract the subtree of svn that you're interested in (if you're
> lucky enough that you only need one subtree) by using 'git subtree
> split'. This creates a new branch or new git repo, depending how you
> do it.
>
> 3. Create a third project that will host your new work with extra
> subtrees that you don't want. Use 'git subtree add' and 'git subtree
> merge' to keep this up to date with the stuff you extracted in step 2.
> (Repeat steps 1-3 as necessary to keep your project up to date with
> the svn project.)
>
> 4. When you want to merge your own changes back into svn, first
> extract them from your own project (step 3) using 'git subtree split'.
> Then merge those changes into the main project (step 1) using 'git
> subtree merge'. Then use git-svn to upload them to the main svn repo.
>
> You can save yourself some steps if you import the *entire* svn
> project into your own project, rather than trying to trim it on
> import. That way you only have to split when going from #3 to #1, not
> in the other direction, and you don't need repository #2.
>
> If all this sounds crazy, it probably is. Maybe see if you can come
> up with a way to avoid trying to do this altogether.
>
> Good luck... :)
Sounding scary. But if the above description of what I'm trying to
achieve helps in finding a simple way to work I'm all ears :)
Thanks.
> Avery
>
> [1] http://github.com/apenwarr/git-subtree
I'll check this out anyway. Thanks.
with regards,
--
Lachlan Deck
^ permalink raw reply
* how to split a hunk
From: bill lam @ 2009-10-28 2:21 UTC (permalink / raw)
To: git
There are occasions where diff of a file is
- aaaa
+ bbbb
+ cccc
I want to add lines bbbb and cccc as separated commits, but git-add -p
seem cannot further split this hunk. Do I have no choice but to edit
it by hand and commit the bbbb and then edit the file to add back the
cccc?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Stephen Boyd @ 2009-10-28 1:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <20091027185223.GH10505@spearce.org>
Shawn O. Pearce wrote:
> NAK on code duplication, especially this much. As Junio already
> pointed out in this thread we need an approach that doesn't cause
> this sort of redundant code.
Ok. Following Junio's suggestion I think we would have to do the following:
(1) Revert the rename (git-completion.bash.in -> git-completion.bash)
(2) Add a "generation" mode to git-completion.bash.generate to generate
the lists and output them to a file
(3) Add logic in git-completion.bash.generate to source the generated
file if it exists
(4) Source git-completion.bash.generate in git-completion.bash to get
the functions moved there
In the end we would have git-completion.bash sourcing
git-completion.bash.generate which then sources the generated file. I
assume this is slower than compiling to just one file.
Or we could just not load the caches until they're needed. This just
delays the performance hit to completion time, but at least it speeds up
loading the script without the need to compile and still has the benefit
of some caching. It also allows users to keep the completion of their
custom merge strategies and git programs in their PATH.
----8<----
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d3fec32..8a7cde3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -326,10 +326,15 @@ __git_remotes ()
__git_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
+ if [ -n "${__git_merge_strategylist-}" ] || {
+ __git_merge_strategylist=$(__git_merge_strategies_gen 2>/dev/null)
+ }; then
echo "$__git_merge_strategylist"
- return
fi
+}
+
+__git_merge_strategies_gen ()
+{
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -340,7 +345,6 @@ __git_merge_strategies ()
}'
}
__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
__git_complete_file ()
{
@@ -491,10 +495,15 @@ __git_complete_strategy ()
__git_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
+ if [ -n "${__git_all_commandlist-}" ] || {
+ __git_all_commandlist="$(__git_all_commands_gen 2>/dev/null)"
+ }; then
echo "$__git_all_commandlist"
- return
fi
+}
+
+__git_all_commands_gen ()
+{
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -505,14 +514,18 @@ __git_all_commands ()
done
}
__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
__git_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
+ if [ -n "${__git_porcelain_commandlist-}" ] || {
+ __git_porcelain_commandlist="$(__git_porcelain_commands_gen 2>/dev/null)"
+ }; then
echo "$__git_porcelain_commandlist"
- return
fi
+}
+
+__git_porcelain_commands_gen ()
+{
local i IFS=" "$'\n'
for i in "help" $(__git_all_commands)
do
@@ -596,7 +609,6 @@ __git_porcelain_commands ()
done
}
__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
^ permalink raw reply related
* Re: [RFC PATCH v3 10/17] Move WebDAV HTTP push under remote-curl
From: Shawn O. Pearce @ 2009-10-28 1:08 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Daniel Barkalow, Mike Hommey
In-Reply-To: <20091019105921.d58c2728.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Thu, Oct 15, 2009 at 11:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> > @@ -34,6 +34,10 @@ Commands are given by the caller on the helper's standard input, one per line.
> > value of the ref. A space-separated list of attributes follows
> > the name; unrecognized attributes are ignored. After the
> > complete list, outputs a blank line.
> > ++
> > +If 'push' is supported this may be called as 'list for-push'
> > +to obtain the current refs prior to sending one or more 'push'
> > +commands to the helper.
>
> The new paragraph should have the same indentation as 'list'.
Isn't the style I have here the standard way of adding a second
paragraph to a list item?
> It would have been great if you implemented this as a filter, such that
> 'list <attr>' lists the refs with the specified attribute <attr>,
> rather than hardcoding it.
Ack, will fix.
> > @@ -59,6 +63,22 @@ suitably updated.
> > +When the push is complete, outputs one or more 'ok <dst>' or
> > +'error <dst> <why>?' lines to indicate success or failure of
> > +each pushed ref. The status report output is terminated by
> > +a blank line. The option field <why> may be quoted in a C
> > +style string if it contains an LF.
>
> You should mention that this behaviour only occurs when the
> --helper-status option is used.
No. This manual page is about what a helper program must do, so I
mean what "git-remote-curl" must do. The fact that git-remote-curl
honors this output format via passing the --helper-status option
into a command it executes is an implementation detail.
> > @@ -106,6 +132,11 @@ OPTIONS
> > +'option dry-run' \{'true'|'false'\}:
> > + If true, pretend like the operation completed successfully,
> > + but don't actually change any repository data. For most
> > + helpers this only applies to the 'push', if supported.
> > +
>
> The 'like' after 'pretend' can be, like, removed. :)
Thanks, fixed.
> Two more areas in http-push.c that should have status messages
> (generated on top of pu):
I folded your patches into my series, thanks.
--
Shawn.
^ permalink raw reply
* [PATCH] add-interactive: handle deletion of empty files
From: Jeff King @ 2009-10-28 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Usually we show deletion as a big hunk deleting all of the
file's text. However, for files with no content, the diff
shows just the 'deleted file mode ...' line. This patch
cause "add -p" (and related commands) to recognize that line
and explicitly ask about deleting the file.
We only add the "stage this deletion" hunk for empty files,
since other files will already ask about the big content
deletion hunk. We could also change those files to simply
display "stage this deletion", but showing the actual
deleted content is probably what an interactive user wants.
Signed-off-by: Jeff King <peff@peff.net>
---
This bit me today. I expect it's pretty rare, but I don't see a reason
not to handle the corner case (and nor do I see a reason to change the
non-corner case, as explained above).
git-add--interactive.perl | 18 +++++++++++++-----
t/t3701-add-interactive.sh | 17 +++++++++++++++++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 69aeaf0..8ce1ec9 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -731,14 +731,17 @@ sub parse_diff_header {
my $head = { TEXT => [], DISPLAY => [], TYPE => 'header' };
my $mode = { TEXT => [], DISPLAY => [], TYPE => 'mode' };
+ my $deletion = { TEXT => [], DISPLAY => [], TYPE => 'deletion' };
for (my $i = 0; $i < @{$src->{TEXT}}; $i++) {
- my $dest = $src->{TEXT}->[$i] =~ /^(old|new) mode (\d+)$/ ?
- $mode : $head;
+ my $dest =
+ $src->{TEXT}->[$i] =~ /^(old|new) mode (\d+)$/ ? $mode :
+ $src->{TEXT}->[$i] =~ /^deleted file/ ? $deletion :
+ $head;
push @{$dest->{TEXT}}, $src->{TEXT}->[$i];
push @{$dest->{DISPLAY}}, $src->{DISPLAY}->[$i];
}
- return ($head, $mode);
+ return ($head, $mode, $deletion);
}
sub hunk_splittable {
@@ -1206,7 +1209,7 @@ sub patch_update_file {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
- ($head, my $mode) = parse_diff_header($head);
+ ($head, my $mode, my $deletion) = parse_diff_header($head);
for (@{$head->{DISPLAY}}) {
print;
}
@@ -1214,6 +1217,9 @@ sub patch_update_file {
if (@{$mode->{TEXT}}) {
unshift @hunk, $mode;
}
+ if (@{$deletion->{TEXT}} && !@hunk) {
+ @hunk = ($deletion);
+ }
$num = scalar @hunk;
$ix = 0;
@@ -1267,7 +1273,9 @@ sub patch_update_file {
print;
}
print colored $prompt_color, $patch_mode_flavour{VERB},
- ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' : ' this hunk'),
+ ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' :
+ $hunk[$ix]{TYPE} eq 'deletion' ? ' deletion' :
+ ' this hunk'),
$patch_mode_flavour{TARGET},
" [y,n,q,a,d,/$other,?]? ";
my $line = prompt_single_character;
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 687bd7a..768236b 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -228,4 +228,21 @@ test_expect_success 'add first line works' '
test_cmp expected diff
'
+cat >expected <<EOF
+diff --git a/empty b/empty
+deleted file mode 100644
+index e69de29..0000000
+EOF
+
+test_expect_success 'deleting an empty file' '
+ git reset --hard &&
+ > empty &&
+ git add empty &&
+ git commit -m empty &&
+ rm empty &&
+ echo y | git add -p empty &&
+ git diff --cached >diff &&
+ test_cmp expected diff
+'
+
test_done
--
1.6.5.2.193.g57820
^ permalink raw reply related
* Re: [PATCH] bash: complete more options for 'git rebase'
From: Shawn O. Pearce @ 2009-10-28 0:32 UTC (permalink / raw)
To: Bj??rn Gustavsson; +Cc: git
In-Reply-To: <4AD98F72.1060901@gmail.com>
Bj??rn Gustavsson <bgustavsson@gmail.com> wrote:
> Complete all long options for 'git rebase' except --no-verify
> (probably used very seldom) and the long options corresponding
> to -v, -q, and -f.
>
> Signed-off-by: Bj??rn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> I am primarily interested in having the --whitespace= option completed,
> but while at it I have added completion for the other potentially useful
> long options.
Indeed, this would be nice. :-)
--
Shawn.
^ 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