Remove dead code around remove_dir_recursively().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
dir.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/dir.c b/dir.c
index 910bfcd..2b31241 100644
--- a/dir.c
+++ b/dir.c
@@ -1464,11 +1464,11
On Sun, Sep 8, 2013 at 12:21 AM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told replace
svn commit with git
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Which can be solved by adding the above fail option, and then
renaming them to pull.integrate and branch.name.integrate to
clarify what these variables are about (it is no
The parameter is called break_score, not minimum_edit.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
diffcore-break.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index 1d9e530..34dd1e0 100644
--- a/diffcore-break.c
+++
On Sun, Sep 8, 2013 at 11:44 AM, Jeff King p...@peff.net wrote:
On Fri, Sep 06, 2013 at 07:46:01AM +0700, Nguyen Thai Ngoc Duy wrote:
---
I had something that could unpack without writing to temp pack file
but I scraped it and chose this way because it follows closely how
index-pack
On Sun, Sep 08, 2013 at 01:28:47PM +0700, Nguyen Thai Ngoc Duy wrote:
From a cursory read, this seems fine. If it were done in complete
isolation, I'd say it was a slight regression, just because we are doing
more I/O for the unpack case, and it is not really saving us any code
(it is not
On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
I think it's fine to tell them to do git pull --merge. What I'd worry
more about is somebody who is suddenly presented with the choice between
--rebase and --merge and doesn't know which to choose. We've created a
cognitive
On Fri, Sep 06, 2013 at 10:46:24AM -0700, Junio C Hamano wrote:
I think it is perfectly fine to expose _only_ HEAD now, and wait
until we find a good reason that we should send this information for
other symbolic refs in the repository.
Yeah, I agree with that.
However, because we already
On Sun, Sep 8, 2013 at 1:54 AM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
I think it's fine to tell them to do git pull --merge. What I'd worry
more about is somebody who is suddenly presented with the choice between
--rebase and
Mostly cleanups after Nico's comments. The diff against v2 is
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 4a24bc3..88340b5 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -22,8 +22,8 @@ struct object_entry {
struct pack_idx_entry idx;
unsigned
---
builtin/index-pack.c | 82
1 file changed, 45 insertions(+), 37 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 1dbabe0..5fbd517 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -277,6 +277,31 @@
---
packv4-parse.c | 8
packv4-parse.h | 1 +
sha1_file.c| 2 ++
3 files changed, 11 insertions(+)
diff --git a/packv4-parse.c b/packv4-parse.c
index 82661ba..d515bb9 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -63,6 +63,14 @@ struct packv4_dict *pv4_create_dict(const
---
builtin/index-pack.c | 49 -
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 3389262..83e6e79 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -11,6 +11,7 @@
---
builtin/index-pack.c | 62 +++-
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 78554d0..3389262 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -431,6 +431,40 @@
---
builtin/index-pack.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 9c1cfac..1dbabe0 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -19,8 +19,8 @@ struct object_entry {
---
packv4-parse.c | 63 --
packv4-parse.h | 8
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index 63bba03..82661ba 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -30,11
---
builtin/index-pack.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index e903a49..ce06473 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1173,10 +1173,13 @@ static struct base_data
For v2, ofs-delta and ref-delta can only have queue one delta base at
a time. A v4 tree can have more than one delta base. Move the queuing
code up to unpack_raw_entry() and give unpack_tree_v4() more
flexibility to add its bases.
---
builtin/index-pack.c | 46
---
builtin/index-pack.c | 94 ++--
1 file changed, 91 insertions(+), 3 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index efb969a..473514a 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -319,6 +319,30 @@
---
builtin/index-pack.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 83e6e79..efb969a 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -288,6 +288,19 @@ static inline void
---
builtin/index-pack.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 8f2d929..e903a49 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -24,6 +24,7 @@ struct object_entry {
This is the most common case for delta trees. In fact it's the only
kind that's produced by packv4-create. It fits well in the way
index-pack resolves deltas and benefits from threading (the set of
objects depending on this base does not overlap with the set of
objects depending on another base)
---
builtin/index-pack.c | 105 +--
1 file changed, 101 insertions(+), 4 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 473514a..dcb6409 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -334,6 +334,14 @@
On Sun, Sep 08, 2013 at 03:13:59AM -0400, Jeff King wrote:
What do you think about teaching git to read extra data after \0 for
_every_ ref line? And then ref advertisement might look something like:
sha1 HEAD\0multi_ack thin-pack ... symref=refs/heads/master\n
sha1 refs/heads/master\n
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 2:33 AM
[snip...]
The snapshot concept is totally orthogonal from the staging area
concept. Git works in snapshots, which are frozen images of how the
content tree was at a certain point in time; IOW; a commit.
On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
I think the guy may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'? Certainly not git.
Any of the hundreds of existing tutorials that
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 3:34 AM
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping j...@keeping.me.uk
wrote:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If
On Tue, Aug 20, 2013 at 05:12:47PM +0200, Antoine Pelisse wrote:
On Sat, Jul 20, 2013 at 2:22 AM, Jeff King p...@peff.net wrote:
I do plan to finish it eventually, but if anyone else feels like picking
it up, I'd be glad to review patches and/or share my work-in-progress as
a starting
From: Jeff King p...@peff.net
Sent: Sunday, September 08, 2013 5:06 AM
Was there some objective argument made that I missed?
Here's more; human semantics:
Isn't this one of those pick any two from three tasks:
'human', 'objective', 'argument'.
Only 1/6 of the time is an 'objective'
On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley philipoak...@iee.org wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 3:34 AM
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping j...@keeping.me.uk wrote:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano
Here's a re-roll (and re-design) of my series to help with git config
and large integers. It takes the different approach we discussed of
simply removing (well, increasing) the range limits for git config
--int.
I also improved the error messages for bogus config (patches 3-4).
[1/5]: config:
When we look at a config value as an integer using the
git_config_int function, we carefully range-check the value
we get and complain if it is out of our range. But the range
we compare to is that of a long, which we then cast to an
int in the function's return value. This means that on
systems
When we are parsing an integer or unsigned long, we use
the strto*max functions, which properly set errno to ERANGE
if we get a large value. However, we also do further range
checks after applying our multiplication factor, but do not
set ERANGE. This means that a caller cannot tell if an error
If we try to parse an integer config argument and get a
number outside of the representable range, we die with the
cryptic message: bad config value for '%s'.
We can improve two things:
1. Show the value that produced the error (e.g., bad
config value '3g' for 'foo.bar').
2. Mention
When you run git config --int, the maximum size of integer
you get depends on how git was compiled, and what it
considers to be an int.
This is almost useful, because your scripts calling git
config will behave similarly to git internally. But relying
on this is dubious; you have to actually know
From: Felipe Contreras felipe.contre...@gmail.com
To: Philip Oakley philipoak...@iee.org
Cc: John Keeping j...@keeping.me.uk; Junio C Hamano
gits...@pobox.com; git@vger.kernel.org; Andreas Krey
a.k...@gmx.de
Sent: Sunday, September 08, 2013 9:16 AM
Subject: Re: [PATCH 0/3] Reject non-ff pulls
On Sun, Sep 8, 2013 at 2:50 AM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
I think the guy may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'?
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley philipoak...@iee.org wrote:
The 'problem' is (would be) that I don't yet know that I would need the
--onto pu until I discover (how?) that the default rebase would result in
conflicts.
I don't see what that has to do with an invocation of 'git
I've gotten complaints that cloning from github.com with -q will
sometimes abort before sending any data. The problem is that during a
quiet clone, upload-pack may be silent for a long time while preparing
the pack (i.e., the counting objects and compressing phases).
We have load balancers and
From: Jeff King p...@peff.net
There is no reason not to turn on keepalives by default.
They take very little bandwidth, and significantly less than
the progress reporting they are replacing. And in the case
that progress reporting is on, we should never need to send
a keepalive anyway, as we will
Whenn upload-pack has started pack-objects, there may be a
quiet period while pack-objects prepares the pack (i.e.,
counting objects and delta compression). Normally we would
see (and send to the client) progress information, but if
--quiet is in effect, pack-objects will produce nothing at
all
On Sun, Sep 8, 2013 at 2:49 AM, Philip Oakley philipoak...@iee.org wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 2:33 AM
[snip...]
The snapshot concept is totally orthogonal from the staging area
concept. Git works in snapshots, which are frozen
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 9:49 AM
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley philipoak...@iee.org
wrote:
The 'problem' is (would be) that I don't yet know that I would need
the
--onto pu until I discover (how?) that the default
On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote:
I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:
1.
On Wed, Sep 4, 2013 at 8:20 AM, Nazri Ramliy ayieh...@gmail.com wrote:
Subject: git: run in a directory given with -C option
This is similar in spirit to to make -C dir ... and tar -C dir
---
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 83edf30..ae049da 100644
---
From: Philip Oakley philipoak...@iee.org
[2] http://dx.doi.org/10.%2F1467-8721.01235 Why People Fail to
Recognize Their Own Incompetence.
Oops, That's behind a paywall, and a more recent variant.
Though the corollaries
(People fail to recognise
Merges are often treated as special case objects so tell users that
they are not special here.
Signed-off-by: Philip Oakley philipoak...@iee.org
---
This updates my in-line patch given in [PATCH v3 07/11]
Documentation/replace: tell that -f option bypasses the type check
($gmane/233997 05
I experienced a weird stall from git bash completion:
$ git add pTAB
I did some investigation and found this call trace:
+ __git_index_files '--others --modified' ''
--- git ls-files --exclude-standard --others --modified
This bash function captures output of the git call and strips all but
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 2 +-
bulk-checkin.c | 2 +-
pack-write.c | 7 +--
pack.h | 3 +--
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/pack-objects.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
pack-write.c | 29 +
pack.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index 88e4788..6f11104 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -1,6 +1,7 @@
This helps construct tree dictionary in pack v4.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 2 +-
builtin/rev-list.c | 4 ++--
list-objects.c | 9 -
list-objects.h | 3 ++-
upload-pack.c | 2 +-
5 files changed, 14
I can produce pack v4 on git.git with this and verify it with
index-pack. I'm not familiar with pack-objects code and not really
confident with my changes. Suggestions are welcome.
Also I chose to keep packv4-create.c in libgit.a and move test code
out to test-packv4.c. Not sure if it's good
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 33faea8..ef68fc5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@
commit_ident_table and tree_path_table are local to packv4-create.c
and test-packv4.c. Move them out of add_*_dict_entries so
add_*_dict_entries can be exported to pack-objects.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
packv4-create.c | 22 --
1 file
git-packv4-create now becomes test-packv4. Code that will not be used
by pack-objects.c is moved to test-packv4.c. It may be removed when
the code transition to pack-objects completes.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Makefile| 4 +-
packv4-create.c |
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
packv4-create.c | 103 --
packv4-create.h (new) | 11 ++
2 files changed, 69 insertions(+), 45 deletions(-)
create mode 100644 packv4-create.h
diff --git a/packv4-create.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 69a22c1..665853d 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 665853d..daa4349 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 85 --
pack.h | 2 +-
2 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/pack-objects.c | 87 --
1 file changed, 85 insertions(+), 2 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index b38d3dc..69a22c1 100644
---
One of the first things git-pull.sh does is setting $curr_branch to
the target of HEAD and $curr_branch_short to the same but with the
leading refs/heads/ removed. Simplify the code by using
$curr_branch_short instead of setting $curr_branch to the same
shortened value.
The only other use of
Am 31.08.2013 19:20, schrieb Felipe Contreras:
A summary should contain as much information that would allow me to
skip the commit message as possible.
If I can't tell from the summary if I can safely skip the commit
message, the summary is not doing a good job.
trivial simplification explains
Am 08.09.2013 16:42, schrieb Ramkumar Ramachandra:
On Sun, Sep 8, 2013 at 6:00 PM, René Scharfe l@web.de
mailto:l@web.de wrote:
Am 08.09.2013 08:09, schrieb Ramkumar Ramachandra:
Remove dead code around remove_dir_recursively().
This basically reverts ae2f203e (clean:
Use das Tag to avoid confusion with the German word Tag (day).
Reported-by: Dirk Heinrichs dirk.heinri...@altum.de
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/po/de.po b/po/de.po
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King p...@peff.net wrote:
By svn-like, I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
Philip Oakley philipoak...@iee.org writes:
What I observed was that all the clones had the same HEAD problem,
which I think comes from clone.c: guess_remote_head().
Yes. They share having to guess property because their data
source does not tell them.
My quick look at clone.c suggested to
Richard Hansen rhan...@bbn.com writes:
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Which can be solved by adding the above fail option, and then
renaming them to pull.integrate and branch.name.integrate to
clarify
The HTTP 1.1 standard requires an Allow header for 405 Method Not Allowed:
The response MUST include an Allow header containing a list of valid methods
for the requested resource.
So provide such a header when we return a 405 to the user agent.
Signed-off-by: brian m. carlson
Jeff King p...@peff.net writes:
A(ny) sanely defined compare A with B function should yield the
result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
That is what you feed qsort() and bsearch() (it is not limited to C;
you see the same in sort { $a = $b }). The definition
On 2013-09-08 14:10, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
What about something like:
pull.mergeoptions (defaults to --ff-only)
pull.rebaseoptions (defaults to empty? --preserve-merges?)
branch.name.pull.mergeoptions (defaults to pull.mergeoptions)
(patches|REBASE 8/9)$ git rebase --continue
Applying: Check for __unix__ instead of __linux
Applying: Completely disable crash handler on archs other than i386 and amd64
Auto packing the repository for optimum performance. You may also
run git gc manually. See git help gc for more information.
On Sun, 8 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
pack-write.c | 29 +
pack.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index 88e4788..6f11104 100644
---
If SSL verification is enabled in git send-email, we could attempt to call a
method on an undefined value if the verification failed, since $smtp would end
up being undef. Look up the error string in a way that will produce a helpful
error message and not cause further errors.
Signed-off-by:
On Sun, 8 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
git-packv4-create now becomes test-packv4. Code that will not be used
by pack-objects.c is moved to test-packv4.c. It may be removed when
the code transition to pack-objects completes.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Hi,
Here is the second iteration of this series. Only one change from the
first iteration: The first patch now also fixes some missing -chaining
noticed by Junio in t2024.
...Johan
Johan Herland (4):
t2024: Fix -chaining and a couple of typos
t3200: Minor fix when preparing for tracking
Improved-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index dee55e4..094b92e 100755
---
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact
From: Per Cederqvist ced...@opera.com
When creating an upstream relationship, we use the configured remotes and
their refspecs to determine the upstream configuration settings
branch.name.remote and branch.name.merge. However, if the matching
refspec does not have refs/heads/something on the
We're testing that trying to --track a ref that is not covered by any remote
refspec should fail. For that, we want to have refs/remotes/local/master
present, but we also want the remote.local.fetch refspec to NOT match
refs/remotes/local/master (so that the tracking setup will fail, as intended).
Make it easier for readers to find the actual config variables that
implement the upstream relationship.
Suggested-by: Per Cederqvist ced...@opera.com
Signed-off-by: Johan Herland jo...@herland.net
---
Documentation/git-branch.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
From: Junio C Hamano gits...@pobox.com
Sent: Sunday, September 08, 2013 6:35 PM
Philip Oakley philipoak...@iee.org writes:
What I observed was that all the clones had the same HEAD problem,
which I think comes from clone.c: guess_remote_head().
Yes. They share having to guess property
On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King p...@peff.net wrote:
$ hack hack hack
$ svn commit ;# oops, somebody else committed in the
From: Junio C Hamano gits...@pobox.com
Sent: Sunday, September 08, 2013 7:10 PM
Richard Hansen rhan...@bbn.com writes:
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com
wrote:
Which can be solved by adding the above fail option,
On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano gits...@pobox.com wrote:
pull.someoption = rebase | merge [| always-fail]
makes that choice in a clear way, I think.
Regarding the verb integrate.
I doubt anybody thinks of pull being an integration, and even if it
is, it's still doesn't
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sequencer.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 351548f..8ed9f98 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -466,10 +466,7 @@ static int allow_empty(struct replay_opts
On Thu, Jul 18, 2013 at 10:27 AM, Rahul Bansal rahul.ban...@rtcamp.com wrote:
I am posting here first time, so please excuse me if this is not right place
to send something like this.
Please check -
On Sun, Sep 8, 2013 at 5:42 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sequencer.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 351548f..8ed9f98 100644
---
On Sun, Sep 8, 2013 at 5:05 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
@@ -290,6 +294,22 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
hashcpy(sha1, tree-object.sha1);
}
+ if (stage = 0 || working_tree = 0) {
Felipe Contreras wrote:
sequencer.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 351548f..8ed9f98 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -466,10 +466,7 @@ static int allow_empty(struct replay_opts *opts, struct
commit
Felipe Contreras wrote:
On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano gits...@pobox.com wrote:
pull.someoption = rebase | merge [| always-fail]
makes that choice in a clear way, I think.
The core issue is that users rarely want to merge locally: that's the
maintainer's job. Users simply
On Sun, Sep 8, 2013 at 10:21 AM, René Scharfe l@web.de wrote:
Am 31.08.2013 19:20, schrieb Felipe Contreras:
A summary should contain as much information that would allow me to
skip the commit message as possible.
If I can't tell from the summary if I can safely skip the commit
message,
On Sun, Sep 8, 2013 at 1:33 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
Calling the abstraction test_diff might have avoided the wasted
brain bandwidth in this thread, but I do not think renaming it in
test-lib-functions.sh is worth the trouble, either ;-)
On Sun, Sep 8, 2013 at 12:02 AM, Jeff King p...@peff.net wrote:
On Sat, Sep 07, 2013 at 11:52:10PM -0500, Felipe Contreras wrote:
Ah, you mean if you think that the compare function should behave like
C *_cmp functions, it should be A-B. Perhaps it is simply that I do not
think of the
On Sun, Sep 08, 2013 at 06:25:45PM -0500, Felipe Contreras wrote:
And I do not think it is a problem. The point of the function is not to
abstract away the idea of comparison. The point is to give a hook for
people on systems without diff -u to run the test suite.
The point according to
On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do, will they choose 'git pull --rebase' by mistake?
I agree, they will not choose git
Felipe Contreras wrote:
Either way it doesn't matter because Junio is determined to stand
alone versus the rest of the world in this issue.
Which is why he's the maintainer. Send in incremental updates, and he
should be fine.
--
To unsubscribe from this list: send the line unsubscribe git in
Hi,
On Sun, Sep 08, 2013 at 05:53:19PM -0500, Felipe Contreras wrote:
On Sun, Sep 8, 2013 at 5:42 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sequencer.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do,
On Sun, Sep 8, 2013 at 4:36 AM, Jeff King p...@peff.net wrote:
When we are parsing an integer or unsigned long, we use
the strto*max functions, which properly set errno to ERANGE
if we get a large value. However, we also do further range
checks after applying our multiplication factor, but do
On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
My patches pretty much do nothing else but introduce a warning.
Nothing is broken, nothing is changed in the test suite:
http://article.gmane.org/gmane.comp.version-control.git/233669
You are confusing my
1 - 100 of 120 matches
Mail list logo
