Max Nanasy gmail.com> writes:
> Tested against v1.7.12.4
Confirmed in 1.8.5.2
--
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 Thu, Feb 27, 2014 at 02:13:03PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Before cdab485 (upload-pack: delegate rev walking in shallow fetch to
> pack-objects - 2013-08-16) upload-pack does not write to the source
> repository. cdab485 starts to write $GIT_DIR/shallow_XX if it's a
> shallow fetc
From: Carlos Martín Nieto
When a remote has multiple fetch refspecs and these overlap in the
target namespace, fetch may prune a remote-tracking branch which still
exists in the remote. The test uses a popular form of this, by putting
pull requests as stored in a popular hosting platform alongsid
From: Carlos Martín Nieto
We need to consider that a remote-tracking branch may match more than
one rhs of a fetch refspec. In such a case, it is not enough to stop at
the first match but look at all of the matches in order to determine
whether a head is stale.
To this goal, introduce a variant
Before writing the shallow file, we stat() the existing file
to make sure it has not been updated since our operation
began. However, we do not do so under a lock, so there is a
possible race:
1. Process A takes the lock.
2. Process B calls check_shallow_file_for_update and finds
no upda
On Thu, Feb 27, 2014 at 04:10:12AM -0500, Jeff King wrote:
> I also notice that check_shallow_file_for_update returns early if
> !is_shallow. Is that safe? Is it possible for another process to have
> made us shallow since the program began? In that case, we would have to
> stat() the file always,
We already replace old SHA with the clipboard content for the mouse
paste event. It seems reasonable to do the same when pasting from
keyboard.
Signed-off-by: Ilya Bobyr
---
gitk-git/gitk |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
ind
On Thu, Feb 27, 2014 at 4:04 PM, Jeff King wrote:
> This is not introduced by your patch, but I notice that we do not seem
> to do anything with the tempfiles when the program dies prematurely.
> We've started collecting stale shallow_XX files in our server repos.
>
> For the writable cases, s
On Thu, Feb 27, 2014 at 4:22 PM, Jeff King wrote:
> On Thu, Feb 27, 2014 at 04:10:12AM -0500, Jeff King wrote:
>
>> I also notice that check_shallow_file_for_update returns early if
>> !is_shallow. Is that safe? Is it possible for another process to have
>> made us shallow since the program began?
On 02/27/2014 10:00 AM, Carlos Martín Nieto wrote:
> From: Carlos Martín Nieto
>
> We need to consider that a remote-tracking branch may match more than
> one rhs of a fetch refspec. In such a case, it is not enough to stop at
> the first match but look at all of the matches in order to determine
On Wed, 26 Feb 2014 12:23:35 -0600
Robert Dailey wrote:
> Oddly I'm not able to find any instructions on how to build Git for
> Windows. I've done a clone of the repository here:
>
> https://github.com/msysgit/git
>
> I did attempt to try doing it myself. I installed 'make' and mingw-gcc
> in C
On Thu, Feb 27, 2014 at 05:18:58PM +0700, Duy Nguyen wrote:
> On Thu, Feb 27, 2014 at 4:22 PM, Jeff King wrote:
> > On Thu, Feb 27, 2014 at 04:10:12AM -0500, Jeff King wrote:
> >
> >> I also notice that check_shallow_file_for_update returns early if
> >> !is_shallow. Is that safe? Is it possible
On 02/26/2014 09:28 AM, Jacopo Notarstefano wrote:
> my name is Jacopo, a student developer from Italy, and I'm interested
> in applying to this years' Google Summer of Code. I set my eyes on the
> project called "git-bisect improvements", in particular the subtask
> about swapping the "good" and "
Matthieu Moy wrote in message :
>> Maybe status should display a stash count if that count is > 0, as
>> this is part of the state of the repo.
> Maybe it would help some users, but not me for example. My main use of
> "git stash" is a safe replacement for "git reset --hard": when I want to
> disc
Change install_branch_config() function to use skip_prefix()
for getting short name of remote branch.
Signed-off-by: Dmitry S. Dolzhenko
---
branch.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..310749b 100644
--- a/branch.c
+++ b/b
On Thu, Feb 27, 2014 at 05:11:41PM +0700, Duy Nguyen wrote:
> We only update shallow file in these cases: clone --depth, fetch
> --update-shallow, fetch --depth, and push when receive.shallowupdate
> is set. All of them may end up not updating shallow file though.
OK, that last sentence is what I
On Wed, Feb 26, 2014 at 12:30:36PM -0800, Junio C Hamano wrote:
> >> pack-kept-objects then?
> >
> > Hmm. That does address my point above, but somehow the word "kept" feels
> > awkward to me. I'm ambivalent between the two.
>
> That word does make my backside somewhat itchy ;-)
>
> Would it hel
On 02/26/2014 05:46 PM, Faiz Kothari wrote:
> I am Faiz Kothari, I am a GSoC aspirant and want to contribute to git.
> I am submitting the patch in reponse to Microproject 1,
> rewrite git-compat-util.h:skip_prefix() as a loop.
>
> Signed-off-by: Faiz Kothari
The subject of your email plus the p
Thanks for the reply,
I was unable to get git send-email working. Now its working, I'll
resend the patch.
I ran all the tests, they are working properly.
About the comment, I meant, there is a similar function
strbuf.c:starts_with() which does the exact same job, but it returns 0
or 1.
I just chang
Dmitry,
Thanks for your patch. Please see my comments below.
On 02/27/2014 12:13 PM, Dmitry S. Dolzhenko wrote:
> Change install_branch_config() function to use skip_prefix()
> for getting short name of remote branch.
English tweak suggestion:
Change THE install_branch_config() function to use
From: Faiz Kothari
Signed-off-by: Faiz Kothari
---
git-compat-util.h |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cbd86c3..bb2582a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -357,8 +357,11 @@ extern int
Michael Haggerty writes:
> Dmitry,
>
> Thanks for your patch. Please see my comments below.
>
> On 02/27/2014 12:13 PM, Dmitry S. Dolzhenko wrote:
>> Change install_branch_config() function to use skip_prefix()
>> for getting short name of remote branch.
>
> English tweak suggestion:
>
> Change
Signed-off-by: Sun He
---
git-compat-util.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cbd86c3..4daa6cf 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -357,8 +357,8 @@ extern int suffixcmp(const char *str, co
Signed-off-by: Sun He
---
branch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..2fe9c05 100644
--- a/branch.c
+++ b/branch.c
@@ -50,7 +50,7 @@ static int should_setup_rebase(const char *origin)
void install_branch_config(int flag,
- Original Message -
> I don't understand the benefit of adding a new command "mark" rather
> than continuing to use "good", "bad", plus new commands "unfixed" and
> "fixed". Does this solve any problems?
I think it could be interesting to allow arbitrary words here. For example, I
recen
--sort=version:refname (or --sort=v:refname for short) sorts tags as
if they are versions. --sort=-refname reverses the order (with or
without ":version").
versioncmp() is copied from string/strverscmp.c in glibc commit
ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding
style. The
I find myself often do "git rebase -i xxx" and replace one "pick" line
with "edit" to amend just one commit when I see something I don't like
in that commit. This happens often while cleaning up a series. This
automates the "replace" step so it sends me straight to that commit.
"commit --fixup" th
On Thu, Feb 27, 2014 at 07:56:52PM +0700, Nguyễn Thái Ngọc Duy wrote:
> --sort=version:refname (or --sort=v:refname for short) sorts tags as
> if they are versions. --sort=-refname reverses the order (with or
> without ":version").
>
> versioncmp() is copied from string/strverscmp.c in glibc comm
Michael,
Thank you for your remarks.
> If you look at what skip_prefix() and starts_with() do, I think you will
> find that you are doing too much work here.
How about this one?
const char *shortname = skip_prefix(remote, "refs/heads/");
int remote_is_branch = shortname != NULL;
Junio C Hamano writes:
> Stephen Leake writes:
>
>>> One _could_ argue that stashed changes are what could be reflected
>>> to the working tree and form the source of the latter, but my gut
>>> feeling is that it is a rather weak argument. At that point you are
>>> talking about what you could
Simon Ruderich writes:
> On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:
>> One easy thing to do OTOH would be to show a hint at the end of "git
>> stash pop"'s output, like
>
> I think that's a good idea. It makes it obvious that Git has kept
> the stash and that the user should dr
On Thu, Feb 27, 2014 at 8:11 PM, Jeff King wrote:
> You had mentioned earlier tweaking the version comparison to handle
> things like -rc better. I think that can come on top of this initial
> patch, but we should probably figure out the final sort order before
> including this in a release.
Yeah
Matthieu Moy writes:
> Omar Othman writes:
>
>> Though I don't know why you think this is important:
>>> Now, the real question is: when would Git stop showing this advice. I
>>> don't see a real way to answer this, and I'd rather avoid doing just a
>>> guess.
>> If it is really annoying for the
Nguyễn Thái Ngọc Duy writes:
> I find myself often do "git rebase -i xxx" and replace one "pick" line
> with "edit" to amend just one commit when I see something I don't like
> in that commit. This happens often while cleaning up a series. This
> automates the "replace" step so it sends me straig
Signed-off-by: Sun He
---
bulk-checkin.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 118c625..8c47d71 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -23,7 +23,8 @@ static struct bulk_checkin_state {
static void fin
Signed-off-by: Sun He
---
bulk-checkin.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 118c625..e3c7fb2 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -23,7 +23,8 @@ static struct bulk_checkin_state {
static void fin
Hi,
On Wed, Feb 26, 2014 at 9:28 AM, Jacopo Notarstefano
wrote:
> Hey everyone,
>
> my name is Jacopo, a student developer from Italy, and I'm interested
> in applying to this years' Google Summer of Code. I set my eyes on the
> project called "git-bisect improvements", in particular the subtask
Signed-off-by: Sun He
---
bundle.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bundle.c b/bundle.c
index e99065c..7809fbb 100644
--- a/bundle.c
+++ b/bundle.c
@@ -19,7 +19,7 @@ static void add_to_ref_list(const unsigned char *sha1, const
char *name,
Change install_branch_config() to use skip_prefix()
for getting the short name of the remote branch.
Signed-off-by: Dmitry S. Dolzhenko
---
branch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..9382e02 100644
--- a/branch.c
+++ b/bran
Signed-off-by: Sun He
---
bundle.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index 7809fbb..1a7b7eb 100644
--- a/bundle.c
+++ b/bundle.c
@@ -14,11 +14,7 @@ static const char bundle_signature[] = "# v2 git bundle\n";
static void add_to_ref_
I'm having a long think (sickness R&R) about the possible options for a
narrow clone implementation.
Is there currently any way in the code base that a complete
sub-directory can be marked as 'missing' as could be the case for a
narrow clone? The assume-unchanged/skip-worktree are close but only
From: "Sun He"
Signed-off-by: Sun He
---
bundle.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index 7809fbb..1a7b7eb 100644
--- a/bundle.c
+++ b/bundle.c
@@ -14,11 +14,7 @@ static const char bundle_signature[] = "# v2 git
bundle\n";
static
Duy Nguyen writes:
> On Thu, Feb 27, 2014 at 7:22 AM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> ---
>>
>> It is a good thing to do to read config from the real repository we
>> are borrowing from when we have .git/commondir, but it ma
Jeff King writes:
> Of all of them, I think --pack-kept-objects is probably the best. And I
> think we are hitting diminishing returns in thinking too much more on
> the name. :)
True enough.
I wonder if it makes sense to link it with "pack.writebitmaps" more
tightly, without even exposing it a
On Wed, Feb 26, 2014 at 5:52 AM, Jeff King wrote:
> This seems like a reasonable feature to me. All of your examples are
> possible with an "e"dit and another git command, but the convenience may
> be worth it (though personally, most of the examples you gave are
> particularly interesting to me[1
Jeff King writes:
> From: Scott J. Goldman
>
> In commit ee27ca4, we started restricting remote git-archive
> invocations to only accessing reachable commits. This
> matches what upload-pack allows, but does restrict some
> useful cases (e.g., HEAD:foo). We loosened this in 0f544ee,
> which allo
Signed-off-by: Faiz Kothari
---
bulk-checkin.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 118c625..feeff9f 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -23,7 +23,7 @@ static struct bulk_checkin_state {
static vo
"Dmitry S. Dolzhenko" writes:
> Refactor binary search in "commit_graft_pos" function: use
> generic "sha1_pos" function.
>
> Signed-off-by: Dmitry S. Dolzhenko
> ---
Looks trivially correct; thanks.
Looking at this patch makes me wonder why we have sha1_pos() and
sha1_entry_pos() helper funct
Michael Haggerty writes:
> Sounds good. I suggest we make your blob a paragraph before the list of
> bullet points rather than part of the list. Please suggest some "TBD*"
> then I'll add it to the text. Would we also fill in "X" with the name
> of the actual student involved in the conversati
Faiz Kothari writes:
> From: Faiz Kothari
Notice that this matches From: in your e-mail message, which means
it is unnecessary. Drop it.
>
>
> Signed-off-by: Faiz Kothari
And make sure this matches how you call yourself above.
> ---
> git-compat-util.h |7 +--
> 1 file changed, 5
Sun He writes:
> Signed-off-by: Sun He
> ---
> git-compat-util.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index cbd86c3..4daa6cf 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -357,8 +357,8 @@ exter
On Thu, 2014-02-27 at 11:21 +0100, Michael Haggerty wrote:
> On 02/27/2014 10:00 AM, Carlos Martín Nieto wrote:
> > From: Carlos Martín Nieto
> >
> > We need to consider that a remote-tracking branch may match more than
> > one rhs of a fetch refspec. In such a case, it is not enough to stop at
>
Sun He writes:
> Signed-off-by: Sun He
> ---
> bulk-checkin.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/bulk-checkin.c b/bulk-checkin.c
> index 118c625..8c47d71 100644
> --- a/bulk-checkin.c
> +++ b/bulk-checkin.c
> @@ -23,7 +23,8 @@ static struct bu
"Dmitry S. Dolzhenko" writes:
> Change install_branch_config() to use skip_prefix()
> for getting the short name of the remote branch.
>
> Signed-off-by: Dmitry S. Dolzhenko
> ---
> branch.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/branch.c b/branch.c
> index
Sun He writes:
> Signed-off-by: Sun He
> ---
The subject reads:
>> Subject: [PATCH] GSoC2014 microprojects #6 Change bundle.c:add_to_ref_list()
>> to use ALLOC_GROW()
I do not think we want to see the leading part of it in our "git
shortlog" output.
Subject: [PATCH] bundle.c:add_to_
Lee Hopkins writes:
> Last week I ran across a potential bug with branch names on case
> insensitive file systems, the complete scenario can be found here:
>
> https://groups.google.com/forum/#!topic/msysgit/ugKL-sVMiqI
>
> The tldr is because refs are stored as plain text files except when
> pac
On Thu, Feb 27, 2014 at 4:00 AM, Carlos Martín Nieto wrote:
> Subject: fetch: add a failing test for prunning with overlapping refspecs
s/prunning/pruning/
> Signed-off-by: Carlos Martín Nieto
> ---
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 1f0f8e6..4949e3d 100755
> --- a/t/t55
Carlos Martín Nieto writes:
> From: Carlos Martín Nieto
>
> We need to consider that a remote-tracking branch may match more than
> one rhs of a fetch refspec.
Hmph, do we *need* to, really?
Do you mean fetching one ref on the remote side and storing that in
multiple remote-tracking refs on ou
On Thu, Feb 27, 2014 at 4:00 AM, Carlos Martín Nieto wrote:
> Subject: fetch: add a failing test for prunning with overlapping refspecs
s/prunning/pruning/
> Signed-off-by: Carlos Martín Nieto
> ---
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 1f0f8e6..4949e3d 100755
> --- a/t/t55
On 02/27/2014 08:19 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Sounds good. I suggest we make your blob a paragraph before the list of
>> bullet points rather than part of the list. Please suggest some "TBD*"
>> then I'll add it to the text. Would we also fill in "X" with the na
Nguyễn Thái Ngọc Duy writes:
> The repo setup procedure is updated to detect $GIT_DIR/commondir and
> set $GIT_COMMON_DIR properly.
>
> The core.worktree is ignored when $GIT_DIR/commondir presents. This is
> because "commondir" repos are intended for separate/linked checkouts
> and pointing the
On 2014-02-27 20.50, Junio C Hamano wrote:
> Lee Hopkins writes:
>
>> Last week I ran across a potential bug with branch names on case
>> insensitive file systems, the complete scenario can be found here:
>>
>> https://groups.google.com/forum/#!topic/msysgit/ugKL-sVMiqI
>>
>> The tldr is because
Michael Haggerty writes:
> On 02/27/2014 08:19 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> Sounds good. I suggest we make your blob a paragraph before the list of
>>> bullet points rather than part of the list. Please suggest some "TBD*"
>>> then I'll add it to the text. Wou
Junio C Hamano writes:
> Sun He writes:
>
>> Signed-off-by: Sun He
>> ---
>> git-compat-util.h |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index cbd86c3..4daa6cf 100644
>> --- a/git-compat-util.h
>> +++ b/git-comp
> Perhaps git-{branch,tag}.txt and possibly gitrepository-layout.txt
> in Documentation/ may need a new "*Note*" section to warn against
> this.
A little more documentation never hurt anyone :).
> Or we can possibly trigger this function at the the of
> "checkout -b" or "fetch" commands ?
> Only
Junio C Hamano writes:
> Carlos Martín Nieto writes:
>
>> From: Carlos Martín Nieto
>>
>> We need to consider that a remote-tracking branch may match more than
>> one rhs of a fetch refspec.
>
> Hmph, do we *need* to, really?
>
> Do you mean fetching one ref on the remote side and storing that
Signed-off-by: Dmitry S. Dolzhenko
---
attr.c | 7 +--
builtin/pack-objects.c | 7 +--
bundle.c | 6 +-
cache-tree.c | 6 +-
commit.c | 8 ++--
diff.c | 12 ++--
diffcore-rename.c | 12 ++--
On 02/27/2014 09:37 PM, Lee Hopkins wrote:
>> Perhaps git-{branch,tag}.txt and possibly gitrepository-layout.txt
>> in Documentation/ may need a new "*Note*" section to warn against
>> this.
>
> A little more documentation never hurt anyone :).
>
>> Or we can possibly trigger this function at the
Am 25.02.2014 22:12, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
+test_expect_success PERL 'difftool properly honours gitlink and
core.worktree' '
+ git submodule add ./. submod/ule &&
+ (
+ cd submod/ule &&
+ git difftool --tool=echo --dir
Students,
Please don't solve more than one microproject. Since the coding part is
such a small part of a microproject, doing many is not much more
impressive than doing just one. And it takes quite a while to come up
with ideas for microprojects! (I can already see that we are running
out and w
On 02/27/2014 03:20 PM, Sun He wrote:
> Signed-off-by: Sun He
> ---
> bulk-checkin.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/bulk-checkin.c b/bulk-checkin.c
> index 118c625..e3c7fb2 100644
> --- a/bulk-checkin.c
> +++ b/bulk-checkin.c
> @@ -23,7 +23
On 02/27/2014 03:58 PM, Sun He wrote:
> Signed-off-by: Sun He
> ---
> bundle.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/bundle.c b/bundle.c
> index e99065c..7809fbb 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -19,7 +19,7 @@ static void add_to_ref_list(cons
On 02/27/2014 05:18 PM, Sun He wrote:
> Signed-off-by: Sun He
> ---
> bundle.c |6 +-
> 1 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/bundle.c b/bundle.c
> index 7809fbb..1a7b7eb 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -14,11 +14,7 @@ static const char bundle_si
Commit 322bb6e12f (add update 'none' flag to disable update of submodule
by default) added the '--checkout' option to "git submodule update" but
forgot to explicitly document it in the synopsis and the man page (It is
only mentioned implicitly in the man page).
Document this option in synopsis and
Dmitry,
That's cool; I never imagined there would be so many sites that could be
cleaned up in this way.
In my opinion, it would be preferable for this patch to be broken into
multiple commits, one for each site (or each file, if a file has
multiple sites that are logically related). That would
David Kastrup writes:
> Junio C Hamano writes:
>
>> Sun He writes:
>>
>>> Signed-off-by: Sun He
>>> ---
>>> git-compat-util.h |4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/git-compat-util.h b/git-compat-util.h
>>> index cbd86c3..4daa6cf 100644
>>> ---
On 02/27/2014 08:02 PM, Faiz Kothari wrote:
> Signed-off-by: Faiz Kothari
> ---
> bulk-checkin.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/bulk-checkin.c b/bulk-checkin.c
> index 118c625..feeff9f 100644
> --- a/bulk-checkin.c
> +++ b/bulk-checkin.c
>
Junio C Hamano writes:
> "Dmitry S. Dolzhenko" writes:
>
>> Change install_branch_config() to use skip_prefix()
>> for getting the short name of the remote branch.
>>
>> Signed-off-by: Dmitry S. Dolzhenko
>> ---
>> branch.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> dif
Am 27.02.2014 21:32, schrieb Torsten Bögershausen:
> On 2014-02-27 20.50, Junio C Hamano wrote:
>> Lee Hopkins writes:
>>
>>> Last week I ran across a potential bug with branch names on case
>>> insensitive file systems, the complete scenario can be found here:
>>>
>>> https://groups.google.com/fo
Hi,
Thanks for the remarks.
I'll stick to this micro project and follow the guidelines.
Yes, the strbuf API is perfectly OK. I was not getting to work it
properly, so I used malloc() / free() instead. My bad.
I'll resubmit the patch.
Thanks.
On Fri, Feb 28, 2014 at 3:47 AM, Michael Haggerty wrote
"Dmitry S. Dolzhenko" writes:
> diff --git a/dir.c b/dir.c
> index b35b633..72f6e2a 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1329,13 +1329,10 @@ static struct path_simplify *create_simplify(const
> char **pathspec)
>
> for (nr = 0 ; ; nr++) {
> const char *match;
> -
On 27 February 2014 06:47, Christian Couder wrote:
> But I think the most important thing right now is first to gather as
> much information as you can from the previous discussions on this
> topic on this mainling list.
> Perhaps you should also gather information on how git bisect works.
I have
Thomas Rast writes:
> The directory hash (for fast checks if the index already has a
> directory) was only used in ignore_case mode and so depended on that
> flag.
>
> Make it generally available on request.
>
> Signed-off-by: Thomas Rast
> ---
I somehow had an impression that we were getting r
On Fri, Feb 28, 2014 at 12:25 AM, Philip Oakley wrote:
> Have there been previous attempts to look at marking sub-dirs as
> --skip-worktree, or some other sentinel value for the missing tree?
I dealt with this by creating partial index, that only contains
entries for interested subtrees. The inde
> If I understand the issue correctly, the problem is that packed-refs are
> always case-sensitive, even if core.ignorecase=true.
> OTOH, checking / updating _unpacked_ refs on a case-insensitive file system
> is naturally case-insensitive.
> So wouldn't it be a better workaround to disallow pack
From: "Duy Nguyen"
On Fri, Feb 28, 2014 at 12:25 AM, Philip Oakley
wrote:
Have there been previous attempts to look at marking sub-dirs as
--skip-worktree, or some other sentinel value for the missing tree?
I dealt with this by creating partial index, that only contains
entries for intereste
Signed-off-by: Faiz Kothari
---
Compiles without errors.
Fails in test t/t1050-large.sh ,fails 12/15 tests. Dumps memory map and
backtrace.
Somewhere its not able to free(): invalid pointer.
Please somone pointout where I am doing it wrong.
Help is really appreciated.
Thanks.
bulk-checkin.c |
On Fri, Feb 28, 2014 at 6:46 AM, Philip Oakley wrote:
> Is there a particular bit of code I'd be worth studying for the partial
> index example to see how well it might fit my ideas?
My last attempt was
http://git.661346.n2.nabble.com/PATCH-00-17-Narrow-clone-v3-was-subtree-clone-tt5499879.html
I
Kindly Find Details In Attach File and Reply via Email:rbi.de...@careceo.com
RBI 14.docx
Description: Binary data
Matthieu Moy writes:
> li...@haller-berlin.de (Stefan Haller) writes:
>
>> Your intention was clearly to drop the stash, it just wasn't dropped
>> because of the conflict. Dropping it automatically once the conflict
>> is resolved would be nice.
>
> Your intention when you ran "git stash pop", ye
Junio C Hamano writes:
> ... So "resolve the conflicts" is assuming the intention of
> the user who issued "pop" too much (let alone "manually"---it does
> not matter how the user resolves conflicts---the only thing we want
> to say is Git did all it would and no further automated help in
> reso
From: modocache
No test asserts that "git branch -u refs/heads/my-branch my-branch"
emits a warning. Add a test that does so.
Signed-off-by: Brian Gesiak
---
t/t3200-branch.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index fcdb867..f70b9
From: modocache
The install_branch_config function reimplemented the skip_prefix
function inline. Use skip_prefix function instead for brevity.
Signed-off-by: Brian Gesiak
Reported-by: Michael Haggerty
---
branch.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff
Stephan:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
wrote:
> You might be adding other files for other reasons. But if you add a file
> that does resolve a conflict caused by 'git stash pop', it is not
> guessing.
Staging a file doesn't tell git that you resolved a conflict. Git will
happily
On Thu, Feb 27, 2014 at 7:04 PM, Faiz Kothari wrote:
> Signed-off-by: Faiz Kothari
> ---
> Compiles without errors.
> Fails in test t/t1050-large.sh ,fails 12/15 tests. Dumps memory map and
> backtrace.
> Somewhere its not able to free(): invalid pointer.
> Please somone pointout where I am doin
On Fri, Feb 28, 2014 at 12:04:18PM +0900, Brian Gesiak wrote:
> No test asserts that "git branch -u refs/heads/my-branch my-branch"
> emits a warning. Add a test that does so.
For an operation like "git branch foo origin" where setting up the
tracking is a side effect, a warning makes sense. But
On Fri, Feb 28, 2014 at 12:04:19PM +0900, Brian Gesiak wrote:
> From: modocache
Both your emailed patches have this, which is due to your author name
not matching your sending identity. You probably want to set user.name,
or if you already have (which it looks like you might have from your
Signe
> For an operation like "git branch foo origin" where setting up the
> tracking is a side effect, a warning makes sense. But the sole purpose
> of the command above is to set the upstream, and we didn't do it; should
> this warning actually be upgraded to an error?
I agree. I originally wrote the
On Thu, Feb 27, 2014 at 09:33:45PM +0100, David Kastrup wrote:
> >> diff --git a/git-compat-util.h b/git-compat-util.h
> >> index cbd86c3..4daa6cf 100644
> >> --- a/git-compat-util.h
> >> +++ b/git-compat-util.h
> >> @@ -357,8 +357,8 @@ extern int suffixcmp(const char *str, const char
> >> *suffi
On Fri, Feb 28, 2014 at 03:17:28PM +0900, Brian Gesiak wrote:
> > For an operation like "git branch foo origin" where setting up the
> > tracking is a side effect, a warning makes sense. But the sole purpose
> > of the command above is to set the upstream, and we didn't do it; should
> > this warn
1 - 100 of 113 matches
Mail list logo
