* Re: BUG. Git config pager when --edit
From: Frans Klaver @ 2011-11-07 13:43 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111107172652.0faade61@ashu.dyn.rarus.ru>
Hi,
On Mon, Nov 7, 2011 at 2:26 PM, Alexey Shumkin <Alex.Crezoff@gmail.com> wrote:
> As far as my config is large enough to be paged I set pager.config=less
> setting. But since that moment when I run
> $ git config --edit
> I get
> Vim: Warning: Output is not to a terminal
> And some messed config output
>
> The same happens if to run
> $ vim .git/config | less
So git is trying to tell vim to pipe its output to less. vim can't do
that because it needs a terminal, as it's the only way vim is usable.
Should pager.config then only be used with --list?
^ permalink raw reply
* BUG. Git config pager when --edit
From: Alexey Shumkin @ 2011-11-07 13:26 UTC (permalink / raw)
To: git
Hello!
I've found an annoying bug.
When I wanna review my config I run
$ git config --list
When I wanna edit config I run
$ git config --edit [--global]
As far as my config is large enough to be paged I set pager.config=less
setting. But since that moment when I run
$ git config --edit
I get
Vim: Warning: Output is not to a terminal
And some messed config output
The same happens if to run
$ vim .git/config | less
Can anybody skilled enough fix it? :)
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Andreas Schwab @ 2011-11-07 13:12 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Jim Meyering, Fredrik Gustafsson
In-Reply-To: <CACBZZX6CRm1W5i43=LeXPJFdcWFgVTkD8cGntHoKsPoWGx_hNg@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> I.e. we'll always have GREP_HEADER_AUTHOR = 0 and
> GREP_HEADER_COMMITTER = 1, we'll never have GREP_HEADER_AUTHOR = and
> GREP_HEADER_COMMITTER = <some int>.
That is irrelevant. You can always assign -1 to an object of enumerated
type and the implicit conversion to the underlying type is fully
defined, no matter what type the compiler choses.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2] pull: introduce a pull.rebase option to enable --rebase
From: Ævar Arnfjörð Bjarmason @ 2011-11-07 12:44 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Eric Herman, Sverre Rabbelier,
Fernando Vezzosi, Johannes Schindelin
In-Reply-To: <4EB6E5AD.7060605@kdbg.org>
On Sun, Nov 6, 2011 at 20:53, Johannes Sixt <j6t@kdbg.org> wrote:
> When you continue an indented item in a separate paragraph, then you
> must not use an empty line, but have line with '+' and un-indented
> continuation paragraphs. See examples in this file.
Thanks for spotting that.
Junio: Should I spam you with another patch or is something you'd
prefer to just fix up?
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Ævar Arnfjörð Bjarmason @ 2011-11-07 12:42 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git, Junio C Hamano, Jim Meyering, Fredrik Gustafsson
In-Reply-To: <m2pqh5nvic.fsf@igel.home>
On Sun, Nov 6, 2011 at 16:03, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Remove an "p->field < 0" comparison in grep.c that'll always be
>> false. In this case "p" is a "grep_pat" where "field" is defined as:
>>
>> enum grep_header_field field;
>>
>> And grep_header_field is in turn defined as:
>>
>> enum grep_header_field {
>> GREP_HEADER_AUTHOR = 0,
>> GREP_HEADER_COMMITTER
>> };
>>
>> Meaning that this comparison will always be false.
>
> The underlying integer type is implementation-defined, and can be any
> signed or unsigned integer type that can represent all enumerations.
Yes, but as far as I can tell since we've done "= 0" there that
doesn't apply to us. To quote the ANSI C Standard (ANSI X3J11/88-090):
3.5.2.2 Enumeration specifiers
Syntax
enum-specifier:
enum identifier<opt> { enumerator-list }
enum identifier
enumerator-list:
enumerator
enumerator-list , enumerator
enumerator:
enumeration-constant
enumeration-constant = constant-expression
Constraints
The expression that defines the value of an enumeration constant
shall be an integral constant expression that has a value
representable as an int.
Semantics
The identifiers in an enumerator list are declared as constants
that have type int and may appear wherever such are permitted./52/ An
enumerator with = defines its enumeration constant as the value of the
constant expression. If the first enumerator has no = , the value of
its enumeration constant is 0. Each subsequent enumerator with no =
defines its enumeration constant as the value of the constant
expression obtained by adding 1 to the value of the previous
enumeration constant. (A combination of both forms of enumerators may
produce enumeration constants with values that duplicate other values
in the same enumeration.) The enumerators of an enumeration are also
known as its members.
Each enumerated type shall be compatible with an integer type; the
choice of type is implementation-defined.
Example
enum hue { chartreuse, burgundy, claret=20, winedark };
/*...*/
enum hue col, *cp;
/*...*/
col = claret;
cp = &col;
/*...*/
/*...*/ (*cp != burgundy) /*...*/
makes hue the tag of an enumeration, and then declares col as an
object that has that type and cp as a pointer to an object that has
that type. The enumerated values are in the set {0, 1, 20, 21}.
I.e. we'll always have GREP_HEADER_AUTHOR = 0 and
GREP_HEADER_COMMITTER = 1, we'll never have GREP_HEADER_AUTHOR = and
GREP_HEADER_COMMITTER = <some int>.
^ permalink raw reply
* Re: How to take dump and import to new git repository
From: Carlos Martín Nieto @ 2011-11-07 11:46 UTC (permalink / raw)
To: redhat1981; +Cc: git
In-Reply-To: <1320666117862-6970049.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Mon, Nov 07, 2011 at 03:41:57AM -0800, redhat1981 wrote:
> 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.
This is what cloning a repository does. You're probably looking for
the --mirror option.
git clone --mirror somerepo.git newrepo.git
will give you a repository in newrepo.git that has all the branches
and tags from somerepo.git.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* 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
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