gree...@obbligato.org writes:
> "David A. Greene" writes:
>
>> From: Techlive Zheng
>>
>> Use %B to format the commit message and body to avoid an extra newline
>> if a commit only has a subject line.
>
> Wow. So that was a spectacular fail. Sorry about th duplicate patch
> e-mails. I have no
"David A. Greene" writes:
> From: Techlive Zheng
>
> Use %B to format the commit message and body to avoid an extra newline
> if a commit only has a subject line.
Is this an unconditional improvement, or is it generally an
improvement but for some users it may be a regression? I am
guessing it
gree...@obbligato.org writes:
> Junio C Hamano writes:
>
>>> With one positional option, git-subtree add simply assumes
>>> it's a refspec. Is there an easy way to check whether a string is a
>>> proper refspec? Even better would be a way to check if a string is a
>>> path to a git repository.
On Tue, Jan 1, 2013 at 1:06 AM, Shawn Pearce wrote:
>> 3. Dropping the "commits" file and just using the pack-*.idx as the
>> index. The problem is that it is sparse in the commit space. So
>> just naively storing 40 bytes per entry is going to waste a lot of
>> space. If we had a
"David A. Greene" writes:
> From: Techlive Zheng
>
> Use %B to format the commit message and body to avoid an extra newline
> if a commit only has a subject line.
Wow. So that was a spectacular fail. Sorry about th duplicate patch
e-mails. I have no idea how that happened.
Junio C Hamano writes:
>> With one positional option, git-subtree add simply assumes
>> it's a refspec. Is there an easy way to check whether a string is a
>> proper refspec? Even better would be a way to check if a string is a
>> path to a git repository.
>
> Do you literally mean "a path to a
gree...@obbligato.org writes:
> I've applied this patch to my working copy but I'm not finding that I
> can recreate the original problem when the patch is disabled.
^ not
-David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
From: Michael Schubert
Add the git-subtree command executable to .gitignore.
Author:Michael Schubert
Signed-off-by:Michael Schubert
Signed-off-by: David A. Greene
---
contrib/subtree/.gitignore |1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/subtree/.gitignore b/cont
From: "Jesper L. Nielsen"
Before install git-subtree documentation, make sure the manpage
directory exists.
Author:Jesper L. Nielsen
Signed-off-by:Jesper L. Nielsen
Signed-off-by: David A. Greene
---
contrib/subtree/Makefile |1 +
1 file changed, 1 insertion(+)
diff --git a/co
From: Michael Schubert
"split" is documented below "push" so fix the reference to it in
push's documentation.
Author:Michael Schubert
Signed-off-by:Michael Schubert
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.txt |2 +-
1 file changed, 1 insertion(+), 1 delet
From: "David A. Greene"
Fix the documentation of add to show that a repository can be
specified along with a commit.
Change "commit" to "refspec" in the synopsis for add.
Suggested by Yann Dirson .
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh |3 ++-
contrib/subtree
From: Adam Tkac
Teach git-subtree's Makefile to honor DESTDIR.
Author:Adam Tkac
Signed-off-by:Adam Tkac
Signed-off-by: David A. Greene
---
contrib/subtree/Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/
From: "David A. Greene"
Check refspecs for validity before passing them on to other commands.
This lets us generate more helpful error messages.
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh | 12
1 file changed, 12 insertions(+)
diff --git a/contrib/subtree
From: James Nylen
Teach git-subtree about --unannotate. This option strips a prefix
from a commit message when doing a subtree split.
Author:James Nylen
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh | 11 +-
contrib/subtree/git-subtree.txt| 15 +++
From: Techlive Zheng
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Author:Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh |5 +++
contrib/subtree/t/t7900-subtree.sh | 73 +
Here are all of the patches for git-subtree that have been posted to
the mailing list that I could apply and test in a reasonable amount of
time. These are all rebased from trunk as of tonight.
Many apologies for being *so* behind. Work has been a bear but I'm
hoping things will ease up in the n
gree...@obbligato.org writes:
> git-subtree add accepts either a refspec or a path to a repository and a
> refspec.
> With one positional option, git-subtree add simply assumes
> it's a refspec. Is there an easy way to check whether a string is a
> proper refspec? Even better would be a way to
Michael Schubert writes:
> Signed-off-by: Michael Schubert
Obviously good. Applied and will send for integration.
-David
--
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
"Jesper L. Nielsen" writes:
> So, small patch to create the folder first in the Makefile. Hope
> everything is right with the patch and submitting of the patch.
I've applied this to my local copy and will send it to the list for
integration.
Thanks for fixing this!
-Da
On Sat, Dec 22, 2012 at 3:33 PM, Junio C Hamano wrote:
> The --reroll-count=$N option, when given a positive integer:
>
> - Adds " v$N" to the subject prefix specified. As the default
>subject prefix string is "PATCH", --reroll-count=2 makes it
>"PATCH v2".
>
> - Prefixes "v$N-" to the
Junio C Hamano writes:
> "Jesper L. Nielsen" writes:
>
>> From: "Jesper L. Nielsen"
>>
>> Hi..
>>
>> I installed Git subtree and discovered that the if the man1dir doesn't exist
>> the man-page for Git Subtree is just called man1.
>>
>> So, small patch to create the folder first in the Makefil
Adam Tkac writes:
> Signed-off-by: Adam Tkac
> ---
>
> It is a good habit in Makefiles to honor DESTDIR variable to support
>
> `make DESTDIR=/instalroot install`
>
> syntax.
>
> Comments are welcomed.
Applied. I'll be sending this to the mailing list tonight or tomorrow.
Yann Dirson writes:
> As the examples in git-subtree.txt show, the synopsis in the same file should
> surely get a patch along the lines of:
>
> -'git subtree' add -P
> +'git subtree' add -P
>
> Failure to specify the repository (by just specifying a local commit) fails
> with
> the cry
This is similar to NO_FNMATCH but it uses wildmatch instead of
compat/fnmatch. This is an intermediate step to let wildmatch be used
as fnmatch replacement for wider audience before it replaces fnmatch
completely and compat/fnmatch is removed.
fnmatch in test-wildmatch is not impacted by this and
Normally when we match "*X" on "abcX", we call dowild("X", "abcX"),
dowild("X", "bcX"), dowild("X", "cX") and dowild("X", "X"). Only the
last call may have a chance of matching. By skipping the text before
"X", we can eliminate the first three useless calls.
compat, '*/*/*' on linux-2.6.git file l
Normally we need recursion for "*". In this case we know that it
matches everything until "/" so we can skip the recursion.
glibc, '*/*/*' on linux-2.6.git file list 2000 times
before:
wildmatch 8s 74513us
fnmatch 1s 97042us or 13.59% faster
after:
wildmatch 3s 521862us
fnmatch 3s 488616us or
So far, wildmatch() has always honoured directory boundary and there
was no way to turn it off. Make it behave more like fnmatch() by
requiring all callers that want the FNM_PATHNAME behaviour to pass
that in the equivalent flag WM_PATHNAME. Callers that do not specify
WM_PATHNAME will get wildcard
It takes a text file, a pattern, a number and pathname flag. Each
line in the text file is matched against the pattern times. If
"pathname" is given, FNM_PATHNAME is used.
test-wildmatch is built with -O2 and tested against glibc 2.14.1 (also
-O2) and compat/fnmatch. The input file is linux-2.6.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wildmatch.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index 2a655fa..1b5bbac 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -52,7 +52,7 @@ typedef unsigned char uchar;
#define ISXDIGIT(c) (I
- All exported constants now have a prefix WM_
- Do not rely on FNM_* constants, use the WM_ counterparts
- Remove TRUE and FALSE to follow Git's coding style
- While at it, turn flags type from int to unsigned int
- Add an (unused yet) argument to carry extra information
so that we don't have to
Signed-off-by: Nguyễn Thái Ngọc Duy
---
compat/fnmatch/fnmatch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
index 9473aed..6f7387d 100644
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch.c
@@ -55,7 +55,8 @@
'special' is too generic and is used for two different purposes.
Replace it with 'match_slash' to indicate "**" pattern and 'negated'
for "[!...]" and "[^...]".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wildmatch.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --gi
"**" is adjusted to only be effective when surrounded by slashes, in
40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
the commit did it wrong:
1. when it checks for "the preceding slash unless ** is at the
beginning", it compares to wrong pointer. It should have compared
t
The first patch actually belongs to nd/wildmatch as it fixes how "**"
is only effective when it's surrounded by slashes.
Other fixes from v2 are WM_PATHNAME check is replaced by match_slash
(or "special" previously) in 8/10 and 9/10. WM_PATHNAME is only used
to set match_slash. If we rely on (the
Drew Crawford writes:
> Ideally it would be better to emit an error-message from a script
> higher up the calling chain that would be more descriptive about the
> problem (such as suggesting no branch is specified).--
Ok, I used git rev-parse --verify and I have this working now. Will
send to J
Drew Crawford writes:
> Ideally it would be better to emit an error-message from a script
> higher up the calling chain that would be more descriptive about the
> problem (such as suggesting no branch is specified).--
I'm looking at implementing this but I need a bit of help from the git
experts
Yann Dirson writes:
> Ah, it's nice to see subtree updates. Any plans to get them merged anytime
> soon ?
As soon as there is one patch per feature that applies cleanly to
contrib/ and testcases use the native git test facility.
These patches should be submitted to the mailing list for review
Drew Crawford writes:
> I noticed today that if you leave off the branch name from git subtree like
> so:
>
> $ git subtree add --prefix somewhere -m "adding CDH as subtree" path/to/repo
> warning: read-tree: emptying the index with no arguments is deprecated; use
> --empty
> fatal: just how do
Junio C Hamano writes:
> Maybe it is a seasonal thing, just before the holiday season, but
> this has been unresponded for a couple of months, not even with a
> "That combination is not supported", or "Thanks for a bug report".
I did finally see this message. I totally admit that I've been pret
Tomi Belan writes:
> Thanks. Here's one more bump. Avery? David?
I don't know how this is supposed to work, unfortunately. I'm still in
the middle of learning the code...
-David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
Dear Mr. Hamano,
so i /did/ misunderstand the documentation – my fault. Thank you very much for
your rapid clarification!
With grateful greetings,
Dennis Heidsiek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More major
James Nylen writes:
> Rather than adding a marker to each commit when splitting out the
> commits back to the subproject, --unannotate removes the specified
> string (or bash glob pattern) from the beginning of the first line of
> the commit message. This enables the following workflow:
I appli
Dennis Heidsiek writes:
> i think there may be a bug in the fetch command: The command
>
>> $ git fetch --all --tags
>> Fetching origin
>
> doesn’t fetch new commits from origin/master, while i see via the
> web browser of my remote repository that they exist.
The "--all" option asks to fetch fr
Dear Git community,
i think there may be a bug in the fetch command: The command
$ git fetch --all --tags
Fetching origin
doesn’t fetch new commits from origin/master, while i see via the web browser
of my remote repository that they exist. The same with verbose:
$ git fetch --all --tags
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is at 1.8.1; the tip of 'next' will
be rewound soonish to reorder topics that are already well cooked
during the
The latest feature release Git v1.8.1 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
ac8dced9c3232c0ec6a88d04600a4d0eaf2ba4e3 git-1.8.1.tar.gz
a256fc56c89dc3c8d58b81a2c02dc89299f1f29b
Jason Holden writes:
> git-gui, gitk, and git-po are maintained upstream of git.
> Document this, and the procedure for submitting patches to these tools
>
> Signed-off-by: Jason Holden
> ---
> Documentation/SubmittingPatches | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a
On Thu, Dec 27, 2012 at 09:27:37AM -0800, Junio C Hamano wrote:
> Peter Hofmann writes:
>
> > Subject: Re: [PATCH] gitk: Replaced "green" with "#00FF00".
>
> > gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now
> > because it has changed from "#00FF00" to "#008000".
>
> Your
Herman van Rink writes:
>> Has anybody looked at this?
>>
>> It has been very useful for me.
I am looking at it now.
> The version of subtree in contrib is rather out-dated unfortunately.
It is the official version. What's missing? You have a bunch of
changes that need rework to include into
gree...@obbligato.org writes:
> Techlive Zheng writes:
>
>> "%s%n%n%b" is not always equal to "%B". If the commit msg does not have
>> a body, this will append an extra new-line character to the msg title
>> which would cause the splited commit has a new sha1 hash. In most cases,
>> this does not
Neil writes:
> Actual: git-subtree.1 fails to be generated because my system doesn't ship
> asciidoc and xmlto.
Well, you need those tools to build ANY git documentation. I just ran a
test to build git-subtree and its documentation and it went just fine.
This is not a bug.
One minor grammar nit below.
On Mon, Dec 31, 2012 at 2:19 PM, Jason Holden
wrote:
> Certain parts of git have a semi-formalized workflow for
> incoming patches. This file documents the maintainers, their area of
> specialization, their email address, and their canonical repository against
> whic
On Mon, Dec 31, 2012 at 03:27:36PM +1100, Paul Mackerras wrote:
>
> Thanks for the patch. I have a couple of comments about it. First,
> the exec command waits for the process to complete, which means that
> the initial gitk GUI will be unresponsive until the user quits the
> gitk window showing
The credit lines "By" and "Via" to credit authors and committers for
their contributions on the side branch are meant as a hint to the
integrator to decide whom to mention in the log message text. After
the integrator saves the message in the editor, they are meant to go
away and that is why they
Thomas Ackermann writes:
>> Thanks; I just realized that nothing in Documentation/ hierarchy
>> mentions these; they are only mentioned in "A Note from the
>> Maintainer" I send out every once in a while (kept in MaintNotes of
>> 'todo' branch):
>
> Wouldn't it be a good idea to put MaintNotes so
Grégory Pakosz writes:
> 1) either make git-filter-branch dereference annotated tags and do
> the verification itself then use the two arguments version of git
> update-ref
> 2) in the case of an annotated tag, pass another to git
> update-ref
>
> Please find below a patch that implements s
On Mon, Dec 31, 2012 at 09:40:19AM +, Thomas Ackermann wrote:
> Junio C Hamano pobox.com> writes:
>
> >
> > Thanks; I just realized that nothing in Documentation/ hierarchy
> > mentions these; they are only mentioned in "A Note from the
> > Maintainer" I send out every once in a while (kept
This thread is pretty interesting. Unfortunately the holidays have
kept me busy. But I am excited by the work David and Peff are doing.
:-)
On Sun, Dec 30, 2012 at 1:31 PM, Jeff King wrote:
> On Sun, Dec 30, 2012 at 07:53:48PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > $ cd objects/pack && ls
>>
Hi Rupert,
On Sat, 29 Dec 2012, rupert THURNER wrote:
> ich hab gesehen, du bist ober-meister des kernle.org git wikis. da
> gibt es ganz schön viel neue user und spam derzeit, zb:
> https://git.wiki.kernel.org/index.php?title=User_talk:Bridgetevans0521&redirect=no
>
> möchtest du das erzeugen v
Please disregard the previous email that contains an incorrect fix
suggestion. I wish my first contribution was flawless.
Here is what's happening.
git-filter-branch let git-update-ref -d verify that the value for $ref
matches $sha1.
However, when $ref points to an annotated tag that is being dele
Hello,
I noticed git-filter-branch doesn't dereference annotated tags prior
to invoking git update-ref -d.
Please find a patch attached that changes the call to git update-ref:
-git update-ref -m "filter-branch: delete" -d "$ref" $sha1
+git update-ref -m "filter-branch: delete" -d $(git rev-pars
On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote:
> It concerns me that git uses any locking at all, even for
> refs since it has the potential to leave around stale
> locks.
> ...
> [a previous not so great attempt to fix this]
> ...
I may have finally figured out a working loose ref
Junio C Hamano pobox.com> writes:
>
> Thanks; I just realized that nothing in Documentation/ hierarchy
> mentions these; they are only mentioned in "A Note from the
> Maintainer" I send out every once in a while (kept in MaintNotes of
> 'todo' branch):
>
Wouldn't it be a good idea to put Maint
>
> Implementation details are part of API; CG and SP are social not
> technical.
>
This depends on your definition of "social" ;-)
>
> Also CG and SP are in the part of the documents that are not
> installed for end-users and that is their right place. They matter
> only to the people who gr
65 matches
Mail list logo
