Signed-off-by: Junio C Hamano
---
cache.h | 1 -
connect.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..2c853ba 100644
--- a/cache.h
+++ b/cache.h
@@ -1098,7 +1098,6 @@ extern struct ref **get_remote_heads(int in, char
*src_buf, size_
One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch "HEAD" points at.
With a capability "symref=HEAD:refs/heads/master", let the sender to
tell the receiver what symbolic ref points at what ref.
This capability can be repeated more than
Signed-off-by: Junio C Hamano
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,15 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone
This reworks the old idea from 2008 ($gmane/102039) to teach
upload-pack to say where symbolic refs are pointing at in the
initial ref advertisement as a new capability "symref", and allows
"git clone" to take advantage of that knowledge when deciding what
branch to point at with the HEAD of the ne
By doing this, clients of upload-pack can now reliably tell what ref
a symbolic ref points at; the updated test in t5505 used to expect
failure due to the ambiguity and made sure we give diagnostics, but
we no longer need to be so pessimistic. Make sure we correctly learn
which branch HEAD points a
The callee does not use cb_data, and the caller is an intermediate
function in a callchain that later wants to use the cb_data for its
own use. Clarify the code by breaking the dataflow explicitly by
not passing cb_data down to mark_our_ref().
Signed-off-by: Junio C Hamano
---
upload-pack.c | 2
When two or more branches point at the same commit and HEAD is
pointing at one of them, without the symref extension, there is no
way to remotely tell which one of these branches HEAD points at.
The test in question attempts to make sure that this situation is
diagnosed and results in a failure.
H
With the same mechanism as used to tell where "HEAD" points at to
the other end, we can tell the target of other symbolic refs as
well.
Signed-off-by: Junio C Hamano
---
upload-pack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index 979fc8e..2826909 100644
Junio C Hamano writes:
> static void upload_pack(void)
> {
> + struct string_list symref = STRING_LIST_INIT_DUP;
> +
> + head_ref_namespaced(find_symref, &symref);
> +
> if (advertise_refs || !stateless_rpc) {
> reset_timeout();
> - head_ref_namespaced(se
Unlike other git commands which work correctly at the top-level or in a
subdirectory, git-contacts fails when invoked in a subdirectory. This is
because it invokes git-blame with pathnames relative to the top-level,
but git-blame interprets the pathnames as relative to the current
directory. Fix th
With the same mechanism as used to tell where "HEAD" points at to
the other end, we can tell the target of other symbolic refs as
well.
Signed-off-by: Junio C Hamano
---
upload-pack.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index 53958b9..7ca6154 100644
The callee does not use cb_data, and the caller is an intermediate
function in a callchain that later wants to use the cb_data for its
own use. Clarify the code by breaking the dataflow explicitly by
not passing cb_data down to mark_our_ref().
Signed-off-by: Junio C Hamano
---
upload-pack.c | 2
Signed-off-by: Junio C Hamano
---
cache.h | 1 -
connect.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..2c853ba 100644
--- a/cache.h
+++ b/cache.h
@@ -1098,7 +1098,6 @@ extern struct ref **get_remote_heads(int in, char
*src_buf, size_
This reworks the old idea from 2008 ($gmane/102039) to teach
upload-pack to say where symbolic refs are pointing at in the
initial ref advertisement as a new capability "sym", and allow
"git clone" to take advantage of that knowledge when deciding what
branch to point at with the HEAD of the newly
Signed-off-by: Junio C Hamano
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,15 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone
Signed-off-by: Junio C Hamano
---
connect.c | 60
1 file changed, 60 insertions(+)
diff --git a/connect.c b/connect.c
index e4c7ae6..a53ef6d 100644
--- a/connect.c
+++ b/connect.c
@@ -6,6 +6,7 @@
#include "run-command.h"
#include "re
One long-standing flaw in the pack transfer protocol was that there
was no way to tell the other end which branch "HEAD" points at.
With a new "sym" capability (e.g. "sym=HEAD:refs/heads/master"; can
be repeated more than once to represent symbolic refs other than
HEAD, such as "refs/remotes/origin
On Wed, Sep 18, 2013 at 12:02 AM, Junio C Hamano wrote:
>> Interaction with "git grep --depth"
>
> I am not sure how that affects anything. Conceptually, isn't
> "--depth" an independent axis to filter out paths that have too many
> components after given positive pathspec elements? E.g. given
>
Hi Duy,
Thanks again for taking a look at these two reports.
>> And it does work for me with CRLF endings (again tested on Linux).
Yes, will do.
I will try, myself, on Linux, as well. It seems quite conceivable its the
sort of thing that only happens under Windows.
Regards,
Martin
--
To un
Jeff King writes:
> I am mostly thinking of the problems we had with the "kup" tool, which
> expected stability across diffs that would be signed by both kernel.org.
> But as far as I know, they do not use patch-id. More details in case you
> are curious (including me arguing that we should not c
Hi Duy,
Thanks for taking a look.
>> > So it does feel like a bug to me: why are files with ^S set remaining in
>> the
>> > working version after
>> >
>> > git read-tree -mu HEAD
>> >
>> > ?
>>
>> I don't know. Maybe the bits are set, but then the remove operation
>> fails (silently). I
Jeff King writes:
> On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote:
>
>> > So given that, is it fair to say that a one-way "go here" merge, limited
>> > by pathspec, is the closest equivalent?
>>
>> Sorry, but it is unclear to me what you mean by one-way "go here"
>> merge. Do y
Sebastian Schuberth writes:
> On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano wrote:
>
>> Keeping the ugliness to deal with the platform issue (i.e. broken
>> string.h) in one place (e.g. compat/mingw) is far more preferrable
>> than having a similar ugliness in git-compat-util.h for people on
>
On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote:
> > So given that, is it fair to say that a one-way "go here" merge, limited
> > by pathspec, is the closest equivalent?
>
> Sorry, but it is unclear to me what you mean by one-way "go here"
> merge. Do you mean oneway_merge() in un
Jeff King writes:
> On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote:
>
>> Taking the state of a subdirectory as a whole as "content", the
>> change we are discussing will make it more like "rm -fr dir && tar
>> xf some-content dir" to replace the directory wholesale, which I
>> per
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
> Ooops. It seems that each time somebody says these two words together,
> people hate him, and he is scorned by friends and family.
>
> For the moment, i want a first feedback, an intermediate between
> "locking is bad" and "
On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote:
> > Hrm. Probably not. It is almost a one-way merge going to the named tree
> > (but limited by the pathspec), except that I think the current
> > git-checkout code may provide some safety checks related to where we are
> > coming fro
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:
> Ooops. It seems that each time somebody says these two words together,
> people hate him, and he is scorned by friends and family.
And strangers on mailing lists. :)
> However,
> - gitolite implement it (but gitolite is no
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
>
> > > A problem with both schemes, though, is that they are not
> > > backwards-compatible with existing git-patch-id implementations.
> >
> > Could you clarify?
> >
Piotr Krukowiecki writes:
> Ignoring (possible) inconsistency thing, I think they are easy to
> understand and use.
Probably you are right (in the sense that I do not offhand think of
a confusing and ambiguous set of positive and negative pathspecs;
others may find holes in my/our thinking).
I
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
> > A problem with both schemes, though, is that they are not
> > backwards-compatible with existing git-patch-id implementations.
>
> Could you clarify?
> We never send patch IDs on the wire - how isn't this compatible?
I meant
On Wed, Sep 18, 2013 at 12:03:25AM +0300, Michael S. Tsirkin wrote:
> > It may be esoteric enough not to worry about, though. By far the most
> > common use of patch-ids is going to be in a single "rev-list
> > --cherry-pick" situation where you are trying to omit commits during
> > a rebase.
> >
Jeff King writes:
> On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
>> >
>> >> I could argue that the above intended behaviour is suboptimal and it
>> >> should have been "the resultin
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote:
> > On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
> >
> > > > Thinking about it some more, it's a best effort thing anyway,
> > > > correct?
> > >
On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
>
> > > Thinking about it some more, it's a best effort thing anyway,
> > > correct?
> > >
> > > So how about, instead of doing a hash over the whole input,
> > > we ha
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
> >
> >> I could argue that the above intended behaviour is suboptimal and it
> >> should have been "the resulting paths in the index and the
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> > > "Michael S. Tsirkin" writes:
> > >
> > > > On Tue, Sep 17, 2013 at 10:24:19AM -0700,
Jeff King writes:
> On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
>
>> I could argue that the above intended behaviour is suboptimal and it
>> should have been "the resulting paths in the index and the work tree
>> that match the given pathspec must be identical to that of the
>
Stefan Beller writes:
> On 09/17/2013 08:17 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> + struct option builtin_repack_options[] = {
>>> + OPT_BIT('a', NULL, &pack_everything,
>>> + N_("pack everything in a single pack"),
>>> ALL_INTO_ONE),
>
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > So might it not be useful to tweak patch id to
> >> > sort the diff, making it a bit
On 09/17/2013 08:17 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +struct option builtin_repack_options[] = {
>> +OPT_BIT('a', NULL, &pack_everything,
>> +N_("pack everything in a single pack"),
>> ALL_INTO_ONE),
>> +OPT_BIT('A', N
On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> > "Michael S. Tsirkin" writes:
> >
> > > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> > >> "Michael S. Tsirkin" writes:
> > >>
> > >> > So
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
> > Thinking about it some more, it's a best effort thing anyway,
> > correct?
> >
> > So how about, instead of doing a hash over the whole input,
> > we hash each chunk and XOR them together?
> >
> > This way it will be stable
On 09/15/2013 05:31 PM, Stefan Beller wrote:
> Rene, thank you very much for the review!
>
> the parameter hex contains the "pack-" already.
> The remove_redundant_pack function is called in a loop iterating over
> elements of existing_packs, which is filled in get_non_kept_pack_filenames,
> whic
On Tue, Sep 17, 2013 at 09:06:59PM +0200, Uwe Kleine-König wrote:
> $ git checkout HEAD^ -- subdir
>
> I'd expect that subdir/b is removed from the index as this file didn't
> exist in HEAD^ but git-status only reports:
I'm not sure if this is intentional or not. The definition of "git
che
Uwe Kleine-König writes:
> after these commands:
>
> $ git init
> $ mkdir subdir
> $ echo a > subdir/a
> $ git add subdir/a
> $ git commit -m a
> $ echo more a >> subdir/a
> $ echo b > subdir/b
> $ git add subdir/*
> $ git commit -m b
>
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
> I could argue that the above intended behaviour is suboptimal and it
> should have been "the resulting paths in the index and the work tree
> that match the given pathspec must be identical to that of the
> tree-ish". In the result
Jason Miller wrote:
> I'm trying out a rather large subversion import, and am trying to
> figure out if there is a way to delete branches during a fast-import.
>
> Right now I can think of only 2 ways to handle this:
>
> 1) End the import, do a git branch -D and then resume the import.
>
> 2) Sc
Am 17.09.2013 10:24, schrieb Jiang Xin:
> I have checked the behavior of UNC path on Windows (msysGit):
>
> * I can cd to a UNC path:
>
> cd //server1/share1/path
>
> * can cd to other share:
>
> cd ../../share2/path
>
> * and can cd to other server's share:
>
> cd ../../../server
Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
However,
- gitolite implement it (but gitolite is not git).
- In the documentation, each time the need is evocated, it is replace
by "do communication, don't use git for
On Tue, Sep 17, 2013 at 9:04 PM, Junio C Hamano wrote:
> Piotr Krukowiecki writes:
>
>> What about simply iterating over options in order in which they
>> are specified and the last option that matches specifies the
>> result?
>
> But isn't it very inconsistent from the way normal pathspec wor
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > So might it not be useful to tweak patch id to
> >> > sort the diff, making it a bit
Lukas Fleischer writes:
>> Imagine if you start from a subdirectory foo/ but the directory did
>> not exist in the older part of the history of the project. When
>> bisect needs to check out a revision that was older than the first
>> revision that introduced that subdirectory, what should happe
On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano wrote:
> Keeping the ugliness to deal with the platform issue (i.e. broken
> string.h) in one place (e.g. compat/mingw) is far more preferrable
> than having a similar ugliness in git-compat-util.h for people on
> all other platforms to see, no?
I
On 17 September 2013 18:27, Junio C Hamano wrote:
> "Burton, Ross" writes:
>
>> Why does git-bisect need to be ran from the top level of the working
>> tree? It sources git-sh-setup.sh which sets GIT_DIR, which
>> git-bisect.sh then appears to consistently use. Is there a reason for
>> needing
Hello,
after these commands:
$ git init
$ mkdir subdir
$ echo a > subdir/a
$ git add subdir/a
$ git commit -m a
$ echo more a >> subdir/a
$ echo b > subdir/b
$ git add subdir/*
$ git commit -m b
$ git checkout HEAD^ -
Piotr Krukowiecki writes:
> What about simply iterating over options in order in which they
> are specified and the last option that matches specifies the
> result?
But isn't it very inconsistent from the way normal pathspec works?
"git log -- A B" and "git log -- B A" would give the same res
Stefan Beller writes:
> + struct option builtin_repack_options[] = {
> + OPT_BIT('a', NULL, &pack_everything,
> + N_("pack everything in a single pack"),
> ALL_INTO_ONE),
> + OPT_BIT('A', NULL, &pack_everything,
> +
"Michael S. Tsirkin" writes:
> On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > So might it not be useful to tweak patch id to
>> > sort the diff, making it a bit more stable?
>>
>> That is one thing that needs to be done, I think. But it
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:
> "Burton, Ross" writes:
>
> > Why does git-bisect need to be ran from the top level of the working
> > tree? It sources git-sh-setup.sh which sets GIT_DIR, which
> > git-bisect.sh then appears to consistently use. Is there a reaso
Thomas Gummerer writes:
> +For performance tests that need cleaning up after them that should not
> +be timed, use
> +
> + test_perf_cleanup 'descriptive string' '
> + command1 &&
> + command2
> + ' '
> + cleanupcommand1 &&
> + cleanupcomman
I'm trying out a rather large subversion import, and am trying to
figure out if there is a way to delete branches during a fast-import.
Right now I can think of only 2 ways to handle this:
1) End the import, do a git branch -D and then resume the import.
2) Scan the entire repository history, id
Junio C Hamano napisał:
>Yeah, it is easy to say that
>
> git log -- A ':(exclude)A/B' A/B/C
>
>has two positive (A, A/B/C) and one negative (A/B), and then the
>most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is
>included.
>
>But to actually _design_ it, there are ambiguiti
"Burton, Ross" writes:
> Why does git-bisect need to be ran from the top level of the working
> tree? It sources git-sh-setup.sh which sets GIT_DIR, which
> git-bisect.sh then appears to consistently use. Is there a reason for
> needing to be at the top-level, or is this an old and redundant
>
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > So might it not be useful to tweak patch id to
> > sort the diff, making it a bit more stable?
>
> That is one thing that needs to be done, I think. But it would be
> unfortunate if we have to d
Duy Nguyen writes:
> On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder
> wrote:
>> On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
>> wrote:
>>> Christian Couder writes:
>>>
In practice though, as git bisect is a kind of binary search, if what
you want to exclude is exclusively touche
Your e-mail has won you ￡1,000,000.00 from BBC XMAS PROMO
1, Name
2, Country
3, Mobile No
4, Occupation
Send Response to ( eruraf...@56788.com )
Prof. Peter
--==Mailed via NDMCTSGH Webmail==--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord..
On Tue, Sep 17, 2013 at 09:26:13AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Actually, after I've looked at the code,
> > diffcore_order is already already called for patch-id.
>
> That was a band-aid for an ill-thought-out orderfile misfeature to
> hide the breakage. Yo
"Michael S. Tsirkin" writes:
> So might it not be useful to tweak patch id to
> sort the diff, making it a bit more stable?
That is one thing that needs to be done, I think. But it would be
unfortunate if we have to do that unconditionally, though, as we may
be "buffering" many hundred kilobyte
On Tue, Sep 17, 2013 at 8:50 AM, Thomas Gummerer wrote:
> Currently git-contacts only works if it is executed from the top level
> of the git repository. Enable the execution in sub directories of that
> repository.
Thanks. This was on my to-do list but fell off my radar when I
accidentally dele
Hi,
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is there a reason for
needing to be at the top-level, or is this an old and redundant
message?
Cheers,
Ross
--
To u
Ramkumar Ramachandra writes:
> Is $GIT_OBJECT_DIRECTORY a standard variable, or should it be
> $GIT_DIR/objects?
"man git" ;-) It has been there since early May 2005
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majo
Eric Sunshine writes:
> * Split v1 patch 1 into v2 patches 1 & 2 to ease review. (This is
> possible now that index_name_exists() retains its original behavior.)
It really shows in [PATCH 2/4] that illustrates which callers were
depending on the old calling convention; I like it.
Thanks.
--
On 09/17/2013 09:26 AM, Christian Couder wrote:
> Hi,
>
> On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster
> wrote:
>> I'm bisecting a linux kernel issue and want to ignore all commits just
>> touching something in ./drives/staging.
>>
>> Currently the only way would be to specify all dir/subdir
"Michael S. Tsirkin" writes:
> Actually, after I've looked at the code,
> diffcore_order is already already called for patch-id.
That was a band-aid for an ill-thought-out orderfile misfeature to
hide the breakage. You somehow make sure that you pass the same
orderfile to diff generating machin
Torsten Bögershausen writes:
> Yes,
> there is a directoctory structure in / like this:
>
> /usr
> /bin
> /lib
> Then we have the drive letters mapped to single letters:
> /c/Documents and Settings
> /c/temp
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Jiang Xin writes:
> diff --git a/compat/mingw.h b/compat/mingw.h
> index bd0a88b..06e9f49 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -311,6 +311,15 @@ int winansi_fprintf(FILE *stream, const char *format,
> ...) __attribute__((format
>
> #define has_dos_drive_prefix(path) (isal
Sebastian Schuberth writes:
> I think this is less favorable compared to my last proposed solution.
That is only needed if you insist to use C preprocessor that does
not understand include_next. That choice is a platform specific
decision (even if you want to use such a compiler on a platform i
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Signed-off-by: Felipe Contreras
---
builtin/add.c | 3 +++
cache.h | 6 ++
config.c | 13 +
environment.c | 1 +
4 files changed, 23 in
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras
---
Makefile | 5 -
gitconfig | 5 +
2 files changed, 9 insertions(+), 1 deletion(-)
create mode 100644 gitconfig
diff --git a/Makefile b/Makefile
index
Currently git-contacts only works if it is executed from the top level
of the git repository. Enable the execution in sub directories of that
repository.
Signed-off-by: Thomas Gummerer
---
I have no experience in perl, so there may be nicer implementations. It works
when tested manually.
co
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in my
office yesterday so I decided to use this very chance to know you. I believe we
should use every opportunity to know each other bett
Currently there is no way to clean up the changes that have been made
with test_perf for the next run. Add a way to reset the repository to
the state before the test for testing commands that modify the git
repository, e.g. for perf testing git add.
Signed-off-by: Thomas Gummerer
---
This enabl
Separate the execution part to make future changes to the tests simpler.
Signed-off-by: Thomas Gummerer
---
t/perf/perf-lib.sh | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index c61d535..95e483c 100644
--- a/t/perf/pe
On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder
wrote:
> On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
> wrote:
>> Christian Couder writes:
>>
>>> In practice though, as git bisect is a kind of binary search, if what
>>> you want to exclude is exclusively touched by half the commits, it
>>> w
On Mon, Sep 16, 2013 at 8:20 PM, Martin Gregory
wrote:
> Hi,
>
> Please see http://pastebin.com/zMXvvXuy
>
> It shows that if the .git/info/sparsecheckout file is in windows format
> (windows line ending) then it doesn't work.
And it does work for me with CRLF endings (again tested on Linux). Ca
On Tue, Sep 17, 2013 at 5:46 AM, Martin Gregory
wrote:
> An additional note. I did
>
> git ls-files -v | grep ^S
>
> and I can see that the files that remain in the working version have the ^S
> bit set.
>
> So it does feel like a bug to me: why are files with ^S set remaining in the
> working ve
Patrick Welche writes:
> On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote:
>> Patrick Welche writes:
>>
>> > Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by
>> > default. If I take 1.8.3.4 and git -c color.ui=always log, I see
>> > the same ESC codes => not a re
On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote:
> Patrick Welche writes:
>
> > Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by
> > default. If I take 1.8.3.4 and git -c color.ui=always log, I see
> > the same ESC codes => not a regression! I'll just have to sort
Patrick Welche writes:
> Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by
> default. If I take 1.8.3.4 and git -c color.ui=always log, I see
> the same ESC codes => not a regression! I'll just have to sort my
> box out if I want colour. (The only oddity is that git status is
>
On Tue, Sep 17, 2013 at 09:15:43AM +0200, Matthieu Moy wrote:
> Matthieu Moy writes:
>
> > Patrick Welche writes:
> >
> >> $ git diff
> >> ESC[1mdiff --cc glib/gmain.cESC[m
> >> ESC[1mindex 738e69c,5aaebd0..000ESC[m
> >> ESC[1m--- a/glib/gmain.cESC[m
> >> ESC[1m+++ b/glib/gmain.cESC[m
> >> E
On Mon, Sep 16, 2013 at 01:18:48PM +0200, Matthieu Moy wrote:
> Patrick Welche writes:
>
> > $ git diff
> > ESC[1mdiff --cc glib/gmain.cESC[m
> > ESC[1mindex 738e69c,5aaebd0..000ESC[m
> > ESC[1m--- a/glib/gmain.cESC[m
> > ESC[1m+++ b/glib/gmain.cESC[m
> > ESC[36m@@@ -4953,32 -4921,32 +4953,48
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
wrote:
> Christian Couder writes:
>
>> In practice though, as git bisect is a kind of binary search, if what
>> you want to exclude is exclusively touched by half the commits, it
>> will only add one more bisection step if you don't exclude it.
>
> A
hi
I like your "crash curse" http://git.or.cz/course/svn.html
(sorry for my bad English)
a little suggestion for revert/checkout
svn revert -R .<---> git checkout '*'
best regards
Michele Paoli
--
---
Dott. Michele Paoli
Innsbruck Medical Un
In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
such DOS drive on MINGW platform. Use an umambigous leading path
"/foo" instead.
Also change two leading slashes (//) to three leading slashes (///),
otherwize it will
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that.
Always use relative_path as
Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have DOS driver prefix
(such as "C:/windows"). And the "relative_path" function won't
work properly if either "in" or "prefix" is a UNC path (like
"//host/share"). ($gmane/234434)
E.g., When e
2013/9/13 Junio C Hamano :
> Jiang Xin writes:
>
>> 2013/9/13 Junio C Hamano :
>>>
>>> For systems that need POSIX escape hatch for Apollo Domain ;-), we
>>> would need a bit more work. When both path1 and path2 begin with a
>>> double-dash, we would need to check if they match up to the next
>>>
Christian Couder writes:
> In practice though, as git bisect is a kind of binary search, if what
> you want to exclude is exclusively touched by half the commits, it
> will only add one more bisection step if you don't exclude it.
Actually, I think the same remark would apply to any other Git co
Hi,
On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster wrote:
> I'm bisecting a linux kernel issue and want to ignore all commits just
> touching something in ./drives/staging.
>
> Currently the only way would be to specify all dir/subdir combination
> under ./linux except that particular directory,
1 - 100 of 106 matches
Mail list logo
