* How to take dump and import to new git repository
From: redhat1981 @ 2011-11-07 11:44 UTC (permalink / raw)
To: git
Hi,
I am Svn admin, I am new to git, Please let me know
How to take dump and import to new git repository.
redhat1981@gmail.com
--
View this message in context: http://git.661346.n2.nabble.com/How-to-take-dump-and-import-to-new-git-repository-tp6970073p6970073.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* How to take dump and import to new git repository
From: redhat1981 @ 2011-11-07 11:43 UTC (permalink / raw)
To: git
Hi,
I am Svn admin, I am new to git, Please let me know
How to take dump and import to new git repository.
redhat1981@gmail.com
--
View this message in context: http://git.661346.n2.nabble.com/How-to-take-dump-and-import-to-new-git-repository-tp6970065p6970065.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* How to take dump and import to new git repository
From: redhat1981 @ 2011-11-07 11:41 UTC (permalink / raw)
To: git
Hi,
I am SVN admin, Fluent with SVN, Git I am a new user, Please let me know,
How to take dump of one git repository and then import that Dump to new
Repo.
Thank you
redhat1981@gmail.com
--
View this message in context: http://git.661346.n2.nabble.com/How-to-take-dump-and-import-to-new-git-repository-tp6970049p6970049.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7
From: Nguyen Thai Ngoc Duy @ 2011-11-07 11:21 UTC (permalink / raw)
To: Tony Wang; +Cc: Git Mailing List
In-Reply-To: <EF1B195E54C9411A91CCF9A21C5FADC2@gmail.com>
On Mon, Nov 7, 2011 at 6:02 PM, Tony Wang <wwwjfy@gmail.com> wrote:
> Yes! It works.
> I do learn from it, thanks!
> But seems it's possible the potential problem exists somewhere else.
Sure. There are 58 resolve_ref() call sites. I'll go through and send
proper patches later.
--
Duy
^ permalink raw reply
* Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7
From: Tony Wang @ 2011-11-07 11:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <20111107104128.GA2964@do>
On Monday, November 7, 2011 at 18:41, Nguyen Thai Ngoc Duy wrote:
> On Mon, Nov 07, 2011 at 05:48:25PM +0800, Tony Wang wrote:
> > > 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.
>
> and the strange value of branch "s/origin/b" in your previous message..
that's the strange thing. seems like part of the string "refs/origin/b"
>
> > >
> > > > 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".
> > >
> >
>
>
>
> ..led me to think that it's because branch points to the static buffer
> returned by by resolve_ref().
>
> lookup_commit_reference() may call resolve_ref() again and change the
> buffer value, which also changes "branch" variable.
>
> So, does this help?
>
> -- 8< --
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 581f494..4f20833 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -1029,7 +1029,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> * Check if we are _not_ on a detached HEAD, i.e. if there is a
> * current branch.
> */
> - branch = resolve_ref("HEAD", head_sha1, 0, &flag);
> + branch = xstrdup(resolve_ref("HEAD", head_sha1, 0, &flag));
> if (branch && !prefixcmp(branch, "refs/heads/"))
> branch += 11;
> if (!branch || is_null_sha1(head_sha1))
> -- 8< --
Yes! It works.
I do learn from it, thanks!
But seems it's possible the potential problem exists somewhere else.
> --
> Duy
--
BR,
Tony Wang
^ permalink raw reply
* Re: [PATCH] gc --auto: warn gc will soon run, give users a chance to run manually
From: Nguyen Thai Ngoc Duy @ 2011-11-07 10:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfwi031ts.fsf@alter.siamese.dyndns.org>
2011/11/7 Junio C Hamano <gitster@pobox.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).
>
> ...
>
> 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).
Speaking for myself, as soon as I see the warning, I would immediately
start a new shell for git-gc alone and get back to my work (hopefully
gc will not be activated again while another gc is running) so one or
maybe three warnings may be enough. But yes, some ratio may be better
for different users.
--
Duy
^ permalink raw reply
* Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7
From: Nguyen Thai Ngoc Duy @ 2011-11-07 10:41 UTC (permalink / raw)
To: Tony Wang; +Cc: Git Mailing List
In-Reply-To: <841269128C1D4788816CA66A33ED39E5@gmail.com>
On Mon, Nov 07, 2011 at 05:48:25PM +0800, Tony Wang wrote:
> > 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.
and the strange value of branch "s/origin/b" in your previous message..
> >
> > > 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".
..led me to think that it's because branch points to the static buffer
returned by by resolve_ref().
lookup_commit_reference() may call resolve_ref() again and change the
buffer value, which also changes "branch" variable.
So, does this help?
-- 8< --
diff --git a/builtin/merge.c b/builtin/merge.c
index 581f494..4f20833 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1029,7 +1029,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* Check if we are _not_ on a detached HEAD, i.e. if there is a
* current branch.
*/
- branch = resolve_ref("HEAD", head_sha1, 0, &flag);
+ branch = xstrdup(resolve_ref("HEAD", head_sha1, 0, &flag));
if (branch && !prefixcmp(branch, "refs/heads/"))
branch += 11;
if (!branch || is_null_sha1(head_sha1))
-- 8< --
--
Duy
^ permalink raw reply related
* Re: [PATCH 4/4] Documentation/gitignore: explain how to un-ignore part of a directory
From: Nguyen Thai Ngoc Duy @ 2011-11-07 10:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Blake, Johannes Sixt, Y.G., Eli Barzilay
In-Reply-To: <20111107081132.GD30486@elie.hsd1.il.comcast.net>
2011/11/7 Jonathan Nieder <jrnieder@gmail.com>:
> 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
>
gitignore.txt is also referred in sparse checkout. And (un)fortunately
the former also works in sparse checkout. I don't know, may be you
could put this in a subsection or something reference-able so we could
mention in sparse checkout document that this part of gitignore.txt
does not apply to sparse checkout?
--
Duy
^ permalink raw reply
* Re: [PATCH 3/4] Documentation: unanchored gitignore patterns match basename
From: Nguyen Thai Ngoc Duy @ 2011-11-07 10:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Blake, Johannes Sixt, Y.G., Eli Barzilay
In-Reply-To: <20111107080926.GC30486@elie.hsd1.il.comcast.net>
2011/11/7 Jonathan Nieder <jrnieder@gmail.com>:
> 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>
Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
--
Duy
^ permalink raw reply
* Re: [PATCH 2/4] Documentation: clarify effect of '/' in gitignore(5) patterns
From: Nguyen Thai Ngoc Duy @ 2011-11-07 10:05 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Blake, Johannes Sixt, Y.G., Eli Barzilay
In-Reply-To: <20111107080842.GB30486@elie.hsd1.il.comcast.net>
2011/11/7 Jonathan Nieder <jrnieder@gmail.com>:
> 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.
I think I make this mistake too. Documenting it is one way. Another way is t
>
> 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.
I think the first slash in 'foo//' may function as the anchor and it's
not very clear to me if it's in the middle of pattern of at the end.
Of course we could just change the code to strip all trailing slashes.
--
Duy
^ permalink raw reply
* Re: [PATCH 1/4] Documentation/gitignore: "foo/" patterns match directories, not files under them
From: Nguyen Thai Ngoc Duy @ 2011-11-07 9:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Blake, Johannes Sixt, Y.G., Eli Barzilay
In-Reply-To: <20111107080711.GA30486@elie.hsd1.il.comcast.net>
2011/11/7 Jonathan Nieder <jrnieder@gmail.com>:
> The gitignore(5) manpage says that "foo/" will match a directory foo
> and paths underneath it.
If git ignores a directory, then it essentially ignores all paths
underneath it, doesn't 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.
I haven't checked but I think it's because when a directory is
ignored, git just stops checking further ignore rules. So "build" _is_
ignored, too strongly that it does not care if some files may need to
be un-ignored later on.
I remember the argument was, because ignore rules are distributed
across .gitignore files, we would need to go into ignored directories
for collecting potential un-ignore rules (for example "!results" on
build/tests/.gitignore) and that just does not make much sense because
we always have to go into ignored directories.
But in your example, where we know we have negated rules, we should
follow the rules and ignore all but build/tests/results.
> 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.
I haven't not read the next patches, maybe you have mentioned this
already. We should make clear that git does not look for negated rules
once a directory is ignored.
Your example however demonstrates a bug that should be fixed in my
opinion. So maybe one or two lines under BUGS section.
> 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).
Looks good.
> ++
> +The trailing slash is removed before applying the remaining
> +rules.
Why does the trailing slash of a rule affect the remaining rules?
--
Duy
^ permalink raw reply
* 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
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