Dear Community,
Is there any way to use .git (e.g., a different set of client commands) that
allows the .git folder to be placed in a location away from the actual files
being versioned ? For example, can one set environment variables that let the
software know where the .git folder is ?
On Sun, Apr 20, 2014 at 4:13 PM, Miller, Hugh hughmil...@chevron.com wrote:
Dear Community,
Is there any way to use .git (e.g., a different set of client commands)
that allows the .git folder to be placed in a location away from the actual
files being versioned ? For example, can one set
When you view a commit from github, it shows extra info besides
standard unified diff format:
- the column number of each line (useful for jumping directly to that
line without manual counting from @@ line)
- --color-words within unified diff format, using background color to
show what part of
Another way, which wouldn't require environment variables or extra
parameters for each command is moving the .git directory, and replace
it with a file called .git, which has the path to the actual .git
directory.
Git submodules use this feature too.
On Sun, Apr 20, 2014 at 11:49 AM, Duy Nguyen
On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
- --color-words within unified diff format, using background color to
show what part of the line has changed. This is only enabled for
1-line changes.
See contrib/diff-highlight.
-Peff
--
To unsubscribe from this list: send the line
When rewrite time_buf[128] to strbuf, find another bug from the original
implement. See detail commit log of 1/2.
Jiang Xin (2):
bugfix: fix broken time_buf paddings for git-blame
blame: use different blame_date_width for different locale
builtin/blame.c | 29 +++--
When show date in relative date format for `git blame`, the max display
width of datetime is set as the length of the string Thu Oct 19
16:00:04 2006 -0700 (30 characters long). But actually the max width
for C locale is only 22 (the length of string x years, xx months ago).
And for other locale,
When `git blame` shows date field in a fixed width (as long as
blame_date_width characters), if time_str shorter than that, add spaces
for padding. But there are two bugs in the following codes:
memcpy(time_buf, time_str, time_len);
memset(time_buf + time_len, ' ',
Stefan Beller wrote:
So this is really bikeshedding at its finest.
You don't seem to understand what is bikeshedding. The reason a bikeshed is
used as reference is because the primary function of a bikeshed is to store
bikes, and therefore the color of the bikeshed doesn't really matter.
A logo
Delcypher wrote:
What is the problem you are trying to solve?
The problem I was trying to solve is I wanted my authentication
details to be in a hgrc local to the repository.
The problem is git-remote-hg will parse
``.git/hg/origin/clone/.hg/hgrc`` but will ignore any settings in it
(this
Junio C Hamano wrote:
As I have said in the recent What's cooking reports, the original
posted here were based on older codebase and needed to be rebased,
but it had some conflicts and I wanted to see the result double
checked by the original author before we can merge it to 'next',
cooked
Commit 512477b (tests: use env to run commands with temporary env-var
settings) missed some variables in the remote-helpers test. Also
standardize these.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 15 +++
1 file changed, 7
Hi,
Here are the patches that allow transport helpers to be completely transparent
by adding the remaining missing feature: pushing refspecs and deleting branches
(old:new :delete).
These were already sent before, but dropped in later patch series because Junio
didn't like some name.
Apparently
We don't want to pass arguments specific to fast-export to
setup_revisions.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/fast-export.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
So that we can convert the exported ref names.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-fast-export.txt | 4
builtin/fast-export.c | 32
For example 'HEAD'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 8
transport-helper.c| 11 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/fast-export.c | 14 ++
t/t9350-fast-export.sh | 11 +++
2 files changed, 25 insertions(+)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
transport-helper.c | 4
1 file changed, 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 36fbf93..a90094d 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -876,8 +876,6 @@ static int
By using fast-export's new --refspec option.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-fast-import.txt | 3 +++
fast-import.c | 13 ++---
t/t9300-fast-import.sh| 18 ++
3 files changed, 31
For remote-helpers that use 'export' to push.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5801-remote-helpers.sh | 8
transport-helper.c| 24 +---
2 files changed, 21 insertions(+), 11
Junio C Hamano wrote:
* transport-helper, fast-import and fast-export have been updated to
allow the ref mapping and ref deletion in a way similar to the
natively supported transports.
Have they?
% git --version
git version 2.0.0.rc0
% git push origin origin master:foo
We shouldn't modify the commits; it screws the following tests.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5516-fetch-push.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 67e0ab3..f4cf0db 100755
---
As it has been discussed before, our support for triangular workflows is
lacking, and the following patch series aims to improve that situation.
We have the concept of upstream branch (e.g. 'origin/master') which is to where
our topic branches eventually should be merged to, so it makes sense
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/revisions.txt | 4
sha1_name.c | 49 -
t/t1508-at-combinations.sh | 5 +
3 files changed, 40 insertions(+), 18 deletions(-)
diff --git
The publish branch is the branch the user wants to push to, akin to the
upstream branch, which is the branch the user wants to use as a
baseline. It overrides other configurations, such as push.default, and
remote.name.push.
The upstream branch is:
branch.$name.remote
branch.$name.merge
The
To setup publish tracking branch, like 'git branch --set-publish'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-push.txt | 9 +-
builtin/push.c | 2 ++
t/t5534-push-publish.sh| 70 ++
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-branch.txt | 11 +++
branch.c | 44 +
branch.h | 2 ++
builtin/branch.c | 57 ++---
t/t3200-branch.sh
It does it along the upstream branch, if any.
* publish ... [master, gh/publish: ahead 1] ...
master ... [master, gh/master] ...
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/branch.c | 17 -
t/t6040-tracking-info.sh | 5 +++--
2 files
The 'upstream' variable doesn't hold an upstream, but a branch, so
make it clearer.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index
It's more efficient to check for the braces first.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 906f09d..aa3f3e0 100644
--- a/sha1_name.c
+++
What version of Mercurial are you using?
$ hg --version
Mercurial Distributed SCM (version 2.9.2)
(see http://mercurial.selenic.com for more information)
Copyright (C) 2005-2014 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even
Delcypher wrote:
What version of Mercurial are you using?
$ hg --version
Mercurial Distributed SCM (version 2.9.2)
Same as me. And which version of git-remote-hg are you using?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
On Sun, Apr 20, 2014 at 12:13 PM, Jiang Xin worldhello@gmail.com wrote:
When `git blame` shows date field in a fixed width (as long as
s/fixed width/fixed-width/
s/long/wide/ would read a bit better.
blame_date_width characters), if time_str shorter than that, add spaces
s/shorter/is
Same as me. And which version of git-remote-hg are you using?
I'm using the version that ships with git 1.9.2
I've taken a look and it seems I made a mistake, sorry. It seems that
[ui]
quiet = True
is being respected when placed in ``.git/hg/origin/clone/.hg/hgrc``
with the un patched
Delcypher wrote:
Same as me. And which version of git-remote-hg are you using?
I'm using the version that ships with git 1.9.2
I've taken a look and it seems I made a mistake, sorry. It seems that
[ui]
quiet = True
is being respected when placed in ``.git/hg/origin/clone/.hg/hgrc``
Hi all,
I have discovered a minor security vulnerability. I could send the
patch to the mailing list, but I wanted someone else to take a look
first just to make sure it's minor enough that folks will think it's OK
to publicly announce.
Who should I send the patch to?
Thanks,
Richard
--
To
`git branch -v` before:
fc/branch/nice-verbose 4761939 [master] branch: reorganize verbose options
`git branch -v` after:
fc/branch/nice-verbose 4761939 [ahead 1] branch: reorganize verbose options
Showing the upstream tracking branch is more important than how many commits
are
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
As I have said in the recent What's cooking reports, the original
posted here were based on older codebase and needed to be rebased,
but it had some conflicts and I wanted to see the result
I see now, I've taken the patch with repo.ui and applied on my repo:
https://github.com/felipec/git/commit/ee17fe1cf80d5196be382ebbbcb1a24c05e61658
Thanks.
It might be helpful to catch the exception raised if https
authentication details are missing so that a more user friendly error
message
Jiang Xin worldhello@gmail.com writes:
When show date in relative date format for `git blame`, the max display
width of datetime is set as the length of the string Thu Oct 19
16:00:04 2006 -0700 (30 characters long). But actually the max width
for C locale is only 22 (the length of
There doesn't seem to be any reason to keep these remote-helpers in the contrib
area.
Felipe Contreras (2):
remote-helpers: move out of contrib
remote-helpers: move tests out of contrib
.gitignore | 2 ++
Makefile
The remote-helpers in contrib/remote-helpers have proved to work, be
reliable, and stable. It's time to move them out of contrib, and be
distributed by default.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
.gitignore | 2 ++
They should be tested by default.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/Makefile| 14 --
t/Makefile | 8 +++-
.../remote-helpers/test-bzr.sh =
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
As I have said in the recent What's cooking reports, the original
posted here were based on older codebase and needed to be rebased,
but
Junio C Hamano wrote:
So I think it is better to quote these in this particular case.
The pipe is purely subjective readability. I can go either way, but
since I was the one who was applying the patch that needed other
changes anyway... ;-)
You started by saying these were not the matter
Hi Heiko,
On Sat, 19 Apr 2014, Heiko Voigt wrote:
Regarding mingwGitDevEnv[2]: That is a project started by Sebastian who
also contributes to msysgit (and Git for Windows).
In fact, Sebastian is not only a contributor. He is co-maintainer of Git
for Windows.
It eventually can (and probably
On Mon, 21 Apr 2014, Johannes Schindelin wrote:
(I also would like to look into getting the performance improvement
Hannes Sixt achieved by his patch [*1*] into mingwGitDevEnv's Git
installation, too.)
Whoops. Footnote *1*: https://github.com/msysgit/msysgit/commit/a0f5d4f
--
To unsubscribe
Duy Nguyen pclo...@gmail.com writes:
On Sun, Apr 20, 2014 at 4:13 PM, Miller, Hugh hughmil...@chevron.com wrote:
Dear Community,
Is there any way to use .git (e.g., a different set of client commands)
that allows the .git folder to be placed in a location away from the actual
files being
Felipe Contreras felipe.contre...@gmail.com writes:
Commit 512477b (tests: use env to run commands with temporary env-var
settings) missed some variables in the remote-helpers test. Also
standardize these.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Good. I was wondering
Hi,
I had already given up on merging important features to Git upstream,
and then one of the features I've had in git-fc (my fork) for quite
some time suddenly got attention (the @{publish} branch), but
everybody forgot I already did the work. So maybe there's other
features in a similar
On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
[3] http://thread.gmane.org/gmane.comp.version-control.git/240030
[4] http://thread.gmane.org/gmane.comp.version-control.git/235981
Actually:
[3] http://thread.gmane.org/gmane.comp.version-control.git/233554
There's no point in this:
% git merge
fatal: No commit specified and merge.defaultToUpstream not set.
We know the most likely scenario is that the user wants to merge the
upstream, and if not, he can set merge.defaultToUpstream to false.
Signed-off-by: Felipe Contreras
It's annoying to see the prompt:
Hit return to start merge resolution tool (foo):
Every time the user does 'git mergetool' even if the user already
configured 'foo' as the wanted tool.
Display this prompt only when the user hasn't explicitly configured a
tool.
Signed-off-by: Felipe Contreras
I don't see why people need to set these to have sensible behavior:
merge.defaulttoupstream = true
mergetool.prompt = false
Let's change them to sane defaults so they are not needed.
Felipe Contreras (2):
merge: enable defaulttoupstream by default
mergetool: run prompt only if guessed
It's similar to the default, except that the other windows are hidden.
This ensures that removed/added colors are still visible on the main
merge window, but the other windows not visible.
Specially useful with merge.conflictstyle=diff3.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Hi,
Using git version 1.9.2 I am getting this error:
[normal@laptop tmp]$ git clone https://github.com/mozilla/rust.git
Cloning into 'rust'...
remote: Reusing existing pack: 296648, done.
remote: Counting objects: 80, done.
remote: Compressing objects: 100% (77/77), done.
remote: Total 296728
This hook is invoked whenever a branch is updated, either when a branch
is created or updated with 'git branch', or when it's rebased with 'git
rebase'. It receives two parameters; the name of the branch, and the
SHA-1 of the latest commit, additionally, if there was a base commit the
branch was
58 matches
Mail list logo
