* Re: [PATCH] remote: fix remote set-url usage
From: Jonathan Nieder @ 2011-11-07 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7vfwi04itx.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -1336,7 +1336,7 @@ static int set_branches(int argc, const char **argv)
> builtin_remote_setbranches_usage, 0);
> if (argc == 0) {
> error("no remote specified");
> - usage_with_options(builtin_remote_seturl_usage, options);
> + usage_with_options(builtin_remote_setbranches_usage, options);
Good eyes. Thanks for catching it.
^ permalink raw reply
* Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7
From: Tony Wang @ 2011-11-07 9:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <CACsJy8C25qurZwTLuuZ8X4EUzg-NP_qwFjcPTZoEs7QOOS-WBA@mail.gmail.com>
On Monday, November 7, 2011 at 17:30, Nguyen Thai Ngoc Duy wrote:
> Hi,
>
> On Mon, Nov 7, 2011 at 3:59 PM, Tony Wang <wwwjfy@gmail.com (mailto:wwwjfy@gmail.com)> wrote:
> > Hi,
> > I don't know if a better way to report this, so I write to the author of the
> > commit. Please let me know if I do wrong. :)
>
>
>
>
> It's good that you bisect to the broken commit and send me. However
> you should always send to git@vger just in case I'm unavailable.
>
Roger.
>
> > The thing is the commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7 made an
> > option broken sometimes (it's weird, but it's true that it didn't happen
> > every time)
> > I set "branch.master.mergeoptions=--squash" in config, but when I do "git
> > merge b", the squash didn't work, however, "git merge b --squash" works as
> > expected.
>
>
>
>
> What was the expection? --squash was not effective or something else?
>
Yes, it just merged like without "--squash"
>
> > I tried to debug, and found after this
> > merge.c:1104
> > head_commit = lookup_commit_or_die(head_sha1, "HEAD");
> > the variable branch becomes "s/origin/b", which is previously "b".
> > I used git bisect and found the
> > commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7 caused this.
>
>
>
>
> Variable "head_sha1"? Strange because lookup_commit_or_die() takes
> "const char *" and the compiler should catch any attempts to change
> the variable.
No, variable "branch". It's declared as "static const char *branch;" in builtin/merge.c
>
> If you can reproduce it, can you make a small test case to demonstrate
> it? I'm not sure what "b" is and how you set up configuration for
> branch master. BTW what git version did you use?
>
I'll try it.
Sorry, "b" is a random branch name, I should use a meaningful one.
I set by "git config branch.master.mergeoptions --squash"
I tried 1.7.7.2 and master of github.com/gitster/git.git (http://github.com/gitster/git.git).
>
> > I browsed the diff, and found the function lookup_commit_or_die
> > uses lookup_commit_reference, but not lookup_commit which was used
> > before lookup_commit_or_die replaced it.
> > Was it on purpose or typo?
>
>
>
>
> It was on purpose. HEAD may contain a tag, in which case
> lookup_commit() would to return a commit fail while
> lookup_commit_reference() can peel the tag to the commit.
However, I tried to make it lookup_commit and it worked as expected. I'll try to read some detail.
>
> > If possible, it'll be good that I can know some details.
> > Thanks!
>
>
>
> --
> Duy
--
BR,
Tony Wang
^ permalink raw reply
* reset reports file as modified when it's in fact deleted
From: Carlos Martín Nieto @ 2011-11-07 9:43 UTC (permalink / raw)
To: git
Hello,
When I delete a file (git rm) and then reset so it exists in the index
again, the message tells me 'M file.txt' even though the file doesn't
exist in the worktree anymore. Running git status afterwards does give
the correct output. So, here's the minimal steps to reproduce:
$ git init
Initialized empty Git repository in /home/carlos/test/reset-err/.git/
$ touch file.txt
$ git add file.txt
$ git ci file.txt -m initial
[master (root-commit) a536393] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file.txt
$ git rm file.txt
rm 'file.txt'
$ git reset -- file.txt
Unstaged changes after reset:
M file.txt
$ git status -b -s
## master
D file.txt
I'd expect the output after "Unstaged changes after reset" to tell me
file.txt has been deleted instead of modified. This happens with
1.7.8-rc0, 1.7.7 and 1.7.4.1 and I expect with many more that I don't
have here.
I thought the index diff code might have been checking the index at the
wrong time, but I can run 'git reset HEAD -- file.txt' as many times
as I want, and it will still say 'M', so now I'm not sure.
cmn
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2011-11-07 9:32 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <CAGdFq_hmF8xDA8PdDUPygSSAVsvrA=BRVKp+eCVRggHxLZzBsQ@mail.gmail.com>
Sverre Rabbelier wrote:
> On Sun, Nov 6, 2011 at 05:31, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> as they use marks
>>> files to store which commits have already been seen. The call graph
>>> is something as follows:
[...]
>>> $ # run `git branch foo` and push it to remote
>>> $ git fast-export --{im,ex}port-marks=marksfile foo
>>>
>>> When fast-export imports the marksfile and sees that all commits in
>>> foo are marked as UNINTERESTING
>>
>> Hmm, I didn't know about this behavior. Would it be possible to add
>> a test for it, too?
>
> What behavior are you referring to here? What kind of test would you want added?
I meant I hadn't remembered that marks result in commits being marked
as UNINTERESTING (even though the manpage warned me), and that it's
possible a priori that fast-export could be broken when you run
git fast-export --import-marks=marksfile master
even without breaking
git fast-export master..master
But don't worry about it --- I can try it as a follow-on when this
series next visits the list if that doesn't sound like fun. :)
FWIW, with the clarifications to the commit message Junio made, I'm
happy with this patch.
^ permalink raw reply
* Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7
From: Nguyen Thai Ngoc Duy @ 2011-11-07 9:30 UTC (permalink / raw)
To: Tony Wang; +Cc: Git Mailing List
In-Reply-To: <BC404302028E4B6F8F2C27DC8E63545F@gmail.com>
Hi,
On Mon, Nov 7, 2011 at 3:59 PM, Tony Wang <wwwjfy@gmail.com> wrote:
> Hi,
> I don't know if a better way to report this, so I write to the author of the
> commit. Please let me know if I do wrong. :)
It's good that you bisect to the broken commit and send me. However
you should always send to git@vger just in case I'm unavailable.
> The thing is the commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7 made an
> option broken sometimes (it's weird, but it's true that it didn't happen
> every time)
> I set "branch.master.mergeoptions=--squash" in config, but when I do "git
> merge b", the squash didn't work, however, "git merge b --squash" works as
> expected.
What was the expection? --squash was not effective or something else?
> I tried to debug, and found after this
> merge.c:1104
> head_commit = lookup_commit_or_die(head_sha1, "HEAD");
> the variable branch becomes "s/origin/b", which is previously "b".
> I used git bisect and found the
> commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7 caused this.
Variable "head_sha1"? Strange because lookup_commit_or_die() takes
"const char *" and the compiler should catch any attempts to change
the variable.
If you can reproduce it, can you make a small test case to demonstrate
it? I'm not sure what "b" is and how you set up configuration for
branch master. BTW what git version did you use?
> I browsed the diff, and found the function lookup_commit_or_die
> uses lookup_commit_reference, but not lookup_commit which was used
> before lookup_commit_or_die replaced it.
> Was it on purpose or typo?
It was on purpose. HEAD may contain a tag, in which case
lookup_commit() would to return a commit fail while
lookup_commit_reference() can peel the tag to the commit.
> If possible, it'll be good that I can know some details.
> Thanks!
--
Duy
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Jonathan Nieder @ 2011-11-07 8:58 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <CAGdFq_gkSxvw9Di_mUqS5N0bgCWh-dygMe_DWcR+ENAo=A-3=A@mail.gmail.com>
Sverre Rabbelier wrote:
> On Sun, Nov 6, 2011 at 06:01, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> These details seem like good details for the commit message, so the
>> next puzzled person looking at the code can see what behavior is
>> deliberate and what are the incidental side-effects.
>
> All of it? I wasn't sure what part should go in the commit message.
Yeah. My rule when in doubt has been to just include everything that
would remain meaningful over time that I could be putting in a cover
letter for the patch. The hard part is to try to be concise in doing
so.
>> The "git fast-export a..$(git rev-parse HEAD^{commit})" case sounds
>> worth a test.
>
> A test_must_fail?
Yep.
>>> +#define REF_HANDLED (ALL_REV_FLAGS + 1)
>>
>> Could TMP_MARK be used for this?
>
> I don't know its usage, is it?
Since handle_tags_and_duplicates() happens after the main revision
traversal, it would be safe. But it's probably not good style. Any
later revwalk would be confused by or clobber that flag.
My actual worry was that if there are too many rev flags some day,
this REF_HANDLED could wrap around to 0. Now I see that custom
per-command flags are not so rare --- it is just this idiom for
allocating them by adding 1 to the all-ones bitmask that is unusual.
The most common idiom is to simply start with 1u<<16:
#define REF_HANDLED (1u<<16)
unpack-objects uses 1u<<20 instead. blame starts with 1u<<12. reflog
starts with 1u<<10. A part of me wishes the command-specific flags
were allocated in revision.h like the standard ones so one could write
#define REF_HANDLED REVFLAGSUSR1
by analogy with SIGUSR1, or that there were some other mechanism for
avoiding collisions.
>>> + dwim_ref(elem->name, strlen(elem->name), elem->item->sha1, &full_name);
>>> +
>>> + if (!prefixcmp(full_name, "refs/tags/") &&
>>
>> What happens if dwim_ref fails, perhaps because a ref was deleted in
>> the meantime?
>
> That would be bad. I assumed that we have a lock on the refs, should I
> add back the die check that's done by the other dwim_ref caller?
Sure, there's a lock. It doesn't stop a non-git process-gone-mad like
/bin/rm from deleting a file under .git/refs. :)
die()-ing on error sounds sane.
[...]
>> If tag_of_filtered_mode == ABORT, we are going to die() soon, right?
>
> I don't know to be honest, perhaps we would have already died by now?
It's the handle_tag() call, later in handle_tags_and_duplicates().
[...]
>> When does the !get_object_mark() case come up?
>
> Eh, it has something to do with it being a replacement (rather than
> the same), maybe? This is mostly just taken from Dscho's original
> patch.
Ah, this is similar to the mysterious case from patch 2/3.
Probably this is the "git fast-export a..a" case, where 'a' was not
dumped because UNINTERESTING but we still want to reset refs/tags/a to
point to it. But won't handle_tag() write
tags refs/heads/a
from :0
[tagger, etc]
when we get to it?
Side question: should the
for (i = extra_refs->nr - 1; i >= 0; i--) {
loop should be earlier in the function and set REF_HANDLED where
appropriate, to avoid resets for these objects, too?
[...]
>> Just curious: is the REF_HANDLED handling actually needed? What
>> would happen if fast-export included the redundant resets?
>
> That would just be sloppy :). I don't think anything particularly bad
> would happen.
I suppose this is needed to avoid pointless changes in output which
could break git's or other projects' test suites without good reason.
Makes sense.
Thanks for the clarifications.
Jonathan
^ permalink raw reply
* [PATCH 4/4] Documentation/gitignore: explain how to un-ignore part of a directory
From: Jonathan Nieder @ 2011-11-07 8:11 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111107080449.GA30448@elie.hsd1.il.comcast.net>
From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 5 Apr 2011 23:15:54 +0200
Trying to whitelist a single file pattern in a directory that I was
otherwise content to ignore, if I try
/m4/
!/m4/virt-*.m4
then 'git add' will keep warning me that I have to use -f. That is
because ignoring a directory is much different than ignoring all files
in a directory, when it comes to later negation patterns:
/m4/*
!/m4/virt-*.m4
However, this example is misleading because it gives the false
impression that you could do
/foo/*
!/foo/bar/baz
and have foo/bar/baz not ignored, and it is still ignored. Add a
paragraph in the NOTES section explaining the general rule and
suggesting ignoring the directory and using "git add -f" to track
exceptions to cope with it.
[jn: change description distilled from messages by Eric and Hannes
to the mailing list.
As Eric noticed, while the "git add -f" trick works well with
commands like "git status" and "git add -u", plain "git add
subdir/<path>" refuses to update the index with changes from an
ignored subdirectory. When describing the trick, explicitly list a
few commands that already behave appropriately to avoid confusion.]
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
That's the end of the series. Thoughts?
Documentation/gitignore.txt | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index e5715a27..8b6f601e 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -113,6 +113,21 @@ use 'git update-index {litdd}assume-unchanged'.
To stop tracking a file that is currently tracked, use
'git rm --cached'.
+When a directory is ignored, it is not possible to un-ignore a single file
+somewhere in the directory using another pattern. E.g., with the patterns
+
+--------------
+/build/
+!/build/tests/results
+--------------
+
+the file "build/tests/results" is still ignored because when a directory is
+ignored, its contents are never investigated. In a situation where a few
+exceptions in an otherwise ignored hierarchy are needed, the recommended
+procedure is to specify to ignore the root of the hierarchy and then to 'git
+add -f' the exceptional files. Subsequent changes to the files will not be
+ignored by 'git status', 'git add .', 'git add -u', or 'git commit -a'.
+
EXAMPLES
--------
--
1.7.8.rc0
^ permalink raw reply related
* [PATCH 3/4] Documentation: unanchored gitignore patterns match basename
From: Jonathan Nieder @ 2011-11-07 8:09 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111107080449.GA30448@elie.hsd1.il.comcast.net>
The rule described by v1.7.1.1~31^2 (gitignore.5: Clarify matching
rules, 2010-03-05) is just false: simple gitignore patterns without a
slash like "foo" and "cscope*" have always matched files in all
directories, not just the toplevel, and a question mark cannot be used
to match the slash separating path components.
For example:
foo/ - matches directories named "foo" throughout the tree
Documentation?foo - does not match Documentation/foo
Reported-by: Y.G. <yamomo1@hotmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/gitignore.txt | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index c7c948dd..e5715a27 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -80,18 +80,19 @@ PATTERN FORMAT
- If the pattern does not contain a slash '/' at the beginning
or in the middle, git treats it as a shell glob pattern and
- matches the entire pathname including slashes, relative to the
- location of the `.gitignore` file (or relative to the toplevel
- of the work tree if the pattern is not from a `.gitignore`
- file), against it.
- For example, "{asterisk}.html" matches HTML files in the
- directory containing the `.gitignore` file and in its
- subdirectories.
+ checks if the pathname with leading path components
+ removed matches it.
+ For example, "x{asterisk}.html" matches HTML files whose
+ filename begins with an "x" in the directory containing
+ the `.gitignore` file and in its subdirectories.
- If the pattern contains a slash '/' at the beginning or in the
middle, git imitates the behavior of fnmatch(3) with the
- FNM_PATHNAME flag: wildcards in the pattern will not match a /
- in the pathname.
+ FNM_PATHNAME flag. The pattern is used to match the entire
+ pathname, relative to the location of the `.gitignore` file
+ (or relative to the toplevel of the work tree if the pattern
+ is not from a `.gitignore` file). Wildcards in the pattern
+ do not match a / in the pathname.
For example, "Documentation/{asterisk}.html" matches
"Documentation/git.html" but not "Documentation/ppc/ppc.html"
or "tools/perf/Documentation/perf.html".
--
1.7.8.rc0
^ permalink raw reply related
* [PATCH 2/4] Documentation: clarify effect of '/' in gitignore(5) patterns
From: Jonathan Nieder @ 2011-11-07 8:08 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111107080449.GA30448@elie.hsd1.il.comcast.net>
The introduction of directory-only matches in v1.5.5-rc0~208^2~1
(gitignore(5): Allow "foo/" in ignore list to match directory "foo",
2008-01-31) was a small, incremental change to gitignore syntax that
did not affect the rest of the rules in any major way. A '/' at the
end of a pattern means "match directories only" and does not otherwise
affect the pattern. And that is how the gitignore(5) manpage explains
the syntax.
However, to a person parsing an unfamiliar gitignore entry like foo/,
it is too easy to notice the later (old) rule that describes how
patterns containing a slash are anchored and miss that the slash
should have been stripped off before considering whether the rule
applies.
Let's just explicitly say that patterns are only anchored if they
contain a slash that is not at the end of the pattern, avoiding this
confusion. A more graceful presentation of this material may be
possible, but for now the goal is to get the facts clear --- we can
refactor the text to scan well without losing its meaning later.
(While at it, tweak the wording for clarity and add an example.)
Reported-by: Y.G. <yamomo1@hotmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/gitignore.txt | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 5b070bf0..c7c948dd 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -77,19 +77,21 @@ PATTERN FORMAT
directory `foo` but will not match a regular file or a
symbolic link `foo` (this is consistent with the way
pathspecs work in general in git).
-+
-The trailing slash is removed before applying the remaining
-rules.
- - If the pattern does not contain a slash '/', git treats it as
- a shell glob pattern and checks for a match against the
- pathname relative to the location of the `.gitignore` file
- (relative to the toplevel of the work tree if not from a
- `.gitignore` file).
+ - If the pattern does not contain a slash '/' at the beginning
+ or in the middle, git treats it as a shell glob pattern and
+ matches the entire pathname including slashes, relative to the
+ location of the `.gitignore` file (or relative to the toplevel
+ of the work tree if the pattern is not from a `.gitignore`
+ file), against it.
+ For example, "{asterisk}.html" matches HTML files in the
+ directory containing the `.gitignore` file and in its
+ subdirectories.
- - Otherwise, git treats the pattern as a shell glob suitable
- for consumption by fnmatch(3) with the FNM_PATHNAME flag:
- wildcards in the pattern will not match a / in the pathname.
+ - If the pattern contains a slash '/' at the beginning or in the
+ middle, git imitates the behavior of fnmatch(3) with the
+ FNM_PATHNAME flag: wildcards in the pattern will not match a /
+ in the pathname.
For example, "Documentation/{asterisk}.html" matches
"Documentation/git.html" but not "Documentation/ppc/ppc.html"
or "tools/perf/Documentation/perf.html".
--
1.7.8.rc0
^ permalink raw reply related
* [PATCH 1/4] Documentation/gitignore: "foo/" patterns match directories, not files under them
From: Jonathan Nieder @ 2011-11-07 8:07 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111107080449.GA30448@elie.hsd1.il.comcast.net>
The gitignore(5) manpage says that "foo/" will match a directory foo
and paths underneath it. But that is completely false: as Johannes
Sixt likes to remind us, patterns with a trailing '/' match the named
directory, not files under that directory. For example, the following
.gitignore file
/build/
!/build/tests/results
does not un-ignore build/tests/results since it was never ignored in
the first place; and commands like "git status" will not notice
changes to build/tests/results because git doesn't enter the (ignored)
build/ directory.
Correct the manual to just say that "foo/" matches the directory
"foo", and make the wording a little clearer in other ways while at
it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/gitignore.txt | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 2e7328b8..5b070bf0 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -72,12 +72,14 @@ PATTERN FORMAT
included again. If a negated pattern matches, this will
override lower precedence patterns sources.
- - If the pattern ends with a slash, it is removed for the
- purpose of the following description, but it would only find
- a match with a directory. In other words, `foo/` will match a
- directory `foo` and paths underneath it, but will not match a
- regular file or a symbolic link `foo` (this is consistent
- with the way how pathspec works in general in git).
+ - If the pattern ends with a slash, it will only match
+ directories. In other words, `foo/` will match a
+ directory `foo` but will not match a regular file or a
+ symbolic link `foo` (this is consistent with the way
+ pathspecs work in general in git).
++
+The trailing slash is removed before applying the remaining
+rules.
- If the pattern does not contain a slash '/', git treats it as
a shell glob pattern and checks for a match against the
--
1.7.8.rc0
^ permalink raw reply related
* [RFC/PATCH 0/5] gitignore.5 clarifications
From: Jonathan Nieder @ 2011-11-07 8:04 UTC (permalink / raw)
To: git
Cc: Eric Blake, Johannes Sixt, Y.G., Eli Barzilay,
Nguyễn Thái Ngọc Duy
Hi,
Y.G. noticed that the explanation of '/' handling in the gitignore
docs are hard to follow. Worse, it's completely wrong in a number
of ways.
Here's a series to fix a few of those. Impact:
- remove some complete nonsense (how did I mislead myself into
thinking patterns without a '/' were anchored?)
- address the frequently asked question "how do I un-ignore part of a
directory I have ignored?"
- relive what seems to be a bug (even when the "foo/" directory is
ignored, a "git add foo/bar" should add new changes to the index
when that file is already tracked)
- some minor clarity improvements
At this point, I can hardly trust myself, so careful review for
correctness and clarity would be very welcome.
Incorporates material from
http://thread.gmane.org/gmane.comp.version-control.git/170907/focus=170916
Johannes Sixt (1):
Documentation/gitignore: explain how to un-ignore part of a directory
Jonathan Nieder (3):
Documentation/gitignore: "foo/" patterns match directories, not files
under them
Documentation: clarify effect of '/' in gitignore(5) patterns
Documentation: unanchored gitignore patterns match basename
Documentation/gitignore.txt | 48 ++++++++++++++++++++++++++++++------------
1 files changed, 34 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Valdis.Kletnieks @ 2011-11-07 7:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Junio C Hamano, Shawn Pearce, git, James Bottomley,
Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFw6JJDkkSJnp=X4cQuibXMHVBgbQ99iPqEbd7p_7J=VfQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
On Fri, 04 Nov 2011 08:14:52 PDT, Linus Torvalds said:
> On Fri, Nov 4, 2011 at 7:59 AM, Ted Ts'o <tytso@mit.edu> wrote:
> > Note that a repository format change will break a bunch of other
> > things as well, including references in commit descriptions ("This
> > fixes a regression introduced in commit 42DEADBEEF")
> No they won't. Not if you do it right. It's easy enough to
> automatically replace the SHA1's in the description, the same way we
> replace everything else.
OK.. I'll bite. How do you disambiguate a '42deadbeef' in the changelog part
of a commit as being a commit ID, as opposed to being an address in a traceback
or something similar? Yes, I know you only change the ones that actually map to
a commit ID, but I'd not be surprised if by now we've got enough commits and
stack tracebacks in the git history that we'll birthday-paradox ourselves into
a false-positive in an automatic replacement.
(And it's OK to say "the 3 stack tracebacks in changelogs we just mangled can
just go jump", but it does need at least a few seconds consideration..)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] sequencer: revert d3f4628e
From: Ramkumar Ramachandra @ 2011-11-07 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List, Christian Couder
In-Reply-To: <7vlirt5aod.fsf@alter.siamese.dyndns.org>
Hi Jonathan and Junio,
Jonathan Nieder writes:
> [...]
Junio C Hamano writes:
> Thanks for detailed reviews, Jonathan; looking forward for a re-roll, as I
> think the general direction the series seems to be aiming to go is good.
Thanks for the early feedback! I'll polish the series this week.
-- Ram
^ permalink raw reply
* Re: [PATCH] gc --auto: warn gc will soon run, give users a chance to run manually
From: Junio C Hamano @ 2011-11-07 6:04 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1320489212-524-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I hate it every single time git hangs because gc is activated.
> Opening another terminal is an option but I would lose all terminal
> settings I have on the current one (e.g. access to suspended vim
> sessions).
>
> I don't think gc_warn_* need their own config vars. Hopefully
> hardcoded offset is good enough.
Let's think about How the user chooses a custom value for the threshold
(or accepts that the default threshold value 6600 is good enough).
In order to minimize the time the user has to endure when the eventual
auto-gc kicks in, the value needs to be small enough, and to minimize the
frequency the auto-gc kicks in, the value needs to be large enough. It is
a balancing act between the two.
Slower users (those who do not create that many objects within a given
time period) can afford to have a small threashold and do not have to
suffer too frequent auto-gc. Busier ones would rather choose larger
threashold to avoid frequent auto-gc because they create many objects
within a given time period.
The reason why the user would want a warning is probably because the user
sometimes is too busy and cannot afford the disruption of auto-gc, but the
busy period luckily does not last indefinitely, e.g. if a warning is given
two days before the auto-gc actually kicks in, then within that two days
there is a window of time that the user can manually run gc while fetching
a cup of coffee. For different users, the "two days" in this example would
be different. Some people would need longer warning period. Some people
can live with shorter warning period. The number of objects before the
next auto-gc run, divided by the number of objects the user would create
on average in an hour, would give the length of the warning period.
Now, I suspect that busier users would need longer window than slower
ones, which leads me to suspect that a good default would not be a
hardcoded constant offset (e.g. once you see the new warning, the auto-gc
kicks in after creating 100 objects) but some ratio of the threshold
(e.g. you have 2% margin after getting a warning before the auto-gc kicks
in).
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Junio C Hamano @ 2011-11-07 5:53 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> +static void handle_tags_and_duplicates(struct rev_info *revs, struct string_list *extra_refs)
> {
> int i;
>
> + /* even if no commits were exported, we need to export the ref */
> + for (i = 0; i < revs->cmdline.nr; i++) {
> + struct rev_cmdline_entry *elem = &revs->cmdline.rev[i];
> +
> + if (elem->flags & UNINTERESTING)
> + continue;
> +
> + if (elem->whence != REV_CMD_REV && elem->whence != REV_CMD_RIGHT)
> + continue;
> +
> + char *full_name;
> + dwim_ref(elem->name, strlen(elem->name), elem->item->sha1, &full_name);
Just a nit I've already fixed locally (iow no need to resend only to fix
this) but this is decl-after-stmt.
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Junio C Hamano @ 2011-11-07 5:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Additionally, the elem->whence != REV_CMD_RIGHT case should really
> check if REV_CMD_RIGHT_REF, but as this is not provided by the
> ref_info structure this is left as is.
I am not sure what you mean by REV_CMD_RIGHT_REF here. Do you mean "We are
only interested in the RHS endpoint of A...B syntax (i.e. B) but only when
it is a refname and not an arbitrary SHA-1 expression (e.g. even though
next~4 in "master...next~4" is a RHS endpoint, it is not a ref, and we do
not want it)"?
I think the distinction you are trying to express ("is it a ref and if so
what exact refname resolve_ref() would produce, or is it just the name of
a random commit?") is a very useful thing in general, but it is orthogonal
to what existing REV_CMD_* are trying to express, which is "where did they
come from", that you can read from the name of the field "whence".
Perhaps we would want to add a new field "const char *ref" to "struct
rev_cmdline_entry" to record the additional information you want perhaps
by storing the result of resolve_ref() if it is a ref and NULL otherwise.
Would it be too much work to add it to perfect this series?
By the way, REV_CMD_REF is meant to mean "the user did not explicitly name
this but it came as a result of iterating over refs/something/ namespace",
and does not mean "this is a tip of some ref" (they happen to be all refs,
but "obtained by iteration, not by explicit naming" is the more important
reason for marking them as such). As they are numerous, if you are going
to add that "const char *ref" field to rev_cmdline_entry, we may want to
either leave it NULL for REV_CMD_REF entries (the name field already has
that information anyway), or have it point at its name field (we need to
audit the codepath to free the name and ref fields if we go that route).
^ permalink raw reply
* pretty placeholders for reflog entries
From: Jack Nagel @ 2011-11-07 5:49 UTC (permalink / raw)
To: git
I have the reflog enabled on a bare repo so that I can have a record of
"who pushed what, when". I'd like to define a custom pretty format for
use with "git log -g" for reading it, but unfortunately the placeholders
for reflog information are somewhat limited. In particular, I'd like to
be able to access the identity (i.e., name and email) and date from each
reflog entry.
Is it possible to extract this information in current git? Perhaps I
overlooked something.
I suppose it would be simple enough to just write a script to parse the
reflog file(s), but it would be nice to be able to do this with git
itself.
Thanks.
Jack
^ permalink raw reply
* Re: [PATCH] remote: fix remote set-url usage
From: Junio C Hamano @ 2011-11-07 5:44 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Jonathan Nieder
In-Reply-To: <7vfwi04itx.fsf@alter.siamese.dyndns.org>
By the way, these two are low-impact fixes to relatively ancient problems,
so while it is not urgent enough to include them to the upcoming 1.7.8
(the users lived with the bug long enough and survived), I do not see much
problem to include them in it, either.
^ permalink raw reply
* Re: Find the size of git push in pre-receive hook
From: Junio C Hamano @ 2011-11-07 5:42 UTC (permalink / raw)
To: Manigandan S; +Cc: git
In-Reply-To: <CAFx4vfb-ssFXFEy9We7U+5+Fi+QsbcckNOEh1eXbMiqNfkU7jQ@mail.gmail.com>
Manigandan S <etc.mani@gmail.com> writes:
> Let me explain it in detail, if I was not clear.
Do not top-post on this list.
You said you wanted to restrict the size of a push, but what you are
trying is to restrict the size of a repository after a push. If accepting
this push will result in your repository go over the quota, the push will
be denied. Otherwise the push will be accepted.
If that is the case, how much the resulting repository weighs is what you
are trying to measure, not the size of _this_ push, i.e. the amount of
additional data this push will introduce, and "du -s" for the repository
inside pre-receive-hook is the way to do so.
^ permalink raw reply
* Re: [PATCH] remote: fix remote set-url usage
From: Junio C Hamano @ 2011-11-07 5:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jonathan Nieder
In-Reply-To: <1320637017-30863-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Bad copy-paste.
>
> Otherwise the help would be for a different command:
> git remote set-url --help
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
Doesn't the same thing apply to set-branches?
builtin/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index c4d17b5..06741ec 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1336,7 +1336,7 @@ static int set_branches(int argc, const char **argv)
builtin_remote_setbranches_usage, 0);
if (argc == 0) {
error("no remote specified");
- usage_with_options(builtin_remote_seturl_usage, options);
+ usage_with_options(builtin_remote_setbranches_usage, options);
}
argv[argc] = NULL;
^ permalink raw reply related
* Re: [PATCH] remote: fix remote set-url usage
From: Junio C Hamano @ 2011-11-07 4:34 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1320637017-30863-1-git-send-email-felipe.contreras@gmail.com>
Good eyes; thanks.
^ permalink raw reply
* Re: [PATCH] git-p4: ignore apple filetype
From: Junio C Hamano @ 2011-11-07 4:33 UTC (permalink / raw)
To: Michael Wookey
Cc: Pete Wyckoff, Git Mailing List, Vitor Antunes, Luke Diamand
In-Reply-To: <CAOk9v+9xbq0zBF=96GXeK4L-Z9PrGB_NO5h06u63PweRgFFB2g@mail.gmail.com>
Thanks, both. Will include the patch in 1.7.8-rc1.
^ permalink raw reply
* Re: [PATCH v2 4/4] fsck: print progress
From: Junio C Hamano @ 2011-11-07 4:33 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Jeff King, Stephen Boyd
In-Reply-To: <1320634766-24511-5-git-send-email-pclouds@gmail.com>
Thanks. Will queue.
^ permalink raw reply
* [PATCH] remote: fix remote set-url usage
From: Felipe Contreras @ 2011-11-07 3:36 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Bad copy-paste.
Otherwise the help would be for a different command:
git remote set-url --help
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index e1285be..2add79a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1427,7 +1427,7 @@ static int set_url(int argc, const char **argv)
"delete URLs"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_seturl_usage,
PARSE_OPT_KEEP_ARGV0);
if (add_mode && delete_mode)
--
1.7.7
^ permalink raw reply related
* [PATCH v2 4/4] fsck: print progress
From: Nguyễn Thái Ngọc Duy @ 2011-11-07 2:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Stephen Boyd,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1320634766-24511-1-git-send-email-pclouds@gmail.com>
fsck is usually a long process and it would be nice if it prints
progress from time to time.
Progress meter is not printed when --verbose is given because
--verbose prints a lot, there's no need for "alive" indicator.
Progress meter may provide "% complete" information but it would
be lost anyway in the flood of text.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-fsck.txt | 11 ++++++++++-
builtin/fsck.c | 40 ++++++++++++++++++++++++++++++++++++++--
pack-check.c | 14 +++++++++++---
pack.h | 3 ++-
4 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index a2a508d..0a17b42 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found]
+ [--[no-]progress] [<object>*]
DESCRIPTION
-----------
@@ -72,6 +73,14 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
a blob, the contents are written into the file, rather than
its object name.
+--progress::
+--no-progress::
+ Progress status is reported on the standard error stream by
+ default when it is attached to a terminal, unless
+ --no-progress or --verbose is specified. --progress forces
+ progress status even if the standard error stream is not
+ directed to a terminal.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 0603f64..c4b1ca6 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -11,6 +11,7 @@
#include "fsck.h"
#include "parse-options.h"
#include "dir.h"
+#include "progress.h"
#define REACHABLE 0x0001
#define SEEN 0x0002
@@ -27,6 +28,7 @@ static const char *head_points_at;
static int errors_found;
static int write_lost_and_found;
static int verbose;
+static int show_progress = -1;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
#define ERROR_PACK 04
@@ -138,7 +140,11 @@ static int traverse_one_object(struct object *obj)
static int traverse_reachable(void)
{
+ struct progress *progress = NULL;
+ unsigned int nr = 0;
int result = 0;
+ if (show_progress)
+ progress = start_progress_delay("Checking connectivity", 0, 0, 2);
while (pending.nr) {
struct object_array_entry *entry;
struct object *obj;
@@ -146,7 +152,9 @@ static int traverse_reachable(void)
entry = pending.objects + --pending.nr;
obj = entry->item;
result |= traverse_one_object(obj);
+ display_progress(progress, ++nr);
}
+ stop_progress(&progress);
return !!result;
}
@@ -530,15 +538,20 @@ static void get_default_heads(void)
static void fsck_object_dir(const char *path)
{
int i;
+ struct progress *progress = NULL;
if (verbose)
fprintf(stderr, "Checking object directory\n");
+ if (show_progress)
+ progress = start_progress("Checking object directories", 256);
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", path, i);
fsck_dir(i, dir);
+ display_progress(progress, i+1);
}
+ stop_progress(&progress);
fsck_sha1_list();
}
@@ -609,6 +622,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
+ OPT_BOOL (0, "progress", &show_progress, "show progress"),
OPT_END(),
};
@@ -621,6 +635,12 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
read_replace_refs = 0;
argc = parse_options(argc, argv, prefix, fsck_opts, fsck_usage, 0);
+
+ if (show_progress == -1)
+ show_progress = isatty(2);
+ if (verbose)
+ show_progress = 0;
+
if (write_lost_and_found) {
check_full = 1;
include_reflogs = 0;
@@ -640,12 +660,28 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
if (check_full) {
struct packed_git *p;
+ uint32_t total = 0, count = 0;
+ struct progress *progress = NULL;
prepare_packed_git();
- for (p = packed_git; p; p = p->next)
+
+ if (show_progress) {
+ for (p = packed_git; p; p = p->next) {
+ if (open_pack_index(p))
+ continue;
+ total += p->num_objects;
+ }
+
+ progress = start_progress("Checking objects", total);
+ }
+ for (p = packed_git; p; p = p->next) {
/* verify gives error messages itself */
- if (verify_pack(p, fsck_obj_buffer))
+ if (verify_pack(p, fsck_obj_buffer,
+ progress, count))
errors_found |= ERROR_PACK;
+ count += p->num_objects;
+ }
+ stop_progress(&progress);
}
heads = 0;
diff --git a/pack-check.c b/pack-check.c
index 3b48b86..63a595c 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "pack.h"
#include "pack-revindex.h"
+#include "progress.h"
struct idx_entry {
off_t offset;
@@ -43,7 +44,9 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
static int verify_packfile(struct packed_git *p,
struct pack_window **w_curs,
- verify_fn fn)
+ verify_fn fn,
+ struct progress *progress, uint32_t base_count)
+
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -127,8 +130,12 @@ static int verify_packfile(struct packed_git *p,
if (eaten)
data = NULL;
}
+ if (((base_count + i) & 1023) == 0)
+ display_progress(progress, base_count + i);
free(data);
+
}
+ display_progress(progress, base_count + i);
free(entries);
return err;
@@ -157,7 +164,8 @@ int verify_pack_index(struct packed_git *p)
return err;
}
-int verify_pack(struct packed_git *p, verify_fn fn)
+int verify_pack(struct packed_git *p, verify_fn fn,
+ struct progress *progress, uint32_t base_count)
{
int err = 0;
struct pack_window *w_curs = NULL;
@@ -166,7 +174,7 @@ int verify_pack(struct packed_git *p, verify_fn fn)
if (!p->index_data)
return -1;
- err |= verify_packfile(p, &w_curs, fn);
+ err |= verify_packfile(p, &w_curs, fn, progress, base_count);
unuse_pack(&w_curs);
return err;
diff --git a/pack.h b/pack.h
index 70f3c29..324a1d7 100644
--- a/pack.h
+++ b/pack.h
@@ -71,12 +71,13 @@ struct pack_idx_entry {
};
+struct progress;
typedef int (*verify_fn)(const unsigned char*, enum object_type, unsigned long, void*, int*);
extern const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, const struct pack_idx_option *, unsigned char *sha1);
extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
extern int verify_pack_index(struct packed_git *);
-extern int verify_pack(struct packed_git *, verify_fn fn);
+extern int verify_pack(struct packed_git *, verify_fn fn, struct progress *, uint32_t);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t, unsigned char *, off_t);
extern char *index_pack_lockfile(int fd);
extern int encode_in_pack_object_header(enum object_type, uintmax_t, unsigned char *);
--
1.7.4.74.g639db
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox