On Fri, Jan 24, 2014 at 4:38 AM, Junio C Hamano wrote:
> Jens Lehmann writes:
>
>> ... But a single
>> trailing '/' does mark "submod" as a directory, which I think is
>> ok for a submodule. And it makes life easier for the user if we
>> accept that, as shell completion will add it there automati
On 01/23/2014 06:28 PM, Jeff King wrote:
I think your understanding is accurate here. So we want repack to
respect keep files for deletion, but we _not_ necessarily want
pack-objects to avoid packing an object just because it's in a pack
marked by .keep (see my other email).
Yes, that makes sen
On Thu, Jan 23, 2014 at 03:53:28PM -0800, Siddharth Agarwal wrote:
> On 01/23/2014 03:45 PM, Siddharth Agarwal wrote:
> >
> >The worry is less certain objects not being packed and more the old
> >packs being deleted by git repack, isn't it? From the man page for
> >git-index-pack:
>
> This should
On Fri, Jan 24, 2014 at 12:56:17AM +0100, Vicent Martí wrote:
> On Fri, Jan 24, 2014 at 12:45 AM, Siddharth Agarwal wrote:
> > Yes, we'd prefer to do that too. How do you actually do this, though? I
> > don't see a way to pass `--honor-pack-keep` (shouldn't I pass in its
> > inverse?) down to `gi
On Thu, Jan 23, 2014 at 03:34:16PM -0800, Jonathan Nieder wrote:
> Line 1484 looks more problematic:
>
> disk_ce = (struct ondisk_cache_entry *)((char *)mmap +
> src_offset);
>
> In v4 indexes, src_offset doesn't have any particular alignment so
> this conversion has undefined beh
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-rebase.txt | 4
git-rebase--am.sh| 8 +---
git-rebase--interactive.sh | 32
git-rebase--merge.sh | 2 +-
git-rebase.sh
From: Nicolas Vigier
There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-am.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
d
This series was posted to the list some time back, but it fell through
the cracks. This is a re-send of Nicolas Vigier's work with an
additional patch that adds --gpg-sign to pull as well. I added my
sign-off to his patches because SubmittingPatches (section (c)) seems to
imply that I should, alt
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-cherry-pick.txt | 7 ++-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 2 ++
sequencer.c | 11 +++
sequencer.h
From: Nicolas Vigier
There is no functionnal change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-rebase.sh | 50 ++
1 file change
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-am.txt | 6 +-
git-am.sh| 9 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 54d8461.
From: Nicolas Vigier
Remove a check on the number of arguments for --onto and -x options.
It is not possible for $# to be <= 2 at this point :
- if --onto or -x has an argument, git rev-parse --parseopt will
provide something like this :
set -- --onto 'x' --
when parsing the "--onto"
git merge already allows us to sign commits, and git rebase has recently
learned how to do so as well. Teach git pull to parse the -S/--gpg-sign
option and pass this along to merge or rebase, as appropriate.
Signed-off-by: brian m. carlson
---
git-pull.sh | 13 -
1 file changed, 12
From: Nicolas Vigier
The -M option does not exist in OPTIONS_SPEC, so there is no use to try
to find it.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d183
From: Nicolas Vigier
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
contrib/examples/git-checkout.sh | 1 +
contrib/examples/git-clean.sh| 1 +
contrib/examples/
Jeff King writes:
> In a triangular workflow, you may have a distinct
> @{upstream} that you pull changes from, but publish by
> default (if you typed "git push") to a different remote (or
> a different branch on the remote). It may sometimes be
> useful to be able to quickly refer to that publis
Vicent Martí wrote:
> On Fri, Jan 24, 2014 at 12:44 AM, Jonathan Nieder wrote:
>>> +#if __BYTE_ORDER != __BIG_ENDIAN
>>
>> Is this portable?
>
> We explicitly set the __BYTE_ORDER macros in `compat/bswap.h`. In
> fact, this preprocessor conditional is the same one that we use when
> choosing what
On Fri, Jan 24, 2014 at 12:45 AM, Siddharth Agarwal wrote:
> Yes, we'd prefer to do that too. How do you actually do this, though? I
> don't see a way to pass `--honor-pack-keep` (shouldn't I pass in its
> inverse?) down to `git-pack-objects`.
We run with this patch in production, it may be of us
On Thu, Jan 23, 2014 at 2:58 PM, Junio C Hamano wrote:
>
> Will be fine, provided if they always use local:remote syntax, I'd
> agree.
Why? No sane user should actually need to use the local:remote syntax.
The normal situation should be that you create the correctly named
branch or tag locally,
On 01/23/2014 03:45 PM, Siddharth Agarwal wrote:
The worry is less certain objects not being packed and more the old
packs being deleted by git repack, isn't it? From the man page for
git-index-pack:
This should probably be "new pack" and not "old packs", I guess. Not
knowing much about how
On Fri, Jan 24, 2014 at 12:44 AM, Jonathan Nieder wrote:
>> --- a/ewah/ewah_io.c
>> +++ b/ewah/ewah_io.c
>> @@ -112,23 +112,38 @@ int ewah_serialize(struct ewah_bitmap *self, int fd)
> [...]
>> +#if __BYTE_ORDER != __BIG_ENDIAN
>
> Is this portable?
We explicitly set the __BYTE_ORDER macros in `c
Jeff King wrote:
> --- a/ewah/ewah_io.c
> +++ b/ewah/ewah_io.c
> @@ -112,23 +112,38 @@ int ewah_serialize(struct ewah_bitmap *self, int fd)
[...]
> +#if __BYTE_ORDER != __BIG_ENDIAN
Is this portable?
On a platform without __BYTE_ORDER or __BIG_ENDIAN defined,
it is interpreted as
#if 0
On 01/23/2014 02:52 PM, Jeff King wrote:
Right, that's expected.
The bitmap format cannot represent objects that are not present in the
pack. So we cannot write a bitmap index if any object reachable from a
packed commit is omitted from the pack.
We could be nicer and downgrade it to a warning,
Jeff King wrote:
> This _might_ still suffer from the issue fixed in 5f6a112 (block-sha1:
> avoid pointer conversion that violates alignment constraints,
> 2012-07-22), as we are taking the pointer of a uint32 in a struct.
No conversion, so no issue there.
Line 1484 looks more problematic:
Jeff King wrote:
> These short names might not be descriptive enough now that they are
> globals. However, they make sense to me.
Yeah, I think they're clear. And they match the Linux kernel's
get_unaligned_be32() / put_unaligned_be32().
--
To unsubscribe from this list: send the line "unsubscri
Jeff King wrote:
> Here it is again, fixing the issues we've discussed.
Thanks! Passes all tests.
Tested-by: Jonathan Nieder # ARMv5
--
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.kerne
Linus Torvalds writes:
> Yes, so you'll get a warning (or, if you get a partial match, maybe
> not even that), but the important part about all these changes is that
> it DOESN'T MATTER.
>
> Why? Because it no longer re-writes the target branch name based on
> that match or non-match. So the pull
On Wed, Jan 22, 2014 at 06:38:57PM -0800, Siddharth Agarwal wrote:
> Running git-next, writing bitmap indexes fails if a keep file is
> present from an earlier pack.
Right, that's expected.
The bitmap format cannot represent objects that are not present in the
pack. So we cannot write a bitmap i
Jeff King wrote:
> On Thu, Jan 23, 2014 at 02:17:55PM -0800, Jonathan Nieder wrote:
>> I don't think that's a big issue. A pair of 4-byte reads would not be
>> too slow.
>
> The header is actually two separate 4-byte values, so that's fine. But
> between the header and trailer are a series of 8-b
On Thu, Jan 23, 2014 at 02:17:55PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Thu, Jan 23, 2014 at 09:53:26PM +, brian m. carlson wrote:
>
> >> Yes, it will. SPARC requires all loads be naturally aligned (4-byte to
> >> an address that's a multiple of 4, 8-byte to a multiple of
Jeff King wrote:
> On Thu, Jan 23, 2014 at 09:53:26PM +, brian m. carlson wrote:
>> Yes, it will. SPARC requires all loads be naturally aligned (4-byte to
>> an address that's a multiple of 4, 8-byte to a multiple of 8, and so
>> on). In general, architectures that do not support unaligned a
On Thu, Jan 23, 2014 at 09:53:26PM +, brian m. carlson wrote:
> On Thu, Jan 23, 2014 at 03:26:45PM -0500, Jeff King wrote:
> > Looking over the format, I think the only thing preventing 4-byte
> > alignment is the 1-byte XOR-offset and 1-byte flags field for each
> > bitmap. If we ever have a
On Thu, Jan 23, 2014 at 03:26:45PM -0500, Jeff King wrote:
> Looking over the format, I think the only thing preventing 4-byte
> alignment is the 1-byte XOR-offset and 1-byte flags field for each
> bitmap. If we ever have a v2, we could pad the sum of those out to 4
> bytes. Is 4-byte alignment eno
Jens Lehmann writes:
> ... But a single
> trailing '/' does mark "submod" as a directory, which I think is
> ok for a submodule. And it makes life easier for the user if we
> accept that, as shell completion will add it there automatically.
OK, that would be annoying.
Perhaps the completion is
On Thu, Jan 23, 2014 at 01:24:44PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Agreed. I was making the minimal change, but I think there is no reason
> > not to fix both while we are there. Do you want to just mark up the
> > patch in transit?
>
> Let's just queue this instead.
Tha
From: Vicent Marti
The caller may hand us an unaligned buffer (e.g., because it
is an mmap of a file with many ewah bitmaps). On some
platforms (like SPARC) this can cause a bus error. We can
fix it with a combination of get_be32 and moving the data
into an aligned buffer (which we would do anywa
Commit d60c49c (read-cache.c: allow unaligned mapping of the
index file, 2012-04-03) introduced helpers to access
unaligned data. However, we already have get_be32, which has
a few advantages:
1. It's already written, so we avoid duplication.
2. It's probably faster, since it does the endian
Am 23.01.2014 22:09, schrieb Junio C Hamano:
> Nguyễn Thái Ngọc Duy writes:
>> diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh
>> index 15a4912..b54251a 100755
>> --- a/t/t4010-diff-pathspec.sh
>> +++ b/t/t4010-diff-pathspec.sh
>> @@ -127,4 +127,10 @@ test_expect_success 'diff-tr
Jeff King writes:
> Agreed. I was making the minimal change, but I think there is no reason
> not to fix both while we are there. Do you want to just mark up the
> patch in transit?
Let's just queue this instead.
-- >8 --
From: Jeff King
Date: Thu, 23 Jan 2014 14:55:18 -0500
Subject: [PATCH] t
The BLK_SHA1 code has optimized wrappers for doing endian
conversions on memory that may not be aligned. Let's pull
them out so that we can use them elsewhere, especially the
time-tested list of platforms that prefer each strategy.
Signed-off-by: Jeff King
---
These short names might not be descr
On Thu, Jan 23, 2014 at 01:33:20PM -0500, Jeff King wrote:
> Here's a patch series (on top of jk/pack-bitmap, naturally) that lets
> t5310 pass there. I assume the ARM problem is the same, though seeing
> the failure in realloc() is unexpected. Can you try it on both your
> platforms with these pa
On Thu, Jan 23, 2014 at 01:12:55PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... The test does not care about the timestamp of the
> > .keep file it creates at all, only that it exists.
>
> Please refrain from using "touch" for such use cases in the first
> place. It appears that
Jeff King writes:
> ... The test does not care about the timestamp of the
> .keep file it creates at all, only that it exists.
Please refrain from using "touch" for such use cases in the first
place. It appears that
>pack-$packsha1.keep &&
is what the test wants.
--
To unsubscribe fro
Translate 27 new messages came from git.pot update in
df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed).
Signed-off-by: Ralf Thielow
---
po/de.po | 90
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/po/de.p
Nguyễn Thái Ngọc Duy writes:
> When you do "git diff HEAD submodule/", "submodule" from the index is
> picked out and match_pathspec_depth() in charge of matching it with
> the pathspec "submodule/".
Is "... is called" or something missing at the end of this sentence?
> Unlike tree_entry_inter
On Thu, Jan 23, 2014 at 12:52:30PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > and assume that it will fail. It doesn't. Solaris happily renames
> > some-file to a regular file named "no-such-dir". So we fail later during
> > the index-update, complaining about adding the entry "no-su
Jeff King writes:
> and assume that it will fail. It doesn't. Solaris happily renames
> some-file to a regular file named "no-such-dir". So we fail later during
> the index-update, complaining about adding the entry "no-such-dir/", but
> still exit(0) at the end. I'm mostly willing to just call S
On Thu, Jan 23, 2014 at 03:03:11PM -0500, Jeff King wrote:
> > My main worry about the patches is that they will probably run into
> > an analagous problem to the one that v1.7.12-rc0~1^2~2 (block-sha1:
> > avoid pointer conversion that violates alignment constraints,
> > 2012-07-22) solved. By c
On 01/22/2014 06:38 PM, Siddharth Agarwal wrote:
In our case we have .keep files lying around from ages ago (possibly
due to kill -9s run on the server). It also means that running repack
-a with bitmap writing enabled on a repo becomes problematic if a
fetch is run concurrently.
We briefly d
On Thu, Jan 23, 2014 at 12:23:42PM -0800, Jonathan Nieder wrote:
> > The memcpy solution is taken from read-cache.c, but as we noted, it
> > probably hasn't been used a lot. The blk_sha1 get_be may be faster, as
> > it converts as it reads.
>
> I doubt there's much difference either way, especial
On Thu, Jan 23, 2014 at 12:14:03PM -0800, Shawn Pearce wrote:
> > Yes, the mmap'd buffers aren't necessarily word-aligned. I don't think
> > we can fix that easily without changing the on-disk format (which comes
> > from JGit anyway).
>
> Ouch, sorry about that. JGit doesn't mmap the file so we
Jeff King wrote:
> If we
> change the signature of align_ntohl, we can do this:
>
> uint32_t align_ntohl(void *ptr)
> {
> uint32_t x;
> memcpy(x, ptr, sizeof(x));
> return ntohl(x);
> }
>
> ...
>
>
Jeff King wrote:
> [1/2]: compat: move unaligned helpers to bswap.h
> [2/2]: ewah: support platforms that require aligned reads
After setting NEEDS_ALIGNED_ACCESS,
Tested-by: Jonathan Nieder # ARMv5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
On Thu, Jan 23, 2014 at 12:12:23PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Thu, Jan 23, 2014 at 11:52:06AM -0800, Jonathan Nieder wrote:
>
> >> My main worry about the patches is that they will probably run into
> >> an analagous problem to the one that v1.7.12-rc0~1^2~2
> [...]
>
On Thu, Jan 23, 2014 at 10:33 AM, Jeff King wrote:
> On Wed, Jan 22, 2014 at 06:05:36PM -0800, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>> > EWAH is a word-aligned compressed variant of a bitset (i.e. a data
>> > structure that acts as a 0-indexed boolean array for many entries).
>>
>> I su
Jeff King wrote:
> On Thu, Jan 23, 2014 at 11:52:06AM -0800, Jonathan Nieder wrote:
>> My main worry about the patches is that they will probably run into
>> an analagous problem to the one that v1.7.12-rc0~1^2~2
[...]
> I think this probably works in practice because align_ntohl is inlined,
> and
On Thu, Jan 23, 2014 at 12:08:04PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Thu, Jan 23, 2014 at 11:56:43AM -0800, Jonathan Nieder wrote:
>
> >> In that case I think git-compat-util.h should include something like
> >> what block-sha1/sha1.c has:
> >>
> >>#if !defined(__i386__
Jeff King wrote:
> On Thu, Jan 23, 2014 at 11:56:43AM -0800, Jonathan Nieder wrote:
>> In that case I think git-compat-util.h should include something like
>> what block-sha1/sha1.c has:
>>
>> #if !defined(__i386__) && !defined(__x86_64__) && \
>> !defined(_M_IX86) && !defined(_M_X6
On Thu, Jan 23, 2014 at 11:56:43AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I think it was a bug waiting to surface if index v4 ever got wide use.
>
> Ah, ok.
>
> In that case I think git-compat-util.h should include something like
> what block-sha1/sha1.c has:
>
> #if !def
On Thu, Jan 23, 2014 at 11:52:06AM -0800, Jonathan Nieder wrote:
> > After my patches, t5310 runs fine for me. I didn't try your patch, but
> > mine are similar. Let me know if you still see the problem (there may
> > simply be a bug in yours, but I didn't see it).
>
> I had left out a cast to un
On Thu, Jan 23, 2014 at 11:43 AM, Junio C Hamano wrote:
>
> I am not sure if it is a good idea to hand-craft "resulting head is
> unique" constraint here. We already have disambiguation rules (and
> warning mechanism) we use in other places---this part should use the
> same rule, I think.
If you
Jeff King wrote:
> I think it was a bug waiting to surface if index v4 ever got wide use.
Ah, ok.
In that case I think git-compat-util.h should include something like
what block-sha1/sha1.c has:
#if !defined(__i386__) && !defined(__x86_64__) && \
!defined(_M_IX86) && !define
t7501.9 tries to check that "git commit" will fail when the
index is unchanged. It relies on previous tests not to have
modified the index. When it was originally written, this was
always the case. However, commit c65dc35 (t7501: test the
right kind of breakage, 2012-03-30) changed earlier tests (4
Some versions of touch (such as /usr/ucb/touch on Solaris)
do not know about the "-r" option. This would make sense as
a feature of test-chmtime, but fortunately this fix is even
easier. The test does not care about the timestamp of the
.keep file it creates at all, only that it exists. So we can
s
Due to the alignment bug in another thread, I had the pleasure of
visiting my old friend Solaris 9 today. The tests _almost_ all run out
of the box.
This series features two minor fixes:
[1/2]: t7501: fix "empty commit" test with NO_PERL
[2/2]: t7700: do not use "touch -r"
I had a few other
Jeff King wrote:
> Here's a patch series (on top of jk/pack-bitmap, naturally) that lets
> t5310 pass there. I assume the ARM problem is the same, though seeing
> the failure in realloc() is unexpected. Can you try it on both your
> platforms with these patches?
Thanks. Trying it out now.
[...]
On Thu, Jan 23, 2014 at 11:41:18AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Commit d60c49c (read-cache.c: allow unaligned mapping of the
> > index file, 2012-04-03) introduced helpers to access
> > unaligned data. Let's factor them out to make them more
> > widely available.
> >
> >
Linus Torvalds writes:
> So this relaxes the remote matching, and allows using the "local:remote"
> syntax to say that the local branch is differently named from the remote
> one.
>
> It is probably worth folding it into the previous patch if you think this
> whole approach is workable.
Haven
Jeff King wrote:
> Commit d60c49c (read-cache.c: allow unaligned mapping of the
> index file, 2012-04-03) introduced helpers to access
> unaligned data. Let's factor them out to make them more
> widely available.
>
> While we're at it, we'll give the helpers more readable
> names, add a helper for
Jeff King writes:
> On Wed, Jan 22, 2014 at 08:06:42PM -0500, Jeff King wrote:
>
>> But I think there is a subtle problem. Here (and elsewhere) we use the
>> parsed value of "0" as a sentinel. I think that is OK for
>> --max-pack-size, where "0" is not a reasonable value. But git-repack(1)
>> say
From: Vicent Marti
The caller may hand us an unaligned buffer (e.g., because it
is an mmap of a file with many ewah bitmaps). On some
platforms (like SPARC) this can cause a bus error. We can
fix it with a combination of force-align macros and moving
the data into an aligned buffer (which we woul
From: Vicent Marti
Commit d60c49c (read-cache.c: allow unaligned mapping of the
index file, 2012-04-03) introduced helpers to access
unaligned data. Let's factor them out to make them more
widely available.
While we're at it, we'll give the helpers more readable
names, add a helper for the "ntoh
On Wed, Jan 22, 2014 at 06:05:36PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > EWAH is a word-aligned compressed variant of a bitset (i.e. a data
> > structure that acts as a 0-indexed boolean array for many entries).
>
> I suspect that for some callers it's not word-aligned.
Yes, th
Jeff King writes:
> Junio, since you prepare such tarballs[1] anyway for kernel.org, it
> might be worth uploading them to the "Releases" page of git/git. I
> imagine there is a programmatic way to do so via GitHub's API, but I
> don't know offhand. I can look into it if you are interested.
I a
Pat Thoyts writes:
>>> GIT_VERSION=1.9.rc0
>>> all:
>>> echo $(join -DMAJOR= -DMINOR= -DPATCH=, \
>>> $(wordlist 1,3,$(filter-out rc%,$(subst -, ,$(subst .,
>>> ,$(GIT_VERSION 0 0))
>>>
>>> This removes any rc* parts and appends a couple of zeros so that all
>>> missing elements s
Jiang Xin writes:
> Maybe three weeks left. You can estimate it by checking the date
> for history tags, such as v1.8.5-rc0 and v1.8.5-rc3.
>
> v1.8.5-rc0: Wed Oct 30 12:17:56 2013 -0700
> v1.8.5-rc3: Wed Nov 20 11:27:39 2013 -0800
> v1.8.5: Wed Nov 27 12:14:52 2013 -0800
Or please c
On Thu, Jan 23, 2014 at 03:38:49AM -0500, shawn wilson wrote:
> My issue is in trying to update the submodules, I'm getting:
> % git submodule update --init
> gits/kt (master ⚡)
> swlap1
> fatal: reference is not a tree: 98f1e9f99fca32ab3de901219eb2f
Jeff King writes:
> ..., but it feels awfully wrong to be so intimate with
> a subprogram that we do not control.
Yeah, I think we are in agreement on that point.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
Paul Mackerras writes:
> Yes, please pull. I have just pushed one more:
>
> 76d64ca gitk: Indent word-wrapped lines in commit display header
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Eric Wong writes:
> Pushed for Junio.
Thanks.
--
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
On 23 January 2014 14:16, Johannes Sixt wrote:
> Am 1/23/2014 13:02, schrieb Pat Thoyts:
>> On 23 January 2014 07:28, Johannes Sixt wrote:
>>> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
>>>
>>> git.res: git.rc GIT-VERSION-FILE
>>> $(QUIET_RC)$(RC) \
>>> - $
On Thu, Jan 23, 2014 at 09:51:49AM +0100, Pierre Penninckx wrote:
> Hi again,
>
> After using the patched git-subtree (with patches 1 to 3) for a while,
> I suspect the added functionality does not do exactly what I wanted.
> So yes, now when doing a rejoin, the squash of the split commits is
> us
Am 1/23/2014 13:02, schrieb Pat Thoyts:
> On 23 January 2014 07:28, Johannes Sixt wrote:
>> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
>>
>> git.res: git.rc GIT-VERSION-FILE
>> $(QUIET_RC)$(RC) \
>> - $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst
Dear friend,
It is understandable that you might be a little bit apprehensive because you do
not know me but I have a lucrative business proposal of mutual interest to
share with you. I got your reference in my search for someone who suits my
proposed business relationship.
I am the foreign op
On 2014-01-22 22.27, salmansheikh wrote:
> Got it working but then I had some issues with the perl portions of the
> install and I subsequently thought I could eliminate those portions and
> tried setting export NO_PERL=1 and that installed everything else...and got
> pass this error but when I tri
We do ignore trailing slash on a directory, so pathspec "abc/" matches
directory "abc". A submodule is also a directory. Apply the same logic
to it. This makes "git log submodule-path" and "git log submodule-path/"
produce the same output.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t4010-diff-pat
When you do "git diff HEAD submodule/", "submodule" from the index is
picked out and match_pathspec_depth() in charge of matching it with
the pathspec "submodule/".
Unlike tree_entry_interesting(), match_pathspec_depth() has no
knowledge about entry mode to realize "submodule" is a directory and
t
On 23 January 2014 07:28, Johannes Sixt wrote:
> From: Johannes Sixt
>
> If the git version number consists of less than three period
> separated numbers, then the Windows resource file compilation
> issues a syntax error:
>
> $ touch git.rc
> $ make V=1 git.res
> GIT_VERSION = 1.9.rc0
>
On Wed, Jan 22, 2014 at 12:18:27PM -0800, Junio C Hamano wrote:
> Is this a good time for me to pull from you? I see these on your
> 'master' branch.
>
> 8f86339 gitk: Comply with XDG base directory specification
> 786f15c gitk: Replace "next" and "prev" buttons with down and up arrows
>
Hi again,
After using the patched git-subtree (with patches 1 to 3) for a while,
I suspect the added functionality does not do exactly what I wanted.
So yes, now when doing a rejoin, the squash of the split commits is
used. But how can I push this squash instead of the individual
commits? The prob
I've got a git repo that just contains a bunch of small projects
(scripts, configs, etc). The idea was (is) to make it so that each
project is tracked seperately (different branches, not needing to
filter out logs for unrelated commits). And it works great for that.
The problem is that I guess I do
Hi,
I have been migrating our svn repo to Git and we are not quite ready to move
yet so I am keeping the Git repo update everyday by doing git svn fetch but
today I ran into an issue which I don't know how to solve :
I get following error when I run git svn fetch :
Incomplete data: Delta source
Hi,
I have been migrating our svn repo to Git and we are not quite ready to move
yet so I am keeping the Git repo update everyday by doing git svn fetch but
today I ran into an issue which I don't know how to solve :
I get following error when I run git svn fetch :
Incomplete data: Delta source
93 matches
Mail list logo
