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
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
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.
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
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
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:
> 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
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:
> 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
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
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
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
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
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
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
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
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 @@
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
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
"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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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,
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 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 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
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
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
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
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...
>
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:
> 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
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
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
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 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
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 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 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
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
53 matches
Mail list logo
