[RFD/PATCH 5/5] RFD: Disallow out-of-refspec refs within refs/remotes/* to be used as upstream

The previous patch adds validation of upstream remote-tracking branches by parsing the configured refspecs, and making sure that the candidate upstream (if not already matching refs/heads/* or refs/remotes/*) is indeed a remote-tracking branch according to some remote's refspec. For a default/conve

[RFD/PATCH 3/5] checkout: Use remote refspecs when DWIMming tracking branches

The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly one remote with a remote-tracking branch called "foo". Git will then automatically create a new local branch called "foo" using the remote-tracking "foo" as

[RFD/PATCH 4/5] branch.c: Look up refspecs to validate tracking branches

The current code for validating tracking branches (e.g. the argument to the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the potential locations for tracking branches. This works well with the conventional refspecs created by "git clone" or "git remote add", but does not work if

[RFD/PATCH 2/5] t2024: Show failure to use refspec when DWIMming remote branch names

When using "git checkout foo" to DWIM the creation of local "foo" from some existing upstream "foo", we assume conventional refspecs as created by "git clone" or "git remote add", and fail to work correctly if the current refspecs do not follow the conventional "refs/remotes/$remote/*" pattern. Si

[RFD/PATCH 1/5] t2024: Add tests verifying current DWIM behavior of 'git checkout '

The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly one remote with a remote-tracking branch called "foo". Git will then automatically create a new local branch called "foo" using the remote-tracking "foo" as

[RFD/PATCH 0/5] Improving the search for remote-tracking branches

Hi, The following patch series has three uncontroversial patches (I hope) to improve the DWIM behavivor "git checkout foo", followed by two more experimental patches meant to trigger discussion about how Git decides on what is a remote-tracking branch, and what is not: The first three patches con

Re: Does git fast-import support deltas?

Hi Ilya, Ilya Basin wrote: > 1) a created a git repo from a foreign source using git fast-import > 2) new commits were added to the foreign source > > Can I create a fast-import input stream not containing the commits > already existing in my git repo and import it? Yes, if the foreign source is

Re: [PATCH] stash: tighten IS_STASH_LIKE logic

Junio C Hamano wrote: > [...] I'm curious. Why are you going back on what you said just one day ago? What changed? In a previous email, you wrote: > You are free to try to think of a way to tighten the implemention to > reject a random two-or-three parent merge commit that is not a > product of

Re: t6200: avoid path mangling issue on Windows

Am 4/18/2013 19:05, schrieb Junio C Hamano: > Johannes Sixt writes: > >> From: Johannes Sixt >> >> MSYS bash interprets the slash in the argument core.commentchar="/" >> as root directory and mangles it into a Windows style path. Use a >> different core.commentchar to dodge the issue. >> >> Sign

Re: Does git fast-import support deltas?

On Fri, Apr 19, 2013 at 12:29 AM, Ilya Basin wrote: > Hi list. > Here's what I mean: > 1) a created a git repo from a foreign source using git fast-import > 2) new commits were added to the foreign source > > Can I create a fast-import input stream not containing the commits > already existing in

Does git fast-import support deltas?

Hi list. Here's what I mean: 1) a created a git repo from a foreign source using git fast-import 2) new commits were added to the foreign source Can I create a fast-import input stream not containing the commits already existing in my git repo and import it? I tried to create such streams with:

[PATCH v2 4/8] contrib: cc-cmd: add option to show commits

Instead of showing the authors and signers, show the commits themselves. Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 13 + 1 file changed, 13 insertions(+) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index e36b1bf..f13ed8f 100755 --- a/cont

[PATCH v2 5/8] contrib: cc-cmd: add option to parse from committish

For example master..feature-a. Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 36 ++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index f13ed8f..462f22c 100755 --- a/contrib

[PATCH v2 7/8] contrib: cc-cmd: fix parsing of rev-list args

For example '-1'. Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index 02e1a99..6911259 100755 --- a/contrib/cc-cmd/git-cc-cmd +++ b/contrib/cc-cmd/gi

[PATCH v2 8/8] contrib: cc-cmd: add option to fetch aliases

Only the mutt format is supported for now. Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 24 1 file changed, 24 insertions(+) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index 6911259..02548c6 100755 --- a/contrib/cc-cmd/git-cc-c

[PATCH v2 6/8] contrib: cc-cmd: parse committish like format-patch

Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 14 ++ 1 file changed, 14 insertions(+) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index 462f22c..02e1a99 100755 --- a/contrib/cc-cmd/git-cc-cmd +++ b/contrib/cc-cmd/git-cc-cmd @@ -138,6 +138,20 @

[PATCH v2 3/8] contrib: cc-cmd: add support for multiple patches

Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index 0a5ec01..e36b1bf 100755 --- a/contrib/cc-cmd/git-cc-cmd +++ b/contrib/

[PATCH v2 2/8] contrib: cc-cmd: add option parsing

Signed-off-by: Felipe Contreras --- contrib/cc-cmd/git-cc-cmd | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd index c7ecf79..0a5ec01 100755 --- a/contrib/cc-cmd/git-cc-cmd +++ b/contrib/cc-cmd/git-cc-

[PATCH v2 1/8] Add new git-cc-cmd helper to contrib

The code finds the changes of a commit, runs 'git blame' for each chunk to see which other commits are relevant, and then reports the author and signers. Finally, it calculates what percentage of the total relevant commits each person was involved in, and show only the ones that pass the threshold

[PATCH v2 0/8] New git-cc-cmd helper

Hi, This script allows you to get a list of relevant persons to Cc when sending a patch series. % git cc-cmd v1.8.1.6^^1..v1.8.1.6^^2 "Henrik Grubbström" (author: 7%) junio (signer: 84%, author: 15%) "Nguyễn Thái Ngọc Duy" (author: 30%, signer: 7%) "Jean-Noël AVILA" (author: 7%) Je

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Junio C Hamano wrote: > You ran 'git add' with neither '-A (--all)' or '--no-all', whose > behaviour will change in Git 2.0 with respect to paths you > removed from your working tree. > > * 'git add --no-all ', which is the current default, > ignores paths you removed from yo

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 03:10:29PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I am expecting a reaction more like "Hmm, I never thought about it > > before. Does that make sense to me or not? Let me think about which > > paths it pertains to and decide". > > Let's step back and re-r

Re: [PATCH v2 3/6] transport-helper: clarify pushing without refspecs

Eric Sunshine writes: >> + grep "remote-helper doesn.t support push; refspec needed" error > > Is "doesn.t" intentional? It certainly works by accident in grep, but > did you mean s/doesn.t/doesn't/ ? The pattern matching the expected string is not by accident, but by design. It of course

Re: [PATCH] cat-file: print tags raw for "cat-file -p"

On Wed, Apr 17, 2013 at 5:00 PM, Jeff King wrote: > Subject: [PATCH] cat-file: print tags raw for "cat-file -p" > > When "cat-file -p" prints commits, it shows them in their > raw format, since git's format is already human-readable. > For tags, however, we print the whole thing raw except for > o

Re: is git-p4 compatible with p4/linux?

On Apr 18, 2013, at 7:09 PM, Pete Wyckoff wrote: > a...@aivor.com wrote on Tue, 16 Apr 2013 23:31 -0500: >> git-p4.py (1.8.2.1.418.gaec3f77) has at least two behaviors that >> seem to be incompatible with the version of p4 that I recently >> downloaded from perforce.com (P4/LINUX26X86_64/2013.1/

Re: [PATCH v2 3/6] transport-helper: clarify pushing without refspecs

On Thu, Apr 18, 2013 at 7:27 PM, Eric Sunshine wrote: > On Thu, Apr 18, 2013 at 12:14 AM, Felipe Contreras > wrote: >> diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh >> index cd1873c..3eeb309 100755 >> --- a/t/t5801-remote-helpers.sh >> +++ b/t/t5801-remote-helpers.sh >> @@ -1

Re: [PATCH v2 3/6] transport-helper: clarify pushing without refspecs

On Thu, Apr 18, 2013 at 12:14 AM, Felipe Contreras wrote: > diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh > index cd1873c..3eeb309 100755 > --- a/t/t5801-remote-helpers.sh > +++ b/t/t5801-remote-helpers.sh > @@ -111,13 +111,13 @@ test_expect_success 'pulling without refspecs'

Help with git-svn and SVN symlinks

Hi, I have been using git-svn successfully for last 1 year. But yesterday somebody checked in something in SVN using svn client and It caused inconsitency in GIT-svn repository. In one of SVN Merge commit, Some symlink files were not made "svn special" by mistake, So there was another SVN commit

Re: is git-p4 compatible with p4/linux?

a...@aivor.com wrote on Tue, 16 Apr 2013 23:31 -0500: > git-p4.py (1.8.2.1.418.gaec3f77) has at least two behaviors that > seem to be incompatible with the version of p4 that I recently > downloaded from perforce.com (P4/LINUX26X86_64/2013.1/610569). > > TLDR: Is git-p4 written for an old version

Re: [PATCH v3 2/2] submodule: drop the top-level requirement

On Thu, Apr 18, 2013 at 3:50 PM, John Keeping wrote: > Use the new rev-parse --prefix option to process all paths given to the > submodule command, dropping the requirement that it be run from the > top-level of the repository. > > Signed-off-by: John Keeping > --- > diff --git a/t/t7400-submodul

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord wrote: > On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras >> Yes please. Show me one of the instances where you hit a bisect with >> any of the remote-hg commits mentioned above by Thomas Rast. > > I made no such claim. In fact, I have never bisected t

Re: git p4 submit failing

christopher.yee...@gmail.com wrote on Thu, 18 Apr 2013 11:24 -0500: > The issue is caused by the line endings. I retested the problem with a > different file and in this case, the error is caused by the line > endings of the file checked out in the perforce workspace being > win-style crlf, and the

[PATCH v4 13/13] pretty: support %>> that steal trailing spaces

This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not use up all 100 columns and %an needs more than 20 columns. By replacing %>(20) with %>>(20), %an can steal spaces from %s. %>> understands escape sequences, so %Cred does not stop it from stealing spaces in %<(100). Signed-off-

[PATCH v4 12/13] pretty: support truncating in %>, %< and %>

%>(N,trunc) truncates the right part after N columns and replace the last two letters with "..". ltrunc does the same on the left. mtrunc cuts the middle out. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/pretty-formats.txt | 7 -- pretty.c | 51 +

[PATCH v4 11/13] pretty: support padding placeholders, %< %> and %>

Either %<, %> or %>< standing before a placeholder specifies how many columns (at least as the placeholder can exceed it) it takes. Each differs on how spaces are padded: %< pads on the right (aka left alignment) %> pads on the left (aka right alignment) %>< pads both ways equally (aka cente

[PATCH v4 10/13] pretty: add %C(auto) for auto-coloring

This is not simply convenient over %C(auto,xxx). Some placeholders (actually only one, %d) do multi coloring and we can't emit a multiple colors with %C(auto,xxx). Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/pretty-formats.txt | 3 ++- pretty.c | 26 +++

[PATCH v4 09/13] pretty: split color parsing into a separate function

Signed-off-by: Nguyễn Thái Ngọc Duy --- pretty.c | 71 +++- 1 file changed, 39 insertions(+), 32 deletions(-) diff --git a/pretty.c b/pretty.c index 5947275..e0413e3 100644 --- a/pretty.c +++ b/pretty.c @@ -954,6 +954,44 @@ static int

[PATCH v4 08/13] pretty: two phase conversion for non utf-8 commits

Always assume format_commit_item() takes an utf-8 string for string handling simplicity (we can handle utf-8 strings, but can't with other encodings). If commit message is in non-utf8, or output encoding is not, then the commit is first converted to utf-8, processed, then output converted to outpu

[PATCH v4 07/13] utf8.c: add reencode_string_len() that can handle NULs in string

Signed-off-by: Nguyễn Thái Ngọc Duy --- compat/precompose_utf8.c | 2 +- utf8.c | 10 +++--- utf8.h | 19 --- 3 files changed, 24 insertions(+), 7 deletions(-) diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c index 8cf5955.

[PATCH v4 05/13] utf8.c: move display_mode_esc_sequence_len() for use by other functions

Signed-off-by: Nguyễn Thái Ngọc Duy --- utf8.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/utf8.c b/utf8.c index 7f64857..6ed93c3 100644 --- a/utf8.c +++ b/utf8.c @@ -9,6 +9,20 @@ struct interval { int last; }; +static size_t display_mo

[PATCH v4 06/13] utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences

Signed-off-by: Nguyễn Thái Ngọc Duy --- utf8.c | 20 ++-- utf8.h | 1 + 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/utf8.c b/utf8.c index 6ed93c3..e7ba33c 100644 --- a/utf8.c +++ b/utf8.c @@ -266,18 +266,26 @@ int utf8_width(const char **start, size_t *remaind

[PATCH v4 04/13] pretty: share code between format_decoration and show_decorations

This also adds color support to format_decorations() Signed-off-by: Nguyễn Thái Ngọc Duy --- log-tree.c | 48 ++-- log-tree.h | 1 + pretty.c | 20 ++--- t/t4207-log-decoration-co

[PATCH v4 03/13] pretty-formats.txt: wrap long lines

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/pretty-formats.txt | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index afac703..6bde67e 100644 --- a/Documentation/pretty-formats.txt

[PATCH v4 01/13] pretty: save commit encoding from logmsg_reencode if the caller needs it

The commit encoding is parsed by logmsg_reencode, there's no need for the caller to re-parse it again. The reencoded message now has the new encoding, not the original one. The caller would need to read commit object again before parsing. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/blame.c

[PATCH v4 02/13] pretty: get the correct encoding for --pretty:format=%e

parse_commit_header() provides the commit encoding for '%e' and it reads it from the re-encoded message, which contains the new encoding, not the original one in the commit object. This never happens because --pretty=format:xxx never respects i18n.logoutputencoding. But that's a different story. G

[PATCH v4 00/13] nd/pretty-formats

v4 fixes comments from v3, mainly in the auto-coloring patch, and uses qz_to_tab_space for changes in t4205. It also fixes a coding style issue in 06/13, spotted in v2 but I missed it in v3. Nguyễn Thái Ngọc Duy (13): pretty: save commit encoding from logmsg_reencode if the caller needs it pre

Re: [PATCH] help.c: add a compatibility comment to cmd_version()

From: "Junio C Hamano" Sent: Thursday, April 18, 2013 1:13 AM "Philip Oakley" writes: How about * E.g. git gui uses the extended regular expression "^git version [1-9]+(\.[0-9]+)+.*" * to check for an acceptable version string. The ERE is from git-gui.sh:L958. That is exactly the kin

Re: Pushing/fetching from/into a shallow-cloned repository

"Philip Oakley" writes: >> So I observe pushing/fetching works OK at least for a simple case like >> this one. >> >> Hence I'd like to ask: if the manual page is wrong or I'm observing >> some corner case? >> -- > The manual is deliberately misleading. Yes, it is erring on the safe side. It was

Re: [PATCH v3 2/2] submodule: drop the top-level requirement

John Keeping writes: > +relative_path () > +{ > + local target curdir result > + target=$1 > + curdir=${2-$wt_prefix} > + curdir=${curdir%/} > + result= > + > + while test -n "$curdir" > + do > + case "$target" in > + "$curdir/"*) > +

Re: [PATCH] stash: tighten IS_STASH_LIKE logic

Ramkumar Ramachandra writes: > Currently, 'git stash show' and 'git stash apply' can show/apply any > merge commit, as the test for setting IS_STASH_LIKE simply asserts if > the commit is a merge. Improve the situation by asserting if the > index_commit and the worktree_commit are based off the

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Jeff King writes: > I am expecting a reaction more like "Hmm, I never thought about it > before. Does that make sense to me or not? Let me think about which > paths it pertains to and decide". Let's step back and re-review the main text. It currently says: In Git 2.0, 'git add ...' will al

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 02:37:53PM -0700, Junio C Hamano wrote: > Because this is to help people who are _used_ to seeing "git add" > not take the removals into account, I doubt that "Did I want those > updated or not? Let me see the details of them." will be the > question they will be asking [*

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Jeff King writes: >> But I think we are doing users a disservice by listing tons of >> paths. Where the difference of versions matters _most_ is when the >> user has tons of removed paths in the working tree. Either with one >> warning per path, or a block of collected paths at the end, we are

What's cooking in git.git (Apr 2013, #06; Thu, 18)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-publi

Re: Git over HTTPS with basic authentication

On Thu, Apr 18, 2013 at 09:54:32PM +0200, Matthieu Moy wrote: > Sebastian Schmidt writes: > > > Why is git not working over HTTPS with basic authentication? I can clone > > just fine, but when I try to push, it tells me > > What are you using on the server? Dumb HTTP works by serving the > repo

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 11:16:33AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > could work for both cases. Something like "not considering" (or another > > synonym for "considering") might be even more accurate. It is not just > > that we did not stage it; it is what we did not even co

Re: Pushing/fetching from/into a shallow-cloned repository

From: "Konstantin Khomoutov" Sent: Thursday, April 18, 2013 10:52 AM The git-clone manual page, both [1] and my local copy coming with Git for Windows 1.8.1, say about the --depth command-line option: --depth Create a shallow clone with a history truncated to the specified number of

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras wrote: > On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord wrote: >> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras >>> If you want to waste your time, by all means, rewrite all my commit >>> messages with essays that nobody will ever read. I'm not g

Re: Git over HTTPS with basic authentication

Sebastian Schmidt writes: > Why is git not working over HTTPS with basic authentication? I can clone > just fine, but when I try to push, it tells me What are you using on the server? Dumb HTTP works by serving the repository files as static pages, which is fundamentally read-only. The recommend

[PATCH v3 2/2] submodule: drop the top-level requirement

Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository. Signed-off-by: John Keeping --- Changes since v2: - Handle relative paths given to "submodule add --reference=./..." - C

[PATCH v3 1/2] rev-parse: add --prefix option

This makes 'git rev-parse' behave as if it were invoked from the specified subdirectory of a repository, with the difference that any file paths which it prints are prefixed with the full path from the top of the working tree. This is useful for shell scripts where we may want to cd to the top of

[PATCH v3 0/2] submodule: drop the top-level requirement

Thanks to Ram and Jens for the feedback on v2. I've addressed most of their comments in this version, but I've ignored a couple of Ram's nits about test cases where leaving it how it is makes the added tests consistent with those already in the same file. Since v2, the main improvement is that th

Git over HTTPS with basic authentication

Why is git not working over HTTPS with basic authentication? I can clone just fine, but when I try to push, it tells me error: Cannot access URL https://..., return code 22 fatal: git-http-push failed I have googled for an hour now, all I find is people that have the same problem and the solution

Re: [PATCH v2 4/6] transport-helper: warn when refspec is not used

On Thu, Apr 18, 2013 at 12:30 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> For the modes that need it. In the future we should probably error out, >> instead of providing half-assed support. >> >> The reason we want to do this is because if it's not present, the remote >> helper migh

Re: [PATCH v2 1/6] transport-helper: clarify *:* refspec

On Thu, Apr 18, 2013 at 12:27 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> The *:* refspec doesn't work, and never has, clarify the code and >> documentation to reflect that. This in effect reverts commit 9e7673e >> (gitremote-helpers(1): clarify refspec behaviour). >> ... >> applic

Re: [PATCH 3/6] transport-helper: clarify pushing without refspecs

On 04/18/2013 02:05 AM, Felipe Contreras wrote: > This has never worked, since it's inception the code simply skips all > s/it's/its/ (sorry for nitpicking) > the refs, essentially telling fast-export to do nothing. > > Let's at least tell the user what's going on. > > [SNIP] > Regards, Stefa

Re: [PATCH v2 3/6] transport-helper: clarify pushing without refspecs

On Thu, Apr 18, 2013 at 10:29:30AM -0700, Junio C Hamano wrote: > John Keeping writes: > >> diff --git a/transport-helper.c b/transport-helper.c > >> index cea787c..4d98567 100644 > >> --- a/transport-helper.c > >> +++ b/transport-helper.c > >> @@ -785,6 +785,9 @@ static int push_refs_with_export(

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Jeff King writes: > could work for both cases. Something like "not considering" (or another > synonym for "considering") might be even more accurate. It is not just > that we did not stage it; it is what we did not even consider it an item > for staging under the current rules. Yes, "not conside

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 10:51:12AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > +static const char *add_would_remove_warning = N_( > > +/* indent for "warning: " */ > > + "In Git 2.0, 'git add ...' will also update the\n" > > +"index for paths removed from the working tree that

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Jeff King writes: > +static const char *add_would_remove_warning = N_( > +/* indent for "warning: " */ > + "In Git 2.0, 'git add ...' will also update the\n" > +"index for paths removed from the working tree that match the given\n" > +"pathspec. If you want to 'add' only changed or newly

Re: [PATCH] remote-hg: fix commit messages

Felipe Contreras writes: > git fast-import expects an extra newline after the commit message data, > but we are adding it only on hg-git compat mode, which is why the > bidirectionality tests pass. > > We should add it unconditionally. > > Signed-off-by: Felipe Contreras > --- Without knowing t

Re: [PATCH v2 6/6] transport-helper: update remote helper namespace

Felipe Contreras writes: > When pushing, the remote namespace is updated correctly > (e.g. refs/origin/master), but not the remote helper's > (e.g. refs/testgit/origin/master), which currently is only updated while > fetching. > > Since the remote namespace is used to tell fast-export which commi

Re: [PATCH v2 4/6] transport-helper: warn when refspec is not used

Felipe Contreras writes: > For the modes that need it. In the future we should probably error out, > instead of providing half-assed support. > > The reason we want to do this is because if it's not present, the remote > helper might be updating refs/heads/*, or refs/remotes/origin/*, > directly,

Re: [PATCH v2 3/6] transport-helper: clarify pushing without refspecs

John Keeping writes: >> +It is recommended that all importers providing the 'import' >> +capability use this. It's mandatory for 'export'. > > s/It's/It is/ I personally do not care _too_ deeply either way, but I agree our documentation tends to use the latter more and being consistent w

Re: [PATCH v2 3/6] transport-helper: clarify pushing without refspecs

Felipe Contreras writes: > This has never worked, since it's inception the code simply skips all > the refs, essentially telling fast-export to do nothing. Good description. > > Let's at least tell the user what's going on. > > Signed-off-by: Felipe Contreras > --- > Documentation/gitremote-h

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Wed, Apr 17, 2013 at 06:39:06PM -0700, Junio C Hamano wrote: > Subject: [PATCH] git add: rework the logic to warn "git add ..." > default change > > [...] > > Rework the logic to detect the case where the behaviour will be > different in Git 2.0, and issue a warning only when it matters. > Eve

Re: [PATCH v2 1/6] transport-helper: clarify *:* refspec

Felipe Contreras writes: > The *:* refspec doesn't work, and never has, clarify the code and > documentation to reflect that. This in effect reverts commit 9e7673e > (gitremote-helpers(1): clarify refspec behaviour). > ... > applicable refspec takes precedence. The left-hand of refspecs > adve

Re: [PATCH v3 07/13] utf8.c: add reencode_string_len() that can handle NULs in string

Nguyễn Thái Ngọc Duy writes: > diff --git a/utf8.h b/utf8.h > index d3da96f..a43ef9a 100644 > --- a/utf8.h > +++ b/utf8.h > @@ -17,12 +17,25 @@ void strbuf_add_wrapped_bytes(struct strbuf *buf, const > char *data, int len, >int indent, int indent2, int width); > >

Re: Bug with rev-list --reverse?

Thomas Rast writes: > You could come up with a patch series that first starts emitting > warnings whenever the user asks for behavior that will change, and later > flips the default and removes the warning (the latter would be merged > for 2.0 or so). Please don't. The fact that "reverse then c

[PATCHv2] l10n: de.po: translate 39 new messages

Translate 39 new messages came from git.pot update in c138af5 (l10n: git.pot: v1.8.3 round 1 (54 new, 15 removed)). While at there, fix some small issues. Signed-off-by: Ralf Thielow Acked-by: Thomas Rast --- po/de.po | 206 +-- 1 fil

Re: t6200: avoid path mangling issue on Windows

Johannes Sixt writes: > From: Johannes Sixt > > MSYS bash interprets the slash in the argument core.commentchar="/" > as root directory and mangles it into a Windows style path. Use a > different core.commentchar to dodge the issue. > > Signed-off-by: Johannes Sixt > ... > - git -c core.com

Re: [PATCH] blame: handle broken commit headers gracefully

On Wed, Apr 17, 2013 at 02:55:29PM -0700, Junio C Hamano wrote: > Or you can imagine nastier input strings, like > >Name <>- 123456789 - >Name - 123456789 - >Name 56789 - > > I am afraid that at some point "we should salvage as much as we > can", which is a worthy goal, b

Re: [PATCH] t3400 (rebase): add failing test for a peculiar rev spec

Ramkumar Ramachandra writes: > 'git rebase' does not recognize revisions specified as :/text. This > is because the attempts to rev-parse ${REV}^0, which fails in this > case. Add a test to document this failure. > - The failure occurs in git-rebase.sh:403. Is it using the ^0 only >to ma

Re: git p4 submit failing

The issue is caused by the line endings. I retested the problem with a different file and in this case, the error is caused by the line endings of the file checked out in the perforce workspace being win-style crlf, and the line endings of the file in the git repo being unix style lf. (In this scen

Re: Git crash in Ubuntu 12.04

Hi, The git crashed during one of the commits by a developer I think, the remote is not even showing the working branch. The local branch of is all right, but the remote repo is corrupted and could not git fsck also. Is restoring the last night's backup is my only option?? $ git remote show origi

Re: [PATCH v2 2/2] submodule: drop the top-level requirement

On Thu, Apr 18, 2013 at 08:16:42PM +0530, Ramkumar Ramachandra wrote: > John Keeping wrote: > > Use the new rev-parse --prefix option to process all paths given to the > > submodule command, dropping the requirement that it be run from the > > top-level of the repository. > > Yay! > > > diff --gi

Re: [PATCH v2 2/2] submodule: drop the top-level requirement

John Keeping wrote: > Use the new rev-parse --prefix option to process all paths given to the > submodule command, dropping the requirement that it be run from the > top-level of the repository. Yay! > diff --git a/git-submodule.sh b/git-submodule.sh > index 79bfaac..bbf7983 100755 > --- a/git-su

Re: [PATCH v2 1/2] rev-parse: add --filename-prefix option

On Thu, Apr 18, 2013 at 07:58:25PM +0530, Ramkumar Ramachandra wrote: > John Keeping wrote: > > This adds a prefix string to any filename arguments encountered after it > > has been specified. > > Very nice. I thought we'd have to resort to path mangling in shell to > fix git-submodule.sh. Glad

Re: [PATCH v2 1/2] rev-parse: add --filename-prefix option

John Keeping wrote: > This adds a prefix string to any filename arguments encountered after it > has been specified. Very nice. I thought we'd have to resort to path mangling in shell to fix git-submodule.sh. Glad to see that we can go with something cleaner. Perhaps pull some bits from your ni

Re: Bug with rev-list --reverse?

Felipe Contreras writes: > On Thu, Apr 18, 2013 at 5:47 AM, Peter Krefting > wrote: > >>> % git log --oneline -1 v1.8.1.5^..v1.8.1.6 >>> % git log --oneline --reverse -1 v1.8.1.5^..v1.8.1.6 >>> >>> I expect to get a different output, and not both showing v1.8.1.6. >>> Wouldn't you agree? >> >>

Re: [PATCH 1/6] transport-helper: clarify *:* refspec

On Thu, Apr 18, 2013 at 7:39 AM, Thomas Rast wrote: > Felipe Contreras writes: > >> On Thu, Apr 18, 2013 at 2:28 AM, Thomas Rast wrote: >>> Felipe Contreras writes: >>> The *:* refspec doesn't work, and never has, clarify the code and documentation to reflect that. This in effect reve

Re: [PATCH 1/6] transport-helper: clarify *:* refspec

Felipe Contreras writes: > On Thu, Apr 18, 2013 at 2:28 AM, Thomas Rast wrote: >> Felipe Contreras writes: >> >>> The *:* refspec doesn't work, and never has, clarify the code and >>> documentation to reflect that. This in effect reverts commit 9e7673e >>> (gitremote-helpers(1): clarify refspec

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 6:46 AM, Ramkumar Ramachandra wrote: > Okay, one more segment needs to be responded to. > > Felipe Contreras wrote: >> If remote-hg wasn't available for users, they would be hurt; if stash >> wasn't available, if rebase --interactive didn't exist, if there was >> no msysgit

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

On Thu, Apr 18, 2013 at 6:31 AM, Ramkumar Ramachandra wrote: > Since you disagreed with the rest, I'll only respond to this part: > > Felipe Contreras wrote: >> But I won't bother trying to convince you that no project is more >> important than its users (in the words of Linus Torvalds), because >

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Okay, one more segment needs to be responded to. Felipe Contreras wrote: > If remote-hg wasn't available for users, they would be hurt; if stash > wasn't available, if rebase --interactive didn't exist, if there was > no msysgit, if it wasn't so fast, if the object model wasn't so simple > and ext

Re: Git crash in Ubuntu 12.04

Hi, > Probably not because there are no debugging symbols. Not sure how > ubuntu packages these symbols.. Would recompiling the source packages and debugging would give different results? > > Any chance you could publish the repository that causes the crash? > -- > Duy I don't think I can publi

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

Since you disagreed with the rest, I'll only respond to this part: Felipe Contreras wrote: > But I won't bother trying to convince you that no project is more > important than its users (in the words of Linus Torvalds), because > most people don't see the big picture. I didn't say otherwise. Wha

Re: Bug with rev-list --reverse?

On Thu, Apr 18, 2013 at 5:47 AM, Peter Krefting wrote: >> % git log --oneline -1 v1.8.1.5^..v1.8.1.6 >> % git log --oneline --reverse -1 v1.8.1.5^..v1.8.1.6 >> >> I expect to get a different output, and not both showing v1.8.1.6. >> Wouldn't you agree? > > > Quoting the manual page: > > Commit

Re: Bug with rev-list --reverse?

On Thu, Apr 18, 2013 at 5:26 AM, John Keeping wrote: > On Thu, Apr 18, 2013 at 05:17:14AM -0500, Felipe Contreras wrote: >> If I do these: >> >> % git log --oneline -1 v1.8.1.5^..v1.8.1.6 >> % git log --oneline --reverse -1 v1.8.1.5^..v1.8.1.6 >> >> I expect to get a different output, and not both

Re: put THEIR commits AFTER my commits with a single rebase command

Am 4/18/2013 10:33, schrieb Ilya Basin: > > JS> Perhaps this one: > > JS>git merge origin/master > JS>git rebase ORIG_HEAD > > JS> -- Hannes > > Wouldn't I have to resolve conflicts twice? Yes. But you did run 'git config rerere.enabled true' when you started with git, didn't you? ;-)

  1   2   >