Changes since v2:
* Fixed typos in commit log 1/2. Thanks, Eric.
* With the help of Junio, write a helper to get suitable blame_date_width.
Jiang Xin (2):
bugfix: fix broken time_buf paddings for git-blame
blame: use a helper to get suitable blame_date_width
builtin/blame.c | 85
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
Command `git blame --date relative` aligns the date field with a
fixed-width (defined by blame_date_width), and if time_str is shorter
than that, it adds spaces for padding. But there are two bugs in the
following codes:
time_len = strlen(time_str);
...
memset(time_buf + t
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 re
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 (de
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
---
How a conflict looks:
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 to
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
---
Documentation/git-me
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
On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras
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
[4] http://thread.gmane.or
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 situatio
Felipe Contreras 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
Good. I was wondering about these myself when juggling some series
that
Duy Nguyen writes:
> On Sun, Apr 20, 2014 at 4:13 PM, Miller, Hugh 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, ca
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
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 probabl
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 matt
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras 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 wante
They should be tested by default.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/Makefile| 14 --
t/Makefile | 8 +++-
.../remote-helpers/test-bzr.sh => t/remote-helpers/bzr.t | 2 +-
.../
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
---
.gitignore | 2 ++
Makefile
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
Jiang Xin 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 string "x years, xx mont
> 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
messag
Junio C Hamano wrote:
> Felipe Contreras 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 double
> >> che
Felipe Contreras writes:
> 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?
Yikes, no. This was me mischaracterizingg the merge
Felipe Contreras 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 double
>> checked by the original author before w
`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 ahead/behind
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 unsu
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/.
> 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 versio
On Sun, Apr 20, 2014 at 12:13 PM, Jiang Xin 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 shorter/
s/add/it adds/
>
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 me
> 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
To setup publish tracking branch, like 'git branch --set-publish'.
Signed-off-by: Felipe Contreras
---
Documentation/git-push.txt | 9 +-
builtin/push.c | 2 ++
t/t5534-push-publish.sh| 70 ++
transport.c| 28 +
Signed-off-by: Felipe Contreras
---
Documentation/git-branch.txt | 11 +++
branch.c | 44 +
branch.h | 2 ++
builtin/branch.c | 57 ++---
t/t3200-branch.sh| 76
It does it along the upstream branch, if any.
* publish ... [master, gh/publish: ahead 1] ...
master ... [master, gh/master] ...
Signed-off-by: Felipe Contreras
---
builtin/branch.c | 17 -
t/t6040-tracking-info.sh | 5 +++--
2 files changed, 19 insertions(+), 3 dele
The 'upstream' variable doesn't hold an "upstream", but a branch, so
make it clearer.
Signed-off-by: Felipe Contreras
---
sha1_name.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 6fca869..906f09d 100644
--- a/sha1_
It's more efficient to check for the braces first.
Signed-off-by: Felipe Contreras
---
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
+++ b/sha1_name.c
@@ -417,7 +417,7 @@ stati
Signed-off-by: Felipe Contreras
---
Documentation/revisions.txt | 4
sha1_name.c | 49 -
t/t1508-at-combinations.sh | 5 +
3 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/Documentation/revisions.txt b/Documen
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..push.
The upstream branch is:
branch.$name.remote
branch.$name.merge
The publ
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 that
We shouldn't modify the commits; it screws the following tests.
Signed-off-by: Felipe Contreras
---
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
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fe
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
Signed-off-by: Felipe Contreras
---
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 push_refs_with_export(struct transpo
Signed-off-by: Felipe Contreras
Signed-off-by: Junio C Hamano
---
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 ad9c17e..ef44816 100644
--- a/builtin/fast-ex
By using fast-export's new --refspec option.
Signed-off-by: Felipe Contreras
Signed-off-by: Junio C Hamano
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-rem
Signed-off-by: Felipe Contreras
Signed-off-by: Junio C Hamano
---
Documentation/git-fast-import.txt | 3 +++
fast-import.c | 13 ++---
t/t9300-fast-import.sh| 18 ++
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/Documenta
For remote-helpers that use 'export' to push.
Signed-off-by: Felipe Contreras
Signed-off-by: Junio C Hamano
---
t/t5801-remote-helpers.sh | 8
transport-helper.c| 24 +---
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/t/t5801-remote-helpe
For example 'HEAD'.
Signed-off-by: Felipe Contreras
---
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 52b3c99..8288669 100755
--- a/t/
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
Signed-off-by: Junio C Hamano
---
builtin/fast-export.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b8d8a3a..
So that we can convert the exported ref names.
Signed-off-by: Felipe Contreras
Signed-off-by: Junio C Hamano
---
Documentation/git-fast-export.txt | 4
builtin/fast-export.c | 32
t/t9350-fast-export.sh| 7 +++
3 files changed,
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
---
t/t5801-remote-helpers.sh | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --
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',
> cooke
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
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
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 loca
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, ' ', blame_date_widt
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 +++--
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 li
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
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 the
On Sun, Apr 20, 2014 at 4:13 PM, Miller, Hugh 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 environment variab
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 ?
Rea
63 matches
Mail list logo
