* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-07 17:22 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1320682032-12698-1-git-send-email-felipe.contreras@gmail.com>
On Mon, Nov 07, 2011 at 06:07:12PM +0200, Felipe Contreras wrote:
> This is useful to mirror all the branches in the current repo to
> another.
> [...]
> +'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.
Why is this in "git remote", and not "git push"? The former is usually
about managing the configuration of remotes, not about actually doing
the ref transfer (the "-f" flag excepted, but that is clearly just
calling out to "fetch").
And how does this differ from "git push --mirror"? It looks like you
have more options for what pushing all versus pruning, but wouldn't it
be better for "git push" to grow those options?
-Peff
^ permalink raw reply
* Re: BUG. Git config pager when --edit
From: Jeff King @ 2011-11-07 17:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frans Klaver, Alexey Shumkin, git
In-Reply-To: <7vpqh327ds.fsf@alter.siamese.dyndns.org>
On Mon, Nov 07, 2011 at 09:02:23AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I should probably polish and submit the patch here:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/182238/focus=182475
>
> I was actually hoping that you won't go that route, but the route to push
> further to decide/spawn pager as late as possible. Clearly no sane person
> would want to run --edit subcommand under pager and "pager.config = less"
> should just be ignored in such a case.
The problem with that is that it dumps the responsibility for running
the pager to every subcommand. For builtins, we can have a flag that
says "respect the pager.log config" or "foo will handle this itself;
don't respect pager.tag".
But what about externals? If "pager.stash" does nothing in git.c, and
leaves it to "git-stash.sh" to start the pager if and when it's
appropriate, then what about my personal "git-foo" that I drop into my
PATH? Now I can't use "config.foo" without carrying code to do so in my
external command.
Maybe that's an OK tradeoff. But it's more of a pain for existing
scripts, and it's not backwards compatible. What do you think?
-Peff
^ permalink raw reply
* Re: BUG. Git config pager when --edit
From: Junio C Hamano @ 2011-11-07 17:02 UTC (permalink / raw)
To: Jeff King; +Cc: Frans Klaver, Alexey Shumkin, git
In-Reply-To: <20111107164250.GC27055@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I should probably polish and submit the patch here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/182238/focus=182475
I was actually hoping that you won't go that route, but the route to push
further to decide/spawn pager as late as possible. Clearly no sane person
would want to run --edit subcommand under pager and "pager.config = less"
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: Tay Ray Chuan @ 2011-11-07 17:02 UTC (permalink / raw)
To: François Dagorn; +Cc: git
In-Reply-To: <4EB7FA3A.8070908@univ-rennes1.fr>
On Mon, Nov 7, 2011 at 11:33 PM, François Dagorn
<Francois.Dagorn@univ-rennes1.fr> wrote:
> - 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 !
Can you update your git installation and try again? v1.7.3.4 sounds
pretty old (almost a year).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 1/4] Documentation/gitignore: "foo/" patterns match directories, not files under them
From: Junio C Hamano @ 2011-11-07 16:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jonathan Nieder, git, Eric Blake, Johannes Sixt, Y.G.,
Eli Barzilay
In-Reply-To: <CACsJy8CZFihbS8MrG=0gWdRPu6F0BqG2FLp48KDxOXWc+4amuQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 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.
Or just remove "In other words, ..." that is bogus. Everything before that
is correct.
>> ++
>> +The trailing slash is removed before applying the remaining
>> +rules.
>
> Why does the trailing slash of a rule affect the remaining rules?
Later rule makes a path with and without a slash in it work differently.
A single token "foo/" acts as if there is no trailing slash to match
any directory in the hierarchy, e.g. it matches a directory "frotz/foo".
^ permalink raw reply
* Re: [PATCH] blame.c: Properly initialize strbuf after calling textconv_object(), again
From: Jeff King @ 2011-11-07 16:49 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, Junio C Hamano
In-Reply-To: <4EB7FEE6.9000609@gmail.com>
On Mon, Nov 07, 2011 at 04:53:10PM +0100, Sebastian Schuberth wrote:
> --- 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)
Your patch is correct in the sense that this fixes a bug, but it just
seems wrong to be touching the alloc parameter outside of the strbuf
code. It looks like the intent is to do the equivalent of:
strbuf_add(&buf, some_heap_buf, len);
free(some_heap_buf);
but avoid the extra allocation and copy. Should there be a
"strbuf_attach" function to encapsulate this pattern?
-Peff
^ permalink raw reply
* Re: [PATCH] blame.c: Properly initialize strbuf after calling textconv_object(), again
From: Junio C Hamano @ 2011-11-07 16:47 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Junio C Hamano, git
In-Reply-To: <4EB7FEE6.9000609@gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> 2564aa4 started to initialize buf.alloc, but that should actually be one
> more byte than the string length due to the trailing \0.
Even when the conversion result is a zero-length string?
> ---
Sign-off?
> 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)
^ permalink raw reply
* Re: [PATCH v2] pull: introduce a pull.rebase option to enable --rebase
From: Junio C Hamano @ 2011-11-07 16:44 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Johannes Sixt, git, Eric Herman, Sverre Rabbelier,
Fernando Vezzosi, Johannes Schindelin
In-Reply-To: <CACBZZX5Lq7vunx-QnsrufQVWJ6xYPoMXnv+tMwhOC3XbrZO11A@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 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?
It is about the same amount of work for me; I've just dedented the two
paragraphs that start with "*NOTE*:" and replaced the blank lines before
them with a single "+". Is that what you wanted to resend, or is there
anything else?
^ permalink raw reply
* Re: BUG. Git config pager when --edit
From: Jeff King @ 2011-11-07 16:42 UTC (permalink / raw)
To: Frans Klaver; +Cc: Alexey Shumkin, git
In-Reply-To: <CAH6sp9Ox+6p4RkjCZ0j3tXG9F4u7SPuwbSrOWmLSXic9DxSKiQ@mail.gmail.com>
On Mon, Nov 07, 2011 at 02:43:41PM +0100, Frans Klaver 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?
Yes, but it can't, because it is not the config command, but the git
wrapper that respects "pager.config". We have similar issues with
setting "pager.tag" (you want it for listing, but not for tag creation)
and others.
I should probably polish and submit the patch here:
http://thread.gmane.org/gmane.comp.version-control.git/182238/focus=182475
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Jeff King @ 2011-11-07 16:38 UTC (permalink / raw)
To: Andreas Schwab
Cc: Ævar Arnfjörð Bjarmason, git, Junio C Hamano,
Jim Meyering, Fredrik Gustafsson
In-Reply-To: <m3pqh4krer.fsf@hase.home>
On Mon, Nov 07, 2011 at 02:12:28PM +0100, Andreas Schwab wrote:
> Æ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.
Yes, but now you are getting into implementation-defined behavior, which
is also something to avoid. IOW, I don't think it's wrong for a static
analyzer to complain about:
if (enum_with_only_positive_values < 0)
just because you could say:
enum_with_only_positive_values = -1;
and it would work on _some_ platforms. That same static analyzer should
be complaining about the second line, which is where the real potential
bug is. If you want "-1" as an enumerated value, then add it to your
enum definition and the compiler will do the right thing.
It is perfectly fine to do:
enum foo { a = -1, b, c };
...
if (foo < 0)
...
and the static analyzer should not complain about the conditional there.
-Peff
^ permalink raw reply
* Re: reset reports file as modified when it's in fact deleted
From: Jeff King @ 2011-11-07 16:26 UTC (permalink / raw)
To: Carlos Martín Nieto, git
In-Reply-To: <20111107094330.GB10936@beez.lab.cmartin.tk>
On Mon, Nov 07, 2011 at 10:43:30AM +0100, Carlos Martín Nieto wrote:
> 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
You can simplify this even further by not touching the index at all:
git init -q &&
>file && git add file && git commit -q -m initial &&
rm file &&
git reset
produces:
Unstaged changes after reset:
M file
> 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.
The index diff code isn't running at all. Those messages are produced by
refresh_index, which outputs only two flags: modified or unmerged. I
think the reason for this is somewhat historical. You would run
"update-index --refresh", and it would helpfully say "by the way, when
refreshing this entry, I noticed that it is in need of being updated in
the index". The text was "file.txt: needs update".
Later, many porcelain commands started to refresh the index themselves,
and the "needs update" message was very confusing. So it was switched to
the more familiar "M file.txt" (though you can still see the original
plumbing message if you run update-index yourself).
I think it is a little more friendly to distinguish deletion from just
modification. And there's shouldn't be any compatibility questions, as
these are explicitly porcelain output (plumbing will still say "needs
update").
There are a few other cases users might expect to see. We'll never show
copies or renames, of course, because we aren't actually doing a diff
with copy detection. We won't see an "A"dded file, because such a file
would be in the working tree but not the index, meaning it is not
tracked.
We could see a "T"ypechange, but the distinction between that and a
modified file is lost by the time we get to refresh_index. We could pass
it up, but I wonder if it's really worth it.
The patch to do "D"eleted is pretty simple:
diff --git a/read-cache.c b/read-cache.c
index dea7cd8..cc1ebdf 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1103,9 +1103,11 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
const char *needs_update_fmt;
+ const char *needs_rm_fmt;
const char *needs_merge_fmt;
needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
+ needs_rm_fmt = (in_porcelain ? "D\t%s\n" : "%s: needs update\n");
needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce, *new;
@@ -1145,7 +1147,10 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
}
if (quiet)
continue;
- show_file(needs_update_fmt, ce->name, in_porcelain, &first, header_msg);
+ if (cache_errno == ENOENT)
+ show_file(needs_rm_fmt, ce->name, in_porcelain, &first, header_msg);
+ else
+ show_file(needs_update_fmt, ce->name, in_porcelain, &first, header_msg);
has_errors = 1;
continue;
}
^ 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
* [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
* [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
* 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
* 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
* 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
* 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
* 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
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