Re: [PATCH v8 4/5] Implement line-history search (git log -L)

2013-03-01 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: Overall, I like this better than the log --follow hack; as the revision traversal is done without any pathspec when being careful and slow (aka -M), you do not suffer from the just use a singleton pathspec

Re: two-way merge corner case bug

2013-03-01 Thread Jeff King
On Tue, Feb 26, 2013 at 01:41:54PM -0800, Junio C Hamano wrote: Isn't this a repeat of: http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=212316 [...] Yeah, I think the patch in your message is a good starting point to solve a half of the issue (i.e. unmerged

Adding --ignore-submodules switch to git-describe

2013-03-01 Thread Francis Moreau
Hello, Would it make sense to add the option --ignore-submodules (currently available in git-status) to git-describe when the later is used with --dirty option ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

[PATCH]

2013-03-01 Thread Jan Pešta
Hi, I found a problem when using GIT-SVN. In inproperly merges in SVN causes that the ranges contains additional character *. Attached patch fix this issue, I have it already tested for several months. Regards, Jan Kind regards / S pozdravem   Jan Pešta SW Engineer Sr. CertiCon a.s.,

Re: [PATCH]

2013-03-01 Thread Matthieu Moy
Jan Pešta jan.pe...@certicon.cz writes: Attached patch fix this issue, Nothing attached, it seems ;-). Please, read Documentation/SubmittingPatches in Git's source code. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the

[PATCH] GIT SVN

2013-03-01 Thread Jan Pešta
Sorry, My fault :) Here is a patch atached. Jan Kind regards / S pozdravem   Jan Pešta SW Engineer Sr. CertiCon a.s., www.certicon.cz Vaclavska 12 12000 Prague 2 Czech Republic   Office Prague: +420 224 904 406 Mobile: +420 604 794 306   E-mail: jan.pe...@certicon.cz -Original

Re: [PATCH] GIT SVN

2013-03-01 Thread Matthieu Moy
Jan Pešta jan.pe...@certicon.cz writes: Sorry, My fault :) Here is a patch atached. Still, please, read Documentation/SubmittingPatches. Your patch cannot be included as it is because of lack of sign-off. Also, please write a commit message describing why this change is needed. Where is

RE: [PATCH] GIT SVN

2013-03-01 Thread Jan Pešta
Hi again, Finally I created patch according to document. Please have a look on referenced site for more details. Currently I have a problems in our project, where SVN is main repository and merge-info contains * which causes troubles in SVN.pm. Regards, Jan Kind regards / S pozdravem   Jan

Re: [PATCH] GIT SVN

2013-03-01 Thread Matthieu Moy
Jan Pešta jan.pe...@certicon.cz writes: Hi again, Finally I created patch according to document. This is much better, but you still haven't taken into account some important parts of Documentation/SubmittingPatches (the part about attachments Vs inline patch, and the part about sign-off).

[PATCH] In inproperly merges, the ranges contains additional character *

2013-03-01 Thread Jan Pešta
In inproperly merges, the ranges contains additional character *. See http://www.open.collab.net/community/subversion/articles/merge-info.html Extract: The range r30430:30435 that was added to 1.5.x in this merge has a '*' suffix for 1.5.x\www. This '*' is the marker for a non-inheritable

Re: Ignore version update changes on git show report?

2013-03-01 Thread Michael J Gruber
Preben Liland Madsen venit, vidit, dixit 26.02.2013 20:53: Hello, I'm trying to investigate some what changes have been done between two versions of a software with the name IP.Board. This proves more troublesome than I thought, since their release builder appearantly updates the

Re: [PATCH v8 4/5] Implement line-history search (git log -L)

2013-03-01 Thread Thomas Rast
Thomas Rast tr...@student.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: I notice that careful and slow is just too slow to be usable even on a small tree like ours. Try running $ git log -M -L:get_name:builtin/describe.c and see how long you have to wait until you hit the

Re: Ignore version update changes on git show report?

2013-03-01 Thread Preben Liland Madsen
Den 1. mars 2013 kl. 14.33 skrev Michael J Gruber: First of all, there is git beat-with-stick that you should apply to those responsible for that mess ;) Haha, yeah I should try that one ;-) I wish they weren't included in their release, but what can you do... I'm sure they have their

Elegant subdirectory checkout of remote-tracking branch?

2013-03-01 Thread W. Trevor King
I'm trying to figure out the most efficient way to keep an up to date `todo` branch checked out in Meta [1]. I've tried a few things like: $ git submodule add -b refs/remotes/origin/todo --reference ./ -- ./ Meta and: $ git clone --single-branch --branch refs/remotes/origin/todo ./ Meta

Debugging a bizarre problem: What can influence 'git fetch'?

2013-03-01 Thread git-users
Hello. I'm working on a small project that talks to external git and fossil repositories. I've run into a bizarre this cannot happen problem and am completely mystified as to what's causing it. Essentially, the problem is that a particular git command, run as part of the unit tests for the

Re: two-way merge corner case bug

2013-03-01 Thread Junio C Hamano
Jeff King p...@peff.net writes: PS I wonder if the initial_checkout hack can just go away under this new rule. Although we don't seem to use o-reset for the initial checkout. Which seems kind of weird. I would think the initial checkout would actually just be a oneway merge. Is the

[PATCH] Documentation/githooks: Fix linkgit

2013-03-01 Thread Andrew Wong
Signed-off-by: Andrew Wong andrew.k...@gmail.com --- Documentation/githooks.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 8181e4e..eab9b35 100644 --- a/Documentation/githooks.txt +++

Re: Adding --ignore-submodules switch to git-describe

2013-03-01 Thread Junio C Hamano
Francis Moreau francis.m...@gmail.com writes: Would it make sense to add the option --ignore-submodules (currently available in git-status) to git-describe when the later is used with --dirty option ? I think the spirit of describe --dirty is to allow people who gives out binaries this

Re: [PATCH] In inproperly merges, the ranges contains additional character *

2013-03-01 Thread Junio C Hamano
Jan Pešta jan.pe...@certicon.cz writes: In inproperly merges, the ranges contains additional character *. Thanks, but -ECANNOTPARSE. What are inproperly merges? See http://www.open.collab.net/community/subversion/articles/merge-info.html Extract: The range r30430:30435 that was added to

Re: Elegant subdirectory checkout of remote-tracking branch?

2013-03-01 Thread Junio C Hamano
W. Trevor King wk...@tremily.us writes: Any suggestions for an elegant solution would be appreciated :). My Meta checkout is not a submodule of anything. It is a totally independent repository and is not linked with git.git in any way. It started as an independent repository, and it still is.

Re: [PATCH] Documentation/githooks: Fix linkgit

2013-03-01 Thread Junio C Hamano
Thanks. grep linkgit *.html in the installed documentation area tells me that this is the only instance that needs to be fixed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Adding --ignore-submodules switch to git-describe

2013-03-01 Thread Jens Lehmann
Am 01.03.2013 18:46, schrieb Junio C Hamano: I think what is missing from --dirty is not --ignore-submodules, but --do-not-ignore-untracked option [*1*]. describe --dirty ignores untracked files in the superproject by default, and we should ignore untracked files in submodule working trees,

[PATCH] Make !pattern in .gitattributes non-fatal

2013-03-01 Thread Thomas Rast
Before 82dce99 (attr: more matching optimizations from .gitignore, 2012-10-15), .gitattributes did not have any special treatment of a leading '!'. The docs, however, always said The rules how the pattern matches paths are the same as in `.gitignore` files; see linkgit:gitignore[5]. By

Re: [PATCH] Make !pattern in .gitattributes non-fatal

2013-03-01 Thread Junio C Hamano
Makes sense. Duy? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Make !pattern in .gitattributes non-fatal

2013-03-01 Thread Junio C Hamano
Thomas Rast tr...@student.ethz.ch writes: Before 82dce99 (attr: more matching optimizations from .gitignore, 2012-10-15), .gitattributes did not have any special treatment of a leading '!'. The docs, however, always said The rules how the pattern matches paths are the same as in

Re: [PATCH] Make !pattern in .gitattributes non-fatal

2013-03-01 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes: Thomas Rast tr...@student.ethz.ch writes: Before 82dce99 (attr: more matching optimizations from .gitignore, 2012-10-15), .gitattributes did not have any special treatment of a leading '!'. The docs, however, always said The rules how the pattern

Re: problem switching branches

2013-03-01 Thread J.V.
On 2/26/2013 10:17 PM, Jeff King wrote: On Tue, Feb 26, 2013 at 04:08:55PM -0700, J.V. wrote: I was on my master branch, I then checked out a branch ( origin/somebranch ), made no updates but did a few git pulls on the branch over about a week; then made a small change to only a single file

RE: [PATCH] In inproperly merges, the ranges contains additional character *

2013-03-01 Thread Jan Pešta
Hi Junio, You have right. But I think if there is a * sign, it should be skiped, instead of failing on comparing string with a number. I will prepare another patch. Regards, Jan Kind regards / S pozdravem Jan Pešta SW Engineer Sr. CertiCon a.s., www.certicon.cz Vaclavska 12 12000 Prague 2

Re: [PATCH] Make !pattern in .gitattributes non-fatal

2013-03-01 Thread Junio C Hamano
Thomas Rast tr...@student.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: Thomas Rast tr...@student.ethz.ch writes: Before 82dce99 (attr: more matching optimizations from .gitignore, 2012-10-15), .gitattributes did not have any special treatment of a leading '!'. The docs,

Re: Subtree in Git

2013-03-01 Thread Paul Campbell
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal kind...@gmail.com wrote: David Michael Barr b at rr-dav.id.au writes: From a quick survey, it appears there are no more than 55 patches squashed into the submitted patch. As I have an interest in git-subtree for maintaining the out-of-tree version of

[ANNOUNCE] Git v1.8.1.5

2013-03-01 Thread Junio C Hamano
The latest maintenance release Git v1.8.1.5 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 3349a15de7c5501715bda9b68301d0406272f8e0 git-1.8.1.5.tar.gz

[git] [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread William Giokas
All, I've been using git for a while and this is the first time I've had to use `git am` and I've got a 16 patch patchset that I'm looking to apply. The files were copied to a separate maildir by mutt to keep things clean, and then I ran `git am -i /path/to/maildir/` expecting things to start

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Junio C Hamano
William Giokas 1007...@gmail.com writes: All, I've been using git for a while and this is the first time I've had to use `git am` and I've got a 16 patch patchset that I'm looking to apply. The files were copied to a separate maildir by mutt to keep things clean, and then I ran `git am -i

Re: two-way merge corner case bug

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote: An initial checkout is *supposed* to happen in an empty working tree, so if we code it not to overwrite an existing path in the working tree, the user cannot lose possibly precious contents with an mistaken initial checkout (they

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 02:27:32PM -0800, Junio C Hamano wrote: I've been using git for a while and this is the first time I've had to use `git am` and I've got a 16 patch patchset that I'm looking to apply. The files were copied to a separate maildir by mutt to keep things clean, and

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote: Note to bystanders. This is coming from populate_maildir_list() in builtin/mailsplit.c; the function claims to know what maildir should look like, so it should be enforcing the ordering as necessary by sorting the list, _if_ the

Re: two-way merge corner case bug

2013-03-01 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote: Nobody seems to use that combination, either from scripts or from C (i.e. when opts.update==1 and opts.merge==1, opts.reset is not set) with a twoway merge, other than git am --abort/--skip. I

Re: two-way merge corner case bug

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 03:06:57PM -0800, Junio C Hamano wrote: I can believe it. So do we want to do that fix, then? Did you want to roll up the two halves of it with a test and write a commit message? I feel like you could write a much more coherent one than I could on this subject.

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote: ... The maildir spec explicitly says that readers should not make assumptions about the content of the filenames. Mutt happens to write them as: ${epoch_seconds}.${pid}_${seq}.${host} so in

suggestion for a simple addition: git update-ref --ff-only

2013-03-01 Thread David Madore
Hi list, I'd like to suggest a very simple, but IMHO quite useful, additional option to git-update-ref: an option --ff-only which would cause the command to refuse unless the current ref is an ancestor of the new one. The reason I think it would be useful: I occasionally wish to perform a

Re: suggestion for a simple addition: git update-ref --ff-only

2013-03-01 Thread Junio C Hamano
David Madore david+n...@madore.org writes: Hi list, I'd like to suggest a very simple, but IMHO quite useful, additional option to git-update-ref: an option --ff-only which would cause the command to refuse unless the current ref is an ancestor of the new one. Mild NAK. What you want may

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote: ... The maildir spec explicitly says that readers should not make assumptions about the content of the filenames. Mutt happens to

Re: two-way merge corner case bug

2013-03-01 Thread Junio C Hamano
Jeff King p...@peff.net writes: I actually was wondering if we can remove that sole uses of two-way merge with --reset -u from git am and replace them with something else. But we do want to keep local change that existed before am started, so we cannot avoid use of two-way merge, I guess...

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote: ... The maildir spec explicitly says that readers should not make assumptions about the content

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Junio C Hamano
Jeff King p...@peff.net writes: diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c index 2d43278..772c668 100644 --- a/builtin/mailsplit.c +++ b/builtin/mailsplit.c @@ -130,6 +130,26 @@ static int populate_maildir_list(struct string_list *list, const char *path) return 0; }

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 03:57:39PM -0800, Junio C Hamano wrote: The epoch_seconds are the time of writing into the maildir. They will typically all be the same, unless your system is very slow, or you are writing a really long patch series. The PID likewise should be the same for a given

Re: [bug report] git-am applying maildir patches in reverse

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 04:08:04PM -0800, Junio C Hamano wrote: +static int maildir_filename_cmp(const char *a, const char *b) +{ + while (1) { It is somewhat funny that we do not need to check !*a or !*b in this loop. As long as readdir() does not return duplicates, we won't be

[BUG?] am --abort on null cache entries fails

2013-03-01 Thread Stephen Boyd
Hi, I was trying git am -3 with a patch that touched files that didn't exist in the branch I was on. Obviously it failed badly, so I wanted to abort out of the git am state with git am --abort. Unfortunately, it seems that git am --abort in this scenario fails with this error: error: cache entry

Re: two-way merge corner case bug

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 03:49:23PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: I actually was wondering if we can remove that sole uses of two-way merge with --reset -u from git am and replace them with something else. But we do want to keep local change that existed

Re: [BUG?] am --abort on null cache entries fails

2013-03-01 Thread Jeff King
On Fri, Mar 01, 2013 at 04:52:16PM -0800, Stephen Boyd wrote: I was trying git am -3 with a patch that touched files that didn't exist in the branch I was on. Obviously it failed badly, so I wanted to abort out of the git am state with git am --abort. Unfortunately, it seems that git am

Re: suggestion for a simple addition: git update-ref --ff-only

2013-03-01 Thread Jeff King
On Sat, Mar 02, 2013 at 12:18:59AM +0100, David Madore wrote: I'd like to suggest a very simple, but IMHO quite useful, additional option to git-update-ref: an option --ff-only which would cause the command to refuse unless the current ref is an ancestor of the new one. The reason I think

Re: [PATCH] Make !pattern in .gitattributes non-fatal

2013-03-01 Thread Duy Nguyen
On Sat, Mar 2, 2013 at 3:06 AM, Thomas Rast tr...@student.ethz.ch wrote: Before 82dce99 (attr: more matching optimizations from .gitignore, 2012-10-15), .gitattributes did not have any special treatment of a leading '!'. The docs, however, always said The rules how the pattern matches

[PATCH] attr: always treat the leading exclamation mark as literal

2013-03-01 Thread Nguyễn Thái Ngọc Duy
8b1bd02 (Make !pattern in .gitattributes non-fatal - 2013-03-01) raises the fact that even though '!' should have been a negative pattern indicator, people have been misusing for plain '!' and old Git versions accept that. This makes the leading '!' a de facto literal. We can't ever make it