On 07/28/2014 12:39 PM, Duy Nguyen wrote:
I know wine is kind of second citizen but is there a cheap trick to
make it work on wine? Reverting fcd428f (Win32: fix broken pipe
detection - 2012-03-01) could result in conflicts in compat that I'm
not comfortable resolving. I don't have Windows at
On 07/27/2014 05:26 PM, Guang Chen wrote:
I use brew upgrade git to this version on OSX. And when I use git add -i, it
says:
Which version did you use before?
Was it installed with brew as well ?
Can't locate Git.pm in @INC (@INC contains: @@@/git/2.0.3/lib/perl5/site_perl
brian m. carlson sandals at crustytoothpaste.net writes:
On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote:
Sorry for error -- I meant: git stash list -p, not git stash -p.
On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol michael-spam at
migdol.net wrote:
I recently
I used 1.9.2 before, it was installed with brew as well.
I didn’t found Git.pm under /usr/local/Cellar/git/,
/usr/local/Cellar/git/2.0.3/, and I looked at /usr/local/Cellar/git/1.9.2/,
there isn’t a Git.pm either.
type perl says:
perl is /usr/bin/perl
Additionally, perl --version says:
This
? ? ? ??, ??? ???:
From : b...@cci.lg.ua
To: git@vger.kernel.org
Subject : Git@vger.kernel.org
Message-ID:
?? ???:
-
text.exe
--
To unsubscribe from this list: send the
Tanay Abhra tanay...@gmail.com writes:
Replace TODO introduced in commit 9c3c22 with documentation
explaining Git config API functions for writing configuration
files.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
Documentation/technical/api-config.txt | 31
On Sat, Jul 19, 2014 at 05:35:17PM +0100, Charles Bailey wrote:
From: Charles Bailey cbaile...@bloomberg.net
git-difftool used to create a command list script containing $( ... )
and explicitly call sh -c with this list.
Instead, allow mergetool --tool-help to take a mode parameter and
On Tue, Jul 29, 2014 at 11:06:25AM +1000, Bryan Turner wrote:
On Tue, Jul 29, 2014 at 10:11 AM, Junio C Hamano gits...@pobox.com wrote:
OK, I pushed out updated 'maint' and 'master'. The former merges
a rebased version of jk/alloc-commit-id in to make the reorganize
the way we manage the
patrick.reyno...@github.com patrick.reyno...@github.com writes:
^
It seems you mixed your name and email address in your config file. I
guess your name is Patrick Reynolds, not
patrick.reyno...@github.com.
Remotes are stored as an array, so looking one up or adding
[please avoid top-posting]
On 07/29/2014 08:55 AM, Guang Chen wrote:
I used 1.9.2 before, it was installed with brew as well.
I didn’t found Git.pm under /usr/local/Cellar/git/,
/usr/local/Cellar/git/2.0.3/, and I looked at /usr/local/Cellar/git/1.9.2/,
there isn’t a Git.pm either.
type perl
On Tue, Jul 29, 2014 at 09:57:45AM +0200, Matthieu Moy wrote:
patrick.reyno...@github.com patrick.reyno...@github.com writes:
^
It seems you mixed your name and email address in your config file. I
guess your name is Patrick Reynolds, not
Yeah, the --authors-prog does work. Is there a way to save the configuration
though so you don't have to add it everytime time you rebase or dcommit?
Thanks
David
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: 28 July 2014 21:08
To: David Braden
Cc:
On Tue, Jul 29, 2014 at 02:59:40AM +, brian m. carlson wrote:
On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote:
Sorry for error -- I meant: git stash list -p, not git stash -p.
On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol michael-s...@migdol.net
wrote:
I
On Tue, Jul 29, 2014 at 08:35:26AM +, David Braden wrote:
Yeah, the --authors-prog does work. Is there a way to save the
configuration though so you don't have to add it everytime time you
rebase or dcommit?
I think that git-svn's config reader uses the command-line options as a
Yeah, that works. Thank you very much
David
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: 29 July 2014 10:27
To: David Braden
Cc: git@vger.kernel.org
Subject: Re: git-svn authors file and SVN users with ‘=’ in the username
On Tue, Jul 29, 2014 at 08:35:26AM +,
Are you in need of a Flexible loan? we offer all kind of loan at 2% annual
interest rate, Contact us now for more details on how to apply please only
email l...@cromwellfncsltd.com for details
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Nico Williams n...@cryptonector.com writes:
On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Sergei Organov wrote:
Is there any scenario at all where pull --rebase=true wins over
preserve?
Basically always in my book. ;-)
When people turn on 'pull --rebase',
[PATCH v4]: One style nit corrected, also added key to error messages.
Diff with v3 at the bottom for easy review.
[PATCH V3]:All the suggestions in [3] applied. Built on top of [1].
[PATCH V2]: All the suggestions in [2] incorporated. git_config() now follows
correct parsing
Semantic errors (for example, for alias.* variables NULL values are
not allowed) in configuration files cause a die printing the line
number and file name of the offending variable.
Add a test documenting that such errors cause a die printing the
the configuration variable, accurate line number
Of all the functions in `git_config*()` family, `git_config()` has the
most invocations in the whole code base. Each `git_config()` invocation
causes config file rereads which can be avoided using the config-set API.
Use the config-set API to rewrite `git_config()` to use the config caching
layer
Store file name and line number for each key-value pair in the cache
during parsing of the configuration files.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
config.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index
From: Matthieu Moy matthieu@grenoble-inp.fr
If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and the file name.
Currently the printed line number is off by one, thus printing the
wrong line number.
Make `linenr` point to the
Add `git_die_config` that dies printing the line number and the file name
of the highest priority value for the configuration variable `key`.
It has usage in non-callback based config value retrieval where we can
raise an error and die if there is a semantic error.
For example,
if
Add tests for `git_config_get_string_const()`, check whether it
dies printing the line number and the file name if a NULL
value is retrieved for the given key.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
t/t1308-config-set.sh | 10 ++
test-config.c | 10 ++
2 files
diff --git a/t/t4055-diff-context.sh b/t/t4055-diff-context.sh
index cd04543..741e080 100755
--- a/t/t4055-diff-context.sh
+++ b/t/t4055-diff-context.sh
@@ -79,7 +79,7 @@ test_expect_success 'non-integer config parsing' '
test_expect_success 'negative integer config parsing' '
git
Imagine you have a simple stash like:
git init
echo base file git add file git commit -m file
echo new file
git stash
Before this series:
$ git stash list -p
stash@{0}: WIP on master: 7a1fd22 file
Er, what? It didn't give me a patch. Oh, that's because stashes are
merge commits,
When showing a combined diff, we are comparing two (or more)
parents to a final state, and some of these states may be
the same. Here's a table of the possible contents for a
given path (for two parents, but we will generalize to more
in a moment; we also omit isomorphic cases where the parents
When you list stashes, you can provide arbitrary git-log
options to change the display. However, adding just -p
does nothing, because each stash is actually a merge commit.
This implementation detail is easy to forget, leading to
confused users who think -p is not working. We can make
this easier
A stash may store not only working tree changes, but also
changes to the index. However, git stash show will only
ever show the working tree changes. We can instead show both
as a combined diff, but use --simplify-combined-diff so
that we show a normal pairwise diff in the common case that
there
On 07/29/2014 08:30 AM, Torsten Bögershausen wrote:
On 07/28/2014 12:39 PM, Duy Nguyen wrote:
I know wine is kind of second citizen but is there a cheap trick to
make it work on wine? Reverting fcd428f (Win32: fix broken pipe
detection - 2012-03-01) could result in conflicts in compat that I'm
Tanay Abhra tanay...@gmail.com writes:
diff --git a/t/t4055-diff-context.sh b/t/t4055-diff-context.sh
index cd04543..741e080 100755
--- a/t/t4055-diff-context.sh
+++ b/t/t4055-diff-context.sh
@@ -79,7 +79,7 @@ test_expect_success 'non-integer config parsing' '
test_expect_success 'negative
Tanay Abhra tanay...@gmail.com writes:
+static int configset_iter(struct config_set *cs, config_fn_t fn, void *data)
+{
+ int i, value_index;
+ struct string_list *values;
+ struct config_set_element *entry;
+ struct configset_list *list = cs-list;
+ struct
One month to go for GSoC to end and I am almost at the end of my project.
So what have we accomplished do far? Let's see,
1 Git config cache:
I have written a config cache which reads and caches the key/value pairs
in a hashmap. It is generalized as config-set which can also be used to read
On Tue, Jul 29, 2014 at 08:00:56AM -0400, Jeff King wrote:
The implementation just cuts the number of parents down to 1, but
otherwise runs through the same combined-diff code. The resulting
pairwise combined-diff differs from a normal diff in a few ways:
1. The header line is still diff
On Tue, Jul 29, 2014 at 7:20 PM, Michael Stefaniuc mstef...@redhat.com wrote:
On 07/29/2014 08:30 AM, Torsten Bögershausen wrote:
On 07/28/2014 12:39 PM, Duy Nguyen wrote:
I know wine is kind of second citizen but is there a cheap trick to
make it work on wine? Reverting fcd428f (Win32: fix
When utf8_width(src) is called with *src == NULL (because the
source string ends with an ansi sequence), it returns 0 and steps
'src' by one. This stepping makes strbuf_utf8_replace add NUL to the
destination string at the end of the loop. Check and break the loop
early.
Signed-off-by: Nguyễn
Tanay Abhra tanay...@gmail.com writes:
a Unsetting previously set values
Local config files can be used to unset config values previously set in system
files. The user may not have the privilege to touch the system files so he can
leverage the new API to unset the previously set values.
I
On 07/29/2014 03:05 PM, Duy Nguyen wrote:
On Tue, Jul 29, 2014 at 7:20 PM, Michael Stefaniuc mstef...@redhat.com
wrote:
On 07/29/2014 08:30 AM, Torsten Bögershausen wrote:
On 07/28/2014 12:39 PM, Duy Nguyen wrote:
I know wine is kind of second citizen but is there a cheap trick to
make it
On 7/29/2014 6:10 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
configset_iter unconditionnally returns 0 (or it dies). Since it is more
or less the equivalent of the old git_config(), I understand why we
never encounter the situation where git_config() would return -1
This fixes all comments from v1. I still keep the long advice when
'git checkout' fails because another branch is locked, because it's
easy(*) to disable the advice. Two more fixes found today. The test
breakages on Windows have to wait until somebody on Windows jumps in.
(*) although I start to
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index c83f476..6ac89eb 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1202,7 +1202,8 @@ static
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitrepository-layout.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index bed4f1a..6bd82af 100644
---
There's a code path in prune_repo_dir() that does not initialize 'st'
buffer, which is checked by the caller, prune_repos_dir(). Instead
of leaking some prune logic out to prune_repos_dir(), move 'st' into
prune_repo_dir().
Another bug that is fixed while at there is the return 0 at the end
of
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 4fbb9c1..3dc416c 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -861,6 +861,8 @@ static int
Give the user a choice in this case: detach, make a new branch,
release current branch in the other checkout or simply 'cd' there and
continue to work.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 4 +++
advice.c | 2 ++
advice.h
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 173aab1..4fbb9c1 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1342,7 +1342,7 @@ int
junk_git_dir is set to sb_repo.buf. By the end of prepare_linked_checkout(),
sb_repo is freed and so junk_git_dir points to nowhere. If the second
checkout command fails, is_junk remains non-zero, remove_junk() will
be called and try to clean junk_git_dir, which could be anything now
(if it does
info/grafts should be part of the common repository when accessed
from a linked checkout (iow $GIT_COMMON_DIR/info/grafts, not
$GIT_DIR/info/grafts).
git_path(info/grafts) returns correctly, even without this fix,
because it detects that $GIT_GRAFT_FILE is not set, so it goes with the
common
Tanay Abhra tanay...@gmail.com writes:
On 7/29/2014 6:10 PM, Matthieu Moy wrote:
So, I think it's time to make it official that git_config() does not
return an error code, and make it return void. I would do that in a
patch before the git_config() - git_config_raw() rewrite.
My preference
Remotes are stored as an array, so looking one up or adding one without
duplication is an O(n) operation. Reading an entire config file full of
remotes is O(n^2) in the number of remotes. For a repository with tens of
thousands of remotes, the running time can hit multiple minutes.
Hash tables
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov o...@javad.com wrote:
Nico Williams n...@cryptonector.com writes:
That exception aside, keeping all local commits on top by always
rebasing them onto the upstream is extremely useful: a) in simplifying
conflict resolution, b) making it easy to
René Scharfe l@web.de writes:
Next call to the function invalidates the return value the last
caller received feels like playing with fire. Most existing
callers are safe in that the first thing they do to the returned
string is xstrdup() it, but we would need to check all the other
Jeff King p...@peff.net writes:
So perhaps we could do something better on the viewing side, and
simplify combined merges for files with all-identical parents.
Or you can ask to show the difference with the first parent, no?
I do not think giving a single-parent diff when --cc/-c is asked
On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So perhaps we could do something better on the viewing side, and
simplify combined merges for files with all-identical parents.
Or you can ask to show the difference with the first parent,
On Tue, Jul 29, 2014 at 02:43:39PM +, Patrick Reynolds wrote:
Remotes are stored as an array, so looking one up or adding one without
duplication is an O(n) operation. Reading an entire config file full of
remotes is O(n^2) in the number of remotes. For a repository with tens of
On 7/29/2014 7:33 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
On 7/29/2014 6:10 PM, Matthieu Moy wrote:
So, I think it's time to make it official that git_config() does not
return an error code, and make it return void. I would do that in a
patch before the git_config()
I spent a few more minutes cleaning up the rough edges here, and this is
what I ended up with. This version uses run_diff to implement the actual
single-parent diff, so that it matches a real diff exactly. It also
introduces a few new patches to let you really specify an empty --pretty
Once upon a time, we parsed pretty options by looking for
--pretty at the start of the string, and then feeding the
rest (including an =) to get_commit_format. Later, commit
48ded91 (log --pretty: do not accept bogus --prettyshort,
2008-05-25) split this into a separate check for --pretty
versus
Until now, we treated --pretty= or --format= as give me
the default format. This was not planned nor documented,
but only what happened to work due to our parsing of
--pretty (which should give the default format).
Let's instead let these be an actual empty userformat.
Otherwise one must write
If the user provides an empty format with --format=, we
end up putting in extra whitespace that the user cannot
prevent. This comes from two places:
1. If the format is missing a terminating newline, we add
one automatically. This makes sense for --format=%h, but
not for a truly empty
When showing a combined diff, we are comparing two (or more)
parents to a final state, and some of these states may be
the same. Here's a table of the possible contents for a
given path (for two parents, but we will generalize to more
in a moment; we also omit isomorphic cases where the parents
When you list stashes, you can provide arbitrary git-log
options to change the display. However, adding just -p
does nothing, because each stash is actually a merge commit.
This implementation detail is easy to forget, leading to
confused users who think -p is not working. We can make
this easier
A stash may store not only working tree changes, but also
changes to the index. However, git stash show will only
ever show the working tree changes. We can instead show both
as a combined diff, but use --simplify-combined-diff so
that we show a normal pairwise diff in the common case that
there
Jeff King p...@peff.net writes:
... People might be doing things like git stash show | git
apply, and would want to ignore the index content ...
FWIW, that is exactly how I use git stash show -p most of the time.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Jeff King p...@peff.net writes:
On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So perhaps we could do something better on the viewing side, and
simplify combined merges for files with all-identical parents.
Or you can ask to show the
Jeff King p...@peff.net writes:
When you list stashes, you can provide arbitrary git-log
options to change the display. However, adding just -p
does nothing, because each stash is actually a merge commit.
This implementation detail is easy to forget, leading to
confused users who think -p
Jeff King p...@peff.net writes:
I think that is my point, though. The user is _not_ aware that the
commit in question is a merge. They stashed some stuff, and now they
want to see the result. I'd like to show them a vanilla commit if the
index is irrelevant, and otherwise show them something
From: Nico Williams n...@cryptonector.com
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov o...@javad.com wrote:
Nico Williams n...@cryptonector.com writes:
That exception aside, keeping all local commits on top by always
rebasing them onto the upstream is extremely useful: a) in
simplifying
MSYS programs typically understand native Windows paths (e.g C:/git), but
native Windows programs (including MinGW) don't understand MSYS paths (e.g.
/c/git).
On Windows, set TRASH_DIRECTORY to the absolute native path so that it can
be used more easily in tests.
MSYS 'tar -f' interprets
Am 28.07.2014 12:39, schrieb Duy Nguyen:
I know wine is kind of second citizen but is there a cheap trick to
make it work on wine? Reverting fcd428f (Win32: fix broken pipe
detection - 2012-03-01) could result in conflicts in compat that I'm
not comfortable resolving. I don't have Windows at
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
When utf8_width(src) is called with *src == NULL (because the
source string ends with an ansi sequence),
I am not sure what you mean by because here. Do you mean somebody
(who?) decides to call the utf8_width() with NULL pointer stored in
*src
Jeff King p...@peff.net writes:
When showing a combined diff, we are comparing two (or more)
parents to a final state, and some of these states may be
the same. Here's a table of the possible contents for a
given path (for two parents, but we will generalize to more
in a moment; we also
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley philipoak...@iee.org wrote:
From: Nico Williams n...@cryptonector.com
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
upstreams (the example exception I gave).
Am 28.07.2014 19:17, schrieb Jeff King:
Hi Karsten,
The hashmap_entry documentation claims:
`struct hashmap_entry`::
An opaque structure representing an entry in the hash table,
which must be used as first member of user data structures.
Ideally it should be
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 173aab1..4fbb9c1 100644
--- a/builtin/checkout.c
Ronnie Sahlberg sahlb...@google.com writes:
+ /*
+ * Always copy loose refs that are to be deleted to the packed refs.
+ * If we are updating multiple refs then copy all non symref refs
+ * to the packed refs too.
+ */
for (i = 0; i n; i++) {
Ronnie Sahlberg sahlb...@google.com writes:
+ packed = get_packed_refs(ref_cache);;
s/;;/;/; ;-)
Sorry, I couldn't resist the urge to type many semicolons ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com writes:
[v13]: v12 was rejected because of redundant implementation of the new
functions,
hope this one is okay.
It is to me at least.
Thanks,
OK, will replace.
--
To unsubscribe from this list: send
From: Nico Williams n...@cryptonector.com
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley philipoak...@iee.org
wrote:
From: Nico Williams n...@cryptonector.com
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley philipoak...@iee.org wrote:
From: Nico Williams n...@cryptonector.com
That workflow works just fine with git.
I'm not saying that it isn't a good technique and can work well. Rather I'm
saying we should be tolerant of the rules and techniques of
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Other than a few bugfix topics still in 'next', the tip of
'master', which has past -rc0, should be more or less feature
complete for the
(or all of a repo's branches)
Teamware recorded whether it had any children and warned about
rebasing published contents. Perhaps git could do the same.
Nico
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
[Hmm, nobody seems ot have commented on this analysis; maybe reposting
it with a subject containing [BUG] will help?]
Samuel Bronson naes...@gmail.com writes:
The following message is a courtesy copy of an article
that has been posted to gmane.comp.version-control.git as well.
Oh, I forgot
83 matches
Mail list logo
