On Wed, Mar 06, 2013 at 09:12:30AM +0100, Yves Blusseau wrote:
i have a socks proxy to access internet.
I successed in configuring git (with GIT_PROXY_COMMAND) to use the
socks proxy for GIT transport protocol.
But how to use this socks proxy with git for HTTP(S) transport protocol ?
Try:
Hello Junio,
On Tue, Mar 05, 2013 at 08:13:50AM -0800, Junio C Hamano wrote:
Support determining the binaries' installation path at runtime even if
called without any path components (i.e. via search path).
The default for any change is not to include it. Is there any
reason why we want
On Tue, Mar 05, 2013 at 02:47:16PM -0800, Junio C Hamano wrote:
clear_commit_marks(struct commit *, unsigned) only can clear flag
bits starting from a single commit; introduce an API to allow
feeding an array of commits, so that flag bits can be cleared from
commits reachable from any of them
On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote:
The primary change since the last round is that it pushes out only
annotated tags that are missing from the other side.
Like you, I have mixed feelings on treating annotated tags separately. I
don't feel like the previous
On Tue, Mar 05, 2013 at 11:13:12PM +0100, David Krmpotic wrote:
Hi guys! Thank you for responses.. I haven't suspected that repos
created via GitHub windows app would have union set by default :( have
to ask them about it.. it seems wrong to me… Here are the defaults for
a windows repo
Try:
git config --global http.proxy 'socks://yourhost:port'
That will enable it for all git repositories on your machine. Git should
also respect any environment variables that curl handles (because we use
libcurl under the hood), if you prefer to set it up that way. See man
curl for
2013/3/6 Jeff King p...@peff.net:
Try:
git config --global http.proxy 'socks://yourhost:port'
That will enable it for all git repositories on your machine. Git should
also respect any environment variables that curl handles (because we use
libcurl under the hood), if you prefer to set it
On Wed, Mar 06, 2013 at 10:21:42AM +0100, Yves Blusseau wrote:
Try:
git config --global http.proxy 'socks://yourhost:port'
That will enable it for all git repositories on your machine. Git should
also respect any environment variables that curl handles (because we use
libcurl
2013/3/6 Jeff King p...@peff.net:
On Wed, Mar 06, 2013 at 10:21:42AM +0100, Yves Blusseau wrote:
Try:
git config --global http.proxy 'socks://yourhost:port'
That will enable it for all git repositories on your machine. Git should
also respect any environment variables that curl
Hello,
I think the following suggestion is sound. And it might even be easy to
implement but I don't know how rerere works, so I might be wrong here.
When applying a patch it's normal to hit a conflict. For me this just
happend:
$ git diff
diff --cc flash_otp_write.c
On Wed, 6 Mar 2013, Yves Blusseau wrote:
I have try with an old version of curl: 7.15.5 and with the latest in
development curl 7.29.1-DEV. But it seem that git-remote-http is compile
with the old one.
libcurl 7.15.5 is over 6 years old.
The support for socks[*]:// prefixes in proxy names
Intro
-
In 'Subject:' characters are encoded in Q encoding, as per RFC 2047, e.g.
föö
becomes
=?UTF-8?q?f=C3=B6=C3=B6?=
. Long encoded lines must be wrapped to be no longer than 76 bytes.
Also RFC 2047, section 5 (3) says:
Each 'encoded-word' MUST represent an integral
Since the previous round:
- reflog format change is dropped
- almost always show HEAD detached from/at xxx instead of
currently not on any branch, where xxx is either a ref, or an
abbreviated sha-1
I wanted to introduce something like @{-1:to} that resolves the to
sha-1 in reflog, in
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 52 +++-
wt-status.h | 5 +++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index ef405d0..183aafe 100644
--- a/wt-status.c
+++
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 183aafe..6a3566b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1044,31 +1044,29 @@
When a remote ref or a tag is checked out, HEAD is automatically
detached. There is no user-friendly way to find out what ref is
checked out in this case. This patch digs in reflog for this
information and shows HEAD detached from origin/master or HEAD
detached at v1.8.0 instead of currently not
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases? Is it detached because the user checks out a remote ref or a
tag (and which one)?
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Since the previous round:
- reflog format change is dropped
- almost always show HEAD detached from/at xxx instead of
currently not on any branch, where xxx is either a ref, or an
abbreviated sha-1
I wanted to introduce something like @{-1:to} that resolves the to
sha-1 in reflog, in
Jeff King venit, vidit, dixit 05.03.2013 18:38:
On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
Change the semantics of git alias --help to show the help for the
command alias is aliased to, instead of just saying:
`git alias' is aliased to `whatever'
E.g. if
We discussed this before about adding configuration variables into
individual command man pages [1]. This may be a step towards
that. With this, I could add selected configuration variables to
git-push.txt, for example, with a simple patch:
-- 8 --
diff --git a/Documentation/git-push.txt
Hello,
Here comes another recipe for a different suggestion:
git init
echo 1 file
git add file
git commit -m 'base'
git branch branch
seq 1 30 | grep -v 15 file
git commit -m 'add 2-30 without 15' file
git checkout branch
Jeff King p...@peff.net writes:
On Tue, Mar 05, 2013 at 02:47:16PM -0800, Junio C Hamano wrote:
clear_commit_marks(struct commit *, unsigned) only can clear flag
bits starting from a single commit; introduce an API to allow
feeding an array of commits, so that flag bits can be cleared from
Jeff King p...@peff.net writes:
On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote:
The primary change since the last round is that it pushes out only
annotated tags that are missing from the other side.
Like you, I have mixed feelings on treating annotated tags separately. I
Greg Price pr...@mit.edu writes:
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 388a225..f89d920 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -105,7 +105,9 @@ apply to the index. See EDITING PATCHES below.
will never stage new
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
remote.*.push is considered before push.default, but there's no
mention about that, except a bit in the examples. The description
of push.default does say something about this, but it would be easier
to find out if it's described here.
The
On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote:
I can phrase this in two ways and I'll start with the short way:
Why does a merge of a git submodule use as merge-base the commit that was
active in the merge-base of the parent repo, rather than the merge-base of
the two
git checkout --conflict=diff3 file
That's somehow unrelated, but shouldn't we have a conflict option to
git-merge as we have for git-checkout ?
With something like this (pasted into gmail):
diff --git a/builtin/merge.c b/builtin/merge.c
index 7c8922c..edad742 100644
---
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 52 +++-
wt-status.h | 5 +++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/wt-status.c
This is how I see what rebase should do:
The simple case for rebase starts from
P---Q---R---S master
\
A---B---C topic
Then git checkout topic ; git rebase master will change it to
P---Q---R---S master
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+static void wt_status_get_detached_from(struct wt_status_state *state)
+{
+ struct grab_1st_switch_cbdata cb;
+ struct commit *commit;
+ unsigned char sha1[20];
+ char *ref = NULL;
+
+ strbuf_init(cb.buf, 0);
+ if
however the difference isn't that easy to spot any more. I expected
diff --cc file
index a07e697,5080129..000
--- a/file
+++ b/file
@@@ -12,7 -12,7 +12,12 @@@
12
13
14
++ ours
+15
On Wed, Mar 06, 2013 at 08:26:57PM +0100, Antoine Pelisse wrote:
however the difference isn't that easy to spot any more. I expected
diff --cc file
index a07e697,5080129..000
--- a/file
+++ b/file
@@@ -12,7 -12,7 +12,12 @@@
12
zdiff3 is identical to ordinary diff3, only it allows more aggressive
compaction than diff3. This way the displayed base isn't necessary
technically correct, but still this mode might help resolving merge
conflicts between two near identical additions.
Signed-off-by: Uwe Kleine-König
Jeff King p...@peff.net writes:
then it will produce the output that Uwe expects. While it can be
misleading,...
Misleading is one thing but in this case isn't it outright wrong?
If you remove ours ||| portion from the combined diff output,
I would expect that the hunk will apply to the
On Wed, Mar 06, 2013 at 09:36:42PM +0100, Uwe Kleine-König wrote:
zdiff3 is identical to ordinary diff3, only it allows more aggressive
compaction than diff3. This way the displayed base isn't necessary
technically correct, but still this mode might help resolving merge
conflicts between two
On Wed, Mar 06, 2013 at 12:40:48PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
then it will produce the output that Uwe expects. While it can be
misleading,...
Misleading is one thing but in this case isn't it outright wrong?
If you remove ours ||| portion from the
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge $LOCAL $LOCAL $REMOTE $MERGED
Commit 0a0ec7bd changed this to:
p4merge empty file $LOCAL $REMOTE $MERGED
to avoid the problem of being unable to save in some circumstances.
Unfortunately this approach does not
Jeff King p...@peff.net writes:
But it would apply to the content that is outside
of the hunk marker; we have changed the concept of what is in the base
and what is in the conflict by shrinking the conflict to its smallest
size.
Hmm, unless you mean by base something entirely different from
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But it would apply to the content that is outside
of the hunk marker; we have changed the concept of what is in the base
and what is in the conflict by shrinking the conflict to its smallest
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
This change makes use of P4Merge consistent with its built-in help, its
reference documentation,
Hello Junio,
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But it would apply to the content that is outside
of the hunk marker; we have changed the concept of what is in the base
and what is in the conflict by shrinking the conflict to
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
But it would apply to the content that is outside
of the hunk marker; we have changed the concept of what is in the base
and what is in the conflict by shrinking the conflict to its smallest
size.
Hmm, unless you
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo
Add basic use cases and corner cases tests for
git diff -M --summary/stat.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
list of fixes:
- Test using diff instead of show
(that is more consistent with commit message).
- add extra spaces around paths
- Use better commit messages
-
Hello
$ git --version
git version 1.7.10.4
$ git fetch origin --no-tags
does what it says
$ git fetch --all --no-tags
still gets all the tags from the remote.
Is this known?
Thanks.
--
Cristian Tibirna(1-418-) 656-2131 / 4340
Laval University - Quebec, CAN
Jeff King p...@peff.net writes:
I think Uwe's example shows that it _is_ useful. Yes, you no longer have
the information about what happened through 1-14 (whether it was really
there in the ancestor file, or whether it was simply added identically).
But that information might or might not be
Cristian Tibirna ctibi...@giref.ulaval.ca writes:
Hello
$ git --version
git version 1.7.10.4
$ git fetch origin --no-tags
does what it says
$ git fetch --all --no-tags
still gets all the tags from the remote.
Is this known?
Because --all (or --multiple) to iterate through all remotes
Hi all-
I have a branch history that looks like this:
--M-M-- master
\ / /
x feature
\ \
x-A- maint
In other words we had a new feature that was so cool that after testing on
master was back-ported to maint (luckily
Antoine Pelisse apeli...@gmail.com writes:
Add basic use cases and corner cases tests for
git diff -M --summary/stat.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
list of fixes:
- Test using diff instead of show
(that is more consistent with commit message).
- add extra
Stephen Bash b...@genarts.com writes:
So what is the actual meaning of Already up-to-date!? Is it
based on the tree, the reachable commits, or something more
complicated?
The resulting tree of the merge happened to be the same as the
original tree (i.e. git diff HEAD^ HEAD is empty).
This
Two changes to the same piece of code that have greatly improved the behaviour
of P4Merge for me. Some of it may also be applicable to other mergetools.
I've put probably overly-long-winded explanations in the commit messages.
Comments welcome. In particular, I know almost nothing of sh, so I
Junio C Hamano gits...@pobox.com writes:
In other words, with the new world order, wouldn't a saner function
signature be:
static const char *read_and_strip_branch(const char **path);
Eh, discard an asterisk from there. Given a string to name the
file, read it to find the branch name
Michael J Gruber g...@drmicha.warpmail.net writes:
Well, even in the simple case one has to wonder: Why does the user
invoke help for co? There are two very likely cases:
A) User does not remember what co is aliased to.
B) User wants to see the man page.
If A is not the case then it's easy
Jan Pešta jan.pe...@certicon.cz writes:
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*'
On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
Cristian Tibirna ctibi...@giref.ulaval.ca writes:
Hello
$ git --version
git version 1.7.10.4
$ git fetch origin --no-tags
does what it says
$ git fetch --all --no-tags
still gets all the tags from the remote.
Kevin Bracey ke...@bracey.fi writes:
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
Given that the ordering of the three variants has been
Jeff King p...@peff.net writes:
On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
Cristian Tibirna ctibi...@giref.ulaval.ca writes:
Hello
$ git --version
git version 1.7.10.4
$ git fetch origin --no-tags
does what it says
$ git fetch --all --no-tags
still
On Wed, Mar 06, 2013 at 01:50:46PM -0800, Junio C Hamano wrote:
I think it is more like I added bread and my wife added bread to
our common shopping list and our two-way RCS merge default is to
collapse that case to one loaf of bread on the shopping list. My
impression has always been that
Hi Junio,
The following changes since commit 7799588faa2a8071da8ef047c87f9a1520fb8903:
Merge git://github.com/git-l10n/git-po (2013-03-04 01:16:02 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to
On Wed, Mar 06, 2013 at 04:41:44PM -0800, Junio C Hamano wrote:
Or we could just pass them through. Looks like this was already fixed by
8556646 (fetch --all: pass --tags/--no-tags through to each remote,
2012-09-05), which is in v1.7.12.2 and higher.
;-) No wonder this looked somewhat
git.kernel.org no longer uses gitweb but has switched to cgit.
Info about this can be found on: https://www.kernel.org/pelican.html or
simply by looking at http://git.kernel.org . This is change since
2013-03-01.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
gitweb/README |3 ---
1
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote:
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge $LOCAL $LOCAL $REMOTE $MERGED
Commit 0a0ec7bd changed this to:
p4merge empty file $LOCAL $REMOTE $MERGED
to avoid the problem of being
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote:
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
+ # This starts with $LOCAL, and uses git apply to
+ # remove lines that are not in $REMOTE.
+ cp --
These slightly improve the reading flow by making it obvious that a list
follows.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65db53b..8cd8b4f 100644
--- a/bundle.c
+++
A more informative message for complete bundles was added in commit
8c3710fd. However, the prerequisites ref list is currently read *after*
we check if it equals zero, which means we never actually print the
newly introduced message.
Move the code that reads the prerequisites ref list before the
On 07/03/2013 02:36, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
Given that
Kevin Bracey ke...@bracey.fi writes:
I agree that this is the controversial patch of the two. It's going to
chuck away 3-4 years of what Git users are used to, albeit in favour
of a decade of what Perforce users are used to. And it also makes it
inconsistent with all the other mergetools (at
David Aguilar dav...@gmail.com writes:
How do we feel about this duplication?
Should we make a common function in the git-sh-setup.sh,
or is it okay to have a slightly modified version of this
function in two places?
It probably is a good idea to have it in one place. That would also
solve
68 matches
Mail list logo
