During a revision traversal in which --max-count has been
specified, we decrement a counter for each revision returned
by get_revision. When it hits 0, we typically return NULL
(the exception being if we still have boundary commits to
show).
However, before we check the counter, we call get_revisi
On Fri, Jul 13, 2012 at 03:50:23AM -0400, Jeff King wrote:
> revision.c | 39 +++
> 1 file changed, 19 insertions(+), 20 deletions(-)
BTW, the patch is slightly hard to read because of the re-indentation.
Here it is with "-w -U5":
diff --git a/revision.c b/re
On Thu, Jul 12, 2012 at 03:17:09PM -0700, Douglas Garstang wrote:
> I'm a relative newcomer to git and I've just inherited a setup where
> all of the company's code is in a single git repository. Within this
> repository are multiple projects. It seems that git doesn't natively
> allow cloning/che
Junio C Hamano writes:
> But is it really true that we want to error out on missing HOME if
> we have usable XDG stuff?
Anyone else have an opinion on this?
In short, the question is whether
export XDG_CONFIG_HOME=some-existing-dir
unset HOME
git config foo.baz boz
should die("$HOME is
Hello,
[I added git@vger.k.o to Cc: please strip the recipents accordingly if
you reply.]
On Fri, Jul 13, 2012 at 09:02:56AM +1000, Marc Reilly wrote:
> Hi Uwe,
>
> > This series was tested on a Phytec pcm038 (mc13783 on spi) using
> > traditional boot (i.e. not dt) and on a i.MX53 based machine
When $HOME is unset, home_config_paths fails and returns NULL pointers
for user_config and xdg_config. Valgrind complains with Syscall param
access(pathname) points to unaddressable byte(s).
Don't call blindly access() on these variables, but test them for
NULL-ness before.
The when the XDG confi
Jeff King writes:
> On Thu, Jul 12, 2012 at 08:00:17PM +0200, Felix Natter wrote:
>
>> I am trying to move freeplane's repository (GPL-project) from bzr to
>> git, but when I do this:
>>
>> $ mkdir freeplane-git1
>> $ cd freeplane-git1
>> $ git init .
>> $ bzr fast-export --export-marks=../marks
On Fri, Jul 13, 2012 at 10:48:18AM +0200, Matthieu Moy wrote:
> Junio C Hamano writes:
>
> > But is it really true that we want to error out on missing HOME if
> > we have usable XDG stuff?
>
> Anyone else have an opinion on this?
>
> In short, the question is whether
>
> export XDG_CONFIG_
On Fri, Jul 13, 2012 at 11:04:21AM +0200, Andreas Schwab wrote:
> > If you run only the bzr half of your command and inspect the output, you
> > will see that the file in question is mentioned twice. Once in a commit
> > on "refs/heads/master" that renames into it from another file:
> >
> > R
Jeff King writes:
> On Fri, Jul 13, 2012 at 10:48:18AM +0200, Matthieu Moy wrote:
>
>> Junio C Hamano writes:
>>
>> > But is it really true that we want to error out on missing HOME if
>> > we have usable XDG stuff?
>>
>> Anyone else have an opinion on this?
>>
>> In short, the question is wh
Jeff King writes:
> On Fri, Jul 13, 2012 at 11:04:21AM +0200, Andreas Schwab wrote:
>
>> > If you run only the bzr half of your command and inspect the output, you
>> > will see that the file in question is mentioned twice. Once in a commit
>> > on "refs/heads/master" that renames into it from a
Matthieu Moy writes:
> Jeff King writes:
>
>> On Fri, Jul 13, 2012 at 10:48:18AM +0200, Matthieu Moy wrote:
>>
>>> Junio C Hamano writes:
>>>
>>> > But is it really true that we want to error out on missing HOME if
>>> > we have usable XDG stuff?
>>>
>>> Anyone else have an opinion on this?
>
Thomas Rast writes:
> Umm, are you sure? I may be somewhat confused about this, but the tests
> I used to trigger the access(NULL) were IIRC
>
> unset HOME
> git config --get foo.bar
> git config --global --get foo.bar
>
> none of which is writing
I was inaccurate, but that doesn't ch
Greetings everyone,
I'm wondering how to commit only selected files/folders on GIT, if even
possible. Note, the ignore list is not a good option for me as I'd like
to add a few files in a folder that contains many hundreds for instance.
Basically, I'm looking for a way to say, don't share any
Greetings everyone,
I'm wondering how to commit only selected files/folders on GIT, if even
possible. Note, the ignore list is not a good option for me as I'd like
to add a few files in a folder that contains many hundreds for instance.
Basically, I'm looking for a way to say, don't share any
On Fri, Jul 13, 2012 at 10:59:55AM -0400, Yves Perron wrote:
> I'm wondering how to commit only selected files/folders on GIT, if even
> possible.
Just "git add" only the files you need.
If you want git to ignore all the rest, you can write '*' in your
.gitignore
--
Edward "Hades" Toroshchin
d
If git am fails to apply something, the end user may need
to know where to find the patch. This is normally known for
a single patch, but if the user is processing a mbox with
many patches, they may not have a single broken out patch
handy. So, provide a helpful hint as to where they can
find the
On Fri, Jul 13, 2012 at 11:35:36AM -0400, Yves Perron wrote:
> Oh I see, thank you for your response,
>
> Can I put all the folders/files I want to add in a config file so I
> don't have to do this every time?
>
> Thx
>
You won't have to do this every time. Once you add a file and commit it,
g
Matthieu Moy writes:
> The old code was:
>
> if (use_global_config) {
> char *home = getenv("HOME");
> if (home) {
> char *user_config = xstrdup(mkpath("%s/.gitconfig",
> home));
> given_config_file = user_co
On 12-07-12 04:00 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
> This is _NOT_ fine, especially if you suggest "patch" the user may
> not have, and more importantly does not have a clue why "git apply"
> rejected it ("am" does _not_ use "patch" at all).
I'm not 100%
Ok, let me rephrase, is there a way to edit a file where we can put
every files/folders we need to add without the need of entering a
command for each entry?
On 7/13/2012 12:14 PM, Edward Toroshchin wrote:
On Fri, Jul 13, 2012 at 11:35:36AM -0400, Yves Perron wrote:
Oh I see, thank you for y
Yves Perron, Fri 2012-07-13 @ 13:40:56-0400:
> Ok, let me rephrase, is there a way to edit a file where we can put
> every files/folders we need to add without the need of entering a
> command for each entry?
Sure, but you don't need functionality built in to Git to do this. Just
list the paths yo
Paul Gortmaker writes:
> Sorry, that description was a bit context free. Two typical cases:
>
> 1) applying a series of commits (e.g. preempt RT feature) to a newer
> baseline. Some of those commits may have been upstreamed and now
> present in mainline. The "git am" failure doesn't really hint
On 7/13/2012 8:21 AM, Edward Toroshchin wrote:
> On Fri, Jul 13, 2012 at 10:59:55AM -0400, Yves Perron wrote:
>> I'm wondering how to commit only selected files/folders on GIT, if even
>> possible.
> Just "git add" only the files you need.
>
> If you want git to ignore all the rest, you can write '
On 7/13/2012 2:08 PM, Illia Bobyr wrote:
*
!.gitignore
!a_file_that_should_be_tracked
!a_dir_to_track/
That is exactly what i was hoping for,
thank you everyone!
--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
On 12-07-11 06:04 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> On 12-07-11 02:21 PM, Junio C Hamano wrote:
>>> marcn...@xiplink.com writes:
>>>
From: Marc Branchaud
The code now has a default_remote_name and an effective_remote_name:
- default_remote_name is
Uwe Kleine-König writes:
> It doesn't move it around, that's only how it looks. I removed enum
> mc13xxx_id (above MC13XXX_NUMREGS) and added struct mc13xxx_variant
> (below MC13XXX_NUMREGS). Git choosed to use the closing brace of enum
> mc13xxx_id and struct mc13xxx_variant respectively as con
On 12-07-11 05:55 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> What about a warning displayed if "remote.default" is not set? Something
>> like:
>>
>> This repository does not have an explicitly configured default
>> remote. Selecting "origin" as the default remote reposit
Paul Gortmaker writes:
> If git am fails to apply something, the end user may need
> to know where to find the patch. This is normally known for
> a single patch, but if the user is processing a mbox with
> many patches, they may not have a single broken out patch
> handy. So, provide a helpful
Marc Branchaud writes:
>> Is it even a _side effect_? Isn't this one of the primary points of
>> the series? I do not think this patch makes sense if we did not
>> want that change to happen.
>>
>> Or am I missing something?
>
> No, you're not -- I agree that this change in behaviour makes sen
Jeff King writes:
> There's no need to make this get_revision_1 call when our
> counter runs out. If we are not in --boundary mode, we will
> just throw away the result and immediately return NULL. If
> we are in --boundary mode, then we will still throw away the
> result, and then start showing
On Fri, Jul 13, 2012 at 02:10:54PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There's no need to make this get_revision_1 call when our
> > counter runs out. If we are not in --boundary mode, we will
> > just throw away the result and immediately return NULL. If
> > we are in --bound
Jeff King writes:
> Yeah, this was my analysis, too. Though reading get_revision-1, it seems
> like we can actually set SHOWN, but I wasn't able to trigger any change
> of behavior in practice. I think it is because we must set both SHOWN
> and BOUNDARY to have an effect, and we do not do so.
In
On 12-07-13 03:58 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
>> If git am fails to apply something, the end user may need
>> to know where to find the patch. This is normally known for
>> a single patch, but if the user is processing a mbox with
>> many patches, they may not have a sin
On 07/12/2012 01:30 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I think the other tests in t/ prefer to unquote it so that we would
>> ignore spaces around "wc -l" output, i.e.
>>
>> test $(wc -l >
>> Thanks for a report.
>
> -- >8 --
> Subject: [PATCH] t1512: ignore whitespaces
Paul Gortmaker writes:
> I'm fine with the changes you've proposed below,...
Here is what I committed for today's integration run. Will be
pushed out on 'pu'.
Thanks.
-- >8 --
From: Paul Gortmaker
Date: Fri, 13 Jul 2012 11:51:30 -0400
Subject: [PATCH] am: indicate where a failed patch is to
Stefano Lattarini writes:
> On 07/12/2012 01:30 AM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> I think the other tests in t/ prefer to unquote it so that we would
>>> ignore spaces around "wc -l" output, i.e.
>>>
>>> test $(wc -l >>
>>> Thanks for a report.
>>
>> -- >8 --
>> Su
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
The sixth batch of topics are now in 'master'.
You can find the changes described here in the integration branches of the
repositories listed a
Hi,
Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even
further up the tree. It would be really nice if I didn't have to type
'HEAD^' but could only type '^'. Bash completion make things easier
but it automatically inserts a space immediately after HEAD so you
have to hit backspace
On Thursday 12 July 2012 05:32:21 Jeff King wrote:
> [...] which means you are probably not even getting to use all 4Gb of your
> address space (my impression is that without special flags, 32-bit Windows
> processes are limited to 2Gb of address space).
Indeed, that's how windows partitions memo
40 matches
Mail list logo
