[Hmm, nobody seems ot have commented on this analysis; maybe reposting
it with a subject containing [BUG] will help?]
Samuel Bronson 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 to provide any
(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 majordom
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 upco
On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley wrote:
> From: "Nico Williams"
>> 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 others who do
> [...]
Sure. I wa
From: "Nico Williams"
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley
wrote:
From: "Nico Williams"
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).
Conversely, if
Matthieu Moy writes:
> Tanay Abhra 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 the line "unsubscribe git" in
the b
Ronnie Sahlberg 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 majordomo info a
Ronnie Sahlberg 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++) {
> struct ref_upd
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> 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
>
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
On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley wrote:
> From: "Nico Williams"
>> 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).
>>
>> Conversely, if you always
Jeff King 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 omit isomorp
Nguyễn Thái Ngọc Duy 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 because of "an
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 a
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 everythi
From: "Nico Williams"
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
Nico Williams 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 identify
as
Jeff King 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 more inter
Jeff King 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" is no
Jeff King writes:
> On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:
>
>> Jeff King 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
Jeff King 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 messa
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
ther
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 eas
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
ar
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 empt
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 w
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"
v
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
user-forma
On 7/29/2014 7:33 PM, Matthieu Moy wrote:
> Tanay Abhra 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() -> gi
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
> thou
On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:
> Jeff King 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?
Y
Jeff King 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
for, which is
René Scharfe 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
>> call
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
> Nico Williams 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 identify as-yet-unintegrated
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 a
Tanay Abhra 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 would b
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 no
"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
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
---
Documentation/config.txt | 4 +++
advice.c | 2 ++
advice.h | 1 +
bu
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 cmd_checkout(int argc, c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 prepare_linked_checkout(const str
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 p
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
--- a/Documentation/gitrepository
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 int parse_branchnam
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 w
On 7/29/2014 6:10 PM, Matthieu Moy wrote:
> Tanay Abhra 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 (syntax
> error,
On 07/29/2014 03:05 PM, Duy Nguyen wrote:
> On Tue, Jul 29, 2014 at 7:20 PM, Michael Stefaniuc
> 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 o
Tanay Abhra 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 had totally forg
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 Thá
On Tue, Jul 29, 2014 at 7:20 PM, Michael Stefaniuc 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 broken pipe
>
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
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
conf
Tanay Abhra 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 key_value_info *kv_inf
Tanay Abhra 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 intege
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 th
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
ther
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 eas
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
ar
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 comm
> 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' '
>
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 (!git_c
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
---
t/t1308-config-set.sh | 10 ++
test-config.c | 10 ++
2 files changed, 20 inserti
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
---
config.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index e5b7f10..5499108 100644
---
From: Matthieu Moy
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 line we just parsed during the
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 an
[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 orde
Nico Williams writes:
> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder 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', they are asking for a cl
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 for details
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
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 +, Davi
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
templa
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
> > wrote:
> > > I recently upgraded f
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: git@vger.kernel.o
On Tue, Jul 29, 2014 at 09:57:45AM +0200, Matthieu Moy wrote:
> "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".
Also, Pat
[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 s
On Tue, Jul 29, 2014 at 12:53:29AM -0700, David Aguilar wrote:
> On Sat, Jul 19, 2014 at 05:35:17PM +0100, Charles Bailey wrote:
> > diff --git a/git-difftool.perl b/git-difftool.perl
> > index 18ca61e..598fcc2 100755
> > --- a/git-difftool.perl
> > +++ b/git-difftool.perl
> > @@ -47,13 +47,9 @@ su
"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 one without
> duplicat
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 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 in-core
On Sat, Jul 19, 2014 at 05:35:17PM +0100, Charles Bailey wrote:
> From: Charles Bailey
>
> 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 call
> mergetool di
Tanay Abhra writes:
> Replace TODO introduced in commit 9c3c22 with documentation
> explaining Git config API functions for writing configuration
> files.
>
> Signed-off-by: Tanay Abhra
> ---
> Documentation/technical/api-config.txt | 31 ++-
Sounds good to me, thank
? ? ? ??, ??? ???:
>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
80 matches
Mail list logo
