On Tue, Jul 28, 2015 at 2:12 PM, David Turner wrote:
> Pseudorefs should not be updated through the ref transaction
> API, because alternate ref backends still need to store pseudorefs
> in GIT_DIR (instead of wherever they store refs). Instead,
> change update_ref and delete_ref to call pseudore
On Tue, Jul 28, 2015 at 2:12 PM, David Turner wrote:
> Add a function ref_type, which categorizes refs as per-worktree,
> pseudoref, or normal ref.
>
> Later, we will use this in refs.c to treat pseudorefs specially.
> Alternate ref backends may use it to treat both pseudorefs and
> per-worktree r
Johan Herland writes:
> I believe it is a bad compromise. It complicates the code, and it
> provides a concurrent notes merges that is unnecessarily tied to (and
> dependent on) worktrees. For example, if I wanted to perform N
> concurrent notes merges in a project that happens to have a huge
> w
Johan Herland writes:
> On Wed, Jul 29, 2015 at 4:00 AM, Junio C Hamano wrote:
>
>> So doing the absolute minimum, leaving the "now what can we do to
>> improve notes-merge process?" outside the scope of the topic.
>
> That's exactly what I was also trying to do: David's topic should not
> have
On Tue, Jul 28, 2015 at 1:39 PM, Christian Couder
wrote:
> On Tue, Jul 28, 2015 at 9:11 AM, Karthik Nayak wrote:
>
>> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
>> index a67138a..897cd81 100644
>> --- a/Documentation/git-branch.txt
>> +++ b/Documentation/git-branch.t
On Tue, Jul 28, 2015 at 1:27 PM, Jacob Keller wrote:
> On Tue, Jul 28, 2015 at 12:11 AM, Karthik Nayak wrote:
>> Make 'branch.c' use 'ref-filter' APIs for iterating through refs
>> sorting. This removes most of the code used in 'branch.c' replacing it
>> with calls to the 'ref-filter' library.
>>
On Wed, Jul 29, 2015 at 4:00 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> It sounds like what a notes merge really wants is a new linked worktree
>> that has branch refs/notes/foo checked out:
>>
>> * This would allow multiple notes merges to take place at the same time
>> provided the
On Wed, Jul 29, 2015 at 4:17 AM, Junio C Hamano wrote:
> Perhaps you meant by "per repo" to mean "per $GIT_DIR" in this
> message, and if that is the case, then I think we are in agreement.
No, by per repo I mean per $GIT_COMMON_DIR (I haven't followed the
linked worktree effort, so this language
On Wed, Jul 29, 2015 at 2:33 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>> ...
>> This is not the case for notes merges. If I start a notes merge from
Johan Herland writes:
> Yes, almost. There are some complications with the concept of
> "checking out" a notes tree:
>
> - The notes tree fanout must be flattened (so that when merging two
> note trees with different fanout, conflicting notes (e.g. deadbeef...
> and de/adbeef) are turned int
Johan Herland writes:
> In fact, you can easily do a notes merge in a _bare_ repo...
You keep repeating that but I do not think it is relevant at all.
If you have a bare repository, you either
(1) do not have any worktree associated with it; or
(2) have worktrees associated with it elsewher
Michael Haggerty writes:
> It sounds like what a notes merge really wants is a new linked worktree
> that has branch refs/notes/foo checked out:
>
> * This would allow multiple notes merges to take place at the same time
> provided they target different merge references.
>
> * This would prevent
On Wed, Jul 29, 2015 at 2:56 AM, Michael Haggerty wrote:
> Johan Herland writes:
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>
> It sounds like what a notes merge really wants is a new linked worktree
> t
On Tue, Jul 28, 2015 at 5:56 PM, Michael Haggerty wrote:
> Johan Herland writes:
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>
> It sounds like what a notes merge really wants is a new linked worktree
> t
Johan Herland writes:
> Here is where we start to differ. I would say that starting a notes
> merge is completely unrelated to your worktree. Consider this:
It sounds like what a notes merge really wants is a new linked worktree
that has branch refs/notes/foo checked out:
* This would allow mult
On Tue, Jul 28, 2015 at 1:12 PM, Karthik Nayak wrote:
> On Tue, Jul 28, 2015 at 6:39 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> We check if given ref is the current branch in print_ref_list(). Move
>>> this check to print_ref_item() where it is checked right before
>>> printing.
Johan Herland writes:
> Here is where we start to differ. I would say that starting a notes
> merge is completely unrelated to your worktree. Consider this:
> ...
> This is not the case for notes merges. If I start a notes merge from
> worktree A, there is no "occupation" of that worktree. Before
On Tue, Jul 28, 2015 at 08:23:40AM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
> > Are you trying to say that the result of 'rev-parse --abbrev-ref HEAD'
> > is suboptimal and that of 'symbolic-ref --short HEAD' is OK?
>
> My "Interesting" was primarily about that I wasn't aware of the
>
On Wed, Jul 29, 2015 at 12:52 AM, Junio C Hamano wrote:
> Johan Herland writes:
>> However, in any case, notes merges are always per _repo_ and never per
>> _worktree_, so this is all unrelated to the current patch/discussion
>> AFAICS.
>
> Thanks for chiming in, but I actually think you are conf
Johan Herland writes:
Johan Herland writes:
> However, in any case, notes merges are always per _repo_ and never per
> _worktree_, so this is all unrelated to the current patch/discussion
> AFAICS.
Thanks for chiming in, but I actually think you are confused.
"git merge" is always per _repo_
On Wed, Jul 29, 2015 at 12:12 AM, Junio C Hamano wrote:
> David Turner writes:
>> Prevent merges to the same notes branch from different worktrees.
>> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
>> code we use to check that two HEADs in different worktrees don't point
>>
On Tue, Jul 28, 2015 at 3:27 PM, Jacob Keller wrote:
> When passing "-n" on the command line, if you have configured sort
> manually, you get an error as it thinks you passed --sort and -n.
>
> It should automatically disable tag_sort if it wasn't passed from the
> command line, as you probably kn
On Tue, Jul 28, 2015 at 9:44 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>> David Turner writes:
>>> All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
>>> per-worktree. We don't want multiple notes merges happening at once
>>> (in different worktrees), so we want to make t
When passing "-n" on the command line, if you have configured sort
manually, you get an error as it thinks you passed --sort and -n.
It should automatically disable tag_sort if it wasn't passed from the
command line, as you probably know what you are doing when passing -n
I'm attempting to work u
On Tue, Jul 28, 2015 at 5:23 PM, David Turner wrote:
> Prevent merges to the same notes branch from different worktrees.
> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
> code we use to check that two HEADs in different worktrees don't point
> to the same branch. Modify th
David Turner writes:
> Prevent merges to the same notes branch from different worktrees.
> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
> code we use to check that two HEADs in different worktrees don't point
> to the same branch. Modify that code, die_if_checked_out, to
David Turner writes:
> Sorry, this one is on top of next.
Thanks, but I'd appreciate if you can be more specific next time.
A topic that truly depends on everything in 'next' cannot graduate
before all the others do, but in this particular case, I think this
change only needs to depend on Eric'
Do you need loan to finance your Businessor Investment? We offer all kinds
of loans (Personal, Mortgage, Refinancing, Debt Consolidation, Investment
Loan etc) at 4% interest rate, Contact us today at: mc.tm...@gmail.com .
Contact Us With Email Only (mc.tm...@gmail.com).
--
To unsubscribe from
On Mon, Jul 27, 2015 at 3:27 AM, Karthik Nayak wrote:
> From: Karthik Nayak
>
> Since 'ref-filter' only has an option to match path names add an
> option for plain fnmatch pattern-matching.
>
> This is to support the pattern matching options which are used in `git
> tag -l` and `git branch -l` wh
Sorry, this one is on top of next.
On Tue, 2015-07-28 at 17:23 -0400, David Turner wrote:
> Prevent merges to the same notes branch from different worktrees.
> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
> code we use to check that two HEADs in different worktrees don't p
On Mon, Jul 27, 2015 at 3:27 AM, Karthik Nayak wrote:
> Add a new atom "padright" and support %(padright:X) where X is a
> number. This will align the succeeding atom value to the left
> followed by spaces for a total length of X characters. If X is less
> than the item size, the entire atom valu
David Turner writes:
> On Tue, 2015-07-28 at 13:47 -0700, Junio C Hamano wrote:
>> David Turner writes:
>>
>> > When we unpack trees into an existing index, we discard the old index
>> > and replace it with the new, merged index. Ensure that this index has
>> > its cache-tree populated. This
Prevent merges to the same notes branch from different worktrees.
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
code we use to check that two HEADs in different worktrees don't point
to the same branch. Modify that code, die_if_checked_out, to take a
"head" ref to examine;
On Tue, 2015-07-28 at 13:47 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > When we unpack trees into an existing index, we discard the old index
> > and replace it with the new, merged index. Ensure that this index has
> > its cache-tree populated. This will make subsequent git statu
Jeff King writes:
> On Tue, Jul 14, 2015 at 12:05:58AM +0100, Philip Oakley wrote:
>
>> It looks like Git has a healthy truck factor of 8, as reported in
>> https://mtov.github.io/Truck-Factor/, which has Git eighth in the list of
>> projects it analyzed, with Linux at second place.
>>
>> The an
There is no need to call it if value is the empty string. This also
eliminates code duplication.
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index d0d267b..bd945d0 100644
--- a/built
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index bd945d0..76ca100 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -975,8 +975,7 @@ static int get_remote_group(const char *key, co
The code for splitting a whitespace-separated list of values in
"remotes." had an off-by-one error that caused it to skip over
remotes whose names consist of a single character.
Also remove unnecessary braces.
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 3 +--
1 file changed, 1 insert
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 98f9048..d0d267b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -978,13 +978,13 @@ static int get_remote_group(const ch
The parsing of `remotes.` was broken if any of the remotes
in the group has a name consisting of a single character.
The first patch fixes the bug; the others are general refactoring to
make the function a little bit clearer.
This series is based on maint, which I just noticed is still v2.4.7,
bu
David Turner writes:
> Git checkout $branch already populates the cache-tree; this is due to
> patches I added last year:
>
> commit aecf567cbfb6ab46e82f7f5df36fb6a2dd5bee69
Heh, our mails crossed ;-)
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mes
David Turner writes:
> When we unpack trees into an existing index, we discard the old index
> and replace it with the new, merged index. Ensure that this index has
> its cache-tree populated. This will make subsequent git status and
> commit commands faster.
>
> Signed-off-by: David Turner
>
On Tue, Jul 28, 2015 at 7:18 PM, Matthieu Moy
wrote:
> Christian Couder writes:
>
>> On Tue, Jul 28, 2015 at 8:56 AM, Karthik Nayak wrote:
>>
>>> +static void ref_array_append(struct ref_array *array, const char *refname)
>>> +{
>>> + size_t len = strlen(refname);
>>> + struct ref_ar
On Tue, Jul 28, 2015 at 1:47 PM, Christian Couder
wrote:
> On Tue, Jul 28, 2015 at 8:56 AM, Karthik Nayak wrote:
>
>> +static void ref_array_append(struct ref_array *array, const char *refname)
>> +{
>> + size_t len = strlen(refname);
>> + struct ref_array_item *ref = xcalloc(1, sizeo
On Sun, Jul 26, 2015 at 9:41 PM, Michael Haggerty wrote:
> On 07/23/2015 09:00 PM, Eric Sunshine wrote:
>> In addition to approxidate-style values ("2.months.ago", "yesterday"),
>> consumers of 'gc.*expire*' configuration variables also accept and
>> respect 'now'/'all' ("do it immediately") and '
On Tue, Jul 28, 2015 at 1:52 PM, Christian Couder
wrote:
> On Tue, Jul 28, 2015 at 8:56 AM, Karthik Nayak wrote:
>> diff --git a/ref-filter.h b/ref-filter.h
>> index 7d1871d..3458595 100644
>> --- a/ref-filter.h
>> +++ b/ref-filter.h
>> @@ -5,6 +5,7 @@
>> #include "refs.h"
>> #include "commit.h
On Tue, 2015-07-28 at 13:04 -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > David Turner writes:
> >
> >> The work done to produce the cache-tree is work that the commit would
> >> otherwise have to do. So we're spending extra time in one place to
> >> eliminate that work in a diffe
On Tue, Jul 28, 2015 at 01:14:47PM -0700, Junio C Hamano wrote:
> I notice that the only time you said that you chose '!' prefix as
> the way to express this new "negative" is as a side note to the
> rejected second variant ;-). The first paragraph would have been a
> good place to say that, beca
Jeff King writes:
> If you hide a hierarchy of refs using the transfer.hideRefs
> config, there is no way to later override that config to
> "unhide" it. This patch implements a "negative" hide which
> causes matches to immediately be marked as unhidden, even if
> another match would hide it. We
On Tue, Jul 28, 2015 at 6:39 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> We check if given ref is the current branch in print_ref_list(). Move
>> this check to print_ref_item() where it is checked right before
>> printing.
>
> This means that the '*' and the different color are coded in
Descriptive text for each tool item is incorrectly formatted using a
fixed width font. Fix formatting to use a variable width font by
unindenting the item text.
Signed-off-by: Eric Sunshine
---
No changes since v1.
Documentation/git-tools.txt | 134 ++--
This is a re-roll of [1] which makes minor improvements to documentation
based upon observations of Michael Haggerty, Junio, and myself. This
version addresses review comments by Michael[2] and includes follow-on
patch 7/6 which arose[3] from my observation that it may be time to
retire the manuall
When Git was young, people looking for third-party Git-related tools
came to the Git project itself to find them, so it made sense to
maintain a list of tools here. These days, however, search engines fill
that role much more efficiently, so retire the manually-maintained
list.
The list of front-e
Cogito -- unmaintained since late 2006[1]
pg -- URL dead; web searches reveal no information
quilt2git -- URL dead; web searches reveal no information
(h)gct -- URL dead; no repository activity since 2007[2]
[1]: http://git.or.cz/cogito/
[2]: http://repo.or.cz/w/hgct.git
Signed-off-by: Eric Sunsh
In addition to approxidate-style values ("2.months.ago", "yesterday"),
consumers of 'gc.*expire*' configuration variables also accept and
respect 'now' ("do it immediately") and 'never' ("suppress entirely").
Suggested-by: Michael Haggerty
Signed-off-by: Eric Sunshine
---
Changes since v1:
* gr
These days, the best way to find Git-related tools is via a search
engine. The Git wiki may be a distant second, and git-tools.txt falls in
last place. Therefore, promote the Git wiki reference to the top of
git-tools.txt so the reader will encounter it first, rather than hiding
it away at the very
Cogito hasn't been maintained since late 2006, so drop the reference
to it. The warning that SCMS front-ends might override listed
environment variables, however, may still be valuable, so keep it but
generalize the wording.
Suggested-by: Junio C Hamano
Signed-off-by: Eric Sunshine
---
No chang
Junio C Hamano writes:
> David Turner writes:
>
>> The work done to produce the cache-tree is work that the commit would
>> otherwise have to do. So we're spending extra time in one place to
>> eliminate that work in a different place.
>
> Good point. Thanks.
Hmm, I forgot about another codep
If you hide a hierarchy of refs using the transfer.hideRefs
config, there is no way to later override that config to
"unhide" it. This patch implements a "negative" hide which
causes matches to immediately be marked as unhidden, even if
another match would hide it. We take care to apply the
matches
The descriptions for receive.hideRefs and
uploadpack.hideRefs are largely the same, and then
transfer.hideRefs refers to both of them. Instead, let's
make transfer.hideRefs the "master" source, and refer to it
from the other sites (with appropriate program-specific
annotations).
This avoids duplic
At GitHub, we keep some information in a private part of the refs
namespace. We use transfer.hideRefs so that users do not see it when
fetching or pushing, and that works well. However, sometimes we want to
expose part of the hidden namespace (e.g., for an internal fetch or
push), and that cannot b
David Turner writes:
> The work done to produce the cache-tree is work that the commit would
> otherwise have to do. So we're spending extra time in one place to
> eliminate that work in a different place.
Good point. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
On Tue, 2015-07-28 at 12:50 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > When we unpack trees into an existing index, we discard the old index
> > and replace it with the new, merged index. Ensure that this index has
> > its cache-tree populated. This will make subsequent git statu
David Turner writes:
> When we unpack trees into an existing index, we discard the old index
> and replace it with the new, merged index. Ensure that this index has
> its cache-tree populated. This will make subsequent git status and
> commit commands faster.
Wouldn't it make repeated calls to
Junio C Hamano writes:
> David Turner writes:
>
>> All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
>> per-worktree. We don't want multiple notes merges happening at once
>> (in different worktrees), so we want to make these refs true refs.
>> ...
> The two "rev-parse --verify"
When we unpack trees into an existing index, we discard the old index
and replace it with the new, merged index. Ensure that this index has
its cache-tree populated. This will make subsequent git status and
commit commands faster.
Signed-off-by: David Turner
Signed-off-by: Brian Degenhardt
---
On Tue, 2015-07-28 at 12:00 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
> > per-worktree. We don't want multiple notes merges happening at once
> > (in different worktrees), so we want to make these refs true refs.
>
On Tue, Jul 28, 2015 at 6:31 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Remove show_detached() and make detached HEAD to be rolled into
>> regular ref_list by adding REF_DETACHED_HEAD as a kind of branch and
>> supporting the same in append_ref().
>
> Again, this lacks the "why?" explan
On Tue, 2015-07-28 at 12:01 -0700, Junio C Hamano wrote:
> On top of what work is this series expected to be applied?
I think I started from 'next' as of a few days ago:
commit df7aaa5e3454bbcbb1f142dd6b95b214d0b8efad
Author: Zoë Blade
Date: Tue Jul 21 14:22:46 2015 +0100
userdiff: add s
On top of what work is this series expected to be applied?
--
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
David Turner writes:
> All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
> per-worktree. We don't want multiple notes merges happening at once
> (in different worktrees), so we want to make these refs true refs.
>
> So, we lowercase NOTES_MERGE_REF and friends. That way, backends
On Tue, 2015-07-28 at 11:18 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Instead of manually writing a pseudoref (in one case) and shelling out
> > to git update-ref (in another), use the update_ref function. This
> > is much simpler.
> >
> > Signed-off-by: David Turner
> > ---
> >
Matthieu Moy writes:
> A simple escaping scheme like the above can solve both points:
>
> 1) If I want to talk about #include in my commit message, I can spell it
>\#include and Git would remove the \. The same way, if I want to tell
>my shell about a " inside a string, I can write "doubl
Eric Sunshine writes:
> I was just getting ready to re-roll this series[1] to address
> Michael's comments[2] and noticed that the add-on patch 7/6 which I
> sent later[3] seems to have been botched when Junio applied it to
> 'pu'. It's currently at 36598db (Documentation/git-tools: drop
> refere
David Turner writes:
> Instead of manually writing a pseudoref (in one case) and shelling out
> to git update-ref (in another), use the update_ref function. This
> is much simpler.
>
> Signed-off-by: David Turner
> ---
> bisect.c | 37 -
> 1 file changed, 8
On Tue, Jul 28, 2015 at 3:17 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> From: Karthik Nayak
>
> Why did send-email add this From: header? Strange, it has the same
> content as your actual From: field.
>
Not sure why, everything else came out fine. Idk what happened here.
>> Remove un
Now update_ref (via write_pseudoref) does almost exactly what
write_cherry_pick_head did, so we can remove write_cherry_pick_head
and just use update_ref.
Signed-off-by: David Turner
---
sequencer.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/sequ
Add a function ref_type, which categorizes refs as per-worktree,
pseudoref, or normal ref.
Later, we will use this in refs.c to treat pseudorefs specially.
Alternate ref backends may use it to treat both pseudorefs and
per-worktree refs differently.
Signed-off-by: David Turner
---
refs.c | 29 +
Instead of manually writing a pseudoref (in one case) and shelling out
to git update-ref (in another), use the update_ref function. This
is much simpler.
Signed-off-by: David Turner
---
bisect.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff -
This version fixes documentation issues found by Eric Sunshine.
It also adds a new patch so as not to create static functions that
aren't immediately used; Eric also noticed that issue.
I refactored the functions to classify a ref into a single public
ref_type function. This makes it easy for ba
Pseudorefs should not be updated through the ref transaction
API, because alternate ref backends still need to store pseudorefs
in GIT_DIR (instead of wherever they store refs). Instead,
change update_ref and delete_ref to call pseudoref-specific
functions.
Signed-off-by: David Turner
---
refs.
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling,
because the files refs backend already handles them correctly. Later,
we will make the LMDB backend call out to the files backend to handle
per-worktree refs.
Signed-off-by: David Turner
-
All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
per-worktree. We don't want multiple notes merges happening at once
(in different worktrees), so we want to make these refs true refs.
So, we lowercase NOTES_MERGE_REF and friends. That way, backends
that distinguish between pseudo
Karthik Nayak writes:
> The 'ifexists' atom allows us to print a required format if the
> preceeding atom has a value. If the preceeding atom has no value then
> the format given is not printed. e.g. to print "[]" we can
> now use the format "%(ifexists:[%s])%(refname)".
A handful of "huh?" on t
Karthik Nayak writes:
> On Tue, Jul 28, 2015 at 7:05 PM, Matthieu Moy
> wrote:
>
>> Ideally, you could also have a modifier atom %(alignleft) [...]
>
> This could work for refname, as each ref_array_item holds the refname,
> But other atoms are only filled in after a call to
> verify_ref_format(
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Actually, is there any reason why we do not allow a simple escaping like
>>
>> \# this is a line starting with #
>> \\ this is a line starting with \
>> # this is a comment
>
> What are we trying to achieve?
What I would like would be a simple
Signed-off-by: Thomas Ackermann
---
Documentation/technical/index-format.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/index-format.txt
b/Documentation/technical/index-format.txt
index b7093af..7392ff6 100644
--- a/Documentation/technical/index-
On Tue, Jul 28, 2015 at 2:20 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> --- a/t/t6302-for-each-ref-filter.sh
>> +++ b/t/t6302-for-each-ref-filter.sh
>> @@ -149,4 +149,25 @@ test_expect_success 'check `colornext` format option' '
>> test_cmp expect actual
>> '
>>
>> +test_expect_s
[+cc:Paul Tan]
On Sun, Jul 26, 2015 at 9:41 PM, Michael Haggerty wrote:
> On 07/23/2015 09:00 PM, Eric Sunshine wrote:
>> In addition to approxidate-style values ("2.months.ago", "yesterday"),
>> consumers of 'gc.*expire*' configuration variables also accept and
>> respect 'now'/'all' ("do it imm
Am 28.07.2015 um 17:23 schrieb Junio C Hamano:
Johannes Sixt writes:
Are you trying to say that the result of 'rev-parse --abbrev-ref HEAD'
is suboptimal and that of 'symbolic-ref --short HEAD' is OK?
My "Interesting" was primarily about that I wasn't aware of the
"--abbrev-ref" option.
Yes
On Mon, Jul 27, 2015 at 4:08 PM, David Turner wrote:
> refs: Introduce pseudoref and per-worktree ref concepts
>
> Add glossary entries for both concepts.
Based upon the above, I thought this was going to be a
documentation-only patch and was mildly surprised to find that it also
changed code. Pe
The latest maintenance release Git v2.4.7 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.4.7'
tag and the 'maint' branch that the tag points at:
url = https://kernel
Paul Tan writes:
> diff --git a/t/t4153-am-resume-override-opts.sh
> b/t/t4153-am-resume-override-opts.sh
> new file mode 100755
> index 000..c49457c
> --- /dev/null
> +++ b/t/t4153-am-resume-override-opts.sh
> @@ -0,0 +1,144 @@
> +#!/bin/sh
> +
> +test_description='git-am command-line optio
Paul Tan writes:
> When resuming, git-am ignores command-line options. For instance, when a
> patch fails to apply with "git am patch", subsequently running "git am
> --3way patch" would not cause git-am to fall back on attempting a
The second one goes without any file argument, i.e. "git am -3"
On Tue, Jul 28, 2015 at 1:24 PM, Jacob Keller wrote:
> On Mon, Jul 27, 2015 at 11:56 PM, Karthik Nayak wrote:
>> The 'ifexists' atom allows us to print a required format if the
>> preceeding atom has a value. If the preceeding atom has no value then
>
> Don't you mean "following atom" here? since
When resuming, git-am ignores command-line options. For instance, when a
patch fails to apply with "git am patch", subsequently running "git am
--3way patch" would not cause git-am to fall back on attempting a
threeway merge. This occurs because by default the --3way option is
saved as "false", and
On Tue, Jul 28, 2015 at 7:08 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> +static int filter_branch_kind(struct ref_filter *filter, const char
>> *refname)
>> +{
>> + int kind, i;
>> +
>> + static struct {
>> + int kind;
>> + const char *prefix;
>> + }
I was considering this case:
- git commit -a '-m# characters are now handled OK'
- hack, hack
- git commit -a '-mWhoops, fixed last commit'
- run git-rebase -i
- squash the second commit into the first
- when prompted for the log message for the combined change,
delete the "Whoops, fixed last co
Duy Nguyen writes:
> This seems like a good thing to fix (i.e. make sure XX is not
> ambiguous before creating it with "git checkout -b XX")
Yeah, sounds like an easy lunch-time hack low-hanging fruit :-).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
Matthieu Moy writes:
> Ed Avis writes:
>
>> Eric Sunshine sunshineco.com> writes:
>>
the editing for the
combined log message treats lines beginning with # as comments. This means
that if you are not careful the commit message can get lost on rebasing.
I suggest that git r
1 - 100 of 138 matches
Mail list logo
