On Sat, Jun 13, 2015 at 7:42 AM, Michael Haggerty wrote:
> This is v2 of this patch series. I think I have addressed all of the
> feedback from v1 [1]. Thanks to Stefan, Peff and Junio for their
> feedback.
This version looks good to me.
>
> Changes since v1:
>
> * Change docstring for delete_re
On Sun, Jun 14, 2015 at 1:21 PM, erik elfström wrote:
> On Sun, Jun 14, 2015 at 5:42 AM, Eric Sunshine
> wrote:
>>
>> This variable name doesn't convey much about its purpose, and
>> introduces a bit of maintenance burden if the limit is some day
>> changed. Perhaps "sane_size_limit" or somethin
Karsten Blees writes:
> diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
> index e9a1d5d..e5f6233 100644
> --- a/Documentation/i18n.txt
> +++ b/Documentation/i18n.txt
> @@ -1,18 +1,28 @@
> -At the core level, Git is character encoding agnostic.
> -
> - - The pathnames recorded in the
Karsten Blees writes:
> members are also compared, but this is not enabled by default
> -because in-core timestamps can have finer granularity than
> +because on Linux, in-core timestamps can have finer granularity than
> on-disk timestamps, resulting in meaningless changes when an
> inode is
On Sun, Jun 14, 2015 at 02:23:47PM -0700, Junio C Hamano wrote:
> What this series wants to achieve makes a lot of sense to me. One
> comment I have after skimming the patfches is that I want the new
> "raw" bit added not as a yet another parameter after "verbose", but
> by turning the existing "v
Paul Tan writes:
> For the purpose of applying the patch and committing the results,
> implement extracting the patch data, commit message and authorship from
> an e-mail message using git-mailinfo.
>
> git-mailinfo is run as a separate process, but ideally in the future,
> we should be be able t
Paul Tan writes:
> +int cmd_am(int argc, const char **argv, const char *prefix)
> +{
> + if (!getenv("_GIT_USE_BUILTIN_AM")) {
> + const char *path = mkpath("%s/git-am", git_exec_path());
> +
> + if (sane_execvp(path, (char**) argv) < 0)
Style:
if (s
Duy Nguyen writes:
> I think we should stop the ok-to-replace feature when submodules are
> involved, we consider submdules much more valuable than symlinks.
Hmm, I am not sure "valuable" is a good criterion to decide what
should happen, though.
The push to use ".git" that is a file pointing at
Thanks.
--
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/majordomo-info.html
"brian m. carlson" writes:
> Currently, verify-commit and verify-tag produce human-readable output.
> This is great for humans, and awful for machines. It also lacks a lot
> of the information that GnuPG's --status-fd output provides.
>
> For example, if you wanted to know
> * the hash algorithm
This message's goal is to explained where am I on the bisect
functions.
-git bisect replay now work with any terms.
-I took account of most of the last reviews (coding style,
double sed ...)
-'git bisect terms' without arguments now display the current
terms
-bisect_terms : if a bisection ha
Matthieu Moy writes:
>> +if test -s "$GIT_DIR/TERMS_DEFINED"
>> +then
>> +terms_defined=1
>> +get_terms
>> +rm -rf "$GIT_DIR/TERMS_DEFINED"
>
>I don't understand why you need to delete this file. I did not review
>thoroughly so there
Louis Stuber writes:
>Matthieu Moy writes:
>
>> Modifying in PATCH 7 some code that you introduced in PATCH 3 is
>> suspicious. Is there any reason you did not name the variable
>> "terms_defined" in the first place? (i.e. squash this hunk and the other
>> instance of start_bad_good into P
verify-commit by default displays human-readable output on standard
error. However, it can also be useful to get access to the raw gpg
status information, which is machine-readable, allowing automated
implementation of signing policy. Add a --raw option to make
verify-commit produce the gpg statu
Currently, verify-commit and verify-tag produce human-readable output.
This is great for humans, and awful for machines. It also lacks a lot
of the information that GnuPG's --status-fd output provides.
For example, if you wanted to know
* the hash algorithm;
* whether the signature was made with
verify-tag by default displays human-readable output on standard error.
However, it can also be useful to get access to the raw gpg status
information, which is machine-readable, allowing automated
implementation of signing policy. Add a --raw option to make verify-tag
produce the gpg status infor
verify-tag was lacking tests. Add some, mirroring those used for
verify-commit.
Signed-off-by: brian m. carlson
---
t/t7030-verify-tag.sh | 85 +++
1 file changed, 85 insertions(+)
create mode 100755 t/t7030-verify-tag.sh
diff --git a/t/t7030-ve
Hi,
I'm happy to announce the first release candidate of git-multimail 1.1.
git-multimail is a tool to send notification emails for pushes to a git
repository. It can be downloaded from
https://github.com/git-multimail/git-multimail (the release itself can
be seen here: https://github.com/git-mul
On Sun, Jun 14, 2015 at 5:42 AM, Eric Sunshine wrote:
>
> This variable name doesn't convey much about its purpose, and
> introduces a bit of maintenance burden if the limit is some day
> changed. Perhaps "sane_size_limit" or something even more descriptive
> (and/or terse) would be better.
>
Wou
On 12/06/15 14:33, Dennis Kaarsemaker wrote:
On vr, 2015-06-12 at 13:39 +0200, Andres G. Aragoneses wrote:
On 12/06/15 13:33, Dennis Kaarsemaker wrote:
On vr, 2015-06-12 at 13:26 +0200, Andres G. Aragoneses wrote:
AFAIU git stores the contents of a repo as a sequence of patches in the
.git me
The following changes since commit 9eabf5b536662000f79978c4d1b6e4eff5c8d785:
Git 2.4.2 (2015-05-26 13:49:59 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.4-maint-de-updates
for you to fetch changes up to a9845c5f504498644abcb5f6fd6adc2ffd076f2b:
On Thu, Apr 23, 2015 at 10:47 AM, Junio C Hamano wrote:
> On Wed, Apr 22, 2015 at 3:32 PM, Jens Lehmann wrote:
>> ...
>>> But it is unclear if we should still do (2) when "subrepo/.git" is
>>> no longer there. That has to be done manually and it may be an
>>> indication that is clear enough that
Matthieu Moy writes:
> Modifying in PATCH 7 some code that you introduced in PATCH 3 is
> suspicious. Is there any reason you did not name the variable
> "terms_defined" in the first place? (i.e. squash this hunk and the other
> instance of start_bad_good into PATCH 3)
>
> (Whether this is a reth
I agree this makes no sense hardcoding old/new once bisect terms is
considerred. It would have been a lot better if we had started
implementing bisect terms immediatly (but we thought old/new would
already be an appreciable step for most of users).
--
To unsubscribe from this list: send the line "u
On Sun, Jun 14, 2015 at 5:21 PM, Sami Boukortt wrote:
>> On Sun, Jun 14, 2015 at 12:18 AM, Sami Boukortt
>> wrote:
>> > git: pathspec.c:317: prefix_pathspec: Assertion
>> > `item->nowildcard_len <= item->len && item->prefix <= item->len'
>> > failed.
>>
>> Known issue, but no one stepped up to fi
> On Sun, Jun 14, 2015 at 12:18 AM, Sami Boukortt
> wrote:
> > git: pathspec.c:317: prefix_pathspec: Assertion
> > `item->nowildcard_len <= item->len && item->prefix <= item->len'
> > failed.
>
> Known issue, but no one stepped up to fix it yet
>
> http://thread.gmane.org/gmane.comp.version-cont
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan
---
builtin/pull.c | 30 +++
b4dc085 (pull: merge into unborn by fast-forwarding from empty
tree, 2013-06-20) established git-pull's current behavior of pulling
into an unborn branch by fast-forwarding the work tree from an empty
tree to the merge head, then setting HEAD to the merge head.
Re-implement this behavior by introd
Re-implement the behavior introduced by f9189cf (pull --rebase: exit
early when the working directory is dirty, 2008-05-21).
Signed-off-by: Paul Tan
---
builtin/pull.c | 77 +-
1 file changed, 76 insertions(+), 1 deletion(-)
diff --git a/b
At the beginning of the rewrite of git-pull.sh to C, we introduced a
redirection to git-pull.sh if the environment variable
_GIT_USE_BUILTIN_PULL was not defined in order to not break test scripts
that relied on a functional git-pull.
Now that all of git-pull's functionality has been re-implemente
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cleverer with r
Specify git-merge's options in the option list, and pass any specified
options to git-merge.
These options are:
* -n, --stat, --summary: since d8abe14 (merge, pull: introduce
'--(no-)stat' option, 2008-04-06)
* --log: since efb779f (merge, pull: add '--(no-)log' command line
option, 2008-04-
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28),
fetch+rebase could be set by default by defining the config variable
branch..rebase. This setting can be overriden on the command line
by --rebase and --no-rebase.
Since 6b37dff (pull: introduce a pull.rebase option to enable --rebase,
2
f947413 (Use GIT_REFLOG_ACTION environment variable instead.,
2006-12-28) established git-pull's method for setting the reflog
message, which is to set the environment variable GIT_REFLOG_ACTION to
the evaluation of "pull${1+ $*}" if it has not already been set.
Re-implement this behavior.
Helped
Tweak the error messages printed by die_no_merge_candidates() to take
into account that we may be "rebasing against" rather than "merging
with".
Signed-off-by: Paul Tan
---
builtin/pull.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin/pull.c b/builti
Since eb2a8d9 (pull: handle git-fetch's options as well, 2015-06-02),
git-pull knows about and handles git-fetch's options, passing them to
git-fetch. Re-implement this behavior.
Since 29609e6 (pull: do nothing on --dry-run, 2010-05-25) git-pull
supported the --dry-run option, exiting after git-fe
Since b814da8 (pull: add pull.ff configuration, 2014-01-15), git-pull.sh
would lookup the configuration value of "pull.ff", and set the flag
"--ff" if its value is "true", "--no-ff" if its value is "false" and
"--ff-only" if its value is "only".
Re-implement this behavior.
Signed-off-by: Paul Tan
Implement the fetch + merge functionality of git-pull, by first running
git-fetch with the repo and refspecs provided on the command line, then
running git-merge on FETCH_HEAD to merge the fetched refs into the
current branch.
Helped-by: Junio C Hamano
Signed-off-by: Paul Tan
---
Notes:
v3
When we have a null-terminated array, it would be useful to convert it
or append it to an argv_array for further manipulation.
Implement argv_array_pushv() which will push a null-terminated array of
strings on to an argv_array.
Signed-off-by: Paul Tan
---
Documentation/technical/api-argv-array.
Certain git commands, such as git-pull, are simply wrappers around other
git commands like git-fetch, git-merge and git-rebase. As such, these
wrapper commands will typically need to "pass through" command-line
options of the commands they wrap.
Implement the parse_opt_passthru() parse-options cal
Commit a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) fully established the current advices given by git-pull for
the different cases where git-fetch will not have anything marked for
merge:
1. We fetched from a specific remote, and a refspec was given, but it
ended up n
Certain git commands, such as git-pull, are simply wrappers around other
git commands like git-fetch, git-merge and git-rebase. As such, these
wrapper commands will typically need to "pass through" command-line
options of the commands they wrap.
Implement the parse_opt_passthru_argv() parse-option
For the purpose of rewriting git-pull.sh into a C builtin, implement a
skeletal builtin/pull.c that redirects to $GIT_EXEC_PATH/git-pull.sh if
the environment variable _GIT_USE_BUILTIN_PULL is not defined. This
allows us to fall back on the functional git-pull.sh when running the
test suite for tes
7f87aff (Teach/Fix pull/fetch -q/-v options, 2008-11-15) taught git-pull
to accept the verbosity -v and -q options and pass them to git-fetch and
git-merge.
Re-implement support for the verbosity flags by adding it to the options
list and introducing argv_push_verbosity() to push the flags into th
This is a re-roll of [v2]. Thanks Junio, Stefan for the reviews last round.
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
[v2] http://thread.gmane.org/gmane.comp.version-control.git/270639
git-pull is a commonly executed command to check for new changes in
Since d38a30d (Be more user-friendly when refusing to do something
because of conflict., 2010-01-12), git-pull will error out with
user-friendly advices if the user is in the middle of a merge or has
unmerged files.
Re-implement this behavior. While the "has unmerged files" case can be
handled by
On Sun, Jun 14, 2015 at 1:42 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> +test_expect_success 'setup some history and refs' '
>> + test_commit one &&
>> + test_commit two &&
>> + test_commit three &&
>> + git checkout -b side &&
>> + test_commit four &&
>> + git c
On Sun, Jun 14, 2015 at 1:34 PM, Matthieu Moy
wrote:
> karthik nayak writes:
>
>> The previous version of the patch can be found at :
>> http://thread.gmane.org/gmane.comp.version-control.git/271423
>>
>> Changes :
>> * Removed an unnecessary commit (v7 3/12)
>> * Change a comment in 01/11 (v8)
>
On Fri, Jun 12, 2015 at 12:52:44PM +0200, Bernd Naumann wrote:
> Hello again,
>
> After digging the code I may have got a clue where to start but I
> would still appreciate some help from a developer, cause I have never
> learned to write C. (Some basics at school which happened over a
> decade a
Karthik Nayak writes:
> +test_expect_success 'setup some history and refs' '
> + test_commit one &&
> + test_commit two &&
> + test_commit three &&
> + git checkout -b side &&
> + test_commit four &&
> + git checkout master &&
> + git update-ref refs/odd/spot master
I
karthik nayak writes:
> The previous version of the patch can be found at :
> http://thread.gmane.org/gmane.comp.version-control.git/271423
>
> Changes :
> * Removed an unnecessary commit (v7 3/12)
> * Change a comment in 01/11 (v8)
And change the order of parameters in ref_filter. More precisel
On Thu, Jun 11, 2015 at 1:14 AM, Junio C Hamano wrote:
> I (or at least some part of me) actually view git_config_get_*() as
> "if you are only going to peek a few variables, you do not have to
> do the looping yourself" convenience, which leads me (or at least
> that part of me) to say "if you ar
52 matches
Mail list logo
