On 04/11/2016 12:59 AM, Ramsay Jones wrote:
The header mentions cygwin, but changes it for linux, BSD and Mac OS as
well.
Is this intentional ?
Signed-off-by: Ramsay Jones
---
git-compat-util.h | 17 -
index-helper.c| 4 ++--
read-cache.c | 2 +-
3 files changed
On 04/11/2016 01:03 AM, Ramsay Jones wrote:
It took me a few minutes to convince myself that, if index-helper is
the only writer for the symlink, that the call to readlink would
result in a properly NULL terminated string. This relies on the
Minor nit:
s/NULL/NUL/
--
To unsubscribe from this l
We can set format.base=auto to record the base commit info automatically,
it is equivalent to set --base=auto in cmdline.
The format.base has lower priority than command line option, so if user
set format.base=auto and pass the command line option in the meantime,
base_commit will be the one passe
Introduce --base=auto to record the base commit info automatically, the
base_commit will be the merge base of tip commit of the upstream branch
and revision-range specified in cmdline.
Helped-by: Junio C Hamano
Helped-by: Wu Fengguang
Signed-off-by: Xiaolong Ye
---
Documentation/git-format-pat
Make commit_patch_id() available to other builtins.
Helped-by: Junio C Hamano
Signed-off-by: Xiaolong Ye
---
patch-ids.c | 2 +-
patch-ids.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/patch-ids.c b/patch-ids.c
index b7b3e5a..a4d0016 100644
--- a/patch-ids.c
+++ b/patc
Maintainers or third party testers may want to know the exact base tree
the patch series applies to. Teach git format-patch a '--base' option
to record the base tree info and append it at the end of the_first_
message(either the cover letter or the first patch in the series).
The base tree info co
V4 mainly addresses Junio's comments on V3, Changes include:
- Polish up the documentation to make output files git-format-patch.1 and
git-format-patch.html more sensible.
- Add error handling when base commit is not ancestor of revision list
specified in cmdline.
- Specify topo order t
On Sun, Apr 10, 2016 at 11:46:10AM -0700, Junio C Hamano wrote:
> > --- a/Documentation/merge-options.txt
> > +++ b/Documentation/merge-options.txt
> > @@ -89,8 +89,10 @@ option can be used to override --squash.
> >
> > --verify-signatures::
> > --no-verify-signatures::
> > - Verify that the
On Sun, Apr 10, 2016 at 9:47 AM, Torsten Bögershausen wrote:
> On 10.04.16 15:18, Stephan Beyer wrote:
>> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
>> @@ -10,36 +10,34 @@ exec > + if [ -f "$_file" ]; then
> I know that the old code did the same, is there a chance
>
On Sun, Apr 10, 2016 at 9:18 AM, Stephan Beyer wrote:
> test_cmp_rev() took exactly two parameters, the expected revision
> and the revision to test. This commit generalizes this function
> such that it takes any number of at least two revisions: the
> expected one and a list of actual ones. The f
On Sun, Apr 10, 2016 at 9:18 AM, Stephan Beyer wrote:
> test_cmp_rev() from t/test-lib-functions.sh is used to make many
> tests clearer.
>
> Signed-off-by: Stephan Beyer
> ---
> diff --git a/t/t3310-notes-merge-manual-resolve.sh
> b/t/t3310-notes-merge-manual-resolve.sh
> @@ -537,8 +537,8 @@ EO
It took me a few minutes to convince myself that, if index-helper is
the only writer for the symlink, that the call to readlink would
result in a properly NULL terminated string. This relies on the
initialization of the address variable setting each byte of the
'struct sockaddr_un' to zero and the
see commit eddda371 ("convert strncpy to memcpy", 24-09-2015).
Signed-off-by: Ramsay Jones
---
index-helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/index-helper.c b/index-helper.c
index 4a8e2ae..00f286a 100644
--- a/index-helper.c
+++ b/index-helper.c
@@ -317,7 +31
Signed-off-by: Ramsay Jones
---
git-compat-util.h | 17 -
index-helper.c| 4 ++--
read-cache.c | 2 +-
3 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 0e35c13..c90c8c6 100644
--- a/git-compat-util.h
+++ b/git-
Hi David, Duy,
If you need to re-roll your 'dt/index-helper' branch, could you please
consider squashing these patches into the relevant patch (equivalent to
commit 12909da4 ("index-helper: new daemon for caching index and related
stuff", 06-04-2016)).
The above commit causes the cygwin build to
On Sun, Apr 10, 2016 at 3:01 PM, Junio C Hamano wrote:
> Subject: t1020: do not overuse printf and use write_script
>
> The test prepares a sample file "dir/two" with a single incomplete
> line in it with "printf", and also prepares a small helper script
> "diff" to create a file with a single inc
On 04/10/2016 09:16 PM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Portabily:
>> Since yesterday/yesterweek the usage of hard-coded
>> #!/bin/sh had shown to be problematic
>
> That is not a new revelation, though ;-) It is just that these are
> problematic to those on minority pl
Torsten Bögershausen writes:
> Portabily:
> Since yesterday/yesterweek the usage of hard-coded
> #!/bin/sh had shown to be problematic
That is not a new revelation, though ;-) It is just that these are
problematic to those on minority platforms, and by definition they
are noticed only when a ver
Junio C Hamano writes:
> I looked at
>
> $ git grep -c '#! */bin/sh' t | grep -v ':1$'
>
> and did a few just for fun. Doing it fully may be a good
> microproject for next year ;-)
>
> t/t1020-subdirectory.sh | 6 +++---
> t/t2050-git-dir-relative.sh | 11 ++-
> t/t3404-reb
The Fox in the Shell writes:
> Hi,
>
> I encountered some issues with the git documentation while modifying
> my deployment scripts to enforce that the tree being fetched was
> signed by a trusted key.
>
> It was unclear which commits needed to be signed (in the case of `git
> merge`) and what we
Felix Ruess writes:
> Thanks a lot!
> Tested the patch and it works as expected :-)
Thanks, lets do this, then.
-- >8 --
Subject: [PATCH] http: differentiate socks5:// and socks5h://
Felix Ruess noticed that with configuration
$ git config --global 'http.proxy=socks5h://127.0.0.1:1080'
Vasco Almeida writes:
> Some translations might also translate "" and "".
This offers an interesting observation that I didn't think of while
reviewing the first round of this series.
Do translations want to translate "remote" and "branch" without the
""? Or is it better to allow translations
On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:
> What I meant is that we could create new options called maybe
> trailer.autocommands and trailer..autocommands that default to
> 'true' and if 'false' the command would not be run automatically and
> the corresponding trailer would
From: "Karthik Nayak"
Hello,
On Sun, Apr 10, 2016 at 8:47 PM, Victor Porton wrote:
I have three branches: master, prerelease, and devel.
Suppose now we are in master.
I often run the following command (in fact it is an alias, to save
typing):
git push && git checkout prerelease && git merg
On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:
> On Sun, Apr 10, 2016 at 11:32 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 06, 2016 at 10:28:21PM -0400, Christian Couder wrote:
> >> On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin wrote:
> >> > On Wed, Apr 06, 2016 at 10:42
On Sun, Apr 10, 2016 at 11:32 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 06, 2016 at 10:28:21PM -0400, Christian Couder wrote:
>> On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin wrote:
>> > On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:
>> >> "Michael S. Tsirkin" writes:
>>
Hello,
On Sun, Apr 10, 2016 at 8:47 PM, Victor Porton wrote:
> I have three branches: master, prerelease, and devel.
>
> Suppose now we are in master.
>
> I often run the following command (in fact it is an alias, to save
> typing):
>
> git push && git checkout prerelease && git merge master && g
On Wed, Apr 06, 2016 at 10:28:21PM -0400, Christian Couder wrote:
> On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin wrote:
> > On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wr
I have three branches: master, prerelease, and devel.
Suppose now we are in master.
I often run the following command (in fact it is an alias, to save
typing):
git push && git checkout prerelease && git merge master && git push &&
git checkout devel && git merge prerelease && git push && git che
On Thu, Apr 07, 2016 at 10:34:51AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > No - but then I will need to re-run mailinfo to parse the result,
> > will I not?
>
> By the way, I suspect (if Christian did his implementation right
> when he did interpret-trailers) all these
This is a simple script that I use by piping
incoming mail with an ack to it.
It produces an empty ack commit suitable for
squshing with git rebase -i -autosquash.
Works best if people ack individual commits: you simply
pipe each ack to git ack, before pushing your branch,
rebase.
Some people ack
This implements a new ack! action for git rebase -i
It is essentially a middle ground between fixup! and squash!:
- commits are squashed silently without editor being started
- commit logs are concatenated (with action line being discarded)
- because of the above, empty commits aren't discarded,
This is a repost after rebasing, and addressing comments by Eric Sunshine and
Fabian Ruch. I'd like to try getting this upstream so I can stop maintaining
it. So reposting - rebased to latest master, with a better motivation in the
cover letter.
As a maintainer, I get patches by mail, then
acked
document ack! behaviour and use
Signed-off-by: Michael S. Tsirkin
---
Documentation/git-rebase.txt | 45 +++-
1 file changed, 40 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0387b40..257d75c
test ack! handling
Signed-off-by: Michael S. Tsirkin
---
t/t3415-rebase-autosquash.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh
index 8f53e54..e78897d 100755
--- a/t/t3415-rebase-autosquash.sh
+++ b/t/t3415-re
On 10.04.16 15:18, Stephan Beyer wrote:
Some nit-comments inline
> ---
> t/t6030-bisect-porcelain.sh | 167
> ++--
> 1 file changed, 85 insertions(+), 82 deletions(-)
>
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 05bc6
This commit gets rid of the O(#commits) extra overhead of
the best_bisection() function.
Signed-off-by: Stephan Beyer
---
Notes:
I made the best_bisection structure be allocated on the heap
because it will get free()d when the code is invoked by
git rev-list --bisect ... The old code
The documentation says that when the maximum possible distance
is found, the algorithm stops immediately. That feature is
reestablished by this commit.
Signed-off-by: Stephan Beyer
---
Notes:
I plugged a memory leak here.
bisect.c | 18 +-
1 file changed, 13 insertions(+),
clear_distance() was a O(#commits)-time function to clear the COUNTED
flag from commits counted in count_distance().
The functions count_distance() and clear_distance() were called for
each merge commit.
This commit gets rid of the clear_distance() function by making
count_distance() use unique ma
We introduce the concept of rising and falling distances
(in addition to a halfway distance).
This will be useful in subsequent commits.
Signed-off-by: Stephan Beyer
---
bisect.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/bisect.c b/bi
The idea is to reverse the DAG and perform a traversal
starting on all sources of the reversed DAG.
We walk from the bottom commits, incrementing the weight while
walking on a part of the graph that is single strand of pearls,
or doing the "count the reachable ones the hard way" using
compute_weig
test_cmp_rev() from t/test-lib-functions.sh is used to make many
tests clearer.
Signed-off-by: Stephan Beyer
---
Notes:
This change is in some way independent of the bisect topic but
the next patch is based on this (for t6030).
t/t2012-checkout-last.sh | 8 ++--
t/t33
It makes no sense that the argument for count_distance() and
halfway() is a commit list when only its first commit is relevant.
Signed-off-by: Stephan Beyer
---
bisect.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/bisect.c b/bisect.c
index 4209c75..2c1102
Signed-off-by: Stephan Beyer
---
bisect.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/bisect.c b/bisect.c
index 2c1102f..cfd406c 100644
--- a/bisect.c
+++ b/bisect.c
@@ -38,6 +38,14 @@ static inline struct node_data *node_data(struct commit
*elem)
Signed-off-by: Stephan Beyer
---
bisect.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/bisect.c b/bisect.c
index 7996c29..901e4d3 100644
--- a/bisect.c
+++ b/bisect.c
@@ -984,6 +984,8 @@ int bisect_next_all(const char *prefix, int no_checkout)
exit(10);
}
+
If DEBUG_BISECT is set to 1, bisect does not only show debug
information but also changes the algorithm behavior: halfway()
is always false.
This commit makes the algorithm independent of DEBUG_BISECT.
Signed-off-by: Stephan Beyer
---
bisect.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Setting the macro DEBUG_BISECT to 1 enables debugging information
for the bisect algorithm. The code did not compile due to struct
changes.
Signed-off-by: Stephan Beyer
---
bisect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 901e4d3..2f54d
Let us use the term "weight" for the number of ancestors
of each commit, and "distance" for the number
min{weight, #commits - weight}. (Bisect finds the commit
with maximum distance.)
In these terms, "count_distance()" is the wrong name of
the function. So it is renamed to "compute_weight()",
and
Now that the documentation talks about bisecting without a good commit
being known, this should also be allowed for "git bisect run".
Signed-off-by: Stephan Beyer
---
Notes:
This is a new patch in the patchset.
git-bisect.sh | 17 -
1 file changed, 12 insertions(+), 5 delet
Hi,
a long time ago[1] I sent the first version of this patchset
to the list. Since then I wrote different variants of the algorithm,
fixed some bugs, made the tests work ;), and finally performed some
performance tests to pick the best version of the different variants.
For the performance tests
The total number of commits in a bisect process is a property of
the bisect process. Making this property global helps to make the code
clearer.
Signed-off-by: Stephan Beyer
---
bisect.c | 74 ++--
1 file changed, 39 insertions(+), 35 d
This is a preparation for subsequent changes.
During a bisection process, we want to augment commits with
further information to improve speed.
Signed-off-by: Stephan Beyer
---
bisect.c | 61 ++---
1 file changed, 30 insertions(+), 31 delet
The bisect algorithm allows different outcomes if, for example,
the number of commits between a good and a bad commit is even.
The current test relies on a specific behavior (for example,
the behavior of the halfway() implementation). By disabling
halfway(), some skip tests fail although the algori
test_cmp_rev() took exactly two parameters, the expected revision
and the revision to test. This commit generalizes this function
such that it takes any number of at least two revisions: the
expected one and a list of actual ones. The function returns true
if and only if at least one actual revisio
This is a preparation commit with copy-and-paste involved.
The function do_find_bisection() is changed and copied to
two almost similar functions compute_all_weights() and
compute_relevant_weights().
The function compute_relevant_weights() stops when a
"halfway" commit is found.
To keep the code
Mention `bisect next` in the documentation of bisect.
`bisect next` is only useful in rare cases and the result
can also be accomplished using other utilities (like reflog).
However, it is available as a bisect command and should hence be
documented.
Also mention the use case when no good commit i
Signed-off-by: Stephan Beyer
---
Notes:
Based on the review by Christian Couder, I use test_cmp_rev()
instead of non-standard test ... -o ...
t/t8010-bisect-algorithm.sh | 155
1 file changed, 155 insertions(+)
create mode 100755 t/t8010-bis
Large repositories with a huge amount of merge commits in the
bisection process could lead to stack overflows in git bisect.
In order to prevent this, this commit uses an *iterative* version
for counting the number of ancestors of a commit.
Signed-off-by: Stephan Beyer
---
bisect.c | 55
58 matches
Mail list logo
