* 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: [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 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 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 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: 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] 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: 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: 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
* 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
* 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: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
* 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
* 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: [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: 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
* 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: 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
* git fsck: failed to apply delta
From: Andre Noll @ 2011-11-07 14:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
Hi
I'm getting this when running git fsck or git repack against a large
(21G) repo which was created from subversion using git svn clone:
fatal: failed to apply delta
The debugging patch below indicates that this repo fails the sanity
check for the size in patch_delta(). With this patch applied I'm
getting the following additional output
error: bad delta header size, expected: 236, have 1994568
This is 100% reproducible. I'm using the git master branch as of
today (5ae0f681) but the same problem showed up also with an older
git version.
Does anybody know what's going on here?
Thanks
Andre
---
diff --git a/patch-delta.c b/patch-delta.c
index 56e0a5e..cff4d79 100644
--- a/patch-delta.c
+++ b/patch-delta.c
@@ -28,8 +28,10 @@ void *patch_delta(const void *src_buf, unsigned long src_size,
/* make sure the orig file size matches what we expect */
size = get_delta_hdr_size(&data, top);
- if (size != src_size)
+ if (size != src_size) {
+ error("bad delta header size, expected: %lu, have %lu", src_size, size);
return NULL;
+ }
/* now the result size */
size = get_delta_hdr_size(&data, top);
--
The only person who always got his work done by Friday was Robinson Crusoe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* how to merge sub directory or file?
From: Emily @ 2011-11-07 14:54 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <20111107172652.0faade61@ashu.dyn.rarus.ru>
Hi,
I have two git projects A and B, content of B is subset of A. For example, Project A and B's tree are as below:
A
--- dir1
--- dir2
--- dir3
|---file1
|---dir4
|---dir5
--- dir6
--- dir7
B
--- dir1
--- dir3
|--- file1
|--- dir4
When there's new changes in project A, how can I merge them to project B without changing B's directory structure?
Your help will be highly appreciated.
Thanks,
Emily
^ permalink raw reply
* Re: how to merge sub directory or file?
From: Konstantin Khomoutov @ 2011-11-07 15:37 UTC (permalink / raw)
To: Emily; +Cc: git@vger.kernel.org
In-Reply-To: <8B3D19E0-2181-4E9C-943F-CA26A399E0D9@gmail.com>
On Mon, 7 Nov 2011 22:54:18 +0800
Emily <lingyan.ren@gmail.com> wrote:
> I have two git projects A and B, content of B is subset of A. For
> example, Project A and B's tree are as below:
[...]
> When there's new changes in project A, how can I merge them to
> project B without changing B's directory structure?
>
> Your help will be highly appreciated.
Subtree merging maybe?
See http://progit.org/book/ch6-7.html
^ permalink raw reply
* git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-07 15:33 UTC (permalink / raw)
To: git
Hello all,
I'm experiencing problems when trying to set up a git repository
managed by git-http-backend. I've done the following :
- on the server side
cd /git
mkdir test13
git --bare init .
>>> Initialized empty Git repository in /git/test13
/usr/local/libexec/git-core/git-update-server-info
chown -R apache.apache .
- on the client side
cd (project-directory)
$ git init
$ (add some files)
$ git add .
$ git commit -m 'Initial commit'
git push http://git.istic.smw.fr/test13 master
Username:
Password:
error: Cannot access URL http://git.istic.smw.fr/test13/, return code 22
fatal: git-http-push failed
- apache acces_log
1) ip-address - metheuser [07/Nov/2011:16:17:31 +0100]
"GET /test13/info/refs?service=git- receive-pack HTTP/1.1" 200 - "-" "git/1.7.3.4"
2) ip-address - metheuser [07/Nov/2011:16:17:32 +0100]
"GET /test13/HEAD HTTP/1.1" 200 23 "-" "git/1.7.3.4"
3) ip-address - - [07/Nov/2011:16:17:32 +0100]
"PROPFIND /test13/ HTTP/1.1" 401 492 "-" "git/1.7.3.4"
- what sounds strange to me : the 2 firsts requests are generated by my client side
(wireshark used as a clue) but the third comes from the server side and the users
credentials are missed !
- And also, I was hoping to use smart httpd and so the generated PROPFIND (DAV)
is amazing.
Any help would be appreciated.
Cheers.
François Dagorn
Université de rennes 1
France
^ permalink raw reply
* [PATCH] blame.c: Properly initialize strbuf after calling textconv_object(), again
From: Sebastian Schuberth @ 2011-11-07 15:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
2564aa4 started to initialize buf.alloc, but that should actually be one
more byte than the string length due to the trailing \0.
---
builtin/blame.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 86c0537..45f0dcc 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2114,7 +2114,7 @@ static struct commit *fake_working_tree_commit(struct diff_options *opt,
case S_IFREG:
if (DIFF_OPT_TST(opt, ALLOW_TEXTCONV) &&
textconv_object(read_from, mode, null_sha1, &buf.buf, &buf_len)) {
- buf.alloc = buf_len;
+ buf.alloc = buf_len + 1;
buf.len = buf_len;
}
else if (strbuf_read_file(&buf, read_from, st.st_size) != st.st_size)
--
1.7.8.rc0.46.g5ae0f.dirty
^ permalink raw reply related
* [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-07 16:07 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
This is useful to mirror all the branches in the current repo to
another.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-remote.txt | 17 +++++++
builtin/remote.c | 108 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 15 ++++++
3 files changed, 140 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 5a8c506..643fc8b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -21,6 +21,7 @@ SYNOPSIS
'git remote' [-v | --verbose] 'show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...]
+'git remote sync' <name> [-a | --all] [-n | --new] [-p | --prune] [-f | --force] [--dry-run]
DESCRIPTION
-----------
@@ -169,6 +170,22 @@ be updated. (See linkgit:git-config[1]).
+
With `--prune` option, prune all the remotes that are updated.
+'sync'::
+
+Synchronizes local branches with certain remote. This is useful to backup all
+the branches in a local repository to a remote one, regardless of what upstream
+is configured for each branch.
++
+With `--prune`, remote branches will be deleted if they are not also locally.
++
+With `--new`, local branches that are not yet in the remote will be pushed too.
++
+With `--all`, basically both `--prune` and `--new` will be selected.
++
+With `--force`, existing branches will be forced to update, like `git push
+--force`.
++
+With `--dry-run`, all the changes will be reported, but not really happen.
DISCUSSION
----------
diff --git a/builtin/remote.c b/builtin/remote.c
index e1285be..b3b9b19 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -64,6 +64,11 @@ static const char * const builtin_remote_update_usage[] = {
NULL
};
+static const char * const builtin_remote_sync_usage[] = {
+ "git remote sync <name> [-a|--all] [-n|--new] [-p|--prune] [<options>]",
+ NULL
+};
+
static const char * const builtin_remote_seturl_usage[] = {
"git remote set-url [--push] <name> <newurl> [<oldurl>]",
"git remote set-url --add <name> <newurl>",
@@ -1492,6 +1497,107 @@ static int set_url(int argc, const char **argv)
return 0;
}
+struct action {
+ struct string_list *list;
+ int type;
+};
+
+static int ref_cb(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct action *action = cb_data;
+ struct string_list_item *item;
+ if (strcmp(refname, "HEAD") == 0)
+ return 0;
+ item = string_list_insert(action->list, refname);
+ item->util = (void *)((long)item->util | action->type);
+ return 0;
+}
+
+static int for_each_in_remote_ref(const char *name, each_ref_fn fn, void *cb_data)
+{
+ char prefix[1000];
+ sprintf(prefix, "refs/remotes/%s/", name);
+ return for_each_ref_in(prefix, fn, cb_data);
+}
+
+static int do_sync(int argc, const char **argv)
+{
+ const char *remotename;
+ struct string_list list;
+ struct action action;
+ struct remote *remote;
+ struct transport *transport;
+ int i, r, nonff;
+ char **refspec;
+ int refspec_nr = 0;
+ int prune = 0, new = 0, all = 0, flags = 0;
+
+ struct option options[] = {
+ OPT_BOOLEAN('p', "prune", &prune, "prune remote branches"),
+ OPT_BOOLEAN('n', "new", &new, "push new branches"),
+ OPT_BOOLEAN('a', "all", &all, "synchronize everything"),
+ OPT_BIT(0, "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
+ OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
+ OPT_END()
+ };
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sync_usage,
+ PARSE_OPT_KEEP_ARGV0);
+ if (argc < 2 || argc > 2)
+ usage_with_options(builtin_remote_sync_usage, options);
+
+ if (all)
+ prune = new = 1;
+
+ remotename = argv[1];
+ if (!remote_is_configured(remotename))
+ die("No such remote '%s'", remotename);
+
+ memset(&list, 0, sizeof(list));
+
+ action.list = &list;
+
+ action.type = 1;
+ for_each_in_remote_ref(remotename, ref_cb, &action);
+
+ action.type = 2;
+ for_each_branch_ref(ref_cb, &action);
+
+ refspec = xmalloc(sizeof(*refspec) * list.nr);
+
+ for (i = 0; i < list.nr; i++) {
+ const char *str = list.items[i].string;
+ char *t = NULL;
+
+ switch ((long)list.items[i].util) {
+ case 1:
+ if (prune)
+ asprintf(&t, ":%s", str);
+ break;
+ case 2:
+ if (new)
+ t = strdup(str);
+ break;
+ case 3:
+ t = strdup(str);
+ break;
+ }
+ if (t)
+ refspec[refspec_nr++] = t;
+ }
+
+ remote = remote_get(remotename);
+ transport = transport_get(remote, NULL);
+ r = transport_push(transport, refspec_nr, (const char **)refspec, flags, &nonff);
+
+ for (i = 0; i < refspec_nr; i++)
+ free(refspec[i]);
+
+ string_list_clear(&list, 0);
+
+ return r;
+}
+
static int get_one_entry(struct remote *remote, void *priv)
{
struct string_list *list = priv;
@@ -1581,6 +1687,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = prune(argc, argv);
else if (!strcmp(argv[0], "update"))
result = update(argc, argv);
+ else if (!strcmp(argv[0], "sync"))
+ result = do_sync(argc, argv);
else {
error("Unknown subcommand: %s", argv[0]);
usage_with_options(builtin_remote_usage, options);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index e8af615..13378c5 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -997,4 +997,19 @@ test_expect_success 'remote set-url --delete baz' '
cmp expect actual
'
+test_expect_success 'remote sync' '
+ setup_repository sync-origin &&
+ (cd sync-origin &&
+ git branch another &&
+ git config receive.denyCurrentBranch ignore) &&
+ git clone sync-origin sync &&
+ (cd sync &&
+ git branch -a > /tmp/a &&
+ git remote sync origin &&
+ git commit --allow-empty -m "Test" &&
+ git checkout side &&
+ git commit --allow-empty -m "Test" &&
+ git remote sync -a origin)
+'
+
test_done
--
1.7.7
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-11-07 16:24 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Ted Ts'o, Junio C Hamano, Shawn Pearce, git, James Bottomley,
Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <22879.1320652337@turing-police.cc.vt.edu>
On Sun, Nov 6, 2011 at 11:52 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
> 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.
I don't think we are quite there yet. And (sadly) most of the commit
ID's in the history are 7 hex characters, because that used to be the
default git abbreviation. So there is unlikely to be any real
conflicts.
If we do miss one or two, that will be sad and embarrassing, but is
not a real problem in practice.
We probably could add various heuristics (the SHA1 values are *often*
preceded by the string "commit"), and a really good import would also
have somebody at least visually inspecting ones that other heuristics
say might be debatable (for example - because they have 8 hex digits
and there are other numbers around them that were *not* converted),
but in the end perfection is the enemy of good. It's not really worth
the headache to worry about *all* the cases, if you can cheaply and
simply get 99+% right.
And I think the 99% is almost trivial. While the last 1% may or may
not be worth worrying about.
Linus
^ 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