Signed-off-by: Sun He sunheeh...@gmail.com
---
builtin/pack-objects.c | 17 +++--
bulk-checkin.c | 8 +---
pack-write.c | 20
pack.h | 2 +-
4 files changed, 25 insertions(+), 22 deletions(-)
diff --git
On Fri, Feb 28, 2014 at 04:28:38PM +0900, Brian Gesiak wrote:
I would be in favor of using test_i18ngrep, but it seems like this
test file overwhelmingly uses test_(i18n)cmp, even when inspecting
stderr output.
We generally prefer cmp checks to grep checks, because they are more
rigorous.
From: Duy Nguyen pclo...@gmail.com
On Fri, Feb 28, 2014 at 6:46 AM, Philip Oakley philipoak...@iee.org
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
On Thu, Feb 27, 2014 at 10:04:44AM -0800, Junio C Hamano wrote:
I wonder if it makes sense to link it with pack.writebitmaps more
tightly, without even exposing it as a seemingly orthogonal knob
that can be tweaked, though.
I think that is because I do not fully understand the , because ...
Mh. Haven't thought of that. I have no experience with TK, so I'm
having trouble digging up where the good and bad labels in the GUI
are generated.
I guess that a solution might involve writing a temporary file in
$GIT_DIR called something like BISECT_LABELS in which the chosen
labels are listed
Jonathan Nieder jrnie...@gmail.com writes:
Hi,
Andrew Wong wrote:
The first two patches are just about rewording a message, and adding messages
to tell users to use git merge --abort to abort a merge.
Sounds like a good idea. I look forward to reading the patches.
We could stop here
On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
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?
As Matthieu Moy remarked in a previous email,
On Thu, Feb 27, 2014 at 10:37:30AM -0800, Junio C Hamano wrote:
Signed-off-by: Jeff King p...@peff.net
Thanks.
Do GitHub people have general aversion against signing off (or
sending out, for that matter) their own patches, unless they were
already active here before they joined GitHub,
This email was sent privately by Michael to me as a result of my
previous error. I'm quoting it in its entirety so that he doesn't have
to submit it twice.
On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
Please forgive my typos and brevity; this was typed on a
Signed-off-by: Sun He sunheeh...@gmail.com
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 7b8d3fa..59a52b0 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -371,7 +371,7 @@ static void parse_options_check(const
Karsten Blees karsten.bl...@gmail.com writes:
If I understand the issue correctly, the problem is that packed-refs
are always case-sensitive, even if core.ignorecase=true.
Perhaps that could be changed? if core.ignorecase=true, packed-refs
should be compared with case-insensitive string
- git could emit an error message and refuse to continue
- git could interpret the command one way or the other, with or without a
warning
By my count that gives at least five possibilities. The feature cannot be
implemented without choosing one.
Let me explain what I meant with an
On 02/28/2014 12:38 AM, Lee Hopkins wrote:
[...] Based Michael Haggerty's response, it seems that always
using loose refs would be a better workaround.
No, I answered the question what would be the disadvantages of using
only packed refs?. Now I will answer the question what would be the
On Fri, Feb 28, 2014 at 2:58 AM, Faiz Kothari faiz.of...@gmail.com wrote:
Signed-off-by: Faiz Kothari faiz.of...@gmail.com
Notes:
I finally got what's happening, and why the errors were caused.
packname is supposed to contain the complete path to the .pack file.
Packs are stored
On Fri, Feb 28, 2014 at 03:01:53AM -0600, Stephen Leake wrote:
Jonathan Nieder jrnie...@gmail.com writes:
And for experienced users, this would be a bad regression.
Backward incompatibility is a real concern.
It might be best if git reset (with _no_ option) be made to error out,
so all
Thank you for your remarks. In this patch I tried to take them into account.
Dmitry S. Dolzhenko (11):
builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()
bundle.c: change add_to_ref_list() to use ALLOC_GROW()
cache-tree.c: change find_subtree() to use ALLOC_GROW()
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
builtin/pack-objects.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c733379..56a6fc8 100644
--- a/builtin/pack-objects.c
+++
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
bundle.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index e99065c..1388a3e 100644
--- a/bundle.c
+++ b/bundle.c
@@ -14,11 +14,7 @@ static const char bundle_signature[] = # v2 git
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
cache-tree.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 0bbec43..30149d1 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -75,11 +75,7 @@ static struct cache_tree_sub
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
commit.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index 6bf4fe0..e004314 100644
--- a/commit.c
+++ b/commit.c
@@ -147,12 +147,8 @@ int register_commit_graft(struct
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
diff.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/diff.c b/diff.c
index e800666..aebdfda 100644
--- a/diff.c
+++ b/diff.c
@@ -1361,11 +1361,7 @@ static struct diffstat_file
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
replace_object.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/replace_object.c b/replace_object.c
index cdcaf8c..843deef 100644
--- a/replace_object.c
+++ b/replace_object.c
@@ -36,12 +36,8 @@ static
Affected functions: read_one_reflog(), add_commit_info()
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
reflog-walk.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index b2fbdb2..879d2ed 100644
---
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
dir.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/dir.c b/dir.c
index 98bb50f..4ae38e4 100644
--- a/dir.c
+++ b/dir.c
@@ -1341,10 +1341,7 @@ static struct path_simplify *create_simplify(const char
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
attr.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/attr.c b/attr.c
index 8d13d70..734222d 100644
--- a/attr.c
+++ b/attr.c
@@ -338,12 +338,7 @@ static void handle_attr_line(struct attr_stack *res,
On Fri, Feb 28, 2014 at 04:07:09AM -0500, Jeff King wrote:
As this does not affect local use of git archive, requested by
refnames may need to be clarified further. Perhaps remote
archives can be requested only for published refnames or something.
I was hoping to be vague. If we really
Commits ee27ca4 and 0f544ee introduced rules by which
git-upload-archive would restrict clients from accessing
unreachable objects. However, we never documented those
rules anywhere, nor their reason for being. Let's do so now.
Signed-off-by: Jeff King p...@peff.net
---
From: Scott J. Goldman scot...@github.com
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 allows `foo:bar`
Stephen Leake stephen_le...@stephe-leake.org writes:
I like commands that do the right thing. So no, this would not be
confusing.
I _hate_ commands that think they know better than to do what they are
told. In particular when doing destructive things. And just because
_you_ like them does
If you feel like continuing on this series, converting the warning()
into a die() would be a much more productive use of time (but if you
don't, I do not see any reason not to take the patches you've posted).
I'd be happy to keep working on this. In fact, I think I have a patch
for this ready.
On Fri, Feb 28, 2014 at 6:15 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 02/28/2014 10:07 AM, Sun He wrote:
Signed-off-by: Sun He sunheeh...@gmail.com
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
On Fri, Feb 28, 2014 at 07:44:10PM +0900, Brian Gesiak wrote:
I notice that the warning comes from install_branch_config, which gets
used both for branch -u, but also in the side effect case I
mentioned above. Is it possible to trigger this as part of such a case?
I think maybe git branch
Since commit 6f084a56 the length of a newly tracked branch name was limited
to 1019 = 1024 - 7 - 7 - 1 characters, a bound derived by having to store
this name in a char[1024] called key with two strings of length at most 7
and a '\0' character.
This was no longer necessary as of commit a9f2c136,
This patch removes this unneeded check and thus allows for branch names
longer than 1019 characters.
Ach! I amended the commit in my local history to read Remove this
unneded check and thus allow for branch names longer than 1019
characters, but for some reason git format-patch -1 --signoff
I just don't want to regress somebody else's workflow due
to my lack of imagination.
This makes a lot of sense to me, although as-is the function emits a
warning and returns immediately (although with a successful status
code), so I'm also stumped as to what kind of workflow this would be
Hi!
On Mon, 24 Feb 2014 20:21:49 +0400, Kirill Smelkov k...@mns.spb.ru wrote:
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
Nice. new_ref is passed in install_branch_config() in latest code. I
guess you already made sure this function did not make any assumption
about new_ref's length?
The function install_branch_config uses the strbuf, as I wrote in the
commit message. The contents of this buffer are then fed to
On Thu, 2014-02-27 at 12:19 -0800, Junio C Hamano wrote:
Carlos Martín Nieto c...@elego.de writes:
From: Carlos Martín Nieto c...@dwim.me
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
On Fri, Feb 28, 2014 at 4:40 PM, Dmitry S. Dolzhenko
dmitrys.dolzhe...@yandex.ru wrote:
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
builtin/pack-objects.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/builtin/pack-objects.c
On Fri, Feb 28, 2014 at 4:46 PM, Dmitry S. Dolzhenko
dmitrys.dolzhe...@yandex.ru wrote:
Affected functions: read_one_reflog(), add_commit_info()
We can usually see this from @@ line so it's not really needed to
describe. Same comment for a few other patches.
--
Duy
--
To unsubscribe from this
On Fri, Feb 28, 2014 at 7:32 PM, Duy Nguyen pclo...@gmail.com wrote:
done_pbase_paths_num++;
If you move this up one line, then you don't have to + 1 in ALLOC_GROW
same comment to a few other patches. The rest of your series looks good.
--
Duy
--
To unsubscribe from this list: send
On Fri, Feb 28, 2014 at 7:14 PM, Jacopo Notarstefano
jacopo.notarstef...@gmail.com wrote:
Nice. new_ref is passed in install_branch_config() in latest code. I
guess you already made sure this function did not make any assumption
about new_ref's length?
The function install_branch_config uses
On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:
On Wed, Feb 26, 2014 at 5:52 AM, Jeff King p...@peff.net wrote:
This seems like a reasonable feature to me. All of your examples are
possible with an edit and another git command, but the convenience may
be worth it (though
On Fri, Feb 28, 2014 at 4:46 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Feb 28, 2014 at 3:28 AM, Sun He sunheeh...@gmail.com wrote:
Signed-off-by: Sun He sunheeh...@gmail.com
---
Nicely done.
Due to the necessary changes to finish_tmp_packfile(), the focus of
this patch has
On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov k...@mns.spb.ru wrote:
diff --git a/Makefile b/Makefile
index dddaf4f..0334806 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +321,7 @@ endif
ifeq ($(uname_S),Windows)
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
+
On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov k...@mns.spb.ru wrote:
diff --git a/Makefile b/Makefile
index dddaf4f..0334806 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +321,7 @@ endif
ifeq ($(uname_S),Windows)
On Fri, Feb 28, 2014 at 08:16:13PM +0900, Brian Gesiak wrote:
I just don't want to regress somebody else's workflow due
to my lack of imagination.
This makes a lot of sense to me, although as-is the function emits a
warning and returns immediately (although with a successful status
Am 28.02.2014 07:41, schrieb Johannes Sixt:
Am 2/28/2014 0:38, schrieb Lee Hopkins:
If I understand the issue correctly, the problem is that packed-refs
are always case-sensitive, even if core.ignorecase=true. OTOH,
core.ignorecase is intended to affect filenames of the worktree, not
On 02/28/2014 01:52 PM, Jeff King wrote:
[...]
Sorry, I missed an important word in my final sentence. It should have
been the examples you gave are NOT particularly interesting to me.
On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:
Particularly all of the ideas expressed
If you are on a case-insensitive filesystem, or work on a cross-platform
project, ensure that you avoid ambiguous refs. Problem solved.
I agree this is the best solution, and I personally avoid the use of
ambiguous refs. However, since there is nothing in git stopping the
use of ambiguous refs,
David Kastrup d...@gnu.org writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
I like commands that do the right thing. So no, this would not be
confusing.
I _hate_ commands that think they know better than to do what they are
told. In particular when doing destructive things.
2014-02-28 21:12 GMT+08:00 Eric Sunshine [via git]
ml-node+s661346n760450...@n2.nabble.com:
On Fri, Feb 28, 2014 at 4:46 AM, Eric Sunshine [hidden email] wrote:
On Fri, Feb 28, 2014 at 3:28 AM, Sun He [hidden email] wrote:
Signed-off-by: Sun He [hidden email]
---
Nicely done.
Due to the
On 02/28/2014 01:40 PM, Duy Nguyen wrote:
On Fri, Feb 28, 2014 at 7:32 PM, Duy Nguyen pclo...@gmail.com wrote:
done_pbase_paths_num++;
If you move this up one line, then you don't have to + 1 in ALLOC_GROW
same comment to a few other patches. The rest of your series looks good.
Stephen Leake stephen_le...@stephe-leake.org writes:
David Kastrup d...@gnu.org writes:
do the right thing commands also tend to do the wrong thing
occasionally with potentially disastrous results when they are used
in scripts where the followup actions rely on the actual result.
That is
I just wrote up another double-idea that has been stewing in my head for
a while:
* Allow configuration values to be unset via a config file
* Fix git config --unset to clean up detritus from sections that are
left empty.
These ideas are more out there than the last, and might be too
On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 02/28/2014 12:38 AM, Lee Hopkins wrote:
[...] Based Michael Haggerty's response, it seems that always
using loose refs would be a better workaround.
No, I answered the question what would be the disadvantages of
Signed-off-by: Sun He sunheeh...@gmail.com
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 7b8d3fa..59a52b0 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -371,7 +371,7 @@ static void parse_options_check(const
I am not sure if this is a bug.
I need your help to find out it.
Cheers,
He Sun
2014-02-28 22:29 GMT+08:00 Sun He sunheeh...@gmail.com:
Signed-off-by: Sun He sunheeh...@gmail.com
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c
On Fri, Feb 28, 2014 at 9:20 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
Duy,
The example in Documentation/technical/api-allocation-growing.txt does
it the same way as Dmitry:
ALLOC_GROW(item, nr + 1, alloc);
item[nr++] = value you like;
The alternative,
nr++;
On 02/28/2014 03:31 PM, Duy Nguyen wrote:
On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
On 02/28/2014 12:38 AM, Lee Hopkins wrote:
[...] Based Michael Haggerty's response, it seems that always
using loose refs would be a better workaround.
No, I answered the
Way too long subject line. Keep it within 70-75 chars. The rest could
be put in the body.
On Fri, Feb 28, 2014 at 9:32 PM, 孙赫 sunheeh...@gmail.com wrote:
I am not sure if this is a bug.
I need your help to find out it.
Tip:git has a wonderful history (most of it anyway). Try git log
--patch
On 02/28/2014 10:29 AM, Dmitry S. Dolzhenko wrote:
Thank you for your remarks. In this patch I tried to take them into account.
Dmitry S. Dolzhenko (11):
builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()
bundle.c: change add_to_ref_list() to use ALLOC_GROW()
Jeff King p...@peff.net writes:
Don't die to let the caller finish its
job in such case.
[...]
Matthieu, can you remember anything else that
led to that decision?
Not at all, unfortunately. I don't remember if I did that in case
there's something like some cleanup to do or because I
Brandon McCaig bamcc...@gmail.com writes:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org 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
2014-02-28 22:43 GMT+08:00 Duy Nguyen [via git]
ml-node+s661346n7604517...@n2.nabble.com:
Way too long subject line. Keep it within 70-75 chars. The rest could
be put in the body.
On Fri, Feb 28, 2014 at 9:32 PM, 孙赫 [hidden email] wrote:
I am not sure if this is a bug.
I need your help to
Signed-off-by: Sun He sunheeh...@gmail.com
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 7b8d3fa..59a52b0 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -371,7 +371,7 @@ static void parse_options_check(const
Signed-off-by: Sun He sunheeh...@gmail.com
---
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c733379..4922ce5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -823,7 +823,7 @@
Stephen Leake stephen_le...@stephe-leake.org writes:
So it appears that adding a file _does_ tell git that the conflict is
resolved.
Yes it does. Git _knows_ that you consider the conflict to be resolved.
It cannot know how happy you are with the result.
Similarly, in a conflicted merge, the
-- Forwarded message --
From: 孙赫 sunheeh...@gmail.com
Date: 2014-02-28 21:37 GMT+08:00
Subject: Re: [PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to
use a strbuf for handling packname
To: Eric Sunshine [via git] ml-node+s661346n7604473...@n2.nabble.com
2014-02-28 17:47
OK, so what can we do next?
Paul
-Original Message-
From: Paul Lotz [mailto:pl...@lsst.org]
Sent: Monday, February 24, 2014 9:44 AM
To: 'David Aguilar'
Cc: 'git@vger.kernel.org'
Subject: RE: difftool sends malformed path to exernal tool on Windows
David,
Thanks for the helpful reply.
Stephen Leake stephen_le...@stephe-leake.org writes:
Brandon McCaig bamcc...@gmail.com writes:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by
Signed-off-by: Sun He sunheeh...@gmail.com
---
The tmpname is uninitialized and it should a bug
Please ignore the former patches about this with wrong format.
I am sorry to cause a jam in your inbox. ^_^
In the end, I wanna thank Michael Haggerty who give me help.
builtin/pack-objects.c | 2 +-
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
cache.h | 13 +
replace_object.c | 7 +++
2 files changed, 20 insertions(+)
diff --git a/cache.h b/cache.h
index b039abc..9407560 100644
--- a/cache.h
+++ b/cache.h
@@ -798,13 +798,26 @@ static inline void
This patch series applies on top of mh/replace-refs-variable-rename,
simply because one of the comments refers to the global variable
check_replace_refs by its new name.
This is a re-roll of patches 1/6 and 6/6 of the series
mh/object-code-cleanup that I submitted earlier [1]. Patches 2-5 of
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
object.c | 29 -
object.h | 7 +++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/object.c b/object.c
index 584f7ac..57a0890 100644
--- a/object.c
+++ b/object.c
@@ -43,14 +43,32 @@ int
Signed-off-by: Sun He sunheeh...@gmail.com
---
I follow the suggestions of Eric Sunshine to fix the patch.
Of cause this patch has assumed that you have already fix the bug of
tmpname in builtin/pack-objects.c:write_pack_file() warning()
I want to say thank you to Eric Sunshine and Michael
The use case:
I'm doing a 'git stash pop'; it had conflicts. At this point, 'git status'
shows:
# On branch master
# Changes to be committed:
# (use git reset HEAD file... to unstage)
#
# modified: Target.java
#
# Unmerged paths:
# (use git reset HEAD file... to unstage)
# (use
On Fri, Feb 28, 2014 at 02:50:04PM +0100, Erik Faye-Lund wrote:
On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov k...@mns.spb.ru wrote:
diff --git a/Makefile b/Makefile
index dddaf4f..0334806 100644
--- a/Makefile
On Feb 28, 2014, at 1:55 AM, Jeff King p...@peff.net wrote:
On Thu, Feb 27, 2014 at 10:04:44AM -0800, Junio C Hamano wrote:
I wonder if it makes sense to link it with pack.writebitmaps more
tightly, without even exposing it as a seemingly orthogonal knob
that can be tweaked, though.
I
From: Jeff King p...@peff.net
I'd expect -$n to mean rebase the last $n commits (as opposed to
everything not in the upstream). That does not work currently, of
course, but:
1. It has the potential to confuse people who read it, since it's
unlike what -1 means in most of the rest of git.
On Fri, Feb 28, 2014 at 6:00 PM, Kirill Smelkov k...@mns.spb.ru wrote:
On Fri, Feb 28, 2014 at 02:50:04PM +0100, Erik Faye-Lund wrote:
On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov k...@mns.spb.ru wrote:
diff --git
David Kastrup d...@gnu.org writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
David Kastrup d...@gnu.org writes:
do the right thing commands also tend to do the wrong thing
occasionally with potentially disastrous results when they are used
in scripts where the followup actions
Matthieu Moy matthieu@grenoble-inp.fr writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
So it appears that adding a file _does_ tell git that the conflict is
resolved.
Yes it does. Git _knows_ that you consider the conflict to be resolved.
It cannot know how happy you are
David Kastrup d...@gnu.org writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
Brandon McCaig bamcc...@gmail.com writes:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
You might be adding other files for other reasons. But if you add a file
Stephen Leake stephen_le...@stephe-leake.org writes:
Matthieu Moy matthieu@grenoble-inp.fr 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
On Fri, 28 Feb 2014, Michael Haggerty wrote:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Acked-by: Nicolas Pitre n...@fluxnic.net
---
object.c | 29 -
object.h | 7 +++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/object.c
Jeff King p...@peff.net writes:
On Thu, Feb 27, 2014 at 10:37:30AM -0800, Junio C Hamano wrote:
Signed-off-by: Jeff King p...@peff.net
Thanks.
Do GitHub people have general aversion against signing off (or
sending out, for that matter) their own patches, unless they were
already
Jeff King p...@peff.net writes:
Here's a series to handle this; I think the end result is much nicer. I
ended up calling the option uploadarchive.allowUnreachable. By moving
it there instead of under archive, it is more clear that this is about
the _serving_ end of the remote connection, and
Stephen Leake stephen_le...@stephe-leake.org writes:
David Kastrup d...@gnu.org writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
David Kastrup d...@gnu.org writes:
do the right thing commands also tend to do the wrong thing
occasionally with potentially disastrous results when
Carlos Martín Nieto c...@elego.de writes:
... However, we now
have 'origin/master' and 'origin/pr/5' both of which match the
'refs/remotes/origin/*' pattern. The current behaviour is to stop at the
first match, which would mark it as stale as there is no
'refs/heads/pr/5' branch in the
Hi,
Thanks for the suggestions and remarks.
I rewrote bulk-checkin.c:finish_bulk_checkin() using strbuf. But saw
that Sun He has already implemented the same way I have done.
Should I submit my implementation as a patch?
Secondly,
I tried implementing this WITHOUT changing the prototype of the
Jeff King p...@peff.net writes:
On Thu, Feb 27, 2014 at 10:04:44AM -0800, Junio C Hamano wrote:
I wonder if it makes sense to link it with pack.writebitmaps more
tightly, without even exposing it as a seemingly orthogonal knob
that can be tweaked, though.
I think that is because I do not
Karsten Blees karsten.bl...@gmail.com writes:
If you are on a case-insensitive filesystem, or work on a cross-platform
project, ensure that you avoid ambiguous refs. Problem solved.
So its OK to lose data if you accidentally use an ambiguous ref? I
cannot believe you actually meant that.
Michael Haggerty mhag...@alum.mit.edu writes:
So my vote is that the patches are OK the way Dmitry wrote them (mind, I
have only read through 05/11 so far).
Seconded ;-)
By the way, I do not like these long subjects. change is a
redundant word when one sends a patch---as all patches are
Duy Nguyen pclo...@gmail.com writes:
On Fri, Feb 28, 2014 at 4:46 PM, Dmitry S. Dolzhenko
dmitrys.dolzhe...@yandex.ru wrote:
Affected functions: read_one_reflog(), add_commit_info()
We can usually see this from @@ line so it's not really needed to
describe. Same comment for a few other
The part string_list of the name of function
pretty_print_string_list is just an implementation
detail. The function pretty-prints command names so
rename it to pretty_print_cmdnames.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Just noticed this while digging through Git codebase.
Hi,
I get 12 of 15 tests faling.
Any idea? the same build works fine on 11.04 where I have a desktop version.
Thanks
not ok 1 - New file
#mkdir A B C D E F
# echo hello1 A/newfile1.txt
# echo hello2 B/newfile2.txt
# cp $TEST_DIRECTORY/test-binary-
1.png
Stephen Leake stephen_le...@stephe-leake.org writes:
I was not aware that the git system could support more than one version
of a file in one branch.
The index only. The history itself does not.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line
Michael Haggerty mhag...@alum.mit.edu writes:
On 02/28/2014 10:07 AM, Sun He wrote:
Signed-off-by: Sun He sunheeh...@gmail.com
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 7b8d3fa..59a52b0 100644
---
Stephen Leake stephen_le...@stephe-leake.org writes:
So a message merge complete; you can drop the stash would be the most
git should do.
From the user experience point of view, that would be good. It could
bother some users, but we have advice.* to silent this kind of warnings.
From the
1 - 100 of 142 matches
Mail list logo
