From: Johannes Sixt
For some reason, 'echo X | dd bs=1k seek=1' creates a file with 2050 bytes
on Windows instead of the expected 1026 bytes, so that a test fails. Since
the actual contents of the file are irrelevant as long as there is at
least one zero byte so that the diff machinery recognizes
Am 7/12/2012 1:30, schrieb Junio C Hamano:
> - test "$(wc -l + test $(wc -l http://vger.kernel.org/majordomo-info.html
Hi all,
This patch causes valgrind warnings in t1300.81 (get --path copes with
unset $HOME) about passing NULL to access():
==25286== Syscall param access(pathname) points to unaddressable byte(s)
==25286==at 0x56E2227: access (in /lib64/libc-2.14.1.so)
==25286==by 0x48CA42: git_config_ea
Dear list,
Is there any option to add user-name and password with git push ?
Or any repo wise configuration file where I can save the info, so that
it doesn't ask the credential before every push ?
Thanks
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
Junio C Hamano writes:
> is easier to understand, while I think
>
> git branch []
> git branch --set-upstream-to= []
Isn't one problem with this that even if a "--set-upstream-to" option
exists, inevitably some [and I'm guessing, many] people will not be
aware of it (after all, nob
On Wed, Jun 13, 2012 at 11:27:04AM +0100, Thomas Lucas wrote:
> Hopefully this is the right place to send bug reports... The
> community page "http://git-scm.com/community"; suggests that it is.
It is the right place. Sorry that you did not get any response before
now.
> During garbage collectio
On Thu, Jul 12, 2012 at 01:48:44PM +0530, J. Bakshi wrote:
> Is there any option to add user-name and password with git push ?
The username can go in the URL. For example:
git push user@host:repo.git
for ssh, or:
git push https://user@host/repo.git
for http.
For ssh, you can't specify a
On Wed, 2012-07-11 at 09:53 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto writes:
>
> > I've added a bit of code to also remove branch.foo.rebase, which
> > I'd also consider to be part of the upstream information.
>
> If "git branch -t" or "git branch --set-upstream" took another
> option
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.
Signed-off-by: Matthie
On 07/12/2012 12:12 AM, Alexander Strasser wrote:
> The nested quoting is not needed in this cases, thus the previous
> version did work just fine. Never the less the usage is misleading,
> so just achieve nested quoting by using double quotes instead. Lower
> the probability of breakage in the fut
> At the moment the bare repository is about 4Gb in size and about 2/3rds the
> way through fetching.
That's a big repo. Lots of binary files in it?
Does git fsck run normally? Does it report a lot of dangling blogs/commits/etc?
Philippe
--
To unsubscribe from this list: send the line "unsubscri
Matthieu Moy writes:
> 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-ne
I've witnessed the following behavior in both git 1.7.6 and 1.7.10.4.
Assume I have a bare clone, some-repo.git. If I run:
- git clone --shared --no-checkout /path/to/some-repo.git shared-repo
- cd shared-repo
- git status
I see that every file in the repository is _staged_ for deletion. I'm
not
On Thu, Jul 12, 2012 at 5:18 AM, J. Bakshi
wrote:
> Or any repo wise configuration file where I can save the info, so that
> it doesn't ask the credential before every push ?
>
I'd like to know how to do that too.
It's a pain to have to type username and password every time I need to
push to gith
Hi,
On 12-07-12 17:04, Thiago Farina wrote:
> On Thu, Jul 12, 2012 at 5:18 AM, J. Bakshi
> wrote:
>> Or any repo wise configuration file where I can save the info, so that
>> it doesn't ask the credential before every push ?
>>
> I'd like to know how to do that too.
>
> It's a pain to have to ty
If git am wasn't run with --reject, we assume the end user
knows where to find the patch. This is normally true 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 p
Miles Bader writes:
> Junio C Hamano writes:
>> is easier to understand, while I think
>>
>> git branch []
>> git branch --set-upstream-to= []
>
> Isn't one problem with this that even if a "--set-upstream-to" option
> exists, inevitably some [and I'm guessing, many] people will no
Johannes Sixt writes:
> Am 7/12/2012 1:30, schrieb Junio C Hamano:
>> -test "$(wc -l > +test $(wc -l
> We have a helper function for this:
>
> test_line_count = 16 actual &&
OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...
Am 11.07.2012 23:08, schrieb Jens Lehmann:
> Am 11.07.2012 22:39, schrieb Johannes Sixt:
>> At this point we can be in a subdirectory of the worktree. With
>> cd_to_toplevel we move up in the directory hierarchy ("cd out"). Then a
>> relative $gitdir or $sm_path now points to the wrong directory. N
Matthieu Moy writes:
> 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-ne
Thiago Farina writes:
> On Thu, Jul 12, 2012 at 5:18 AM, J. Bakshi
> wrote:
>> Or any repo wise configuration file where I can save the info, so that
>> it doesn't ask the credential before every push ?
>>
> I'd like to know how to do that too.
>
> It's a pain to have to type username and passwo
Bryan Turner writes:
> I've witnessed the following behavior in both git 1.7.6 and 1.7.10.4.
>
> Assume I have a bare clone, some-repo.git. If I run:
> - git clone --shared --no-checkout /path/to/some-repo.git shared-repo
> - cd shared-repo
> - git status
I do not recall we *designed* it in such
Paul Gortmaker writes:
> If git am wasn't run with --reject, we assume the end user
> knows where to find the patch. This is normally true for
> a single patch,
Not at all. Whether it is a single or broken, the patch is fed to
underlying "apply" from an unadvertised place.
> So, provide a hel
Since 69c3051 (submodules: refactor computation of relative gitdir path)
cloning a submodule recursively fails for nested submodules when a
symbolic link is part of the path to the work tree of the superproject.
This happens when module_clone() tries to find the relative paths between
the work tre
hi,
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.bzr ../trunk/ | git fast-import
--export-marks=../marks.git
$ git checkout
then there are no errors
On 12-07-12 01:45 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
>> If git am wasn't run with --reject, we assume the end user
>> knows where to find the patch. This is normally true for
>> a single patch,
>
> Not at all. Whether it is a single or broken, the patch is fed to
> underlying
Paul Gortmaker writes:
> On 12-07-12 01:45 PM, Junio C Hamano wrote:
>> Paul Gortmaker writes:
>>
>>> If git am wasn't run with --reject, we assume the end user
>>> knows where to find the patch. This is normally true for
>>> a single patch,
>>
>> Not at all. Whether it is a single or broken
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> 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 varia
On 12-07-12 02:53 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
>> On 12-07-12 01:45 PM, Junio C Hamano wrote:
>>> Paul Gortmaker writes:
>>>
If git am wasn't run with --reject, we assume the end user
knows where to find the patch. This is normally true for
a single patch,
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% sure I'm following what part here is not OK. If you
Matthieu Moy writes:
>>> + if (user_config && access(user_config, R_OK) &&
>>> + xdg_config && !access(xdg_config, R_OK))
>>> given_config_file = xdg_config;
>>
>> Shouldn't we be using xdg_config, if user_config is NULL and
>> xdg_config is defined and
On Thu, Jul 12, 2012 at 02:32:01PM -0400, Paul Gortmaker wrote:
> In case it helps any, a brief summary of my workflow is this:
>
> git am /tmp/mbox
>
> patch -p1 --dry-run < .git/rebase-apply/patch
> # gauge status. Is patch really invalid, or already applied?
> # already applied; "git am --sk
It is perfectly OK for a valid decimal integer to begin with '9' but
116eb3a (parse_date(): allow ancient git-timestamp, 2012-02-02) did
not express the range correctly.
Signed-off-by: Junio C Hamano
---
date.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/date.c b/date.c
i
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.bzr ../trunk/ | git fast-impo
Paul Gortmaker writes:
> I think this is where our two thinking paths diverge. You are
> suggesting I edit and fix the patch. Yes, occasionally I do
> that, if it is a trivial context change. But hand editing a
> patch is not for Joe Average, and gets very complicated in all
> but the trivial
The 12/07/12, Junio C Hamano wrote:
> It does not matter at all that 0001-foo.patch only has a single
> patch. If you are going to fix up the patch after you saw "git am"
> failed, you will be fixing .git/rebase-apply/patch with your editor
> and re-run "git am" without arguments, at which point
Nicolas Sebrecht writes:
> The 12/07/12, Junio C Hamano wrote:
>
>> It does not matter at all that 0001-foo.patch only has a single
>> patch. If you are going to fix up the patch after you saw "git am"
>> failed, you will be fixing .git/rebase-apply/patch with your editor
>> and re-run "git am"
Bryan Turner writes:
>> If you populated $GIT_DIR/index from the tree of HEAD, you would see
>> everything is deleted in the working tree. You can simulate it by
>> doing this:
>>
>> git clone -n $over_there here
>> cd here
>> git read-tree HEAD
>> git status
>>
>
All,
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/checking out of individual paths within the repo (ie
projects), which wo
Hi,
Johannes Sixt wrote:
> From: Johannes Sixt
>
> For some reason, 'echo X | dd bs=1k seek=1' creates a file with 2050 bytes
> on Windows instead of the expected 1026 bytes, so that a test fails. Since
> the actual contents of the file are irrelevant as long as there is at
> least one zero byt
Hi Zbigniew,
Zbigniew Jędrzejewski-Szmek wrote:
> On 07/12/2012 12:12 AM, Alexander Strasser wrote:
[...]
> I have some spelling corrections (minor, but since you intend to re-roll
> anyway, I'll post them), and one more thing which could be corrected
> (below).
>
> 3/6: s/Never the less/Neverthe
Difference from v1:
* Remove "tee" usage in t9814, just send output to a file
and grep it directly.
Recent p4 supports a "move" command that records explicitly that
a file was moved from one place to another. It can be changed a bit
during the move, too. Use this feature, if it exists,
From: Gary Gibbons
P4Submit.applyCommit()
To avoid recalculating the same diffOpts for each commit, move it
out of applyCommit() and into the top-level run(). Also fix a bug
in that code which interpreted the value of detectRenames as a
string rather than as a boolean.
[pw: fix documentation,
From: Gary Gibbons
For -M option (detectRenames) in P4Submit, use 'p4 move' rather
than 'p4 integrate'. Check Perforce server for exisitence of
'p4 move' and use it if present, otherwise revert to 'p4 integrate'.
[pw: wildcard-encode src/dest, add/update tests, tweak code]
Signed-off-by: Gary
44 matches
Mail list logo
