On Wed, Jun 10, 2015 at 09:55:30PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > It can be useful to have grafts or replace refs for specific
> > use-cases while keeping the default "view" of the repository
> > pristine (or with a different set of grafts/replace refs).
> >
> > It is po
Mike Hommey writes:
> It can be useful to have grafts or replace refs for specific use-cases while
> keeping the default "view" of the repository pristine (or with a different
> set of grafts/replace refs).
>
> It is possible to use a different graft file with GIT_GRAFT_FILE, but while
> replace
On Wed, Jun 10, 2015 at 05:21:33PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
> > [0] https://github.com/bk2204/git.git object-id-part2
>
> No approach other than just letting reviewers fetch from there and
> taking a look is reasonable, I would think.
>
> Did you create this manu
A config option 'rebase.instructionFormat' can override the
default 'oneline' format of the rebase instruction list.
Since the list is parsed using the left, right or boundary mark plus
the sha1, they are prepended to the instruction format.
Signed-off-by: Michael Rappazzo
---
Documentation/git
It can be useful to have grafts or replace refs for specific use-cases while
keeping the default "view" of the repository pristine (or with a different
set of grafts/replace refs).
It is possible to use a different graft file with GIT_GRAFT_FILE, but while
replace refs are more powerful, they don'
Difference between v2 and v3 of this patch:
- Fixed autosquash
- Added documentation on the config options
- Added two tests to t3414 (rebase-autosquash)
Michael Rappazzo (1):
git-rebase--interactive.sh: add config option for custom instruction
format
Documentation/git-rebase.
"brian m. carlson" writes:
> On Wed, Jun 10, 2015 at 11:51:14PM +, brian m. carlson wrote:
>> On Wed, Jun 10, 2015 at 03:50:32PM -0700, Junio C Hamano wrote:
>> > "brian m. carlson" writes:
>> > > Convert struct object to object_id
>> >
>> > It seems that the last one didn't make it...
>>
On Wed, Jun 10, 2015 at 11:51:14PM +, brian m. carlson wrote:
> On Wed, Jun 10, 2015 at 03:50:32PM -0700, Junio C Hamano wrote:
> > "brian m. carlson" writes:
> > > Convert struct object to object_id
> >
> > It seems that the last one didn't make it...
>
> It appears the mail was too large
On Wed, Jun 10, 2015 at 03:50:32PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
> > Convert struct object to object_id
>
> It seems that the last one didn't make it...
It appears the mail was too large for vger. Unfortunately for
bisectability reasons, it is necessarily large. I
On 05/06, Johannes Löthberg wrote:
Each ref namespace have their own separate branches, tags, and HEAD, so
when pushing to a namespace we need to make sure that there exists a
HEAD ref for the namespace, otherwise you will not be able to check out
the repo after cloning from a namespace
Signed-o
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Somehow we are getting quite a many new topics in the past few
weeks. All the new contributors we acquired recently, including but
not limited
Paul Tan writes:
> +/**
> + * Returns remote's upstream branch for the current branch. If remote is
> NULL,
> + * the current branch's configured default remote is used. Returns NULL if
> + * `remote` does not name a valid remote, HEAD does not point to a branch,
> + * remote is not the branch's
"brian m. carlson" writes:
> The final piece in this series is the conversion of struct object to use
> struct object_id. This is a necessarily large patch because of the
> large number of places this code is used.
>
> brian m. carlson (8):
> refs: convert some internal functions to use object
Well, now it gets more complicated. I want git-p4 to ignore submodules
completely. But it fails only *only* the submodules changed. (At
least, my version fails. I'll try to diff against latest.)
But to debug this, I had to add a dry-run mode to git-p4. And I am
using a version of git-p4 which uses
Junio C Hamano writes:
> I like this change very much; it removes the mysteriously misnamed
> start-bad-good variable (because you do not really _care_ that
> 'start' was what implicitly decided that good/bad pair is the term
> we use in this session; what you care is that the terms are already
>
On Wed, Jun 10, 2015 at 4:27 PM, Jeff King wrote:
> I dunno. With respect to the original patch, I am OK if we just want to
> revert it. This area of stash seems a bit under-designed IMHO, but if
> people were happy enough with it before, I do not think the safety
> benefit from ed178ef is that gr
Frans Klaver writes:
> 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
> ---
Good eyes; thanks.
> Documentation/git-format-patch.txt | 2 +-
> 1 file changed, 1 insertion(+
Michael Haggerty writes:
> 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"
>>> #inc
On Wed, Jun 10, 2015 at 7:00 AM, 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
Antoine Delaite writes:
> -USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
> +USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
I think this patch makes the whole series go in the right direction.
I wonder if you can skip the "we
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
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
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
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
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 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
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 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
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 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
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
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
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 +++---
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
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
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
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_
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
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
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
-
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
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:
> 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:
> 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:
> 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
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
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
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
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
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
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
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
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
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
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
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
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.
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:
> 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:
> 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
> > +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
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
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 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_
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",
>>
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
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
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
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
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
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
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
'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
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
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
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
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
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
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
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
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())
>> +
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
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 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
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 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
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:
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
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
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
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
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
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'
> 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
1 - 100 of 120 matches
Mail list logo
