Eric Sunshine writes:
> The pattern [y] will match file named 'y'. It probably is unusual for
> files named 'y', 'n', etc. to exist in the top-level directory, but
> the gitignore patterns already provide an escape hatch for these
> unusual cases.
But how does the user know that?
I'd rather sta
The last error I encountered is:
r7009 = 39805bb078983e34f2fc8d2c8c02d695d00d11c0 (refs/remotes/DMC4_Basic)
Too many open files: Can't open file
'/home/il/builds/sicap/gitsvn/prd_dmc4.svn/db/revs/0/786': Too many open
files at
/.snapshots/persist/builds/git/git-git/
Hi Eric. I'm out of spare time and I still unable to import my repo.
The code of SVN.pm is too complex. Please help me.
Here's the list of my issues:
* I think git-svn doesn't handle the case, when a tag is deleted.
I expected it to rename the ref from "tags/tagname" to
"tags/tagname@rev", but
Hi Matthieu,
On Mon, May 6, 2013 at 3:58 AM, Matthieu Moy
wrote:
> Eric Sunshine writes:
>
>> The pattern [y] will match file named 'y'. It probably is unusual for
>> files named 'y', 'n', etc. to exist in the top-level directory, but
>> the gitignore patterns already provide an escape hatch for
David Goldfarb writes:
> Git works correctly under Linux (Ubuntu 12.04; git 1.7.9.5). I've attached
> the strace outputs. (Note: for reasons that are probably irrelevant, I needed
> to run the commands sudo'd. Shout back if this is an issue).
>
> Under Windows 7, Cygwin git 1.7.9, commit fails
Dimitar Bonev writes:
> One more argument against the suggestion of doing a commit ahead of
> time is that I like to think in separation to reduce complexity - in
> particular I like to think only for the working dir and index states,
> commits - I treat them as finished work. If I have to amend
Looks like it works.
>From the windows machine:
U:\foo>git cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37foo1
100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014foo2
U:\foo>
Double-checking that nothing was fixe
Jonathan Nieder writes:
> Thomas Rast wrote:
>> Junio C Hamano writes:
>
>>> * jn/config-ignore-inaccessible (2013-04-15) 1 commit
>>> - config: allow inaccessible configuration under $HOME
>>>
>>> When $HOME is misconfigured to point at an unreadable directory, we
>>> used to complain and di
David Goldfarb writes:
> Looks like it works.
>
> From the windows machine:
> U:\foo>git cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
> 100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37foo1
> 100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014foo2
>
> U:\foo>
>
Ok. Continuing in the same shell:
U:\foo>git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# new file: trace1
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
>> Felipe Contreras writes:
>
>> How do we know that this doesn't break any users of fast-import? Your
>> comment isn't very reassuring:
>>
>>> the vast majority of them will never be used agai
Michael Haggerty writes:
> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
>> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
>>> Felipe Contreras writes:
>>
>>> How do we know that this doesn't break any users of fast-import? Your
>>> comment isn't very reassuring:
>>>
the vast majo
On 05/06/2013 12:32 PM, Thomas Rast wrote:
> Michael Haggerty writes:
>
>> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
>>> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
Felipe Contreras writes:
>>>
How do we know that this doesn't break any users of fast-import? Your
c
Oops, I earlier missed the second half of your message, where you suggested
that I patch move_temp_to_file().
Sorry, I don't have the tool-chain or knowledge to recompile git into this
win/Cygwin environment.
What I can do, realistically, is:
- Follow exact instructions.
- (with some obvious hes
On 05/03/2013 10:38 AM, Jeff King wrote:
> I found another race related to the packed-refs code. Consider for a
> moment what happens when we are looking at refs and another process does
> a simultaneous "git pack-refs --all --prune", updating packed-refs and
> deleting the loose refs.
>
> If we a
On 05/03/2013 07:28 PM, Jeff King wrote:
> On Fri, May 03, 2013 at 11:26:11AM +0200, Johan Herland wrote:
>
>> You don't really need to be sure that packed-refs is up-to-date. You
>> only need to make sure that don't rely on lazily loading loose refs
>> _after_ you have loaded packed-refs.
>
> Tr
Hi Thomas,
On Mon, 6 May 2013, Thomas Rast wrote:
> The proposed patch wants to stop writing marks (in --export-marks) for
> anything but commits.
Then it should not go in.
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.k
On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
> We don't care about blobs, or any object other than commits, but in
> order to find the type of object, we are parsing the whole thing, which
> is slow, specially in big repositories with lots of big files.
I did a double-take on
Commit 54bb901 (t/Makefile: fix result handling with
TEST_OUTPUT_DIRECTORY - 2013-04-26) incorrectly defined
TEST_RESULTS_DIRECTORY relative to itself, when it should be relative to
TEST_OUTPUT_DIRECTORY. Fix this.
Signed-off-by: John Keeping
---
t/Makefile | 2 +-
1 file changed, 1 insertion(+
Hi,
I'm getting a segfault in git merge-tree using v1.8.2.2 on MacOS
10.8.3. I can't share the repo, but I can build patches and check if
they fix the problem :)
Here's a bt:
(gdb) run
Starting program:
/usr/local/Cellar/git/1.8.2.2/libexec/git-core/git-merge-tree
027058e6ac8d03e029c4e1455bf90f6
> -Original Message-
> From: Thomas Rast
> Sent: Monday, May 06, 2013 5:42 AM
>
> David Goldfarb writes:
>
> > Git works correctly under Linux (Ubuntu 12.04; git 1.7.9.5). I've
> attached the strace outputs. (Note: for reasons that are probably
> irrelevant, I needed to run the commands
On Mon, May 06, 2013 at 03:02:10PM +0200, Andreas Jacobsen wrote:
> I'm getting a segfault in git merge-tree using v1.8.2.2 on MacOS
> 10.8.3. I can't share the repo, but I can build patches and check if
> they fix the problem :)
Can you rebuild with debugging information and try the backtrace aga
Jonathan Nieder writes:
> I ran into this message for the first time today.
>
> $ git fetch --all
> Fetching origin
> remote: Counting objects: 368, done.
> [...]
> Fetching gitk
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and t
Hello,
The included patch attempts to improve post-receive-email. It's a
trivial change, but one that helps us Gitolite users. Comments are
welcome, and this is my first attempt at contributing to the Git
project. Please keep me on CC as I'm not on the list.
>From 878a7af9088e2bcc3afc9b09b9023f1
Sure, here you go, this time built from the HEAD I found on github
(7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
NO_GETTEXT=1 make prefix=/usr/local/Cellar/git/HEAD CC=cc CFLAGS='-O0
-g' install (this is homebrew's setup, but I built it manually rather
than using the recipe.)
And the gdb outpu
On Mon, May 06, 2013 at 04:13:28PM +0200, Andreas Jacobsen wrote:
> Sure, here you go, this time built from the HEAD I found on github
> (7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
>
> NO_GETTEXT=1 make prefix=/usr/local/Cellar/git/HEAD CC=cc CFLAGS='-O0
> -g' install (this is homebrew's setu
Felipe Contreras writes:
> On Wed, May 1, 2013 at 6:14 PM, Felipe Contreras
> wrote:
>> On Wed, May 1, 2013 at 5:59 PM, Junio C Hamano wrote:
>
>>> It is just the "strip this, strip that" explanation, which is not
>>> technically correct, does _not_ have to be our justification for
>>> picking
On Mon, May 06, 2013 at 03:29:23PM +0100, John Keeping wrote:
> On Mon, May 06, 2013 at 04:13:28PM +0200, Andreas Jacobsen wrote:
> > Sure, here you go, this time built from the HEAD I found on github
> > (7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
> >
> > NO_GETTEXT=1 make prefix=/usr/local/
Dimitar Bonev writes:
[administrivia: please do not drop people out of Cc list]
> Actually this is not the case as I tried to explain with the 'git
> commit' followed by 'git checkout HEAD~1 -- targetfile' followed by
> 'git commit --amend' example. The index and the working dir states are
> ver
Jeff King writes:
> On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
>
>> We don't care about blobs, or any object other than commits, but in
>> order to find the type of object, we are parsing the whole thing, which
>> is slow, specially in big repositories with lots of big file
Michael Haggerty writes:
> Yes, it can be handy to start loading the first "blobfile" in parallel
> with the later stages of the conversion, before the second "dumpfile" is
> ready. In that case the user needs to pass --export-marks to the first
> fast-import process to export marks on blobs so
John Keeping writes:
> Commit 54bb901 (t/Makefile: fix result handling with
> TEST_OUTPUT_DIRECTORY - 2013-04-26) incorrectly defined
> TEST_RESULTS_DIRECTORY relative to itself, when it should be relative to
> TEST_OUTPUT_DIRECTORY. Fix this.
>
> Signed-off-by: John Keeping
> ---
> t/Makefile
git-merge-tree causes a null pointer dereference when a directory
entry exists in only one or two of the three trees being compared with
no corresponding entry in the other tree(s).
When this happens, we want to handle the entry as a directory and not
attempt to mark it as a file merge. Do this b
Trond Hasle Amundsen writes:
> The included patch attempts to improve post-receive-email. It's a
> trivial change, but one that helps us Gitolite users. Comments are
> welcome, and this is my first attempt at contributing to the Git
> project. Please keep me on CC as I'm not on the list.
Bah.. I
[ Unashamedly offtopic... asking here because I like git design and
coding style, and ppg is drawing plenty of inspiration from the old
git shell scripts. Please kindly flame me privately... ]
ppg is a wrapper around git to maintain and distribute Puppet configs,
adding a few niceties.
Now, ppg w
Trond Hasle Amundsen writes:
> Hello,
>
> The included patch attempts to improve post-receive-email. It's a
Please don't ;-)
Eh, actually, thanks for the patch.
But when you send a patch the next time around, please have the
above and the next three lines (i.e. "introductory text") _below_
the
Junio C Hamano writes:
> Trond Hasle Amundsen writes:
>
>> Hello,
>>
>> The included patch attempts to improve post-receive-email. It's a
>
> Please don't ;-)
More precisely: you should have a look at git-multimail (in directory
contrib/, in branch for now pu/, or from
https://github.com/mhagge
On Mon, May 06, 2013 at 11:34:28AM -0400, Martin Langhoff wrote:
> [ Unashamedly offtopic... asking here because I like git design and
> coding style, and ppg is drawing plenty of inspiration from the old
> git shell scripts. Please kindly flame me privately... ]
>
> ppg is a wrapper around git to
Junio C Hamano writes:
> By discarding marks on blobs, we may be robbing some optimization
> possibilities, and by discarding marks on tags, we may be robbing
> some features, from users of fast-export; we might want to add an
> option "--use-object-marks={blob,commit,tag}" or something to both
>
On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote:
> > I'm also not sure why your claim "we don't care about blobs" is true,
> > because naively we would want future runs of fast-export to avoid having
> > to write out the whole blob content when mentioning the blob again.
>
> The ex
Junio C Hamano writes:
> But when you send a patch the next time around, please have the
> above and the next three lines (i.e. "introductory text") _below_
> the three-dash line.
Allright, noted.
>> From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001
>> From: Trond Hasle Amu
Matthieu Moy writes:
>>> The included patch attempts to improve post-receive-email. It's a
>>
>> Please don't ;-)
>
> More precisely: you should have a look at git-multimail (in directory
> contrib/, in branch for now pu/, or from
> https://github.com/mhagger/git-multimail) before spending time o
Jeff King writes:
> On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote:
>
>> > I'm also not sure why your claim "we don't care about blobs" is true,
>> > because naively we would want future runs of fast-export to avoid having
>> > to write out the whole blob content when mentioning t
On Mon, May 06, 2013 at 09:32:41AM -0700, Junio C Hamano wrote:
> > OK. If the argument is "we do not write them, so do not bother reading
> > them back in", I think that is reasonable.
>
> The way I read builtin/fast-export.c::import_marks() is that it is
> more like "we do not write them, and w
Translate 44 new messages came from git.pot update in
c6bc7d4 (l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 139 +++
1 file changed, 77 insertions(+), 62 deletions(-)
diff --git a/po/d
Johan Herland writes:
> Let me try to summarize my views on how refnames should work in Git, to
> see if we can identify where we differ on the principles (or if we, in
> fact, differ at all):
Thanks; I think I already said where I think we differ in a separate
message, but a short version is th
Santi Béjar writes:
> The next question could be: why not make it work with $url too? As in:
>
> $ git merge git://git.kernel.org/pub/scm/git/git.git//master
You need to remember "merge" is a local operation, working in your
local repository. Like it or not, the UI of Git makes distinction
betw
Jeff King writes:
> So yes, I think this is an obviously correct optimization. Thanks for
> clarifying, and sorry to be so slow.
No need to be sorry. It just shows that the log message could have
been more helpful.
Here is what I tentatively queued.
commit 83582e91d22c66413b291d4d6d45bbeafddc
On Mon, May 06, 2013 at 10:17:41AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So yes, I think this is an obviously correct optimization. Thanks for
> > clarifying, and sorry to be so slow.
>
> No need to be sorry. It just shows that the log message could have
> been more helpful.
>
Junio C Hamano writes:
Just a few typofixes...
> Johan Herland writes:
>
>> Let me try to summarize my views on how refnames should work in Git, to
>> see if we can identify where we differ on the principles (or if we, in
>> fact, differ at all):
>
> Thanks; I think I already said where I think
On Mon, May 06, 2013 at 01:19:35PM -0400, Jeff King wrote:
> > Here is what I tentatively queued.
> > [...]
>
> Yeah, that is much for to understand (to me, at least).
Ugh. That was supposed to be "much easier to understand". Perhaps I will
learn to type one day.
-Peff
--
To unsubscribe from th
Johan Herland writes:
> ... there is AFAICS _no_ way for sscanf() - having
> already done one or more format extractions - to indicate to its caller
> that the input fails to match the trailing part of the format string.
Yeah, we can detect when we did not have enough, but we cannot tell
where i
I've observed that the p4 command that git-p4 delegates to occasionally
outputs Windows-style line endings even on the OS X platform. When this
happens, git-p4 gets very confused and crashes out.
I've attached a patch which seems to fix the issue in my case. Now this
patch is a pretty bad hack
On Mon, May 06, 2013 at 02:03:40PM +0200, Michael Haggerty wrote:
> > We could fix this by making sure our packed-refs file is up to date
>
> s/file/cache/
Yeah, I meant "our view of the packed-refs file", but I think "cache"
says that more succinctly. I'll be sure to make it clear when I start
On Mon, May 06, 2013 at 02:12:29PM +0200, Michael Haggerty wrote:
> > I think that would be correct (modulo that step 1 cannot happen for
> > enumeration). But we would like to avoid loading all loose refs if we
> > can. Especially on a cold cache, it can be quite slow, and you may not
> > even ca
On Mon, May 6, 2013 at 7:31 AM, Jeff King wrote:
> On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
>
>> We don't care about blobs, or any object other than commits, but in
>> order to find the type of object, we are parsing the whole thing, which
>> is slow, specially in big repo
On Mon, May 6, 2013 at 10:08 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
>>
>>> We don't care about blobs, or any object other than commits, but in
>>> order to find the type of object, we are parsing the whole thing, which
On Mon, May 06, 2013 at 02:02:13PM -0500, Felipe Contreras wrote:
> > I did a double-take on reading this subject line and first paragraph,
> > thinking "surely fast-export needs to actually output blobs?".
>
> If you think that, then you are not familiar with the code.
>
> --export-marks=::
> [
On Mon, May 6, 2013 at 11:20 AM, Jeff King wrote:
> On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote:
>
>> > I'm also not sure why your claim "we don't care about blobs" is true,
>> > because naively we would want future runs of fast-export to avoid having
>> > to write out the whole
On Mon, May 6, 2013 at 2:11 PM, Jeff King wrote:
> On Mon, May 06, 2013 at 02:02:13PM -0500, Felipe Contreras wrote:
>
>> > I did a double-take on reading this subject line and first paragraph,
>> > thinking "surely fast-export needs to actually output blobs?".
>>
>> If you think that, then you ar
Am 06.05.2013 02:19, schrieb Chris Packham:
> This did get me thinking. Why does an uninitialized submodule need to
> have an empty directory? If it didn't the maintainer in question
> probably would have realized that he needed to run "git submodule
> update --init" when his "cd submodule" command
El 06/05/2013 19:11, "Junio C Hamano" va escriure:
>
> Santi Béjar writes:
>
> > The next question could be: why not make it work with $url too? As in:
> >
> > $ git merge git://git.kernel.org/pub/scm/git/git.git//master
>
> You need to remember "merge" is a local operation, working in your
> loc
Implement a 'git add --interactive' style of interactive git-clean.
It will show what would be done before start to clean. See
``Interactive mode`` for details.
Interactive mode
When the command enters the interactive mode, it shows the
files and directories to be cleaned, and go
Show what would be done and the user must confirm before actually
cleaning. In the confirmation dialog, the user has three choices:
* y/yes: Start to do cleaning.
* n/no: Nothing will be deleted.
* e/edit: Exclude items from deletion using ignore patterns.
When the user chooses the edit mod
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns instead of in one column will solve
this problem.
Since no longer show items to be cleaned using the "Would remove ..."
format (only plain filenames) in interactive mode, we add instructions
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables for other git commands, such as
git-add--interactive and git-stash:
* color.interactive: When set to always, always use colors for
interactive prompts and displays. When false (or never),
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We can reused this method later for
more actions.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated memory of the array.
* The a
The documentation assures users that "A...B" is defined as 'r1 r2 --not
$(git merge-base --all r1 r2)'. This isn't in fact quite true, because
the calculated merge bases are not sent to add_rev_cmdline().
Previously, the effect was pretty minor - all that I can think of is
that "git rev-list --anc
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and retur
Add a "rm -i" style interactive cleaning method. User must confirm one
by one before starting to delete.
Signed-off-by: Jiang Xin
---
builtin/clean.c | 36
1 file changed, 36 insertions(+)
diff --git a/builtin/clean.c b/builtin/clean.c
index 3b07f..f36ad 100
Signed-off-by: Jiang Xin
---
Documentation/git-clean.txt | 70 -
1 file changed, 63 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index f5572..56d60 100644
--- a/Documentation/git-clean.txt
+++ b/D
Ralf Thielow writes:
> #: branch.c:275
> -#, fuzzy, c-format
> +#, c-format
> msgid "Not a valid branch point: '%s'."
> -msgstr "Ungültiger Zweig-Name: '%s'"
> +msgstr "Ungültige Zweig-Version: '%s'"
That's a bit strange and calls for a proper translation of "branch
point". "Abzweigung" is re
Kevin Bracey writes:
> Some side branching and odd merging to illustrate various flaws in
> revision list scans, particularly when limiting the list.
>
> Many expected failures, which will be gone by the end of the "history
> traversal refinements" series.
>
> Signed-off-by: Kevin Bracey
> ---
>
On 04/30/13 15:47, René Scharfe wrote:
> Am 30.04.2013 02:11, schrieb Stephen Boyd:
>> (resending since the attachment seems to make vger sad)
>>
>> Hi,
>>
>> I'm running git rev-list | git cherry-pick --stdin on a range of about
>> 300 commits. Eventually the chery-pick dies with:
>>
>> error
Kevin Bracey writes:
> +#,---E--. *H--. * marks !TREESAME parent paths
> +# /\ / \*
> +# *A--*B---D--*F-*G-K-*L-*M
> +# \ /* \ /
> +#`-C-' `-*I-*J
> +#
> +# A creates "file", B and F change it.
> +# Odd
Kevin Bracey writes:
> diff --git a/revision.c b/revision.c
> index a67b615..c88ded8 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -429,10 +429,100 @@ static int rev_same_tree_as_empty(struct rev_info
> *revs, struct commit *commit)
> return retval >= 0 && (tree_difference == REV_TREE_
Felipe Contreras writes:
>> The story is different on the fast-import side, where we do say we
>> dump the full table and a later run can depend on these marks.
>
> Yes, and gaining nothing but increased disk-space.
I thought that the "gaining nothing" has already been refuted by the
discussion
On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty wrote:
> On 05/06/2013 12:32 PM, Thomas Rast wrote:
>> Michael Haggerty writes:
>>
>>> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
> Felipe Contreras writes:
> How do we kn
On Mon, May 6, 2013 at 7:20 AM, Johannes Schindelin
wrote:
> Hi Thomas,
>
> On Mon, 6 May 2013, Thomas Rast wrote:
>
>> The proposed patch wants to stop writing marks (in --export-marks) for
>> anything but commits.
>
> Then it should not go in.
If that rationale was valid, no change in behavior
On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Yes, it can be handy to start loading the first "blobfile" in parallel
>> with the later stages of the conversion, before the second "dumpfile" is
>> ready. In that case the user needs to pass --export-marks t
Kevin Bracey writes:
> The documentation assures users that "A...B" is defined as 'r1 r2 --not
> $(git merge-base --all r1 r2)'. This isn't in fact quite true, because
> the calculated merge bases are not sent to add_rev_cmdline().
We want the commands to be able to tell which ones in revs->pend
On Mon, May 6, 2013 at 3:58 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> The story is different on the fast-import side, where we do say we
>>> dump the full table and a later run can depend on these marks.
>>
>> Yes, and gaining nothing but increased disk-space.
>
> I thought that
When using -s for commit, revert, and format-patch (there
may be more) command the comments message gets a generated
and hard-coded signed-off-by message. For some projects a
different header is used, eg. HostAP. Adding a config parameter
named 'signoff.label'.
Signed-off-by: Arend van Spriel
---
On Mon, May 6, 2013 at 4:19 PM, Felipe Contreras
wrote:
> On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> Yes, it can be handy to start loading the first "blobfile" in parallel
>>> with the later stages of the conversion, before the second "dumpfile" is
On Mon, May 06, 2013 at 02:41:22PM -0400, Jeff King wrote:
> That is a weaker guarantee, and I think we can provide it with:
>
> 1. Load all loose refs into cache for a particular enumeration.
>
> 2. Make sure the packed-refs cache is up-to-date (by checking its
> stat() information and
On Tue, Jan 22, 2013 at 08:49:22AM +0100, Robin Rosenberg wrote:
> Specifically the fields uid, gid, ctime, ino and dev are set to zero
> by JGit. Other implementations, eg. Git in cygwin are allegedly also
> somewhat incompatible with Git For Windows and on *nix platforms
> the resolution of the
On Mon, May 6, 2013 at 7:06 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> Let me try to summarize my views on how refnames should work in Git, to
>> see if we can identify where we differ on the principles (or if we, in
>> fact, differ at all):
>
> Thanks; I think I already said where I th
Kevin Bracey writes:
> On 04/05/2013 20:25, Ramsay Jones wrote:
>> Sparse issues an "'sole_interesting' not declared. Should it be static?"
>> warning. In order to suppress the warning, since this symbol does not
>> need more than file visibility, we simply add the static modifier to
>> its decla
Johan Herland writes:
> +test_expect_success 'work-around "clone" with namespaced remote refs' '
> + rm -rf client &&
> + git init client &&
> + (
> + cd client &&
> + git remote add origin ../server &&
> + git config --unset-all remote.origin.fetch
Johan Herland writes:
> This test verifies that the following expressions all evaluate to the
> full refname "refs/remotes/origin/heads/master":
As I've aleady said, I am not convinced that local refname
resolution should pay attention to refspec mapping, so I won't look
at this step.
--
To unsu
Johan Herland writes:
> diff --git a/refs.c b/refs.c
> index 7231f54..8b02140 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1724,7 +1724,24 @@ const char *prettify_refname(const char *name)
> 0);
> }
>
> -const char *ref_rev_parse_rules[] = {
> +static void ref_expand_txtly(const st
Johan Herland writes:
> This patch removes the only remaining user of ref_rev_parse_rules.
> It has now been fully replaced by ref_expand_rules. Hence this patch
> also removes ref_rev_parse_rules.
Yeah, I was wondering when you would do this while reading [4/7], as
removing the parse_rules[] wo
Johan Herland writes:
> refname_match() is used to check whether a given shorthand name matches a
> given full refname, but that full refname does not always belong in the
> local repo, rather it is sometimes taken from list of refs sent over from
> a remote repo.
That "local vs remote" is a wro
Felipe Contreras writes:
>>> How?
>>
>> * if we teach fast-import to optionally not write marks for blobs
>>and trees out, your remote-bzr can take advantage of it,
>
> I already said remote-bzr is irrelevant. *Everybody* benefits.
Everybody who does _not_ need to look at marks for non-comm
I'd love for "git apply" to have an equivalent to "git add -p". (I'm
guessing it would be called --interactive since "git apply -p" is
taken and --patch would be confusing.) Has anyone thought about this?
After taking a quick look at git-add--interactive.perl, it seems like
the main steps would
Johan Herland writes:
> Ok, so whereas I consider the refspec to be "king", and that the expansion
> from convenient shorthands to full remote-tracking refnames should be
> derived from the chosen refspec, you would (if I understand you correctly)
> rather have a constant (i.e. independent of rem
This fixes the races I brought up in the surrounding thread:
http://thread.gmane.org/gmane.comp.version-control.git/223299
The individual races are describe in more detail in each commit, but for
reference, here is the complete reproduction recipe (which I posted
already in several parts throug
When we attempt to resolve a ref, the first thing we do is
call lstat() to see if it is a symlink or a real ref. If we
find that the ref is missing, we fall back to looking it up
in the packed-refs file. If we find the loose ref does exist
(and is a regular file), we continue with trying to open it
It can sometimes be useful to know whether a path in the
filesystem has been updated without going to the work of
opening and re-reading its content. We trust the stat()
information on disk already to handle index updates, and we
can use the same trick here.
This patch introduces a "stat_validity"
Once we read the packed-refs file into memory, we cache it
to save work on future ref lookups. However, our cache may
be out of date with respect to what is on disk if another
process is simultaneously packing the refs. Normally it
is acceptable for us to be a little out of date, since there
is no
1 - 100 of 129 matches
Mail list logo
