Junio C Hamano wrote:
> Sverre Rabbelier writes:
>> Perhaps it makes sense to instead count the number of signed tags and
>> emit "Stripped signature from %d tags"? For example, for git.git it
>> would be on the order of a hundred warning lines.
>
> When you see 78 in the output and you know you
On Mon, Apr 15, 2013 at 11:12 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> So it should be clear now: the remote namespace refs/origin/master is
>> updated, but not the remote helper's namespace
>> refs/testgit/origin/master, which is what I already said. I don't know
>> what more do
Ramkumar Ramachandra wrote:
> "If there were uncommitted worktree changes present when the merge
> started, git merge --abort will in some cases be unable to reconstruct
> these changes. It is therefore recommended to always commit or stash
> your changes before running git merge."
>
> Matthieu (a
Jonathan Nieder wrote:
> I wouldn't be surprised if there's still a documentation bug, though:
> a lack of clarity, a missing hint somewhere else, something else
> misleading. That seems especially likely when you say "I trusted the
> documentation on this one". Care to point to the appropriate s
On Mon, Apr 15, 2013 at 9:47 PM, Junio C Hamano wrote:
> When you see 78 in the output and you know you have 92 tags in the
> repository, is that sufficient to let you go on, or do we also need
> an easy way to tell which ones are those 78 that were stripped and
> the remaining 14 were not strippe
Sverre Rabbelier writes:
> On Sun, Apr 14, 2013 at 3:57 AM, John Keeping wrote:
>> This issues a warning while stripping signatures from signed tags, which
>> allows us to use it as default behaviour for remote helpers which cannot
>> specify how to handle signed tags.
>
> Perhaps it makes sense
Drew Northup writes:
>> + Note that the GITWEB_CONFIG_SYSTEM system-wide configuration file is
>> + only used for instances that lack per-instance configuration file.
>> + You can use GITWEB_CONFIG_COMMON common system-wide configuration
>> + file (normally /etc/gitweb-common.conf) to keep co
On Mon, Apr 15, 2013 at 07:53:48AM -0700, Junio C Hamano wrote:
> > Yes. The concept isn't that hard, but the question was one of whether it
> > would break some obscure workflows. But I don't remember all of the
> > details; I think I gave some examples in past threads.
>
> I think the one Thoma
Thanks, both. Will replace what is queued with this version.
--
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
Jeff King writes:
> FWIW, I do not think it was so much rejected as that I had initially
> planned to implement it, then decided against it. Mostly because I
> wanted to actually get annoyed with each piece of advice before
> disabling it. Because sometimes the right answer is actually "make the
Felipe Contreras writes:
> So it should be clear now: the remote namespace refs/origin/master is
> updated, but not the remote helper's namespace
> refs/testgit/origin/master, which is what I already said. I don't know
> what more do you expect. When you push 'refs/heads/master' to origin,
> you
On Sun, Apr 14, 2013 at 3:57 AM, John Keeping wrote:
> This issues a warning while stripping signatures from signed tags, which
> allows us to use it as default behaviour for remote helpers which cannot
> specify how to handle signed tags.
Perhaps it makes sense to instead count the number of sig
On Mon, Apr 15, 2013 at 11:18 AM, Ramkumar Ramachandra
wrote:
> A few small personal itches off the top of my head:
>
> - Make git status -s show "state status" as well: this essentially
> requires writing an equivalent of wt_status_print_state() for use in
> wt_shortstatus_print().
I actually su
Signed-off-by: Jiang Xin
Reviewed-by: Nguyễn Thái Ngọc Duy
Reviewed-by: Jonathan Nieder
---
> Micronit: it would be nicer to use printf_ln to save translators the
> trouble of worrying about the final newline.
Reroll with the help of Jonathan Nieder.
branch.c | 54 +++--
n Mon, Apr 15, 2013 at 4:28 PM, Junio C Hamano wrote:
> * jn/gitweb-install-doc (2013-04-15) 1 commit
> - gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM
>
> Reword gitweb configuration instrutions.
>
> Will merge to 'next'.
While the re-worded text is easier on the eyes it fails
Ramkumar Ramachandra wrote:
> Matthieu Moy wrote:
>> No, you don't. Just try if you're not convinced:
>
> Oh, I trusted the documentation on this one and never tried with a
> dirty worktree myself. Please fix the documentation, if you know how
> exactly to correct it.
The manual says:
"
On Fri, Apr 12, 2013 at 6:20 PM, Jakub Narębski wrote:
> -- >8 --
> Subject: [PATCH] gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM
>
> The flow of the text describing GITWEB_CONFIG_SYSTEM and
> GITWEB_CONFIG_COMMON in gitweb/INSTALL is awkward. "This is
> bad. Oh the other hand, b
Matthieu Moy wrote:
> Junio C Hamano writes:
>> Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
>> and pull.autosquash is harmful.
>
> To speak from my experience: I find myself typing "git stash && git pull
> && git stash pop" relatively often.
To that end, maybe "git
Ramkumar Ramachandra wrote:
>When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the path specified by this variable.
Interesting. As the discussion downthread from this illustrated, I a
On Mon, Apr 15, 2013 at 06:45:04PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -603,7 +603,7 @@ static NORETURN void die_async(const char *err, va_list
> > params)
> > {
> > vreportf("fatal: ", err, params);
> >
> > - if (!pt
On Mon, Apr 15, 2013 at 07:34:07PM -0700, Brandon Casey wrote:
> > Right. My assumption was that we are primarily interested in protecting
> > against the die_routine. Compat functions should never be calling die.
>
> I think the rule we have been enforcing is less strict than that. We
> have on
Jiang Xin wrote:
> --- a/branch.c
> +++ b/branch.c
[...]
> @@ -79,23 +79,23 @@ void install_branch_config(int flag, const char *local,
> const char *origin, cons
> if (flag & BRANCH_CONFIG_VERBOSE) {
> if (remote_is_branch && origin)
> printf(rebasing ?
>
On Mon, Apr 15, 2013 at 5:42 PM, Jeff King wrote:
> On Mon, Apr 15, 2013 at 05:11:36PM -0700, Brandon Casey wrote:
>
>> > +static void check_die_recursion(const char *fmt, va_list ap)
>> > +{
>> > + static int dying;
>> > +
>> > + if (!dying++)
>> > + return;
>> > +
>> >
Jonathan Nieder wrote:
> As you hinted before, this would involve reverting the introduction
> of "branch..pushremote", with the explanation that it was a
> mistake inspired by that false symmetry, that you noticed and were
> uncomfortable with but the rest of us were blind too.
s/too/to/
For th
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> That "changing the meaning of " in the middle, and doing so
>> will be confusing to the users, is exactly the issue, isn't it?
>
> Yes, but we have to change _something_ if we don't want to hit a WTF
> like 'git push master next' pushing maste
Jeff King wrote:
> --- a/run-command.c
> +++ b/run-command.c
> @@ -603,7 +603,7 @@ static NORETURN void die_async(const char *err, va_list
> params)
> {
> vreportf("fatal: ", err, params);
>
> - if (!pthread_equal(main_thread, pthread_self())) {
> + if (!running_main_thread()) {
Jeff King wrote:
> I was also tempted to suggest just dropping the recursion check
> altogether. While it is neat to detect such things, it's a "should never
> happen" bug situation, and an infinite loop of printing out the same
> message is pretty easy to notice.
On servers it might be useful to
On Mon, Apr 15, 2013 at 8:30 PM, Jeff King wrote:
> Subject: [PATCH] http: set curl FAILONERROR each time we select a handle
>
> Until commit 6d052d7 (http: add HTTP_KEEP_ERROR option,
> 2013-04-05), setting curl's FAILONERROR option was a global
> setup; we never changed it. However, 6d052d7 intr
On Mon, Apr 15, 2013 at 06:32:49PM +0200, Matthieu Moy wrote:
> > - Create an advice.ui (like color.ui) to turn off all advice. I don't
> > need advice.
>
> I tend to agree with you, but the idea has explicitly been rejected in
> the past. The problem with an option like this is that it would al
Junio C Hamano wrote:
> Just rerolling with what _you_ think is an appropriate level of
> explanation (either or both in log and in-code) and see what happens
> would probably be the best way to proceed, I think, at this
> point. Either you hear "It still is wrong and too sketchy", "Yeah,
> thinki
On Tue, Apr 16, 2013 at 01:49:13AM +0200, Øyvind A. Holm wrote:
> > [1] I know you always test master before pushing it out, but I suspect
> > you do not run the GIT_TEST_HTTPD tests. The failures are in t5541
> > and t5551.
>
> Ah, that explains why the test suite passed here, I built a
On Mon, Apr 15, 2013 at 05:11:36PM -0700, Brandon Casey wrote:
> > +static void check_die_recursion(const char *fmt, va_list ap)
> > +{
> > + static int dying;
> > +
> > + if (!dying++)
> > + return;
> > +
> > + vreportf("fatal: ", fmt, ap);
>
> How do you know it'
On Mon, Apr 15, 2013 at 07:25:32PM -0400, Jeff King wrote:
> On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
>
> > * jk/http-error-messages (2013-04-06) 9 commits
> [...]
> ...the tip of your current master does not currently pass the test
> suite[1]. I bisected the problem to "sh
On Mon, Apr 15, 2013 at 4:08 PM, Jeff King wrote:
> When any git code calls die(), we chain to a custom
> die_routine, which we expect to print a message and exit the
> program. To avoid infinite loops, we detect a recursive call
> to die() with a simple counter, and break out of the loop by
> pri
On 16 April 2013 01:25, Jeff King wrote:
> On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
> > [Graduated to "master"]
> > [...]
> > * jk/http-error-messages (2013-04-06) 9 commits
> > (merged to 'next' on 2013-04-11 at 7a03981)
> > [...]
>
> ...the tip of your current master doe
On Mon, Apr 15, 2013 at 07:45:03PM -0400, Eric Sunshine wrote:
> On Mon, Apr 15, 2013 at 7:08 PM, Jeff King wrote:
> > This patch teaches die() to print the original die message
> > to stderr before reporting the recursion. The custom
> > die_routine may or may not have put it the message to
>
>
On Mon, Apr 15, 2013 at 7:08 PM, Jeff King wrote:
> This patch teaches die() to print the original die message
> to stderr before reporting the recursion. The custom
> die_routine may or may not have put it the message to
s/put it the/emitted/ perhaps?
> stderr, but this is the best we can do (i
On Mon, Apr 15, 2013 at 6:14 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> And about this:
>> http://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contre...@gmail.com
>
> What about it? Is that the one you said you are going to reroll?
At first, but then I changed my mind.
On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
> [Graduated to "master"]
> [...]
> * jk/http-error-messages (2013-04-06) 9 commits
> (merged to 'next' on 2013-04-11 at 7a03981)
> + http: drop http_error function
> + remote-curl: die directly with http error messages
> + http:
Felipe Contreras writes:
> And about this:
> http://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contre...@gmail.com
What about it? Is that the one you said you are going to reroll?
I do not recall the details of Peff's complaints, but re-reading the
log message of the patch itself, s
When we have started threads with the async subsystem, both
the thread and the main program may call die(). The async
subsystem sets up a special die routine to call pthread_exit
rather than regular exit, but the recursion check in die()
happens outside of this routine, and does not know that it's
When the async subsystem is used, we may spawn off
sub-threads (if the platform supports it), and consider the
original thread to be the "main" thread of execution. We use
this information in a custom die_routine to decide whether
to call pthread_exit or a regular full-process exit.
Let's pull thi
When any git code calls die(), we chain to a custom
die_routine, which we expect to print a message and exit the
program. To avoid infinite loops, we detect a recursive call
to die() with a simple counter, and break out of the loop by
printing a message and exiting ourselves, without chaining
to th
If upload-pack fails while generating a pack, the receiving side of a
fetch will print out a message like this:
fatal: git remote host hung up unexpectedly
fatal: recursion detected in die handler
You can see it by instrumenting upload-pack to fail like this:
diff --git a/upload-pack.c b/upl
On Mon, Apr 15, 2013 at 3:28 PM, Junio C Hamano wrote:
> * fc/remote-hg (2013-04-11) 21 commits
> - remote-hg: activate graphlog extension for hg_log()
> - remote-hg: fix bad file paths
> - remote-hg: document location of stored hg repository
> - remote-hg: fix bad state issue
> - remote-hg:
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If "rebase -m" were to be taught to do this, the natural way to do
>> so is to
>>
>> (1) Prepare the todo the usual way
>> (2) Do those two commits for index and working tree
>> (3) Append two insns (exec reset HEAD^ and exec reset --s
In the current transport-helper code, refs without namespaced refspecs don't
work correctly, so let's always use them.
Some people reported issues with 'git clone --mirror', and this fixes them, as
well as possibly others.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bz
Erik Faye-Lund writes:
> This is absolutely the right thing to do. However, stuff have changed
> a bit since the patch was written; this change now needs to go in
> config.mak.uname instead of config.mak.
Thanks for a quick response.
What's your preference? I could just ignore a patch I won't
Oj W wrote:
> Change a binary file whose filename contains an ampersand, then view
> the commitdiff page in gitweb.
>
> Git outputs a message like "Binary files a/b&w.dll and b/b&w.dll differ"
>
> Gitweb format_diff_from_to_header() doesn't notice anything in that
> output which needs escaping,
Karsten Blees writes:
> is_excluded doesn't handle ignored directories, results for paths within
> ignored directories are incorrect. This is probably based on the premise
> that recursive directory scans should stop at ignored directories,...
Correct. Long time ago, we used to have strange rul
On Mon, Apr 15, 2013 at 11:00 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jonathan Nieder writes:
>>
>>> If you try this:
>>>
>>> 1. Install Git for Windows (from the msysgit project)
>>> 2. Put
>>>
>>> [core]
>>> autocrlf = false
>>> eol = native
>>>
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> If you try this:
>>
>> 1. Install Git for Windows (from the msysgit project)
>> 2. Put
>>
>> [core]
>> autocrlf = false
>> eol = native
>>
>> in your .gitconfig.
>> 3. Clone a project with
>>
>> *.tx
Marc Branchaud writes:
> So it looks like the proposed change to git-clone provides no benefit to the
> submodule-adding machinery, which still needs to know when and how to
> relocate .git directories.
>
> Ram, assuming Junio's explanations match your intentions, if the whole
That is a huge ass
Jeff King writes:
> And by the way, I am actually not sure that such a shared-object setup
> is a good idea, but only that _if_ you are going to do it with
> submodules, you might as well do it for all repos. In theory, it is not
> that hard to have a big per-user object-only repository (either f
Ilya Basin wrote:
> Does this --fast-export thing support what John mentioned, the
> "incremental import support"? Does 'git fast-import' has it?
> I need it, because full import takes too long.
>
> The central repo of my employer is CVS, other people commit to it and
> I use git internally to be
On 13-04-15 02:50 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>>> After that "clone" or "init" creates a repository, you still have to
>>> "add" if you want to make it a submodule to the toplevel.
>>
>> To me it makes more sense to move the .git directory when the user invokes
>> "git su
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Karsten Blees writes:
> Am 15.04.2013 21:33, schrieb Junio C Hamano:
>> Junio C Hamano writes:
>>
>>> Karsten Blees writes:
>>>
This patch series addresses several bugs and performance issues in
.gitignore processing.
>>>
>>> A 8-patch series ending at 5d765dc7888b (dir.c: git-status
Mr_and_Mrs_D gmail.com> writes:
>
> I am on windows 7 Pro - mingwin
>
> I decided to turn autocrlf to false and use .gitattributes instead and was
> bitten by this bug :
>
> http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-
does-not-seem-to-checkout-the-right-li
Thanks for the regular update! This is great work.
One issue with the plural form messages, though:
Am Montag, 15. April 2013, 18:27:40 schrieb Ralf Thielow:
> #: bundle.c:186
> -#, fuzzy, c-format
> +#, c-format
> msgid "The bundle contains this ref:"
> msgid_plural "The bundle contains these
Am 15.04.2013 21:33, schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> Karsten Blees writes:
>>
>>> This patch series addresses several bugs and performance issues in
>>> .gitignore processing.
>>
>> A 8-patch series ending at 5d765dc7888b (dir.c: git-status: avoid
>> is_excluded checks for
Junio C Hamano writes:
> Karsten Blees writes:
>
>> This patch series addresses several bugs and performance issues in
>> .gitignore processing.
>
> A 8-patch series ending at 5d765dc7888b (dir.c: git-status: avoid
> is_excluded checks for tracked files, 2013-03-18) has been cooking
> in 'next';
Karsten Blees writes:
> This patch series addresses several bugs and performance issues in
> .gitignore processing.
A 8-patch series ending at 5d765dc7888b (dir.c: git-status: avoid
is_excluded checks for tracked files, 2013-03-18) has been cooking
in 'next'; in general we won't revert and reque
'git-status --ignored' still scans the work tree twice to collect
untracked and ignored files, respectively.
fill_directory / read_directory already supports collecting untracked and
ignored files in a single directory scan. However, the DIR_COLLECT_IGNORED
flag to enable this has some git-add spe
'git-status --ignored' recursively scans directories up to three times:
1. To collect untracked files.
2. To collect ignored files.
3. When collecting ignored files, to check that an untracked directory
that potentially contains ignored files doesn't also contain untracked
files (i.e.
Checking if a file is in the index is much faster (hashtable lookup) than
checking if the file is excluded (linear search over exclude patterns).
Skip is_excluded checks for files: move the cache_name_exists check from
treat_file to treat_one_path and return early if the file is tracked.
This can
Signed-off-by: Karsten Blees
---
builtin/add.c | 5 +---
builtin/check-ignore.c | 6 +---
builtin/ls-files.c | 15 +++---
dir.c | 79 --
dir.h | 16 ++
unpack-trees.c | 10 +--
Thomas Rast writes:
> From a cursory glance it looks like it's actually an existing bug in
> read_revisions_from_stdin or handle_revision_arg, depending on which way
> you look at it. read_revisions_from_stdin passes its temporary buffer
> down to handle_revision_arg:
>
> struct strbuf s
The is_excluded and is_path_excluded APIs are very similar, except for a
few noteworthy differences:
is_excluded doesn't handle ignored directories, results for paths within
ignored directories are incorrect. This is probably based on the premise
that recursive directory scans should stop at ignor
Move prep_exclude in preparation for the next patch.
Signed-off-by: Karsten Blees
---
dir.c | 144 +-
1 file changed, 72 insertions(+), 72 deletions(-)
diff --git a/dir.c b/dir.c
index 594307c..fcb3def 100644
--- a/dir.c
+++ b/dir.
Signed-off-by: Karsten Blees
---
dir.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/dir.c b/dir.c
index f10fb69..594307c 100644
--- a/dir.c
+++ b/dir.c
@@ -751,6 +751,26 @@ int is_excluded_from_list(const char *pathname,
return
The notion of "ignored tracked" directories introduced in 721ac4ed "dir.c:
Make git-status --ignored more consistent" has a few unwanted side effects:
- git-clean -d -X: deletes ignored tracked directories. git-clean should
never delete tracked content.
- git-ls-files --ignored --other --dir
'git-status --ignored path/' doesn't list ignored files and directories
within 'path' if some component of 'path' is classified as untracked.
Disable the DIR_SHOW_OTHER_DIRECTORIES flag while traversing leading
directories. This prevents treat_leading_path() with DIR_SHOW_IGNORED flag
from abortin
'git-status --ignored' lists empty untracked directories as ignored, even
though they don't have any ignored files.
When checking if a directory is already listed as untracked (i.e. shouldn't
be listed as ignored as well), don't assume that the directory has only
ignored files if it doesn't have u
'git-ls-files --ignored --directories' hides empty directories even though
--no-empty-directory was not specified.
Treat the DIR_HIDE_EMPTY_DIRECTORIES flag independently from
DIR_SHOW_IGNORED to make all git-ls-files options work as expected.
Signed-off-by: Karsten Blees
---
dir.c
'git-status --ignored' lists ignored tracked directories without any
ignored files if a tracked file happens to match an exclude pattern.
Always exclude tracked files.
Signed-off-by: Karsten Blees
---
dir.c | 11 ---
t/t7061-wtstatus-ignore.sh | 24 +
'git-status --ignored' lists both the ignored directory and the ignored
files if the files are in a tracked sub directory.
When recursing into sub directories in read_directory_recursive, pass on
the check_only parameter so that we don't accidentally add the files.
Signed-off-by: Karsten Blees
-
'git-status --ignored' drops ignored directories if they contain untracked
files in an untracked sub directory.
Fix it by getting exact (recursive) excluded status in treat_directory.
Signed-off-by: Karsten Blees
---
dir.c | 9 +
t/t7061-wtstatus-ignore.sh | 27 +++
This patch series addresses several bugs and performance issues in
.gitignore processing.
Patches #1 - #6 fix bugs and add appropriate test cases.
Patch #7 changes handling of "ignored tracked" directories, as I discovered
that with the current bahavior git-clean can delete tracked content.
Patc
On 13-04-15 01:50 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> In general I think it is a mistake to overload "git clone" with the notion of
>> adding a submodule.
>
> I agree with that principle, but my understanding is that this
> effort is not about teaching "git clone" to create a
On 13-04-15 02:00 PM, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>>
>> I do not think the addition Ram is envisioning in the patch will
>> prevent you from teaching "add" to do that. An implemention of such
>> an addition indeed would most likely use the same --separate-git-dir
>> mechan
Marc Branchaud writes:
>> After that "clone" or "init" creates a repository, you still have to
>> "add" if you want to make it a submodule to the toplevel.
>
> To me it makes more sense to move the .git directory when the user invokes
> "git submodule add" instead of creating it in an unusual pla
On Mon, Apr 15, 2013 at 11:30:40PM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > My
> > understanding is that this "config" is about making that option
> > easier to use when you _know_ any new repository you create with
> > "git clone" or "git init" inside your (toplevel super)pr
>
> But I do not know if the description of the longhand ":(top)" is
> unnecessary for the user. Is the equivalence between it and :/
> described anywhere else in our documentation set?
>
The only complete "documentation" for all of this is in setup.c and I must
confess that I missed the subtl
Thomas Rast writes:
> From a cursory glance it looks like it's actually an existing bug in
> read_revisions_from_stdin or handle_revision_arg, depending on which way
> you look at it. read_revisions_from_stdin passes its temporary buffer
> down to handle_revision_arg:
>
> struct strbuf s
On Mon, Apr 15, 2013 at 11:38:20PM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > If "rebase -m" were to be taught to do this, the natural way to do
> > so is to
> >
> > (1) Prepare the todo the usual way
> > (2) Do those two commits for index and working tree
> > (3) Append t
Thomas Ackermann writes:
> Use "SHA-1" instead of "SHA1" whenever we talk about the hash function.
> When used as a programming symbol, we keep "SHA1".
>
> Signed-off-by: Thomas Ackermann
> ---
Thanks. Will queue as-is for now, but I wonder if we want to fix
them to more official "object name"
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
Looks sensible. Thanks.
> Documentation/glossary-content.txt | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/Documentation/glossary-content.txt
> b/Documentation/glossary-content.txt
> inde
Thomas Ackermann writes:
> fix the idendation of
> the first paragraph after the bullet list
That's indentation, I think, and is a good fix.
> and remove the one-item
> list of magic signatures with its - for the user - unnecessary
> introduction of "magic word 'top'".
But I do not know if the
Junio C Hamano wrote:
> If "rebase -m" were to be taught to do this, the natural way to do
> so is to
>
> (1) Prepare the todo the usual way
> (2) Do those two commits for index and working tree
> (3) Append two insns (exec reset HEAD^ and exec reset --soft
> HEAD^) at the end of the re
Junio C Hamano wrote:
> My
> understanding is that this "config" is about making that option
> easier to use when you _know_ any new repository you create with
> "git clone" or "git init" inside your (toplevel super)project's
> working tree will become its submodule, as it is more convenient to
> h
Hi Eric.
I tried --fast-export. It's 2 times faster.
The first thing that differs: in cvsps2 commits with adjacent
timestamps were joined into one (see the attached files). Do you know
the reason?
Does this --fast-export thing support what John mentioned, the
"incremental import support"? Does 'g
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> git-rebase --autostash
>>
>> git commit --allow-empty -m 'index part'
>> git commit --allow-empty -a -m 'working tree part'
>> git rebase --onto $UPSTREAM
>> git reset H
Marc Branchaud wrote:
> git add ssh://host/blammo.git
Heh. And I want git add *coffee* to make me coffee.
What's your gripe with git submodule add?
> I could have
> ~/.git/
> to maintain revisions of various personal files, config .dotfiles, scripts in
> ~/bin/ and so on.
> [...]
Marc Branchaud writes:
> In general I think it is a mistake to overload "git clone" with the notion of
> adding a submodule.
I agree with that principle, but my understanding is that this
effort is not about teaching "git clone" to create a submodule.
Both "git clone" and "git init" already kno
The exact definition of "refspec" can be found in git-fetch
and git-push manpages. So don't duplicate this here in the glossary.
Actually the definition of "pathspec" should be moved to a separate
file akin to the way it's done with "refspec". But this will only
be wortwhile when there's more to
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function.
When used as a programming symbol, we keep "SHA1".
Signed-off-by: Thomas Ackermann
---
Documentation/config.txt | 2 +-
Documentation/git-cat-file.txt| 6 +++---
Docume
The name of the hash function is "SHA-1", not "SHA1".
Also to people who look up "object name" in the glossary,
the details of which hash function is applied on what to
compute "object name" is not important but the fact that the
name is meant to be an unique identifier for the contents
stored in
Signed-off-by: Thomas Ackermann
---
Documentation/glossary-content.txt | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index eb7ba84..5a7a486 100644
--- a/Documentation/glossary-content.txt
+
This is another reroll of my patches for glossary-content.txt.
- The first patch is the same as in v2.
- The second patch only adds the log message which Junio suggested and a
missing full stop.
- The third patch is new and is a direct consequence of the second patch.
- In the fourth patch there
1 - 100 of 173 matches
Mail list logo
