Hi,
Thanks for the review !
(sorry if you received this twice)
Christian Couder wrote :
>>> + name_bad = "bad";
>>> + name_good = "good";
>>> + } else {
>>> + strbuf_getline(&str, fp, '\n');
>>> + name_bad = strbuf_detach(&str, NULL);
>>> + strbuf_getline(&str, fp, '\n');
>>> + name_go
Hi,
Thanks for the review,
(sorry if you received this twice)
Matthieu Moy wrote:
>> +static const char *name_bad;
>> +static const char *name_good;
>
>Same remark as PATCH 2.
After the discussion you had with Christian I think we will
keep name_bad/good for now.
>> -
>> - fprintf(s
On Wed, Jun 10, 2015 at 7:16 AM, Junio C Hamano wrote:
> Almost the same comment as 01/19 applies to this comment.
>
> I think it makes good sense to have two variants, one that lets the
> last one win and pass only that last one (i.e. 01/19) and the other
> that accumulates them into an argv_arra
Hi,
thanks for the review,
(sorry if you received this twice)
Junio C Hamano writes:
>Just throwing a suggestion. You could perhaps add a new verb to be
>used before starting to do anything, e.g.
>
> $ git bisect terms new old
Yes it would be nice and should not be hard to implement. B
> That is very different from ENOENT, which is an expected error when
> you are not using a customized terms.
But in the current state, we are going to create bisect_terms even if
the bisection is in bad/good mode. Should we differentiate the erors
then ? and should we abort the bisection instead
Add additional tests of some corner-cases of the
--changes-block-size git-p4 parameter.
Also reduce the number of p4 changes created during the
tests, so that they complete faster.
Signed-off-by: Luke Diamand
Acked-by: Lex Spoon
---
t/t9818-git-p4-block.sh | 56
This series of patches teaches git-p4 to break up calls to the
P4 server into smaller chunks, to avoid hitting the maxresults and
maxscanrows server-side limits.
The previous iteration of this series didn't handle non-integer
P4 revision ranges (e.g. //depot/...@2014/1/1,2015/1/1).
This version n
Test that git-p4 can handle a sync with a non-numeric revision
range (e.g. a date).
Signed-off-by: Luke Diamand
---
t/t9800-git-p4-basic.sh | 38 ++
1 file changed, 38 insertions(+)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 5b56212.
The --changes-block-size handling was intended to help when
a user has a limited "maxscanrows" (see "p4 group"). It used
"p4 changes -m $maxchanges" to limit the number of results.
Unfortunately, it turns out that the "maxscanrows" and "maxresults"
limits are actually applied *before* the "-m maxc
Change the --changes-block-size git-p4 test to use an account with
limited "maxresults" and "maxscanrows" values.
These conditions are applied in the server *before* the "-m maxchanges"
parameter to "p4 changes" is applied, and so the strategy that git-p4
uses for limiting the number of changes do
Junio C Hamano writes:
> Don't do that. Always start your function like so:
>
> type funcname(args)
> {
> declarations;
>
> first statement;
> ...
Hint: create a file config.mak with this content:
$ cat config.mak
CFLAGS += -Wdeclaratio
On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote:
> Just because Git allows distributed workflows, doesn't mean we
> should only focus on being distributed IMHO.
>
> The question for content not being mergable easily pops up all
> the time. (Game/Graphics designers, documents, all thi
On Wed, Jun 10, 2015 at 9:56 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> +enum rebase_type {
>> + REBASE_INVALID = -1,
>> + REBASE_FALSE = 0,
>> + REBASE_TRUE,
>> + REBASE_PRESERVE
>> +};
>> +
>> +/**
>> + * Parses the value of --rebase, branch.*.rebase or pull.rebase. If va
Antoine Delaite writes:
>>> -
>>> - fprintf(stderr, "The merge base %s is bad.\n"
>>> - "This means the bug has been fixed "
>>> - "between %s and [%s].\n",
>>> - bad_hex, bad_hex, good_hex);
>>> -
>>> + if (!strcmp(name_bad, "bad")) {
>>> + fprintf(stderr, "The merge base %s is bad.\n"
Louis-Alexandre Stuber writes:
>> That is very different from ENOENT, which is an expected error when
>> you are not using a customized terms.
>
> But in the current state, we are going to create bisect_terms even if
> the bisection is in bad/good mode.
Which means that in normal cases, you'll e
Paul Tan writes:
> I don't see how it feels iffy.
That is largely a taste thing. And a good taste matters.
What is iffy is to use strbuf as an external interface between the
implementation of the parse_opt_pass() API function and its users.
I would expect that no users of the parse_opt_pass()
Antoine Delaite writes:
> Hi,
>
> thanks for the review,
>
> (sorry if you received this twice)
>
> Junio C Hamano writes:
>
>>Just throwing a suggestion. You could perhaps add a new verb to be
>>used before starting to do anything, e.g.
>>
>> $ git bisect terms new old
>
> Yes it would b
> Subject: Re: [PATCH 0/7] changes from last version
This is not a good subject. You want the subject to say what the series
is about.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ker
Nothing serious, but you did something weird while sending. This message
does not have a References: or an In-reply-to: field, so it breaks
threading. See how it's displayed on
http://thread.gmane.org/gmane.comp.version-control.git
Remi Lespinet writes:
> Remove leading and trailing whitespac
Remi Lespinet writes:
> As alias file formats supported by git send-email doesn't take
> whitespace into account, it is useless to consider whitespaces in
> alias name. remove leading and trailing whitespace before expanding
s/remove/Remove/
> allow to recognize strings like " alias" or "alias\
> Nothing serious, but you did something weird while sending. This message
> does not have a References: or an In-reply-to: field, so it breaks
> threading. See how it's displayed on
>
> http://thread.gmane.org/gmane.comp.version-control.git
Yes, send-email was aborted after 5/7, I realized and
Matthieu Moy writes:
> Actually, once you have this, PATCH 6/7 becomes useless, right? (at
> least, the test passes if I revert it)
> It seems to me that doing this space trimming just once, inside or right
> after split_at_commas would be clearer.
You're right, I put it twice because of there'
But ENOENT is not a normal case at all. Should we not treat it the same
way as other fopen() errors ? (either going on with default case or
returning an error)
Would :
> if (!fp) {
> die("could not read file '%s': %s",
> filename, strerror
On Tue, Jun 9, 2015 at 11:28 PM, brian m. carlson
wrote:
> diff --git a/sha1_file.c b/sha1_file.c
> index 7e38148..09f7f03 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -3173,6 +3173,11 @@ int has_sha1_file(const unsigned char *sha1)
> return find_pack_entry(sha1, &e);
> }
>
> +int
Instead of removing a line to remove the commit, you can use the
command "drop" (just like "pick" or "edit"). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a c
Check if commits were removed (i.e. a line was deleted) and print
warnings or stop git rebase depending on the value of the
configuration variable rebase.missingCommitsCheck.
This patch gives the user the possibility to avoid silent loss of
information (losing a commit through deleting the line in
Check before the start of the rebasing if the commands exists, and for
the commands expecting a SHA-1, check if the SHA-1 is present and
corresponds to a commit. In case of error, print the error, stop git
rebase and prompt the user to fix with 'git rebase --edit-todo' or to
abort.
This allows to
On 06/10/2015 01:09 PM, Matthieu Moy wrote:
Junio C Hamano writes:
> Don't do that. Always start your function like so:
>
> type funcname(args)
> {
> declarations;
>
> first statement;
> ...
Hint: create a file config.mak with this content:
On Wed, Jun 10, 2015 at 09:43:34AM +0700, Duy Nguyen wrote:
> On Tue, Jun 9, 2015 at 10:00 PM, brian m. carlson
> wrote:
> > You've increased this by 20, but you're adding 40 characters to the
> > strcpy. Are you sure that's enough?
> >
> > Also, you might consider writing this in terms of GIT_SH
Hello,
i've tested "git difftool" with -t --ext-cmd and other options to see
my diff with external tools, but it always show internal text-diff in
console. The same tests with "git mergetool" working as expected. I've
compared (nanually reviewed) git-mergetool.sh with git-difftool.pl and
see that
On Wed, Jun 10, 2015 at 04:59:58PM +0700, Duy Nguyen wrote:
> On Tue, Jun 9, 2015 at 11:28 PM, brian m. carlson
> wrote:
> > diff --git a/sha1_file.c b/sha1_file.c
> > index 7e38148..09f7f03 100644
> > --- a/sha1_file.c
> > +++ b/sha1_file.c
> > @@ -3173,6 +3173,11 @@ int has_sha1_file(const unsig
On Tue, Jun 09, 2015 at 08:46:24PM -0700, Shawn Pearce wrote:
> > This patch introduces a "quick" flag to has_sha1_file which
> > callers can use when they would prefer high performance at
> > the cost of false negatives during repacks. There may be
> > other code paths that can use this, but the
On Wed, Jun 10, 2015 at 9:00 PM, Jeff King wrote:
> On Tue, Jun 09, 2015 at 08:46:24PM -0700, Shawn Pearce wrote:
>
>> > This patch introduces a "quick" flag to has_sha1_file which
>> > callers can use when they would prefer high performance at
>> > the cost of false negatives during repacks. Ther
Junio C Hamano writes:
> Paul Tan writes:
>
>> @@ -422,6 +423,14 @@ int cmd_pull(int argc, const char **argv, const char
>> *prefix)
>>
>> parse_repo_refspecs(argc, argv, &repo, &refspecs);
>>
>> +git_config(git_default_config, NULL);
>> +
>> +if (read_cache_unmerged())
>> +
Paul Tan writes:
>> Hmph, it is somewhat surprising that we do not have such a helper
>> already. Wouldn't we need this logic to implement $branch@{upstream}
>> syntax?
>
> Right, the @{upstream} syntax is implemented by branch_get_upstream()
> in remote.c. It, however, does not check to see if t
Where it says:
Su rama está delante de < "por".
Cheers,
Gabriel
--
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
Galan Rémi writes:
> Check if commits were removed (i.e. a line was deleted) and print
> warnings or stop git rebase depending on the value of the
> configuration variable rebase.missingCommitsCheck.
>
> This patch gives the user the possibility to avoid silent loss of
> information (losing a com
Hi Gabriel,
On 2015-06-10 16:51, Gabriel wrote:
> Where it says:
>
> Su rama está delante de <
> it should say:
>
> Su rama está delante de <
> Notice "para" --> "por".
Good catch.
You could earn eternal fame by cloning Git itself (e.g. via `git clone
https://github.com/git/git), finding th
Torsten Bögershausen writes:
> git checkout can be used to revert changes in the working tree.
I somehow thought that concensus in the recent thread was that
"restore", not "revert", is the more appropriate wording?
And I think that is indeed sensible because "revert" (or "reset")
already mean
Matthieu Moy writes:
> Louis-Alexandre Stuber writes:
>
>>> That is very different from ENOENT, which is an expected error when
>>> you are not using a customized terms.
>>
>> But in the current state, we are going to create bisect_terms even if
>> the bisection is in bad/good mode.
>
> Which me
On Wed, Jun 10, 2015 at 10:38 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Paul Tan writes:
>>
>>> @@ -422,6 +423,14 @@ int cmd_pull(int argc, const char **argv, const char
>>> *prefix)
>>>
>>> parse_repo_refspecs(argc, argv, &repo, &refspecs);
>>>
>>> +git_config(git_defaul
'restore' may be more consistent with git's internal terminology.
But from an outsider's perspective, 'revert' rather than 'restore' is in my
view much clearer and more consistent with other version control systems:
for example 'svn revert' is what you use to revert files in the working copy.
The
Remi Lespinet writes:
> I agree, I'd like to put it right after split_at_commas in a separate
> function "trim_list". Is it a good idea even if the function is one
> line long ?
Hmph, if I have "A, B, C" and call a function that gives an array of
addresses, treating the input as comma-separated
Remi Lespinet writes:
> From: Jorge Juan Garcia Garcia
>
> Accept a list of emails separated by commas in flags --cc, --to and
> --bcc. Multiple addresses can already be given by using these options
> multiple times, but it is more convenient to allow cutting-and-pasting
> a list of addresses f
Galan Rémi writes:
> +# from the todolist in stdin
> +check_bad_cmd_and_sha () {
> + git stripspace --strip-comments |
> + while read -r command sha1 rest
> + do
> + case $command in
> + ''|noop|x|"exec")
> + ;;
> + pick|p|drop|d
On Wed, Jun 10, 2015 at 12:47 AM, Fredrik Gustafsson wrote:
> On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote:
>> Just because Git allows distributed workflows, doesn't mean we
>> should only focus on being distributed IMHO.
>>
>> The question for content not being mergable easily po
Bob Bell writes:
> Is this a proper solution, or did I just "luck out"? Am I perhaps
> doing something foolish?
Yes, we happen to run checkout in the index order, but that is not
something we guarantee, so you can call yourself lucky. You are
being doubly lucky that nobody in your project is c
Matthieu Moy writes:
> "Somebody else did it like that" is not a good justification. Especially
> when the previous code was not merged: the code wasn't finished.
>
> But I actually disagree with the fact that it was not the idea. The
> point of having the terms in BISECT_TERMS was precisely to b
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Louis-Alexandre Stuber writes:
>>
That is very different from ENOENT, which is an expected error when
you are not using a customized terms.
>>>
>>> But in the current state, we are going to create bisect_terms even if
>>> the bisectio
Louis-Alexandre Stuber writes:
> But ENOENT is not a normal case at all. Should we not treat it the same
> way as other fopen() errors ? (either going on with default case or
> returning an error)
>
> Would :
>
>> if (!fp) {
>> die("could not read file '%s': %s",
>>
On Wed, Jun 10, 2015 at 10:44 PM, Junio C Hamano wrote:
> Paul Tan writes:
>
>>> Hmph, it is somewhat surprising that we do not have such a helper
>>> already. Wouldn't we need this logic to implement $branch@{upstream}
>>> syntax?
>>
>> Right, the @{upstream} syntax is implemented by branch_get_
Junio C Hamano writes:
> Remi Lespinet writes:
>
>> I agree, I'd like to put it right after split_at_commas in a separate
>> function "trim_list". Is it a good idea even if the function is one
>> line long ?
>
> Hmph, if I have "A, B, C" and call a function that gives an array of
> addresses, tr
On Wed, Jun 10, 2015 at 5:24 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> "Somebody else did it like that" is not a good justification. Especially
>> when the previous code was not merged: the code wasn't finished.
>>
>> But I actually disagree with the fact that it was not the idea. The
> > +git stripspace --strip-comments |
> > +while read -r command sha1 rest
> > +do
> > +case $command in
> > +''|noop|x|"exec")
> > +;;
> > +pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
> > +
Matthieu Moy writes:
> > +warn_file "$todo".miss
>
> I would find it more elegant with less intermediate files, like
>
> git rev-list $opt <"$todo".miss | while read -r line
> do
> warn " - $line"
> done
I am not really sure since I also use warn_file to display
Remi Galan Alfonso writes:
> Matthieu Moy writes:
>> > +warn_file "$todo".miss
>>
>> I would find it more elegant with less intermediate files, like
>>
>> git rev-list $opt <"$todo".miss | while read -r line
>> do
>> warn " - $line"
>> done
>
> I am not really s
Matthieu Moy writes:
> Remi Galan Alfonso writes:
>
> > Matthieu Moy writes:
> >> > +warn_file "$todo".miss
> >>
> >> I would find it more elegant with less intermediate files, like
> >>
> >> git rev-list $opt <"$todo".miss | while read -r line
> >> do
> >> warn
Remi Galan Alfonso writes:
> It is mainly because here the SHA-1 is a long one (40 chars)
OK, but then the minimum would be to add a comment saying that.
Now, this makes me wonder why you are doing the check after the sha1
expansion and not before. Also, when running `git bisect --edit-todo`, I
Christian Couder writes:
> On Wed, Jun 10, 2015 at 5:24 PM, Junio C Hamano wrote:
>> Matthieu Moy writes:
>>>
>>> Moving from "one hardcoded pair of terms" to "two hardcoded pairs of
>>> terms" is a nice feature, but hardly a step in the right direction wrt
>>> maintainability.
>>
>> Nicely put
Matthieu Moy writes:
> Junio C Hamano writes:
>
> > Remi Lespinet writes:
> >
> >> I agree, I'd like to put it right after split_at_commas in a separate
> >> function "trim_list". Is it a good idea even if the function is one
> >> line long ?
> >
> > Hmph, if I have "A, B, C" and call a functi
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> But I do not think it is a good idea to penalize the normal case by
>> writing the terms file and reading them back from it when the user
>> is bisecting with good/bad in the first place, so
>
> No strong opinion on that, but creating one fi
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Remi Lespinet writes:
>>
>>> I agree, I'd like to put it right after split_at_commas in a separate
>>> function "trim_list". Is it a good idea even if the function is one
>>> line long ?
>>
>> Hmph, if I have "A, B, C" and call a function that
Paul Tan writes:
> so it's more or less a direct translation of the shell script, and we
> can be sure it will have the same behavior. I'm definitely in favor of
> switching this to use remote_find_tracking(), the question is whether
> we want to do it in this patch or in a future patch on top.
We create a file BISECT_TERMS in the repository .git to be read during a
bisection. The fonctions to be changed if we add new terms are quite
few.
In git-bisect.sh :
check_and_set_terms
bisect_voc
In bisect.c :
handle_bad_merge_base
Signed-off-by: Antoine Delaite
Signed-of
Signed-off-by: Antoine Delaite
---
bisect.c|2 +-
t/t6030-bisect-porcelain.sh |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bisect.c
index 10f5e57..de92953 100644
--- a/bisect.c
+++ b/bisect.c
@@ -743,7 +743,7 @@ static void handle_b
To add new tags like old/new and have keywords less confusing, the
first step is to avoid hardcoding the keywords.
The default mode is still bad/good.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
Signed-off-by: Valentin Duperray
Signed-off-by: Franck Jonas
Signed-off-by: Lucien
When not looking for a regression during a bisect but for a fix or a
change in another given property, it can be confusing to use 'good'
and 'bad'.
This patch introduce `git bisect new` and `git bisect old` as an
alternative to 'bad' and good': the commits which have a certain
property must be mar
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Hmph, if I have "A, B, C" and call a function that gives an array of
>>> addresses, treating the input as comma-separated addresses, I would
>>> expect ("A", "B", "C") to be returned from that function, instead of
Antoine Delaite writes:
>>> +get_terms () {
>>> +if test -s "$GIT_DIR/BISECT_TERMS"
>>> +then
>>> +NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
>>> +NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"
>>
>>It is sad that we need to open the file twi
Stefan Beller writes:
> I could imagine a "git lock" command which looks like this:
>
> git config lock.centralServer origin
> git config lock.defaultBranch master
>
> git lock add [branch] [--]
> git lock remove [branch] [--]
> git lock ls []
>
> And the way this is implem
Ed Avis writes:
> 'restore' may be more consistent with git's internal terminology.
> But from an outsider's perspective, 'revert' rather than 'restore' is in my
> view much clearer and more consistent with other version control systems:
> for example 'svn revert' is what you use to revert files
Sorry. I thought empty patches were made to work in other cases.
'git-p4' needs to skip these. Wrong mailing list then.
On Tue, Jun 9, 2015 at 1:52 PM, Jens Lehmann wrote:
> Am 05.06.2015 um 01:20 schrieb Christopher Dunn:
>>
>> (Seen in git versions: 2.1.0 and 1.9.3 et al.)
>>
>> $ git format-p
https://github.com/cdunn2001/git-sym
https://github.com/cdunn2001/git-sym-test/wiki/Examples
--
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
Paul Tan writes:
> On Wed, Jun 10, 2015 at 10:38 PM, Junio C Hamano wrote:
>>> If you are going to do the git_config() call yourself, it might make
>>> more sense to define git_pull_config() callback and parse the pull.ff
>>> yourself, updating the use of the lazy git_config_get_value() API you
Michael Haggerty writes:
> diff --git a/builtin/add.c b/builtin/add.c
> index df5135b..aaa9ce4 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -5,6 +5,7 @@
> */
> #include "cache.h"
> #include "builtin.h"
> +#include "tempfile.h"
> #include "lockfile.h"
> #include "dir.h"
> #includ
Michael Haggerty writes:
> Remove the following functions and rewrite their callers to use the
> equivalent tempfile functions directly:
>
> * fdopen_lock_file() -> fdopen_tempfile()
> * reopen_lock_file() -> reopen_tempfile()
> * close_lock_file() -> close_tempfile()
Hmph,
My knee-jerk reacti
Michael Haggerty writes:
> Add several functions for creating temporary files with
> automatically-generated names, analogous to mkstemps(), but also
> arranging for the files to be deleted on program exit.
>
> The functions are named according to a pattern depending how they
> operate. They will
Michael Haggerty writes:
> Allow an existing file to be registered with the tempfile-handling
> infrastructure; in particular, arrange for it to be deleted on program
> exit.
>
> Signed-off-by: Michael Haggerty
> ---
Hmph. Where does such a tempfile that is not on list come from?
Puzzled, but
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> read-cache.c | 37 +
> 1 file changed, 5 insertions(+), 32 deletions(-)
Nicely done.
>
> diff --git a/read-cache.c b/read-cache.c
> index 3e49c49..4f7b70f 100644
> --- a/read-cache.c
> +++ b
The environment variable GIT_PS1_STATESEPARATOR can be used to set the
separator between the branch name and the state symbols in the prompt.
At present the variable is not mentioned in the inline documentation which
makes it difficult for the casual user to identify.
Signed-off-by: Joe Cridge
-
On Sun, Jun 7, 2015 at 9:40 AM, Jeff King wrote:
> Hrm. The new protection in v2.4.2 is meant to prevent you from losing
> your index state during step 4 when we run into a conflict. But here you
> know something that git doesn't: that we just created the stash based on
> this same state, so it sh
On 2015-06-10 17.05, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
(Need to drop Eric from CC-list(
>> git checkout can be used to revert changes in the working tree.
>
> I somehow thought that concensus in the recent thread was that
> "restore", not "revert", is the more appropriate
Am 10.06.2015 um 19:40 schrieb Junio C Hamano:
Michael Haggerty writes:
Remove the following functions and rewrite their callers to use the
equivalent tempfile functions directly:
* fdopen_lock_file() -> fdopen_tempfile()
* reopen_lock_file() -> reopen_tempfile()
* close_lock_file() -> close_
Michael Haggerty writes:
> These patches are also available from my GitHub repo [2], branch
> "tempfile".
Overall the series made a lot of sense.
On a few points I raised:
- I still think that exposing the implementation detail of the
lockfile API that it builds on tempfile API is going ba
When the user passes --depth to git-clone the server's capabilities are
not currently consulted. The client will send shallow requests even if
the server does not understand them, and the resulting error may be
unhelpful to the user. This change pre-emptively checks so git-clone can
exit with a hel
On Wed, Jun 10, 2015 at 03:19:41PM -0300, bär wrote:
> On Sun, Jun 7, 2015 at 9:40 AM, Jeff King wrote:
> > Hrm. The new protection in v2.4.2 is meant to prevent you from losing
> > your index state during step 4 when we run into a conflict. But here you
> > know something that git doesn't: that
From: Louis Stuber
The function reads BISECT_TERMS and stores it at the adress given in
parameters (instead of global variables name_bad and name_good).
This allows to use the function outside bisect.c.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
---
bisect.c | 15 +++---
Introduction of the git bisect terms function.
The user can set its own terms.
List of known commands not available :
`git bisect replay`
`git bisect terms term1 term2
then
git bisect start bad_rev good_rev`
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
---
Documentation/git-bisec
From: Louis Stuber
Calling git rev-list --bisect when an old/new mode bisection was started
shows the help notice. This has been fixed by reading BISECT_TERMS in
revision.c to find the correct bisect refs path (which was always
refs/bisect/bad (or good) before and can be refs/bisect/new (old) now
On Wed, Jun 10, 2015 at 02:35:20PM -0400, Mike Edgar wrote:
> When the user passes --depth to git-clone the server's capabilities are
> not currently consulted. The client will send shallow requests even if
> the server does not understand them, and the resulting error may be
> unhelpful to the us
Jeff King writes:
> So I am trying to figure out what the use case here is. Clearly the
> above is a toy case, but why is "stash -k" followed by a quick pop
> useful in general? Certainly I use "stash" (without "-k") and a quick
> pop all the time, and I think that is what stash was designed for.
On Wed, Jun 10, 2015 at 12:16:25PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I am trying to figure out what the use case here is. Clearly the
> > above is a toy case, but why is "stash -k" followed by a quick pop
> > useful in general? Certainly I use "stash" (without "-k") and a
Duy Nguyen writes:
> On Sun, May 31, 2015 at 07:16:29PM -0400, Spencer Baugh wrote:
>> --- a/builtin/checkout.c
>> +++ b/builtin/checkout.c
>> @@ -1237,6 +1237,7 @@ static int parse_branchname_arg(int argc, const char
>> **argv,
>> char *head_ref = resolve_refdup("HEAD", 0, sha1, &f
> On Wed, Jun 10, 2015 at 3:05 PM, Jeff King wrote:
> I see that do_fetch_pack checks server_supports("shallow"). Is that
> enough to cover all fetch cases? And if it is, why does it not cover the
> matching clone cases?
> -Peff
Great question. I determined that the do_fetch_pack logic doesn't wo
On Wed, Jun 10, 2015 at 04:25:45PM -0400, Michael Edgar wrote:
> > On Wed, Jun 10, 2015 at 3:05 PM, Jeff King wrote:
> > I see that do_fetch_pack checks server_supports("shallow"). Is that
> > enough to cover all fetch cases? And if it is, why does it not cover the
> > matching clone cases?
> > -
On Wed, Jun 10, 2015 at 08:22:18AM -0700, Junio C Hamano wrote:
> Bob Bell writes:
> > Is this a proper solution, or did I just "luck out"? Am I perhaps
> > doing something foolish?
>
> Yes, we happen to run checkout in the index order, but that is not
> something we guarantee, so you can call y
On 06/10/2015 07:36 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> diff --git a/builtin/add.c b/builtin/add.c
>> index df5135b..aaa9ce4 100644
>> --- a/builtin/add.c
>> +++ b/builtin/add.c
>> @@ -5,6 +5,7 @@
>> */
>> #include "cache.h"
>> #include "builtin.h"
>> +#include "tempfile
reroll count documentation states that v will be pretended to the
filename. Judging by the examples that should have been 'prepended'.
Signed-off-by: Frans Klaver
---
Documentation/git-format-patch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-format-p
Antoine Delaite writes:
> Related discussions:
>
> - http://thread.gmane.org/gmane.comp.version-control.git/86063
> introduced bisect fix unfixed to find fix.
> - http://thread.gmane.org/gmane.comp.version-control.git/182398
> discussion around bisect yes/n
On 10/06/15 18:04, Christopher Dunn wrote:
Sorry. I thought empty patches were made to work in other cases.
'git-p4' needs to skip these. Wrong mailing list then.
Possibly the right mailing list - can you explain what you mean here
w.r.t git-p4 please?
Thanks!
Luke
On Tue, Jun 9, 2015
1 - 100 of 120 matches
Mail list logo
