Rename 'refinfo' to 'ref_array_item' and intoduce 'ref_filter_cbdata'
which will hold 'ref_filter' (Conditions to filter the refs on) and
'ref_array' (The array of ref_array_items). Modify the code to use
these new structures.
Re-order the fields in 'ref_array_item' so that refname can be
eventual
Rename some of the functions and make them publically available.
This is a preparatory step for moving code from 'for-each-ref'
to 'ref-filter' to make meaningful, targeted services available to
other commands via public APIs.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-b
Move most of the code from 'for-each-ref' to 'ref-filter' to make
it publically available to other commands, this is to unify the code
of 'tag -l', 'branch -l' and 'for-each-ref' so that they can share
their implementations with each other.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Remi Lespinet writes:
> From: Jorge Juan Garcia Garcia
>
> Add the possibility to use a list of emails separated by commas
> in flags --cc --to and --bcc instead of having to use one flag
> per email address.
>
> The use-case is to copy-paste a list of addresses from an email.
> This change make
Johannes Schindelin writes:
> Hi Stefan,
>
> On 2015-05-27 23:47, Stefan Beller wrote:
>> On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano wrote:
>> Talking about ideas:
>> I sometimes have the wrong branch checked out when doing a small
>> fixup commit. So I want to drop that patch from the curr
On Thu, May 28, 2015 at 9:45 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Noticed-by: Philip Oakley
>> Helped-by: Junio C Hamano
>> Signed-off-by: Stefan Beller
>> ---
>> Documentation/glossary-content.txt | 17 +
>> 1 file changed, 17 insertions(+)
>
> The updates i
Paul Tan writes:
>> diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
>> index 0d8ba48..3190c05 100644
>> --- a/Documentation/git-am.txt
>> +++ b/Documentation/git-am.txt
>> @@ -89,11 +89,13 @@ default. You can use `--no-utf8` to override this.
>> linkgit:git-mailinfo[1])
On Thu, May 28, 2015 at 11:26 AM, Eric Sunshine wrote:
> On Thu, May 28, 2015 at 6:42 AM, Remi Lespinet
> wrote:
>> + The format supported for email list is the following:
>> + "Foo , b...@example.com".
>> + Please notice that the email list does not handle commas in
>> +
On Thu, May 28, 2015 at 9:10 AM, Paul Tan wrote:
> Take these comments/suggestions with a pinch of salt because I'm not
> that experienced with the code base as well ;-).
I agree with pretty much all of your review comments. See below for a
minor addenda.
> On Wed, May 27, 2015 at 5:32 AM, Remi
Matthieu Moy writes:
> But I think there are more relevant information to show (e.g. list of
> already applied commits, remaining list of commits, possibly truncated
> if the list is overly long, and information that rebase gave you when
> stopping like the path to the file being applied). Having
Eric Sunshine writes:
> Moreover, it lacks justification and explanation of why you consider
> the cleanup unnecessary. History [1] indicates that its application to
> -F but not -t was intentional.
>
> [1]: bc92377 (commit: fix ending newline for template files, 2015-05-26)
Sorry, but the date
On Thu, May 28, 2015 at 2:22 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> Moreover, it lacks justification and explanation of why you consider
>> the cleanup unnecessary. History [1] indicates that its application to
>> -F but not -t was intentional.
>>
>> [1]: bc92377 (commit: fix endi
Stefan Beller writes:
> I am not sure if the discussion belongs into the glossary though.
Probably not. Perhaps in tutorial.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/maj
Eric Sunshine writes:
> On Tue, May 26, 2015 at 2:15 AM, Patryk Obara wrote:
>> Currently messages are compared with --pretty=format:%s%b which does
>> not retain raw format of commit message. In result it's not clear what
>> part of expected commit msg is subject and what part is body. Also, it
On Tue, May 26, 2015 at 5:32 PM, Remi Lespinet
wrote:
> Add new functions to keep the setup cleaner:
> - setup_temporary_branch: creates a new branch, check it out
>and automatically delete it after the test is over
> - setup_fixed_branch: creates a fixed branch, which can be re-used
>in
On Thu, May 28, 2015 at 3:09 PM, Eric Sunshine wrote:
> On Tue, May 26, 2015 at 5:32 PM, Remi Lespinet
> wrote:
>> +setup_temporary_branch () {
>> + tmp_name=${2-"temporary"}
I forgot to mention the broken &&-chain here. Although the missing &&
doesn't actively hurt the function today, som
Junio C Hamano writes:
>> I've noticed that in the block above that initializes all the variables,
>>
>> sign= utf8=t keep= keepcr= skip= interactive= resolved= rebasing= abort=
>> messageid= resolvemsg= resume= scissors= no_inbody_headers=
>> git_apply_opt=
>> committer_date_is_a
SZEDER Gábor writes:
> @@ -16,11 +16,12 @@ SYNOPSIS
> 'git config' [] [type] [-z|--null] --get-all name [value_regex]
> 'git config' [] [type] [-z|--null] --get-regexp name_regex
> [value_regex]
> 'git config' [] [type] [-z|--null] --get-urlmatch name URL
> +'git config' [] [-z|--null] --get-
Junio C Hamano writes:
> The 'type' may also be shared between these two options, no? It
> would be logically consistent if you can say
>
> git config --bool --get-name-regexp '.*' 'no'
>
> to find all configuration variables that are set to 'false' in
> different spellings like '0', 'fals
Junio C Hamano writes:
> If this topic enhances 'git status' with the in-progress rebase
> information, I'd view it as turning 'git status' from 'a more or
> less useless command during rebase' to 'a useful command'.
For day-to-day operations, what we already have in status already
qualifies as
When a rebase stops because of a conflict, and I edit the file to
resolve the conflict and say "git rebase --continue", then the
pre-commit hook doesn't run at that point, which means that I can commit
bad stuff which the pre-commit hook would normally not allow in. We were
bitten by this a few tim
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> If this topic enhances 'git status' with the in-progress rebase
>> information, I'd view it as turning 'git status' from 'a more or
>> less useless command during rebase' to 'a useful command'.
>
> For day-to-day operations, what we already have
li...@haller-berlin.de (Stefan Haller) writes:
> When a rebase stops because of a conflict, and I edit the file to
> resolve the conflict and say "git rebase --continue", then the
> pre-commit hook doesn't run at that point,...
> From glancing through the githooks manpage, I couldn't see any other
Karthik Nayak writes:
> This is a preperatory patch for restructuring 'for-each-ref' and
> evntually moving most of it to 'ref-filter' to provide the
s/evntually/eventually/
The patch looks much nicer now.
> - int cnt;
> [...]
> + REALLOC_ARRAY(cb->grab_array, cb->grab_cnt + 1);
> +
Karthik Nayak writes:
> Rename 'refinfo' to 'ref_array_item' and intoduce 'ref_filter_cbdata'
The fact that you need to use "and" to describe your changes is a hint
that you can split better.
The patch looks much better, but I think you still need to split more to
make it easier to review.
> -
On 05/29/2015 01:43 AM, Matthieu Moy wrote:
Karthik Nayak writes:
This is a preperatory patch for restructuring 'for-each-ref' and
evntually moving most of it to 'ref-filter' to provide the
s/evntually/eventually/
Noted.
The patch looks much nicer now.
- int cnt;
[...]
+
Karthik Nayak writes:
> Move most of the code from 'for-each-ref' to 'ref-filter' to make
> it publically available to other commands, this is to unify the code
s/publically/publicly/
> --- /dev/null
> +++ b/ref-filter.h
Moving file to the .h file should be done in a separate patch. I don't
wa
On 05/29/2015 01:56 AM, Matthieu Moy wrote:
Karthik Nayak writes:
Rename 'refinfo' to 'ref_array_item' and intoduce 'ref_filter_cbdata'
The fact that you need to use "and" to describe your changes is a hint
that you can split better.
But the patch alone wouldn't make much sense here, as t
On Thu, May 28, 2015 at 02:29:33PM +0200, SZEDER Gábor wrote:
> Fixed misspelled option names in docs and in commit message, incorporated
> Peff's suggestions, and renamed 'show_only_keys' to 'omit_values' in 1/2.
>
> Only minor tweaking in 2/2's commit message.
This version looks good to me (th
Karthik Nayak writes:
> On 05/29/2015 01:56 AM, Matthieu Moy wrote:
>> Karthik Nayak writes:
>>
>>> Rename 'refinfo' to 'ref_array_item' and intoduce 'ref_filter_cbdata'
>>
>> The fact that you need to use "and" to describe your changes is a hint
>> that you can split better.
>>
>
> But the patc
On 05/29/2015 02:11 AM, Matthieu Moy wrote:
The point of separating them is that the rename implies a relatively
long patch (you have 17 occurences of 'refinfo' in the deletion part of
your patch), but it is straightforward to review (apply, run "git diff
--color-words" and press space a few time
On Thu, May 28, 2015 at 10:11:55AM -0700, Junio C Hamano wrote:
> > if (contents == MAP_FAILED) {
> > + if (errno == ENODEV && S_ISDIR(st.st_mode))
> > + errno = EISDIR;
> > error("unable to mmap '%s': %s",
> >
On 05/29/2015 02:05 AM, Matthieu Moy wrote:
Karthik Nayak writes:
Move most of the code from 'for-each-ref' to 'ref-filter' to make
it publically available to other commands, this is to unify the code
s/publically/publicly/
--- /dev/null
+++ b/ref-filter.h
Moving file to the .h file shou
Jeff King writes:
> We also know S_ISDIR(st.st_mode) _before_ we actually mmap. So I was
> tempted to simply check it beforehand, under the assumption that the
> mmap cannot possibly work if we have a directory. But by doing it in the
> error code path, then we _know_ we are not affecting the out
Matthieu Moy writes:
> Not very important, but two spaces after a period is what one is
> supposed to do in English. Not everybody follow the rule, but it seems
> backward to change the code to break it.
I am old fashioned enough to personally agree, but this practice
that originates in the type
Signed-off-by: Trevor Saunders
---
The test change only kind of tests the change in behavior and doesn't seem all
that useful. However I'm not sure if its preferable to not even try and test
that something isn't output.
bisect.c| 7 ++-
t/t6030-bisect-porcelain.sh | 3 ++
Junio C Hamano writes:
> Sent off-list to reduce noise level; this is an issue that attracts
> a lot of useless comments.
Heh, somehow I screwed up and sent on-list X-<.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More m
Trevor Saunders writes:
> Signed-off-by: Trevor Saunders
> ---
> The test change only kind of tests the change in behavior and doesn't seem all
> that useful. However I'm not sure if its preferable to not even try and test
> that something isn't output.
As the only objective of this patch is t
Junio C Hamano writes:
> * pt/pull-tests (2015-05-18) 8 commits
> - t5520: check reflog action in fast-forward merge
> - t5521: test --dry-run does not make any changes
> - t5520: test --rebase failure on unborn branch with index
> - t5520: test --rebase with multiple branches
> - t5520: tes
On Wed, May 27, 2015 at 9:33 AM, Paul Tan wrote:
> git-am.sh supports mbox, stgit and mercurial patches. Re-implement
> support for splitting out mbox/maildirs using git-mailsplit, while also
> implementing the framework required to support other patch formats in
> the future.
>
> Re-implement sup
Using git version 2.4.1.171.ga34f239, and gitolite v3.6.3 (b05c94ff).
I apologize I don't know enough about the client vs server functions,
during a git push, to know whether this is a git or gitolite issue.
After cloning the public glibc repo, and creating a new bare repo on
my local gitserver by
Michael Darling writes:
> $ git push --tags --set-upstream origin
[...]
> Note this time there is NO:
>
> * [new branch] master -> master
> Branch master set up to track remote branch master from origin.
man git-push says:
SYNOPSIS
git push [...] [ [...]]
[...]
--tags
On Wed, May 27, 2015 at 12:31:47PM +0200, SZEDER Gábor wrote:
> Some thoughts:
>
>1) Perhaps 'git config' should be more careful in the first place
> and refuse to set 'core.worktree' when 'core.bare' is already
> true and vice versa.
Right now git-config doesn't know anything ab
On 05/26/2015 09:19 PM, Matthieu Moy wrote:
Seconded. Some reasons/guide to split:
* Split trivial and non-trivial stuff. I can quickly review a
"rename-only" patch even if it's a bit long (essentially, I'll check
that you did find-and-replace properly), but reviewing a mix of
renames a
Junio C Hamano writes:
> I think there is a difference between (silently) accepting just to
> be lenient and documenting and advocating mixed case uses.
>
> Personally, I'd rather not to see gratuitous flexibility to allow
> the same thing spelled in 47 different ways for no good reason.
It was
On Wed, May 27, 2015 at 03:38:12PM -0700, Junio C Hamano wrote:
> The patch was meant to be a tongue-in-cheek tangent that is a vast
> improvement for cases where we absolutely need to use mmap but does
> not help the OP at all ;-) I do not think there is any need for the
> config reader to read
Once upon a time, git's in-memory representation of a cache
entry actually pointed to the mmap'd on-disk data. So in
520fc24 (Allow writing to the private index file mapping.,
2005-04-26), we specified PROT_WRITE so that we could tweak
the entries while we run (in our own MAP_PRIVATE copy-on-write
We mmap the existing config file, but fail to unmap it if we
hit an error. The function already has a shared exit path,
so we can fix this by moving the mmap pointer to the
function scope and clearing it in the shared exit.
Signed-off-by: Jeff King
---
config.c | 9 +
1 file changed, 5 i
The config-writing code uses xmmap to map the existing
config file, which will die if the map fails. This has two
downsides:
1. The error message is not very helpful, as it lacks any
context about the file we are mapping:
$ mkdir foo
$ git config --file=foo some.key value
If we try to mmap a directory, we'll get ENODEV. This
translates to "no such device" for the user, which is not
very helpful. Since we've just fstat()'d the file, we can
easily check whether the problem was a directory to give a
better message.
Signed-off-by: Jeff King
---
It feels a bit wrong to
On Tue, May 26, 2015 at 8:15 AM, Patryk Obara wrote:
>
> These are my first patches to git, so be extra pedantic during review, please.
>
> I noticed, that newline is appended, when I try to use template file - which
> is annoying if template ends with comment. I digged a bit and it turned out
> t
Hello,
I've corrected an old patch from an Ensimag student.
(http://thread.gmane.org/gmane.comp.version-control.git/228182). This
patch allows multiple email addresses for options --cc, --to and
--bcc. As said in the commit message, this patch doesn't handle commas
in name, and the only possibilit
From: Jorge Juan Garcia Garcia
Add the possibility to use a list of emails separated by commas
in flags --cc --to and --bcc instead of having to use one flag
per email address.
The use-case is to copy-paste a list of addresses from an email.
This change makes it so that we no longer need to cut
On Wed, 27 May 2015 17:28:34 -0700
Stefan Beller wrote:
> so I just run into this problem again (which happens to me maybe
> twice a week): I want to do a git operations, so I type "git " into
> my shell,
[...]
> then I copy the whole operation "git revert --abort" in this case and
> paste it to
Karthik Nayak writes:
> On 05/26/2015 09:19 PM, Matthieu Moy wrote:
>> Seconded. Some reasons/guide to split:
>>
>> * Split trivial and non-trivial stuff. I can quickly review a
>>"rename-only" patch even if it's a bit long (essentially, I'll check
>>that you did find-and-replace properly
Remi Lespinet writes:
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -519,6 +519,12 @@ Result: OK
> EOF
> "
>
> +replace_variable_fields () {
> + sed -e "s/^\(Date:\).*/\1 DATE-STRING/" \
> + -e "s/^\(Message-Id:\).*/\1 MESSAGE-ID-STRING/" \
> +
On Wed, May 27, 2015 at 10:11 PM, SZEDER Gábor wrote:
> Recenty I created a multi-line branch description with '.' and '='
> characters on one of the lines, and noticed that fragments of that line
> show up when completing set variable names for 'git config', e.g.:
>
> $ git config --get branch.
It is an almost empty code I send to validate the global architecture
of this command. I choose to write it in C because git status is
already in C and it seems that it is the current tendency to port
shell code to C. Moreover I would like to use code from wt_status to
implement this functionnalit
List all set config variable names with 'git config --list-names' instead
of '--list' and post processing. Similarly, use 'git config
--get-name-regexp' instead of '--get-regexp' to get config variables in a
given section.
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash |
Fixed misspelled option names in docs and in commit message, incorporated
Peff's suggestions, and renamed 'show_only_keys' to 'omit_values' in 1/2.
Only minor tweaking in 2/2's commit message.
SZEDER Gábor (2):
config: add options to list only variable names
completion: use new 'git config' o
Recenty I created a multi-line branch description with '.' and '='
characters on one of the lines, and noticed that fragments of that line
show up when completing set variable names for 'git config', e.g.:
$ git config --get branch.b.description
Branch description to fool the completion script
Guillaume Pagès writes:
> It is an almost empty code I send to validate the global architecture
> of this command. I choose to write
Avoid personal wording (I choose to write ... because -> The code is
written ... because). What matters in the commit message is the reason
for the choice, not wh
Hello.
Recently, the guys from Google have to deal with an issue in Android
Studio where the user can no longer type in the IDE.
Their workaround is to restart ibus via "ibus restart", which works
more or less [1].
As a side effect I noticed that wish and therefore gitk and git-gui
die as soon as
Guillaume Pagès writes:
> It is an almost empty code I send to validate the global architecture
> of this command.
One more note: I know what "git rebase --status" is about because I'm
the one who suggested it and I read your previous message, but not
everybody is me, and most people would appre
Hi,
Take these comments/suggestions with a pinch of salt because I'm not
that experienced with the code base as well ;-).
On Wed, May 27, 2015 at 5:32 AM, Remi Lespinet
wrote:
> Add new functions to keep the setup cleaner:
> - setup_temporary_branch: creates a new branch, check it out
>and
Stefan Beller writes:
> so I just run into this problem again (which happens to me maybe twice
> a week):
> I want to do a git operations, so I type "git " into my shell, and
> then [...] I copy the whole operation "git revert --abort" in this case and
> paste it to the shell
On my side, that wo
On Tue, May 26, 2015 at 2:15 AM, Patryk Obara wrote:
> Currently messages are compared with --pretty=format:%s%b which does
> not retain raw format of commit message. In result it's not clear what
> part of expected commit msg is subject and what part is body. Also, it's
> impossible to test if me
Hi,
On Wed, May 27, 2015 at 5:32 AM, Remi Lespinet
wrote:
> Add the am.threeWay configuration variable to use the -3 or --3way
> option of git am by default. When am.threeway is set and not desired
> for a specific git am command, the --no-3way option can be used to
> override it.
>
> Signed-off-
Preparatory commit for a git rebase --status command. This command
will indicate the state of the process in the rebase, and the reason
why it stopped.
Signed-off-by: Guillaume Pagès
---
The observations from Matthieu Moy have been taken into account
It is an almost empty code sent to validate
On Tue, May 26, 2015 at 2:15 AM, Patryk Obara wrote:
> git-commit with -t or -F -e uses content of user-supplied file as
> initial value for commit msg in editor. There is no guarantee, that this
> file ends with newline - it depends on file content and editor used to
> create file (some editors a
On Thu, May 28, 2015 at 6:42 AM, Remi Lespinet
wrote:
> Add the possibility to use a list of emails separated by commas
> in flags --cc --to and --bcc instead of having to use one flag
s/--cc --to/--cc, --to/
Ditto in subject.
> per email address.
>
> The use-case is to copy-paste a list of add
Guillaume Pagès writes:
> It is an almost empty code sent to validate the global architecture of
> this command. It is written in C because git status is already in C
> and it seems that it is the current tendency to port shell code to
> C. Moreover will likely use code from wt_status to impleme
Hi,
"Paul Tan" :
> I haven't kept up with the discussion, but I'm wondering: since you
> need the functionality in wt-status.c, why not implement it in git
> status? In fact, git-status already shows if there is a rebase in
> progress, so why not extend it to say which patch/todo line the r
Guillaume Pages writes:
> Hi,
>
> "Paul Tan" :
>> I haven't kept up with the discussion, but I'm wondering: since you
>> need the functionality in wt-status.c, why not implement it in git
>> status? In fact, git-status already shows if there is a rebase in
>> progress, so why not extend it
Stefan Beller writes:
> Noticed-by: Philip Oakley
> Helped-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
> Documentation/glossary-content.txt | 17 +
> 1 file changed, 17 insertions(+)
The updates in this version relative to the previous one looks very
good, at leas
Remi Galan Alfonso
writes:
> Junio C Hamano writes:
>> I think there is a difference between (silently) accepting just to
>> be lenient and documenting and advocating mixed case uses.
>>
>> Personally, I'd rather not to see gratuitous flexibility to allow
>> the same thing spelled in 47 differe
Hi Stefan,
On 2015-05-27 23:47, Stefan Beller wrote:
> On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano wrote:
> Talking about ideas:
> I sometimes have the wrong branch checked out when doing a small
> fixup commit. So I want to drop that patch from the current branch
> and apply it to another br
Jeff King writes:
> On Wed, May 27, 2015 at 03:38:12PM -0700, Junio C Hamano wrote:
>
>> The patch was meant to be a tongue-in-cheek tangent that is a vast
>> improvement for cases where we absolutely need to use mmap but does
>> not help the OP at all ;-) I do not think there is any need for th
Jeff King writes:
> If we try to mmap a directory, we'll get ENODEV. This
> translates to "no such device" for the user, which is not
> very helpful. Since we've just fstat()'d the file, we can
> easily check whether the problem was a directory to give a
> better message.
>
> Signed-off-by: Jeff
On Thu, May 28, 2015 at 10:06 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On 2015-05-27 23:47, Stefan Beller wrote:
>> On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano wrote:
>> Talking about ideas:
>> I sometimes have the wrong branch checked out when doing a small
>> fixup commit. So I want
Hello,
After the second version of the WIP/PATCH ($gmane/269836), This is a
follow up.
Changes:
* Broke down the first commit into 3 separate commits, cause they were
logically different and needed to built up incrementally.
* renamed some functions which were made public so that they don't s
Extract two helper functions out of grab_single_ref(). Firstly,
new_refinfo() which is used to allocate memory for a new refinfo
structure and copy the objectname, refname and flag to it.
Secondly, match_name_as_path() which when given an array of patterns
and the refname checks if the refname matc
82 matches
Mail list logo
