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 commit
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
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 Tue, Jun 9, 2015 at 11:28 PM, brian m. carlson
sand...@crustytoothpaste.net 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
On 06/10/2015 01:09 PM, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com 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
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 l...@diamand.org
Acked-by: Lex Spoon l...@lexspoon.org
---
t/t9818-git-p4-block.sh |
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
Test that git-p4 can handle a sync with a non-numeric revision
range (e.g. a date).
Signed-off-by: Luke Diamand l...@diamand.org
---
t/t9800-git-p4-basic.sh | 38 ++
1 file changed, 38 insertions(+)
diff --git a/t/t9800-git-p4-basic.sh
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 maxchanges
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 does not
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 remi.lespi...@ensimag.grenoble-inp.fr writes:
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
sand...@crustytoothpaste.net 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
Junio C Hamano gits...@pobox.com 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 +=
Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr 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
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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
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,
On Wed, Jun 10, 2015 at 7:16 AM, Junio C Hamano gits...@pobox.com 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
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 this
On Wed, Jun 10, 2015 at 9:56 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
+enum rebase_type {
+ REBASE_INVALID = -1,
+ REBASE_FALSE = 0,
+ REBASE_TRUE,
+ REBASE_PRESERVE
+};
+
+/**
+ * Parses the value of --rebase, branch.*.rebase or
Matthieu Moy matthieu@grenoble-inp.fr 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
Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr writes:
Hi,
thanks for the review,
(sorry if you received this twice)
Junio C Hamano gits...@pobox.com writes:
Just throwing a suggestion. You could perhaps add a new verb to be
used before starting to do anything, e.g.
$ git
Hi,
thanks for the review,
(sorry if you received this twice)
Junio C Hamano gits...@pobox.com 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
Louis-Alexandre Stuber stub...@ensimag.grenoble-inp.fr 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
Paul Tan pyoka...@gmail.com 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
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
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
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
sand...@crustytoothpaste.net 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
Junio C Hamano gits...@pobox.com writes:
Paul Tan pyoka...@gmail.com 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
Where it says:
Su rama está delante de origin/master para 6 commits.
it should say:
Su rama está delante de origin/master por 6 commits.
Notice para -- por.
Cheers,
Gabriel
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Hi Gabriel,
On 2015-06-10 16:51, Gabriel wrote:
Where it says:
Su rama está delante de origin/master para 6 commits.
it should say:
Su rama está delante de origin/master por 6 commits.
Notice para -- por.
Good catch.
You could earn eternal fame by cloning Git itself (e.g. via `git
On Wed, Jun 10, 2015 at 9:00 PM, Jeff King p...@peff.net 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.
Paul Tan pyoka...@gmail.com 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
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr 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
Torsten Bögershausen tbo...@web.de writes:
git checkout pathspec 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)
On 06/10/2015 12:37 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com writes:
@@ -54,7 +59,6 @@ int cmd_for_each_ref(int argc, const char **argv, const
char *prefix)
/* for warn_ambiguous_refs */
git_config(git_default_config, NULL);
-memset(ref_cbdata, 0,
Hi,
Thanks for the review !
(sorry if you received this twice)
Christian Couder christian.cou...@gmail.com wrote :
+ name_bad = bad;
+ name_good = good;
+ } else {
+ strbuf_getline(str, fp, '\n');
+ name_bad = strbuf_detach(str, NULL);
+ strbuf_getline(str, fp, '\n');
+
Hi,
Thanks for the review,
(sorry if you received this twice)
Matthieu Moy matthieu@grenoble-inp.fr 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.
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Louis-Alexandre Stuber stub...@ensimag.grenoble-inp.fr 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
Louis-Alexandre Stuber stub...@ensimag.grenoble-inp.fr 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
On Wed, Jun 10, 2015 at 5:24 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr 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
On Wed, Jun 10, 2015 at 10:44 PM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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
Paul Tan pyoka...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
+warn_file $todo.miss
I would find it more elegant with less intermediate files, like
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
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 antoine.dela...@ensimag.grenoble-inp.fr
Signed-off-by: Louis Stuber stub...@ensimag.grenoble-inp.fr
Signed-off-by:
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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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
Ed Avis e...@waniasset.com 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
Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr 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
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr 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.
Christian Couder christian.cou...@gmail.com writes:
On Wed, Jun 10, 2015 at 5:24 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Moving from one hardcoded pair of terms to two hardcoded pairs of
terms is a nice feature, but hardly a step in 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 matthieu@grenoble-inp.fr 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
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Matthieu Moy matthieu@grenoble-inp.fr 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
Stefan Beller sbel...@google.com 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] [--] path/to/file
git lock remove [branch] [--] path/to/file
git lock ls
Duy Nguyen pclo...@gmail.com 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,
On Wed, Jun 10, 2015 at 3:05 PM, Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Wed, Jun 10, 2015 at 12:16:25PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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 mhag...@alum.mit.edu
---
Hmph. Where does such a tempfile that is
Michael Haggerty mhag...@alum.mit.edu 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
#include
Michael Haggerty mhag...@alum.mit.edu 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
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 Wed, Jun 10, 2015 at 03:19:41PM -0300, bär wrote:
On Sun, Jun 7, 2015 at 9:40 AM, Jeff King p...@peff.net 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
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 jens.lehm...@web.de wrote:
Am 05.06.2015 um 01:20 schrieb Christopher Dunn:
(Seen in git versions: 2.1.0 and 1.9.3 et al.)
$
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
On 2015-06-10 17.05, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
(Need to drop Eric from CC-list(
git checkout pathspec 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
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
Michael Haggerty mhag...@alum.mit.edu 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
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
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 user.
On Sun, Jun 7, 2015 at 9:40 AM, Jeff King p...@peff.net 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
From: Louis Stuber stub...@ensimag.grenoble-inp.fr
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
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 antoine.dela...@ensimag.grenoble-inp.fr
Signed-off-by:
From: Louis Stuber stub...@ensimag.grenoble-inp.fr
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
Paul Tan pyoka...@gmail.com writes:
On Wed, Jun 10, 2015 at 10:38 PM, Junio C Hamano gits...@pobox.com 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
Am 10.06.2015 um 19:40 schrieb Junio C Hamano:
Michael Haggerty mhag...@alum.mit.edu 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()
*
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,
Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr 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
Frans Klaver franskla...@gmail.com writes:
reroll count documentation states that vn will be pretended to the
filename. Judging by the examples that should have been 'prepended'.
Signed-off-by: Frans Klaver franskla...@gmail.com
---
Good eyes; thanks.
Documentation/git-format-patch.txt |
On Wed, Jun 10, 2015 at 7:00 AM, Jeff King p...@peff.net 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.
On 06/10/2015 07:36 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
On Wed, Jun 10, 2015 at 04:25:45PM -0400, Michael Edgar wrote:
On Wed, Jun 10, 2015 at 3:05 PM, Jeff King p...@peff.net 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 4:27 PM, Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com 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
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
brian m. carlson sand...@crustytoothpaste.net 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
Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr 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
reroll count documentation states that vn will be pretended to the
filename. Judging by the examples that should have been 'prepended'.
Signed-off-by: Frans Klaver franskla...@gmail.com
---
Documentation/git-format-patch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, Jun 10, 2015 at 08:22:18AM -0700, Junio C Hamano wrote:
Bob Bell b_...@thebellsplace.com 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
Michael Haggerty mhag...@alum.mit.edu writes:
On 06/10/2015 07:36 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Paul Tan pyoka...@gmail.com 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
1 - 100 of 120 matches
Mail list logo
