Felipe Contreras writes:
> No functional changes.
>
> Signed-off-by: Felipe Contreras
> ---
> GIT-VERSION-GEN | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> index 06026ea..b0db139 100755
> --- a/GIT-VERSION
From a763550fc59b756580f9b162839d2737c27f2fe3 Mon Sep 17 00:00:00 2001
From: Uli Heller
Date: Tue, 3 Sep 2013 09:14:03 +0200
Subject: [PATCH] git-svn: Fix termination issues for remote svn connections
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This i
Felipe Contreras writes:
> If the version is 'v1.8.4-rc1' that is the version, and there's no need
> to change it to anything else, like 'v1.8.4.rc1'.
>
> Signed-off-by: Felipe Contreras
> ---
> GIT-VERSION-GEN | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/GIT-VERSION-GEN b/GIT-VERSIO
Felipe Contreras (2):
version-gen: cleanup
version-gen: avoid messing the version
GIT-VERSION-GEN | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
--
1.8.4-338-gefd7fa6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
No functional changes.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 06026ea..b0db139 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -7,21 +7,24 @@
If the version is 'v1.8.4-rc1' that is the version, and there's no need
to change it to anything else, like 'v1.8.4.rc1'.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 1 -
1 file changed, 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b0db139..2b9fd2f 100755
--- a/G
On Sun, Sep 8, 2013 at 9:49 PM, Nazri Ramliy wrote:
> On Sun, Sep 8, 2013 at 6:32 PM, Eric Sunshine wrote:
>>> +This option affects options that expect path name like --git-dir and
>>> +--work-tree in that their interpretations of the path names would be
>>> +made relative to the working director
Hi,
brian m. carlson wrote:
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -594,8 +594,11 @@ int main(int argc, char **argv)
>
> if (strcmp(method, c->method)) {
> const char *proto = getenv("SERVER_PROTOCOL");
> -
On Tue, Sep 3, 2013 at 1:50 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> diff --git a/sha1_name.c b/sha1_name.c
>> index 93197b9..b8ece6e 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -1004,6 +1004,26 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
>> return
This is useful to make sure we don't step outside the boundaries of what
we are interpreting at the moment. For example while interpreting
foobar@{u}~1, the job of interpret_branch_name() ends right before ~1,
but there's no way to figure that out inside the function, unless the
len argument is pas
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1
Felipe Contreras (2):
sha1-name: pass len argument to interpret_branch_name()
Add new @ shortcut for HEAD
Documentation/git-check-ref-format.txt | 2 ++
Documentation/revisions.txt| 3 +++
cache.h| 2 +-
refs.c |
On Sun, Sep 8, 2013 at 6:32 PM, Eric Sunshine wrote:
> For consistency with existing formatting in git.txt, you may want to
> squash in the following fixes (sans gmail whitespace damage):
>
> --- >8 ---
[ diff snipped ]
> --- >8 ---
Thanks. I'll submit a reroll later.
>> +This option affects opt
On Sun, Sep 8, 2013 at 8:23 PM, Felipe Contreras
wrote:
> To prepare our uses for the upcoming changes we should warn them and let
> them know that they will need to specify a merge or a rebase in the
> future (when a non-fast-forward situation arises). Also, let them know
> we fallback to 'git pu
Also 'branch..rebase' to 'branch..pullmode'.
This way 'pull.mode' can be set to 'merge', and the default can be
something else.
The old configurations still work, but get deprecated.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 22 +++---
Documentation/git-p
It is very typical for Git newcomers to inadvertently create merges and worst:
inadvertently pushing them. This is one of the reasons many experienced users
prefer to avoid 'git pull', and recommend newcomers to avoid it as well.
To avoid these problems and keep 'git pull' useful, it has been sugg
Signed-off-by: Felipe Contreras
---
git-pull.sh | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index de57c1d..f53d193 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -48,8 +48,7 @@ if test -z "$mode"
then
mode=$(git co
To prepare our uses for the upcoming changes we should warn them and let
them know that they will need to specify a merge or a rebase in the
future (when a non-fast-forward situation arises). Also, let them know
we fallback to 'git pull --merge', so when the obsoletion of this mode
comes, they know
It is very typical for Git newcomers to inadvertently create merges and
worst; inadvertently pushing them. This is one of the reasons many
experienced users prefer to avoid 'git pull', and recommend newcomers to
avoid it as well.
To avoid these problems and keep 'git pull' useful, it has been
sugg
Also, deprecate --no-rebase since there's no need for it any more.
Signed-off-by: Felipe Contreras
---
Documentation/git-pull.txt | 8 ++--
git-pull.sh| 6 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pu
On Sun, Sep 8, 2013 at 6:45 PM, Jeff King wrote:
> 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 with
On Sun, Sep 8, 2013 at 7:15 PM, Ramkumar Ramachandra wrote:
> 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
On Sun, Sep 08, 2013 at 07:36:21PM -0500, Felipe Contreras wrote:
> On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras
> 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.c
On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras
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 proposal with Junio's on
On Sun, Sep 8, 2013 at 4:36 AM, Jeff King 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 not
> set
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
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, will they choose 'git
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
> wrote:
> > Signed-off-by: Ramkumar Ramachandra
> > ---
> > sequencer.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/sequencer.c b
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
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
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 acco
On Sun, Sep 8, 2013 at 12:02 AM, Jeff King 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 funct
On Sun, Sep 8, 2013 at 1:33 PM, Junio C Hamano wrote:
> Jeff King 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 ;-)
Yes, but then it wouldn't be
On Sun, Sep 8, 2013 at 10:21 AM, René Scharfe 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,
Felipe Contreras wrote:
> On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano wrote:
>
>> pull. = 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 want to rebase, and
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, struc
On Sun, Sep 8, 2013 at 5:05 PM, Ramkumar Ramachandra 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) {
On Sun, Sep 8, 2013 at 5:42 PM, Ramkumar Ramachandra wrote:
> Signed-off-by: Ramkumar Ramachandra
> ---
> 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
> @
On Thu, Jul 18, 2013 at 10:27 AM, Rahul Bansal wrote:
> I am posting here first time, so please excuse me if this is not right place
> to send something like this.
>
> Please check -
> http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order
>
> A
Signed-off-by: Ramkumar Ramachandra
---
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
com
On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano wrote:
> pull. = 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 explain what 'integra
From: "Junio C Hamano"
Sent: Sunday, September 08, 2013 7:10 PM
Richard Hansen writes:
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano
wrote:
Which can be solved by adding the above "fail" option, and then
renaming them to "pull.integrate" and
On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson
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 wrote:
>> > $ hack hack hack
>> > $ svn commit ;# oops, somebody else committed in the meantime
>> > $ svn update
>> >
From: "Junio C Hamano"
Sent: Sunday, September 08, 2013 6:35 PM
"Philip Oakley" 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 te
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
Signed-off-by: Johan Herland
---
Documentation/git-branch.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branc
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 wi
From: Per Cederqvist
When creating an upstream relationship, we use the configured remotes and
their refspecs to determine the upstream configuration settings
branch..remote and branch..merge. However, if the matching
refspec does not have refs/heads/ on the remote side, we end
up rejecting the m
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
Signed-off-by: Johan Herland
---
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
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-
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
> ---
> Makefile
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: bria
On Sun, 8 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> 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-
(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 2013-09-08 14:10, Junio C Hamano wrote:
> Richard Hansen writes:
>> What about something like:
>>
>> pull.mergeoptions (defaults to --ff-only)
>> pull.rebaseoptions (defaults to empty? --preserve-merges?)
>> branch..pull.mergeoptions (defaults to pull.mergeoptions)
>> branch..p
Jeff King 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 natur
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
---
http-back
Richard Hansen writes:
> On 2013-09-07 22:41, Felipe Contreras wrote:
>> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote:
>>
>>> Which can be solved by adding the above "fail" option, and then
>>> renaming them to "pull.integrate" and "branch..integrate" to
>>> clarify what these variables
"Philip Oakley" 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 me that there w
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King 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 pul
Use "das Tag" to avoid confusion with the German word "Tag" (day).
Reported-by: Dirk Heinrichs
Signed-off-by: Ralf Thielow
---
po/de.po | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/po/de.po b/po/de.po
index 11dde11..f4076fb 100644
--- a/po/de.po
+
Am 08.09.2013 16:42, schrieb Ramkumar Ramachandra:
On Sun, Sep 8, 2013 at 6:00 PM, René Scharfe 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: preserve ne
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" explain
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 $c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 daa4349..f6586a1 100644
-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
--- a/builtin/pack-objects.c
+++ b/
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
@@ -1759,8 +1759,12 @@ s
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
@@ -1332,7 +1332,8 @@ sta
This helps construct tree dictionary in pack v4.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 insertions(+), 6 delet
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 decis
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
@@ -81,6 +81,7 @@ static
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
---
packv4-create.c | 22 --
1 file changed, 12 insertions(+)
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
---
Makefile| 4 +-
packv4-create.c | 491 +--
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 b/packv4-create.c
index
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 b/builtin/pack-objects.c
index f069462..
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 @@
#include "cache.h"
#incl
Am 08.09.2013 08:09, schrieb Ramkumar Ramachandra:
Remove dead code around remove_dir_recursively().
This basically reverts ae2f203e (clean: preserve nested git worktree in
subdirectories). t7300 still seems to pass, though. I wonder why.
Signed-off-by: Ramkumar Ramachandra
---
dir.c |
I experienced a weird stall from git bash completion:
$ git add p
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
the
Merges are often treated as special case objects so tell users that
they are not special here.
Signed-off-by: Philip Oakley
---
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 September 2013 23:20) and J
From: "Philip Oakley"
[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 their own skills, a
On Wed, Sep 4, 2013 at 8:20 AM, Nazri Ramliy 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
> --- a/Documen
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:
>
>
From: "Felipe Contreras"
Sent: Sunday, September 08, 2013 9:49 AM
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley
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
On Sun, Sep 8, 2013 at 2:49 AM, Philip Oakley wrote:
> From: "Felipe Contreras"
> 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 a
From: Jeff King
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 constantly be
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
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 a
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley 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 rebase'
without argum
On Sun, Sep 8, 2013 at 2:50 AM, Jeff King 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'? Ce
From: "Felipe Contreras"
To: "Philip Oakley"
Cc: "John Keeping" ; "Junio C Hamano"
; ; "Andreas Krey"
Sent: Sunday, September 08, 2013 9:16 AM
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley
wrote:
From: "Felipe Contreras"
Sent: Sun
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
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 t
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
was
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
system
When we are parsing integers for config, we use an intmax_t
(or uintmax_t) internally, and then check against the size
of our result type at the end. We can parameterize the
maximum representable value, which will let us re-use the
parsing code for a variety of range checks.
Unfortunately, we cann
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]: confi
On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Sunday, September 08, 2013 3:34 AM
>
>> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote:
>>>
>>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not w
From: "Jeff King"
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' answer the re
On Tue, Aug 20, 2013 at 05:12:47PM +0200, Antoine Pelisse wrote:
> On Sat, Jul 20, 2013 at 2:22 AM, Jeff King 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 point.
>
>
From: "Felipe Contreras"
Sent: Sunday, September 08, 2013 3:34 AM
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping
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 so what do you want to do after "git pull"
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 tutorial
1 - 100 of 119 matches
Mail list logo
