On Mon, 23 May 2016, Thaina Yu wrote:
> git should have REST api and able to work with command from remote
> place (and also localhost)
you should write and contribute it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
git should have REST api and able to work with command from remote
place (and also localhost)
--
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 Sun, May 22, 2016 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> This should address all of Eric's comments (thanks!). An extra change
> I made is free_worktrees() at the end of {,un}lock_worktree() to avoid
> leaking. This series depends on nd/worktree-cleanup-post-head-protection.
Thanks, this ad
On Sun, May 22, 2016 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -500,6 +501,37 @@ static int lock_worktree(int ac, const char **av, const
> char *prefix)
> +static int unlock_worktree(int ac, con
On Sun, May 22, 2016 at 7:32 PM, Eric Sunshine wrote:
> On Sun, May 22, 2016 at 5:33 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> @@ -467,6 +467,8 @@ int cmd_worktree(int ac, const char **av, const char
>> *prefix)
>> if (ac < 2)
>> usage_with_options(worktree_usage, options);
>
On Sun, May 22, 2016 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> Helped-by: Eric Sunshine
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -150,7 +161,8 @@ instead.
>
> To prevent a $GIT_DIR/worktrees entry from being
On 05/22/2016 10:03 AM, Mike Hommey wrote:
On Sun, May 22, 2016 at 08:07:05AM +0200, Torsten Bögershausen wrote:
On 22.05.16 01:17, Mike Hommey wrote:
Signed-off-by: Mike Hommey
---
connect.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/connect.c b/connect.c
index c53f3f1..caa2
On Sun, May 22, 2016 at 6:31 AM, Duy Nguyen wrote:
> On Mon, May 16, 2016 at 7:09 AM, Eric Sunshine
> wrote:
>>> + old_reason = is_worktree_locked(wt);
>>> + if (old_reason) {
>>> + if (*old_reason)
>>> + die(_("already locked, reason: %s"), old_re
On Sun, May 22, 2016 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> So far we haven't needed to identify an existing worktree from command
> line. Future commands such as lock or move will need it. There are of
> course other options for identifying a worktree, for example by branch
> or even by intern
On Sun, May 22, 2016 at 5:53 AM, Duy Nguyen wrote:
> On Fri, May 13, 2016 at 11:52 PM, Eric Sunshine
> wrote:
>> Actually, I recall that when I suggested the idea of 'struct worktree'
>> and get_worktrees() to Mike that it would be natural for the structure
>> to have a 'locked' (or 'locked_reas
On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote:
> That is, I wonder if the above can become something like:
>
>> From github.com:pclouds/git
>> * [new branch] { -> pclouds/}2nd-index
>> * [new branch] { -> pclouds/}3nd-index
>> * [new branch] { -> pclouds/}file-watcher
>>
On Sun, May 22, 2016 at 6:43 AM, Nguyễn Thái Ngọc Duy wrote:
> So far we haven't needed to identify an existing worktree from command
> line. Future commands such as lock or move will need it. There are of
> course other options for identifying a worktree, for example by branch
> or even by intern
larsxschnei...@gmail.com writes:
> Junio usually pushes many commits at once to the public "pu"/"next"/
> "master" branches. If a test fails then it is not obvious what commit
> caused the failure. Therefore we run Git bisect with the merge base
> between the failing rev and its more stable branch
On Sun, May 22, 2016 at 5:33 AM, Nguyễn Thái Ngọc Duy wrote:
> This is mostly commit message update plus
>
> - dropping "--force" from the completion patch (a comment from Szeder
>Gabor in a previous attempt of worktree completion support).
>
> - the removal of clear_worktree() patch.
>
> I
On Sun, May 22, 2016 at 8:44 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>> For what it's worth I agree with you and disagree with Eric here and
>> Junio in the "[PATCH 03/21] i18n: advice: internationalize message for
>> conflicts" thread.
>>
>> Of course there's a trade-off in s
Pierre-François CLEMENT gmail.com> writes:
> 2014-06-10 17:27 GMT+02:00 David Kastrup gnu.org>:
>> Pierre-François CLEMENT gmail.com> writes:
>>
>>> ...
>>>
>>> Hm I see. Even though the documentation doesn't make it very clear
>>> about what happens to such files, it turns out the scenario we
>
Nguyễn Thái Ngọc Duy writes:
> Currently fetch hard-codes the "remote" column to be 10. For repos
> with long branch names, the output could look ugly like this
>
> From github.com:pclouds/git
> * [new branch] 2nd-index -> pclouds/2nd-index
> * [new branch] 3nd-index -> pclouds/3nd
Ævar Arnfjörð Bjarmason writes:
> For what it's worth I agree with you and disagree with Eric here and
> Junio in the "[PATCH 03/21] i18n: advice: internationalize message for
> conflicts" thread.
>
> Of course there's a trade-off in source code verbosity when you have
> to change every occurance
On Sun, May 22, 2016 at 5:33 AM, Nguyễn Thái Ngọc Duy wrote:
> This also makes slash conversion always happen on Windows (a side effect
> of prefix_filename). Which is a good thing.
Selling this patch as a mere simplification seems misguided
(especially as it's subjective whether this is indeed s
Lars Schneider wrote:
> > On 19 May 2016, at 19:11, Junio C Hamano wrote:
> > Eric Wong writes:
> >
> >> Anyways, how about making the tests run on separate ports and
> >> not worry about serializing them at all?
> >
> > Yeah, that does sound like a more sensible approach.
>
> Makes sense. Ho
INTRODUCTION ==
The purpose of this project is to convert the git-bisect utility which
partly exists in the form of shell scripts to C code so as to make it more
portable. I plan to do this by converting each function to C and then
calling it
Hey Matthieu,
Sorry for the late reply. Somehow your email didn't receive my
mailbox. I got to see this mail when I was going through the gmane
archives.
Matthieu Moy grenoble-inp.fr> writes:
Pranit Bauva gmail.com> writes:
>> +int bisect_voc(const char *term)
>> +{
>> + if (!strcmp(term, "ba
This is actually worse than I thought; when git is being run with a
detached work tree, GIT_INDEX_FILE is treated as a path relative to CWD,
instead of the normal behavior of relative the top of the work tree.
Normal and expected (according to this thread anyway):
joey@darkstar:~/src/other/git/Do
Hey Lars,
On Sun, May 22, 2016 at 4:30 PM, wrote:
> From: Lars Schneider
>
> Junio usually pushes many commits at once to the public "pu"/"next"/
> "master" branches. If a test fails then it is not obvious what commit
> caused the failure. Therefore we run Git bisect with the merge base
> betwe
> On 22 May 2016, at 17:35, Christian Couder wrote:
>
> On Sun, May 22, 2016 at 1:00 PM, wrote:
>
> [...]
>
>> +#
>> +# Run Git bisect
>> +#
>> +run_bisect () {
>> + TEST_SCRIPT=$1
>> + BAD_REV=$2
>> + GOOD_RV=$3
>> + TMPDIR=$(mktemp -d -t "ci-report-bisect-XX" 2>
On Sun, May 22, 2016 at 1:00 PM, wrote:
[...]
> +#
> +# Run Git bisect
> +#
> +run_bisect () {
> + TEST_SCRIPT=$1
> + BAD_REV=$2
> + GOOD_RV=$3
> + TMPDIR=$(mktemp -d -t "ci-report-bisect-XX" 2>/dev/null)
> + cat > "$TMPDIR/bisect-run.sh" < +
> +EOF
> + c
On Fri, May 20, 2016 at 4:25 AM, Stefan Beller wrote:
>> My take is to pretend sparse checkout does not exist at all and then
>> go from there ;-)
Hehe.. shameless plug, narrow checkout [1] should be its great
successor where everything is done right (famous last words). Maybe I
can convince Stef
I recently got a taste of a busy github repository where many branches
are created (for Pull Requests) every day. Because branch names should
be descriptive, branch names could range from 10 to 60 chars long.
This makes "git fetch" output really messy.
So I resurrect a patch (1/2) I sent two years
A flaw with the previous patch is, if there is a single long ref name,
the rest of the ref list will be aligned with the big column, wasting
lots of space (and potentially be wrapped around by the terminal, making
it even harder to read).
This patch tries to mitigate that. If there are five consec
Currently fetch hard-codes the "remote" column to be 10. For repos
with long branch names, the output could look ugly like this
>From github.com:pclouds/git
* [new branch] 2nd-index -> pclouds/2nd-index
* [new branch] 3nd-index -> pclouds/3nd-index
* [new branch] file-watcher -
On UNIX, when there is no prefix, prefix_filename() returns the input string
as-is. Avoiding it only makes sense before 9e5f5d4 (prefix_filename():
safely handle the case where pfx_len=0 - 2010-10-17) because the function
back then could try to dereference a NULL pointer.
On Windows, even when the
From: Lars Schneider
Move the code and adjust it to the Git shell script coding guidelines.
Signed-off-by: Lars Schneider
---
.travis.yml | 12 +---
ci/test-report.sh | 19 +++
2 files changed, 20 insertions(+), 11 deletions(-)
create mode 100755 ci/test-report.s
From: Lars Schneider
The verbose output clutters the Travis CI webview and is not really
useful since test debugging usually happens on a local machine.
Signed-off-by: Lars Schneider
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
i
From: Lars Schneider
This patch series run Git bisect on failing tests on Travis CI.
Example output on Travis CI:
https://travis-ci.org/larsxschneider/git/jobs/132049871
Plaintext example output:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/132049871/log.txt
Please scroll all the way do
From: Lars Schneider
Junio usually pushes many commits at once to the public "pu"/"next"/
"master" branches. If a test fails then it is not obvious what commit
caused the failure. Therefore we run Git bisect with the merge base
between the failing rev and its more stable branch ("next" for "pu",
This provides an API for checking if a worktree is locked. We need to
check this to avoid double locking a worktree, or try to unlock one when
it's not even locked.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
worktree.c | 21 +
worktree.h | 6 ++
2 files changed, 27 insertio
Main worktree _is_ different. You can lock a linked worktree but not the
main one, for example. Provide an API for checking that.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
worktree.c | 5 +
worktree.h | 5 +
2 files changed, 10 insertions(+)
diff --git a/worktree.c b/worktree.c
index c5d4
This should address all of Eric's comments (thanks!). An extra change
I made is free_worktrees() at the end of {,un}lock_worktree() to avoid
leaking. This series depends on nd/worktree-cleanup-post-head-protection.
Interdiff
-- 8< --
diff --git a/Documentation/git-worktree.txt b/Documentation/git-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-worktree.txt | 5 +
builtin/worktree.c | 34 ++
contrib/completion/git-completion.bash | 2 +-
t/t2028-worktree-move.sh | 14 ++
4 files changed, 5
Helped-by: Eric Sunshine
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-worktree.txt | 22 ++
builtin/worktree.c | 43 +++
contrib/completion/git-completion.bash | 5 +++-
t/t2028-worktree-move.sh (new +x) | 54
So far we haven't needed to identify an existing worktree from command
line. Future commands such as lock or move will need it. There are of
course other options for identifying a worktree, for example by branch
or even by internal id. They may be added later if proved useful.
Helped-by: Eric Suns
(the answer to rest of your questions is "yes you're right, will fix"
or something along that line so I will not quote them here)
On Mon, May 16, 2016 at 7:09 AM, Eric Sunshine wrote:
>> + old_reason = is_worktree_locked(wt);
>> + if (old_reason) {
>> + if (*old_reason)
> On 19 May 2016, at 19:11, Junio C Hamano wrote:
>
> Eric Wong writes:
>
>> Anyways, how about making the tests run on separate ports and
>> not worry about serializing them at all?
>
> Yeah, that does sound like a more sensible approach.
Makes sense. However, it's not something I will tack
On Fri, May 13, 2016 at 11:52 PM, Eric Sunshine wrote:
> Actually, I recall that when I suggested the idea of 'struct worktree'
> and get_worktrees() to Mike that it would be natural for the structure
> to have a 'locked' (or 'locked_reason') field, in which case the
> reason could be stored there
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index aaee0e2..b53f802 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -262,7 +262,7 @@ static int add_worktree(const
This also makes slash conversion always happen on Windows (a side effect
of prefix_filename). Which is a good thing.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/worktree.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index b53
This is mostly commit message update plus
- dropping "--force" from the completion patch (a comment from Szeder
Gabor in a previous attempt of worktree completion support).
- the removal of clear_worktree() patch.
I keep the completion patch anyway even though two versions of it were
poste
strbuf is a bit overkill for this function. What we need is to call
absolute_path() twice and make sure the second call does not destroy the
result of the first. One buffer allocation is enough.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
worktree.c | 16 +++-
1 file changed, 7 insertion
This is probably not the best order. But it makes it no-brainer to know
where to insert new commands. At some point we might want to reorder at
least the synopsis part again, grouping commonly use subcommands together.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-worktree.txt | 10 +
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/worktree.c | 2 +-
worktree.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index bf80111..aaee0e2 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -95,7 +95,7 @@ st
This adds bare-bone completion support for git-worktree. More advanced
completion (e.g. ref completion in git-worktree-add) can be added later.
--force completion in "worktree add" is left out because that option
should be handled with care.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/compl
On Wed, May 11, 2016 at 1:36 PM, Eric Sunshine wrote:
> On Tue, May 10, 2016 at 10:15 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> The use case is keep some worktree and discard the rest of the worktree
>> list.
>
> So, you're saying that rather than a client freeing the entire
> worktree list like this:
On Sun, May 22, 2016 at 08:07:05AM +0200, Torsten Bögershausen wrote:
> On 22.05.16 01:17, Mike Hommey wrote:
> > Signed-off-by: Mike Hommey
> > ---
> > connect.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/connect.c b/connect.c
> > index c53f3f1..caa2a3c 100644
> > ---
53 matches
Mail list logo
