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
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,
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,
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
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
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
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
>>
>
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"
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
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
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
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 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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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...
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
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
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
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
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
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
> 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
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
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 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
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, 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
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
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
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
Am 7/12/2012 1:30, schrieb Junio C Hamano:
> - test "$(wc -l + test $(wc -l http://vger.kernel.org/majordomo-info.html
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
44 matches
Mail list logo
