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 negativ
On Sat, Mar 2, 2013 at 3:06 AM, Thomas Rast 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 paths are the same as
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 t
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 --
On Fri, Mar 01, 2013 at 03:49:23PM -0800, Junio C Hamano wrote:
> Jeff King 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 bef
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
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
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
Jeff King 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;
> }
>
> +s
Jeff King writes:
> On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote:
>
>> Jeff King 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 f
Jeff King 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...
>
On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote:
> Jeff King 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 wri
David Madore 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 be "git push . n
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 trivial
Jeff King 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 p
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
> > subje
Jeff King 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 c
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,
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,
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 (t
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
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 from
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
84d832fc70a053e97ce336c4a0af03714
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal wrote:
> David Michael Barr 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 vcs-svn/ and
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Thomas Rast 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 pa
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
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 & c
Junio C Hamano writes:
> Thomas Rast 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
Thomas Rast 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
> `.gitignore` files; se
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
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 those
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 worki
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 http://vger.kernel.org/
"W. Trevor King" 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.
That it has b
Jan Pešta 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 1.5.x in this me
Francis Moreau 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 assurance:
The
Signed-off-by: Andrew Wong
---
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
+++ b/Documentation/githooks.txt
@@ -365,7 +365,7 @@
Jeff King 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 point
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 proj
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
Th
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 the
Thomas Rast writes:
> Junio C Hamano 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 first line of
>> outp
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 th
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 mergei
Jan Pešta 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).
Thanks,
--
Matthieu
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 P
Jan Pešta 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 this extra "*" commin
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 Message-
Jan Pešta 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 body of a message to
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., www
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 majord...@vger.kernel.
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. unmerg
Junio C Hamano writes:
> Junio C Hamano 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 globally regardless of
53 matches
Mail list logo
