Hi Junio,
On 2015-07-17 23:39, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> On 2015-07-17 19:09, Charles Bailey wrote:
>>> From: Charles Bailey
>>>
>>> According to POSIX specification uname must return -1 on failure and a
>>> non-negative value on success. Although many implementat
On Fri, Jul 17, 2015 at 11:58 AM, Garbageyard wrote:
> We have a pre-receive hook that checks for JIRA ID whenever someone pushes
> code to Git server. I'm trying to avoid this check when someone is applying
> a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar
>
> This is the link
On Fri, Jul 17, 2015 at 07:00:09PM -0400, Eric Sunshine wrote:
> Fix oversight where branch auto-vivication incorrectly kicks in when
> --detach is specified and omitted. Instead, treat:
>
> git worktree add --detach
>
> as shorthand for:
>
> git worktree add --detach HEAD
>
> Signed
check_linked_checkout() only understands symref-style HEAD (i.e. "ref:
refs/heads/master"), however, HEAD may also be a an actual symbolic link
(on platforms which support it). To accurately detect if a branch is
checked out elsewhere, it needs to handle symbolic link HEAD, as well.
Signed-off-by:
Now that git-worktree sets HEAD explicitly to its final value via either
git-symbolic-ref or git-update-ref, rather than relying upon
git-checkout to do so, the "hack" for pacifying is_git_directory() with
a temporary HEAD, though still necessary, can be simplified.
Since the real HEAD is now popu
git-worktree currently conflates branch creation, setting of HEAD in the
new worktree, and worktree population into a single sub-invocation of
git-checkout, which requires git-checkout to be specially aware that it
is operating in a newly-created worktree. The goal is to free
git-checkout of that s
git-worktree currently conflates setting of HEAD in the new worktree
with initial worktree population via a single git-checkout invocation,
which requires git-checkout to have special knowledge that it is
operating in a newly created worktree. The eventual goal is to separate
these operations and r
git-worktree currently conflates setting of HEAD in the new worktree and
initial worktree population into a single git-checkout invocation which
requires git-checkout to have special knowledge that it is operating on
a newly created worktree. The eventual goal is to rid git-checkout of
that overly-
Now that git-worktree no longer relies upon git-checkout for new branch
creation, new worktree HEAD set up, or initial worktree population,
git-checkout no longer needs intimate knowledge that it may be operating
in a newly created worktree. Therefore, drop 'new_worktree_mode' and the
private GIT_C
check_linked_checkout() only understands symref-style HEAD (i.e. "ref:
refs/heads/master"), however, HEAD may also be a an actual symbolic link
(on platforms which support it), thus it will need to check that style
HEAD, as well (via readlink()). As a preparatory step, simplify parsing
of symref-st
The plan is to publish die_if_checked_out() so that callers other than
git-checkout can take advantage of it, however, those callers won't have
access to git-checkout's "struct branch_info". Therefore, change it to
accept the full name of the branch as a simple string instead.
While here, also giv
Be consistent with git-checkout which disallows this (not particularly
meaningful) combination.
Signed-off-by: Eric Sunshine
---
Changes since v2: add tests
builtin/worktree.c | 4 ++--
t/t2025-worktree-add.sh | 12
2 files changed, 14 insertions(+), 2 deletions(-)
diff --g
Fix oversight where branch auto-vivication incorrectly kicks in when
--detach is specified and omitted. Instead, treat:
git worktree add --detach
as shorthand for:
git worktree add --detach HEAD
Signed-off-by: Eric Sunshine
---
New in v3.
builtin/worktree.c | 2 +-
t/t2025-
Take advantage of 'struct child_process.env' to make it obvious that
environment variables set by add_worktree() are intended specifically
for sub-commands it invokes to operate in the new worktree.
We assign a local 'struct argv_array' to child_process.env, rather than
utilizing the child_process
The caller of add_worktree() provides it with a command to invoke to
populate the new worktree. This was a useful abstraction during the
conversion of "git checkout --to" functionality to "git worktree add"
since git-checkout and git-worktree constructed the population command
differently. However,
Make 'new_branch' be the name of the new branch for both forced and
non-forced cases; and add boolean 'force_new_branch' to indicate forced
branch creation. This will simplify logic later on when git-worktree
handles branch creation locally rather than delegating it to
git-checkout as part of the w
add_worktree() will eventually need to deal with some options itself, so
introduce a structure into which options can be conveniently bundled,
and pass it along to add_worktree().
Signed-off-by: Eric Sunshine
---
No changes since v2.
builtin/worktree.c | 45 +++-
die_if_checked_out() is intended to check if the branch about to be
checked out is already checked out either in the main worktree or in a
linked worktree. However, if .git/worktrees directory does not exist,
then it never bothers checking the main worktree, even though the
specified branch might i
When git-worktree creates a new worktree, it reports:
Enter "" (identifier )
which misleadingly implies that it is setting as the working
directory (as if "cd " had been invoked), whereas it's actually
preparing the new worktree by creating its administrative files, setting
HEAD, and populat
Now that git-worktree handles all functionality (--force, --detach,
-b/-B) previously delegated to git-checkout, actual population of the
new worktree can be accomplished more directly and lightweight with
"git reset --hard" in place of "git checkout".
Signed-off-by: Eric Sunshine
---
No changes
check_linked_checkouts() doesn't just "check" linked checkouts for
"something"; specifically, it aborts the operation if the branch about
to be checked out is already checked out elsewhere. Therefore, rename it
to die_if_checked_out() to give a better indication of its function.
The more meaningful
git-worktree currently conflates new branch creation, setting of HEAD in
the new wortkree, and worktree population into a single sub-invocation
of git-checkout. However, these operations will eventually be separated,
and git-worktree itself will need to be able to detect if the branch is
already ch
This is v3 of [1] which rids git-checkout of specialized knowledge that
it's operating in a newly created linked worktree. Thanks to Junio for
his review, and Duy and Michael J Gruber for additional observations.
A v2 to v3 interdiff is included below.
Changes since v2:
* patch 06/22: strip only
When check_linked_checkout() discovers that the branch is already
checked out elsewhere, it emits the diagnostic:
'blorp' is already checked out at '/some/path/.git'
which is misleading since "checked out at" implies the working tree, but
".git" is the location of the repository administrativ
There is no reason to keep the strbuf active long after its last use.
By releasing it as early as possible, resource management is simplified
and there is less worry about future changes resulting in a leak.
Signed-off-by: Eric Sunshine
---
No changes since v2.
builtin/checkout.c | 7 +++
When --ignore-other-worktree is specified, we unconditionally skip the
check to see if the requested branch is already checked out in a linked
worktree. Since we know that we will be skipping that check, there is no
need to resolve HEAD in order to detect other conditions under which we
may skip th
Junio C Hamano writes:
> Zoë Blade writes:
>
>> More information about the Fountain format can be found on its
>> official website, at http://fountain.io .
So I visited there.
>> +PATTERNS("fountain", "^((INT|EST|EXT)?\\.[A-Z0-9' -]+)$",
>> + "[^ \t-]+"),
After skimming http://fountain.i
Signed-off-by: Junio C Hamano
---
rerere.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/rerere.c b/rerere.c
index 1089a9c..30bdfeb 100644
--- a/rerere.c
+++ b/rerere.c
@@ -644,16 +644,13 @@ static void do_rerere_one_path(struct string_list_item
*rr_item,
It's just easier to follow this way.
Signed-off-by: Junio C Hamano
---
rerere.c | 69
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/rerere.c b/rerere.c
index 09b72ed..1089a9c 100644
--- a/rerere.c
+++ b/rerere.c
@
handle_cache() loops 3 times starting from an index entry that is
unmerged, while ignoring an entry for a path that is different from
what we are looking for.
As the index is sorted, once we see a different path, we know we saw
all stages for the path we are interested in. Just loop while we
see
Explain the internals of rerere as in-code comments, while
sprinkling "NEEDSWORK" comment to highlight iffy bits and
questionable assumptions.
This covers the codepath that implements "rerere gc" and "rerere
clear".
Signed-off-by: Junio C Hamano
---
rerere.c | 20
1 file ch
Explain the internals of rerere as in-code comments, while
sprinkling "NEEDSWORK" comment to highlight iffy bits and
questionable assumptions.
This covers the codepath that implements "rerere forget".
Signed-off-by: Junio C Hamano
---
rerere.c | 24
1 file changed, 24 i
Explain the internals of rerere as in-code comments.
This one covers our thin I/O abstraction to read from either
a file or a memory while optionally writing out to a file.
Signed-off-by: Junio C Hamano
---
rerere.c | 38 +++---
1 file changed, 31 insertions(+),
As the nature of the conflict marker line determies if there should
a SP and label after it, the caller shouldn't have to pass the
parameter redundantly.
Signed-off-by: Junio C Hamano
---
rerere.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/re
The MERGE_RR file records a collection of NUL-terminated entries,
each of which consists of
- a hash that identifies the conflict
- a HT
- the pathname
We used to read this piece-by-piece, and worse yet, read the
pathname part a byte at a time into a fixed buffer of size PATH_MAX.
Instead, re
Most places we call conflict IDs "name" and some others we call them
"hex"; update all of them to "id".
Signed-off-by: Junio C Hamano
---
builtin/rerere.c | 4 +--
rerere.c | 76
rerere.h | 2 +-
3 files changed, 41 inser
Instead of writing the hash for a conflict, a HT, and the path
with three separate write_in_full() calls, format them into a
single record into a strbuf and write it out in one go.
As a more recent "rerere remaining" codepath abuses the .util field
of the merge_rr data to store a sentinel token, m
Explain the internals of rerere as in-code comments, while
sprinkling "NEEDSWORK" comment to highlight iffy bits and
questionable assumptions.
This one covers the codepath reached from rerere(), the primary
interface to the subsystem.
Signed-off-by: Junio C Hamano
---
rerere.c | 95
By consistently using "upon failure, set 'ret' and jump to out"
pattern, flatten the function further.
Signed-off-by: Junio C Hamano
---
rerere.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/rerere.c b/rerere.c
index 469
Signed-off-by: Junio C Hamano
---
rerere.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/rerere.c b/rerere.c
index 27b287d..304df02 100644
--- a/rerere.c
+++ b/rerere.c
@@ -482,6 +482,8 @@ static void update_paths(struct string_list *update)
Explain the internals of rerere as in-code comments, while
sprinkling "NEEDSWORK" comment to highlight iffy bits and
questionable assumptions.
This one covers the "$GIT_DIR/MERGE_RR" file and in-core merge_rr
that are used to keep track of the status of "rerere" session in
progress.
Signed-off-by
Extract the body of a loop that attempts to replay recorded
resolution for each conflicted path into a helper function, not
because I want to call it from multiple places later, but because
the logic has become too deeply nested and hard to read.
Signed-off-by: Junio C Hamano
---
rerere.c | 75 +
This gives a thin abstraction between the conflict ID that is a hash
value obtained by inspecting the conflicts and the name of the
directory under $GIT_DIR/rr-cache/, in which the previous resolution
is recorded to be replayed. The plan is to make sure that the
presense of the directory does not
When ac49f5ca (rerere "remaining", 2011-02-16) split out a new
helper function check_one_conflict() out of find_conflict()
function, so that the latter will use the returned value from the
new helper to update the loop control variable that is an index into
active_cache[], the new variable incremen
The merge_rr string list stores the conflict ID (a hexadecimal
string that is used to index into $GIT_DIR/rr-cache) in the .util
field of its elements, and when do_plain_rerere() resolves a
conflict, the field is cleared. Also, when rerere_forget()
recomputes the conflict ID to updates the preimag
This is a resend of v2:
http://thread.gmane.org/gmane.comp.version-control.git/273117
plus 5 new changes. I have a few more real-fix changes that build
on top, but they are not sufficiently polished to be published yet
compared to these early clean-up bits.
Junio C Hamano (18):
rerere: fi
Johannes Schindelin writes:
> On 2015-07-17 19:09, Charles Bailey wrote:
>> From: Charles Bailey
>>
>> According to POSIX specification uname must return -1 on failure and a
>> non-negative value on success. Although many implementations do return 0
>> on success it is valid to return any posit
David Turner writes:
> Don't update files in the worktree from cache entries which are
> flagged with CE_WT_REMOVE.
>
> When a user does a sparse checkout, git removes files that are marked
> with CE_WT_REMOVE (because they are out-of-scope for the sparse
> checkout). If those files are also mark
I've prepared another version of my pluggable backends series.
This version has the following changes:
1. Addressed all cosmetic review comments from previous version
2. Significant cleanup of LMDB code: formatting and variable names,
functions extracted, etc.
3. Explicit handling of per-worktree
Don't update files in the worktree from cache entries which are
flagged with CE_WT_REMOVE.
When a user does a sparse checkout, git removes files that are marked
with CE_WT_REMOVE (because they are out-of-scope for the sparse
checkout). If those files are also marked CE_UPDATE (for instance,
becaus
Eric Sunshine writes:
>> Thanks. I have two comments.
>>
>> "if using Cogito etc.", which is totally outside the topic of this
>> patch, is way outdated. Perhaps we would want to remove or replace
>> it.
>
> Do you want me to re-roll the current patch to also include the
> "Cogito" change as a "
On 2015-07-17 19:09, Charles Bailey wrote:
> From: Charles Bailey
>
> According to POSIX specification uname must return -1 on failure and a
> non-negative value on success. Although many implementations do return 0
> on success it is valid to return any positive value for success. In
> particul
On 17.07.15 19:28, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> Signed-off-by: Beat Bolli
>>> Reviewed-by: Eric Sunshine
>>> Reviewed-by: Johannes Sixt
>>
>> You should drop these Reviewed-by: footers, as they imply that the
>> code was thoroughly digested and the implementation deemed
On Fri, Jul 17, 2015 at 1:03 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> This should have been changed by 93a3649 (Documentation: move linked
>> worktree description from checkout to worktree, 2015-07-06).
>>
>> Signed-off-by: Eric Sunshine
>> ---
>> @@ -845,7 +845,7 @@ Git so take care
David Turner writes:
> Don't update files in the worktree from cache entries which are
> flagged with CE_WT_REMOVE. This is fixes merges in sparse
> checkouts.
s/This is/This/;
But more importantly, what is missing is "why" it is a good fix.
i.e. things like:
- why is it wrong to update what
Don't update files in the worktree from cache entries which are
flagged with CE_WT_REMOVE. This is fixes merges in sparse
checkouts.
Signed-off-by: Anatole Shaw
Signed-off-by: David Turner
---
This patch was written by my colleague Anatole Shaw for Twitter's git;
I just rebased it on mainstrea
Garbageyard writes:
> We have a pre-receive hook that checks for JIRA ID whenever someone pushes
> code to Git server. I'm trying to avoid this check when someone is applying
> a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar
>
> This is the link for output: http://pastebin.com
Ralf Thielow writes:
> The usage string of git-branch shows generic options and specific
> options. However, the specific options are called "actions".
> Call them both options.
I think this is a valid problem to address, but I do not know if the
proposed solution is the right one.
Originally,
We have a pre-receive hook that checks for JIRA ID whenever someone pushes
code to Git server. I'm trying to avoid this check when someone is applying
a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar
This is the link for output: http://pastebin.com/tBGmYaZF
Problem is that if i
The usage string of git-branch shows generic options and specific
options. However, the specific options are called "actions".
Call them both options.
Signed-off-by: Ralf Thielow
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/b
On Fri, 2015-07-17 at 15:12 +, Alexander wrote:
> Hello,
>
> I have problem with architecure of my project, help me to resolve
> problem
> . I want to do in my remote repo two branches with two different
> working
> folders (master , dev ) to check it . How can I do it ?
> Thank you.
Sou
Good afternoon,
I've been trying to download the git-osx-installer but SourceForge
seems to be having problems. Is there an alternate download location?
--
Thank you,
Jordan Lowe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.or
Eric Sunshine writes:
>> Signed-off-by: Beat Bolli
>> Reviewed-by: Eric Sunshine
>> Reviewed-by: Johannes Sixt
>
> You should drop these Reviewed-by: footers, as they imply that the
> code was thoroughly digested and the implementation deemed correct.
... and the most importantly, the named p
On Fri, Jul 17, 2015 at 4:39 AM, Beat Bolli wrote:
> When referring to earlier commits in commit messages or other text, one
> of the established formats is
>
> ("", )
>
> Add a "Copy commit summary" command to the context menu that puts this
> text for the currently selected commit on the cl
Zoë Blade writes:
> Add support for Fountain, a plain text screenplay format. Git
> facilitates not just programming specifically, but creative writing
> in general, so it makes sense to also support other plain text
> documents besides source code.
>
> In the structure of a screenplay specific
On 17 Jul 2015, at 16:12, Alexander wrote:
> Hello,
>
> I have problem with architecure of my project, help me to resolve problem
> . I want to do in my remote repo two branches with two different working
> folders (master , dev ) to check it . How can I do it ?
>
> Thank you.
You'll probab
From: Charles Bailey
According to POSIX specification uname must return -1 on failure and a
non-negative value on success. Although many implementations do return 0
on success it is valid to return any positive value for success. In
particular, Solaris returns 1.
Signed-off-by: Charles Bailey
Charles Bailey writes:
> ... I think '< 0' is
> probably better. In POSIX, we shouldn't ever get a negative value which
> isn't -1, but if we ever do it is probably safer to fail. I'll send and
> update.
Thanks; I was about to type the same reasoning and conclusion ;-)
--
To unsubscribe from thi
On Fri, Jul 17, 2015 at 11:19 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
>> wrote:
>>> Two more observations:
>>>
>>> $ git worktree add /tmp/gitwt
>>> Enter /tmp/gitwt (identifier gitwt)
>>> Switched to a new branch 'gitwt'
>>>
>>> Now
Eric Sunshine writes:
> This should have been changed by 93a3649 (Documentation: move linked
> worktree description from checkout to worktree, 2015-07-06).
>
> Signed-off-by: Eric Sunshine
> ---
> Documentation/git.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Doc
On Fri, Jul 17, 2015 at 8:49 AM, Duy Nguyen wrote:
> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
> wrote:
>> Two more observations:
>>
>> $ git worktree add /tmp/gitwt
>> Enter /tmp/gitwt (identifier gitwt)
>> Switched to a new branch 'gitwt'
>>
>> Now I'm in /tmp/gitwt at branch gitwt. Rig
On Fri, Jul 17, 2015 at 03:06:57PM +0200, Johannes Schindelin wrote:
>
> From a quick `git grep '== -1'` and another quick `git grep '< 0'` it appears
> to me that we prefer the latter. Maybe you want to adjust it in the patch,
> too?
I did the same grep and found lots of examples of both. Many
Hi Zoë,
On 2015-07-17 16:03, Zoë Blade wrote:
> On 17 Jul 2015, at 14:03, Johannes Schindelin
> wrote:
>
>> Maybe you want to add a paragraph explaining a bit more about Fountain, or
>> at least link to http://fountain.io/?
>>
>> In any case, you will need to sign off on your patch:
>>
>>
>
Fetching from all remotes by default is useful if you're working on a
repo with few and/or fast remotes. It also lets you fetch from origin
even if the current branch's upstream is elsewhere without specifying it
explicitly.
Signed-off-by: Øystein Walle
---
Thanks for the quick feedback, Remi. Th
Øystein Walle writes:
> Fetching from all remotes by default is useful if you're working on a
> repo with few and/or fast remotes.
That part is sensible.
> It also lets you fetch from origin
> even if the current branch's upstream is elsewhere without specifying it
> explicitly.
I do not think
Hello,
I have problem with architecure of my project, help me to resolve problem
. I want to do in my remote repo two branches with two different working
folders (master , dev ) to check it . How can I do it ?
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
Paul Mackerras writes:
> We have an item in the preferences menu to control the SHA1 length
> that is automatically selected when going to a new commit. It's
> stored in the variable $autosellen. That seems like it would be a
> reasonable choice for the SHA1 length to use here.
Reusing a confi
Duy Nguyen writes:
> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
> wrote:
>> Two more observations:
>>
>> $ git worktree add /tmp/gitwt
>> Enter /tmp/gitwt (identifier gitwt)
>> Switched to a new branch 'gitwt'
>>
>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
Hi,
Øystein Walle writes:
> +fetch.all::
> +If true, fetch will automatically behave as if the `--all`
> +option was given on the command line uness a remote was given. The
> +default is false.
s/uness/unless
> +test_expect_success 'git fetch (fetch.all = true)' '
> +
Add support for Fountain, a plain text screenplay format. Git
facilitates not just programming specifically, but creative writing
in general, so it makes sense to also support other plain text
documents besides source code.
In the structure of a screenplay specifically, scenes are roughly
analogo
On 17 Jul 2015, at 14:03, Johannes Schindelin
wrote:
> Maybe you want to add a paragraph explaining a bit more about Fountain, or at
> least link to http://fountain.io/?
>
> In any case, you will need to sign off on your patch:
>
>
> https://github.com/git/git/blob/v2.4.6/Documentation/Su
Fetching from all remotes by default is useful if you're working on a
repo with few and/or fast remotes. It also lets you fetch from origin
even if the current branch's upstream is elsewhere without specifying it
explicitly.
Signed-off-by: Øystein Walle
---
This is scratching a itch I have. Most
Hi Charles,
On 2015-07-17 14:11, Charles Bailey wrote:
> diff --git a/dir.c b/dir.c
> index 8209f8b..52dbfd0 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1848,7 +1848,7 @@ static const char *get_ident_string(void)
>
> if (sb.len)
> return sb.buf;
> - if (uname(&uts))
> +
Hi Zoë,
On 2015-07-17 13:59, Zoë Blade wrote:
> Add support for Fountain, a plain text screenplay format. In the
> structure of a screenplay, scenes are roughly analogous to functions,
> in the sense that it makes your job slightly easier if you can see
> which ones were changed in a given rang
On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
wrote:
> Two more observations:
>
> $ git worktree add /tmp/gitwt
> Enter /tmp/gitwt (identifier gitwt)
> Switched to a new branch 'gitwt'
>
> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
> at the original branch.
>
> So
Two more observations:
$ git worktree add /tmp/gitwt
Enter /tmp/gitwt (identifier gitwt)
Switched to a new branch 'gitwt'
Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
at the original branch.
So either we cd to the new location or quelch these messages or add a
message
From: Charles Bailey
According to POSIX specification uname must return -1 on failure and a
non-negative value on success. Although many implementations do return 0
on success it is valid to return any positive value for success. In
particular, Solaris returns 1.
Signed-off-by: Charles Bailey
Add support for Fountain, a plain text screenplay format. In the
structure of a screenplay, scenes are roughly analogous to functions,
in the sense that it makes your job slightly easier if you can see
which ones were changed in a given range of patches.
---
Documentation/gitattributes.txt | 2 ++
On Thu, Jul 16, 2015 at 05:29:25PM +0200, Beat Bolli wrote:
> When referring to earlier commits in commit messages or other text, one
> of the established formats is
>
> ("", )
>
> Add a "Copy commit summary" command to the context menu that puts this
> text for the currently selected commit
On 2015-07-17 10:50, li...@haller-berlin.de wrote:
Junio C Hamano wrote:
Beat Bolli writes:
> When referring to earlier commits in commit messages or other
text, one
> of the established formats is
>
> ("", )
> ...
> +proc copysummary {} {
> +global rowmenuid commitinfo
> +
> +
Junio C Hamano wrote:
> Beat Bolli writes:
>
> > When referring to earlier commits in commit messages or other text, one
> > of the established formats is
> >
> > ("", )
> > ...
> > +proc copysummary {} {
> > +global rowmenuid commitinfo
> > +
> > +set id [string range $rowmenuid 0
Hi,
I'm setting some URL overrides via
> -c foo.insteadof=bar
to "git clone --recursive", but they are not used in the subsequent
submodule requests on git 1.9.1.
Is this expected behavior, or a bug?
--
Regards/Mit freundlichen Grüßen
Christian Weiske
-= Geeking around in the name of science
When referring to earlier commits in commit messages or other text, one
of the established formats is
("", )
Add a "Copy commit summary" command to the context menu that puts this
text for the currently selected commit on the clipboard. This makes it
easy for our users to create well-format
93 matches
Mail list logo
