* [PATCH] git-submodule add: Record branch name in .gitmodules
From: W. Trevor King @ 2012-10-22 16:34 UTC (permalink / raw)
To: Git; +Cc: W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This removes a configuration step if you're trying to setup Ævar's
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
workflow from
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
If you're not using that workflow, I see no harm in recording the
branch used to determine the original submodule commit.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 3 ++-
git-submodule.sh | 4 ++++
t/t7400-submodule-basic.sh | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..b9f437f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -207,7 +207,8 @@ OPTIONS
-b::
--branch::
- Branch of repository to add as submodule.
+ Branch of repository to add as submodule. The branch name is
+ recorded in .gitmodules for future reference.
-f::
--force::
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..fd15a54 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -366,6 +366,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..5031e2a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test "$(git config -f .gitmodules submodule.submod-branch.branch)" = initial &&
git submodule init
) &&
--
1.8.0.2.g09b91ca
^ permalink raw reply related
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 19:35 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <CAMP44s27oPMu8Goded-Tcw9_fmgRux3yiNvu0FBPUxHOdp1Zgw@mail.gmail.com>
On Mon, Oct 22, 2012 at 7:12 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Oct 22, 2012 at 4:31 PM, Felipe Contreras
> I've tried everything, and yet a SIGPIPE is detected only with
> remote-testgit, not with my code, and they both exit the same way, and
> at the same time, and fast-export exits the main function (apparently
> a process can finish with SIGPIPE after main?)
>
> I have no idea what's going on, so I don't know if we need any extra
> code in transport-helper at all.
>
> Any ideas?
Must be a timing issue:
sh -c 'echo hello' | sh -c 'exit 1' -> no signal
sh -c 'echo hello' | /usr/bin/false -> SIGPIPE
I can trigger it by adding an extra delay:
This works:
test_expect_success 'proper failure checks for pushing 1' '
export GIT_REMOTE_TESTGIT_FAILURE=1 &&
(cd localclone && ! git push --all) 2> errors &&
grep -q "Error while running fast-export" errors
'
This doesn't:
test_expect_success 'proper failure checks for pushing 2' '
export GIT_REMOTE_TESTGIT_FAILURE=1 &&
export GIT_REMOTE_TESTGIT_SLEEPY=1 &&
(cd localclone && ! git push --all) 2> errors &&
grep -q "Error while running fast-export" errors
'
This does:
test_expect_success 'proper failure checks for pushing 3' '
export GIT_REMOTE_TESTGIT_FAILURE=1 &&
export GIT_REMOTE_TESTGIT_SLEEPY=1 &&
(cd localclone && ! git push --all) 2> errors &&
grep -q "Told to fail" errors
'
So, depending on your luck, transport-helper might or might display an
error, it will exit at the right place nonetheless, because of:
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
exit(128);
}
Not ideal, but I guess it's not a big deal.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v3 6/8] longest_ancestor_length(): require prefix list entries to be normalized
From: Johannes Sixt @ 2012-10-22 20:04 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, Jiang Xin, Lea Wiemann, David Reiss, git
In-Reply-To: <1350799057-13846-7-git-send-email-mhagger@alum.mit.edu>
Am 21.10.2012 07:57, schrieb Michael Haggerty:
> Move the responsibility for normalizing the prefixes passed to
> longest_ancestor_length() to its caller. In t0060, only test
> longest_ancestor_lengths using normalized paths: remove empty entries
> and non-absolute paths, strip trailing slashes from the paths, and
> remove tests that thereby become redundant.
t0060 does not pass on Windows with this change. Bash's path mangling
strikes again, but the real reason for the failure is that
test-path-util does not normalize its input before it calls into
longest_ancestor_length(). It is not sufficient to reduce the test cases
to normalized ones, because due to path mangling on Windows they are
turned into unnormalized paths (with backslashes instead of forward
slashes).
I suggest to export the new normalize_ceiling_entry() and use it from
test-path-util. Then don't change or remove existing tests.
-- Hannes
^ permalink raw reply
* [PATCH] remote-testgit: properly check for errors
From: Felipe Contreras @ 2012-10-22 20:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce,
Felipe Contreras
'feature done' was missing, which allowed fast-import exit properly, and
transport-helper to continue checking for refs and what not when in fact
the remote-helper died.
Let's enable that, and make sure the error paths are triggered.
Now transport-helper correctly detects the errors from fast-import,
unfortunately, not from fast-export because it might finish before
detecting a SIGPIPE. This means transport-helper will quit silently and
the user will not see any errors, which is bad. Hopefully the helper
will print the error before dying anyway, so not all is lost.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-remote-testgit.py | 8 ++++++++
t/t5800-remote-helpers.sh | 21 +++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..b8707e6 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -159,6 +159,11 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
+ print "feature done"
+
+ if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
@@ -172,6 +177,9 @@ def do_export(repo, args):
if not repo.gitdir:
die("Need gitdir to export")
+ if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
update_local_repo(repo)
changed = repo.importer.do_import(repo.gitdir)
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index e7dc668..446cc8e 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -145,4 +145,25 @@ test_expect_failure 'push new branch with old:new refspec' '
compare_refs clone HEAD server refs/heads/new-refspec
'
+test_expect_success 'proper failure checks for fetching' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ export GIT_REMOTE_TESTGIT_FAILURE &&
+ cd localclone &&
+ test_must_fail git fetch 2>&1 | \
+ grep "Error while running fast-import"
+ )
+'
+
+# We sleep to give fast-export a chance to catch the SIGPIPE
+test_expect_failure 'proper failure checks for pushing' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ export GIT_REMOTE_TESTGIT_FAILURE &&
+ GIT_REMOTE_TESTGIT_SLEEPY=1 &&
+ export GIT_REMOTE_TESTGIT_SLEEPY &&
+ cd localclone &&
+ test_must_fail git push --all 2>&1 | \
+ grep "Error while running fast-export"
+ )
+'
+
test_done
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] remote-testgit: properly check for errors
From: Sverre Rabbelier @ 2012-10-22 21:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King, Shawn O. Pearce
In-Reply-To: <1350939394-21622-1-git-send-email-felipe.contreras@gmail.com>
On Mon, Oct 22, 2012 at 1:56 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> index 5f3ebd2..b8707e6 100644
> --- a/git-remote-testgit.py
> +++ b/git-remote-testgit.py
> @@ -159,6 +159,11 @@ def do_import(repo, args):
> ref = line[7:].strip()
> refs.append(ref)
>
> + print "feature done"
There's not enough context for me to see in which part of the code
this is, import or export? If you advertise 'feature done', shouldn't
you also print 'done' when you finish writing the fast-export stream?
If that's already the case feel free to ignore me :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: The config include mechanism doesn't allow for overwriting
From: Jeff King @ 2012-10-22 21:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4cu9XuS5AtduWrNeXNUeZ4rqDUzRdmyz2b3cXtmo1nqQ@mail.gmail.com>
On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I was hoping to write something like this:
>
> [user]
> name = Luser
> email = some-default@example.com
> [include]
> path = ~/.gitconfig.d/user-email
>
> Where that file would contain:
>
> [user]
> email = local-email@example.com
The intent is that it would work as you expect, and produce
local-email@example.com.
> But when you do that git prints:
>
> $ git config --get user.email
> some-default@example.com
> error: More than one value for the key user.email: local-email@example.com
Ugh. The config code just feeds all the values sequentially to the
callback. The normal callbacks within git will overwrite old values,
whether from earlier in the file, from a file with lower priority (e.g.,
/etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
you can check with:
$ git var GIT_AUTHOR_IDENT
Luser <local-email@example.com> 1350936694 -0400
But git-config takes it upon itself to detect duplicates in its
callback. Which is just silly, since it is not something that regular
git would do. git-config should behave as much like the internal git
parser as possible.
> I think config inclusion is much less useful when you can't clobber
> previously assigned values.
Agreed. But I think the bug is in git-config, not in the include
mechanism. I think I'd like to do something like the patch below, which
just reuses the regular config code for git-config, collects the values,
and then reports them. It does mean we use a little more memory (for the
sake of simplicity, we store values instead of streaming them out), but
the code is much shorter, less confusing, and automatically matches what
regular git_config() does.
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
---
builtin/config.c | 111 ++++++++++++-----------------------
1 file changed, 38 insertions(+), 73 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d6a066b..72cb0a8 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -16,7 +16,6 @@ static int do_not_match;
static int use_key_regexp;
static int do_all;
static int do_not_match;
-static int seen;
static char delim = '=';
static char key_delim = ' ';
static char term = '\n';
@@ -110,12 +109,19 @@ static int show_config(const char *key_, const char *value_, void *cb)
return 0;
}
-static int show_config(const char *key_, const char *value_, void *cb)
+struct strbuf_list {
+ struct strbuf *items;
+ int nr;
+ int alloc;
+};
+
+static int collect_config(const char *key_, const char *value_, void *cb)
{
+ struct strbuf_list *values = cb;
+ struct strbuf *buf;
char value[256];
const char *vptr = value;
int must_free_vptr = 0;
- int dup_error = 0;
int must_print_delim = 0;
if (!use_key_regexp && strcmp(key_, key))
@@ -126,12 +132,15 @@ static int show_config(const char *key_, const char *value_, void *cb)
(do_not_match ^ !!regexec(regexp, (value_?value_:""), 0, NULL, 0)))
return 0;
+ ALLOC_GROW(values->items, values->nr + 1, values->alloc);
+ buf = &values->items[values->nr++];
+ strbuf_init(buf, 0);
+
if (show_keys) {
- printf("%s", key_);
+ strbuf_addstr(buf, key_);
must_print_delim = 1;
}
- if (seen && !do_all)
- dup_error = 1;
+
if (types == TYPE_INT)
sprintf(value, "%d", git_config_int(key_, value_?value_:""));
else if (types == TYPE_BOOL)
@@ -153,16 +162,12 @@ static int show_config(const char *key_, const char *value_, void *cb)
vptr = "";
must_print_delim = 0;
}
- seen++;
- if (dup_error) {
- error("More than one value for the key %s: %s",
- key_, vptr);
- }
- else {
- if (must_print_delim)
- printf("%c", key_delim);
- printf("%s%c", vptr, term);
- }
+
+ if (must_print_delim)
+ strbuf_addch(buf, key_delim);
+ strbuf_addstr(buf, vptr);
+ strbuf_addch(buf, term);
+
if (must_free_vptr)
/* If vptr must be freed, it's a pointer to a
* dynamically allocated buffer, it's safe to cast to
@@ -175,20 +180,8 @@ static int get_value(const char *key_, const char *regex_)
static int get_value(const char *key_, const char *regex_)
{
- int ret = CONFIG_GENERIC_ERROR;
- char *global = NULL, *xdg = NULL, *repo_config = NULL;
- const char *system_wide = NULL, *local;
- struct config_include_data inc = CONFIG_INCLUDE_INIT;
- config_fn_t fn;
- void *data;
-
- local = given_config_file;
- if (!local) {
- local = repo_config = git_pathdup("config");
- if (git_config_system())
- system_wide = git_etc_gitconfig();
- home_config_paths(&global, &xdg, "config");
- }
+ struct strbuf_list values = {0};
+ int i;
if (use_key_regexp) {
char *tl;
@@ -211,14 +204,11 @@ static int get_value(const char *key_, const char *regex_)
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, "Invalid key pattern: %s\n", key_);
free(key);
- ret = CONFIG_INVALID_PATTERN;
- goto free_strings;
+ return CONFIG_INVALID_PATTERN;
}
} else {
- if (git_config_parse_key(key_, &key, NULL)) {
- ret = CONFIG_INVALID_KEY;
- goto free_strings;
- }
+ if (git_config_parse_key(key_, &key, NULL))
+ return CONFIG_INVALID_KEY;
}
if (regex_) {
@@ -230,37 +220,12 @@ static int get_value(const char *key_, const char *regex_)
regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, "Invalid pattern: %s\n", regex_);
- ret = CONFIG_INVALID_PATTERN;
- goto free_strings;
+ return CONFIG_INVALID_PATTERN;
}
}
- fn = show_config;
- data = NULL;
- if (respect_includes) {
- inc.fn = fn;
- inc.data = data;
- fn = git_config_include;
- data = &inc;
- }
-
- if (do_all && system_wide)
- git_config_from_file(fn, system_wide, data);
- if (do_all && xdg)
- git_config_from_file(fn, xdg, data);
- if (do_all && global)
- git_config_from_file(fn, global, data);
- if (do_all)
- git_config_from_file(fn, local, data);
- git_config_from_parameters(fn, data);
- if (!do_all && !seen)
- git_config_from_file(fn, local, data);
- if (!do_all && !seen && global)
- git_config_from_file(fn, global, data);
- if (!do_all && !seen && xdg)
- git_config_from_file(fn, xdg, data);
- if (!do_all && !seen && system_wide)
- git_config_from_file(fn, system_wide, data);
+ git_config_with_options(collect_config, &values,
+ given_config_file, respect_includes);
free(key);
if (regexp) {
@@ -268,16 +233,16 @@ static int get_value(const char *key_, const char *regex_)
free(regexp);
}
- if (do_all)
- ret = !seen;
- else
- ret = (seen == 1) ? 0 : seen > 1 ? 2 : 1;
+ if (!values.nr)
+ return 1;
-free_strings:
- free(repo_config);
- free(global);
- free(xdg);
- return ret;
+ for (i = 0; i < values.nr; i++) {
+ struct strbuf *buf = values.items + i;
+ if (do_all || i == values.nr - 1)
+ fwrite(buf->buf, 1, buf->len, stdout);
+ strbuf_release(buf);
+ }
+ return 0;
}
static char *normalize_value(const char *key, const char *value)
^ permalink raw reply related
* tag storage format
From: Uri Moszkowicz @ 2012-10-22 22:23 UTC (permalink / raw)
To: git
I'm doing some testing on a large Git repository and am finding local
clones to take a very long time. After some investigation I've
determined that the problem is due to a very large number of tags
(~38k). Even with hard links, it just takes a really long time to
visit that many inodes. As it happens, I don't care for most of these
tags and will prune many of them anyway but I expect that over time it
will creep back up again. Have others reported this problem before and
is there a workaround? Perhaps Git should switch to a single-file
block text or binary format once a large number of tags becomes
present in a repository.
^ permalink raw reply
* Re: tag storage format
From: Andreas Schwab @ 2012-10-22 22:46 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5ATiAx09eAEo1=6+=hPv=5c6qtOiLRG5jrQn5dfCKUrvMQ@mail.gmail.com>
Uri Moszkowicz <uri@4refs.com> writes:
> Perhaps Git should switch to a single-file block text or binary format
> once a large number of tags becomes present in a repository.
This is what git pack-refs (called by git gc) does (by putting the refs
in .git/packed-refs).
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
* [PATCH 1/2] git-pull: Avoid merge-base on detached head
From: Phil Hord @ 2012-10-22 22:50 UTC (permalink / raw)
To: git
Cc: gitster, phil.hord, santi, Elijah Newren, Johannes Schindelin,
Phil Hord
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
"usage" help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few parameters.
Since we do not need the merge-base trick in the case of a
detached HEAD, detect this condition and bypass the clever
trick and the usage noise.
---
git-pull.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..266e682 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -200,6 +200,7 @@ test true = "$rebase" && {
require_clean_work_tree "pull with rebase" "Please commit or stash them."
fi
oldremoteref= &&
+ test -n "$curr_branch" &&
. git-parse-remote &&
remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
--
1.8.0.2.ge1a3bdd
^ permalink raw reply related
* Re: Migrating from StarTeam to GIT
From: victorcruz @ 2012-10-22 23:24 UTC (permalink / raw)
To: git
In-Reply-To: <89b129c60902190919p2cdbe349o4a2a659617dae341@mail.gmail.com>
victor cruz alonso
vitycruz@gmail.com
The following is a small web application that converts projects of StarTeam
to GIT repository.
http://dl.dropbox.com/u/101447754/startgit.tar.gz
I developed because in my work decided to migrate and give the possibility
that any group without previous research work to make such a process.
Now:
StartGIT es una sencilla herramienta para trabajar con Controladores de
Versiones, su fin es poder convertir un repositorio en Starteam a GIT, para
ello se hace uso del script "svnimporter-1.2-st" obtenido en
"http://www.polarion.com/user/direct_register.php?dl=svnimporterst":
Tener instalado:
- GIT
- git-svn
- java
- apache2
Pasos:
- Descomprimir "startgit.zip"
- Colocar la carpeta descomprimida "startgit" en el directorio "/var/www/"
- Abrir navegador web y colocar la siguiente direccción
"http://localhost/startgit"
//-------------------------------------------------------------
StartGIT is a simple tool, its purpose is to convert a Starteam repository
to GIT.
This script uses the "svnimporter-1.2-st" obtained "http://www.polarion.com
/ user / direct_register.php? dl = svnimporterst "
Have installed:
- GIT
- Git-svn
- java
- apache2
steps:
- Unzip "startgit.zip"
- Place the unzipped folder "startgit" in the "/ var / www /"
- Open web browser and "http://localhost/startgit"
--
View this message in context: http://git.661346.n2.nabble.com/Migrating-from-StarTeam-to-GIT-tp2354198p7569734.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] git-status: show short sequencer state
From: Phil Hord @ 2012-10-22 23:29 UTC (permalink / raw)
To: hordp
Cc: phil.hord, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien, git,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is also useful in short form to
humans and scripts, but no option is available to boil it down.
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as "conflicted" or "resolved".
Move the am_empty_patch flage out of wt_status_state and into
this new substate.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
cherry-pick a git-cherry-pick is in progress
bisect a git-bisect is in progress
conflicted there are unresolved conflicts
resolved conflicts have been resolved
editing interactive rebase stopped to edit a commit
edited interactive rebase edit has been edited
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
clean
index
modified
untracked
---
Documentation/git-status.txt | 18 ++++++
builtin/commit.c | 12 +++-
wt-status.c | 128 +++++++++++++++++++++++++++++++++++--------
wt-status.h | 13 ++++-
4 files changed, 146 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..200a8e2 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,24 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more tokens
+ describing the state of several git sequence operations. Each
+ token is separated by a newline.
++
+ merge a git-merge is in progress
+ am a git-am is in progress
+ rebase a git-rebase is in progress
+ rebase-interactive a git-rebase--interactive is in progress
+ cherry-pick a git-cherry-pick is in progress
+ bisect a git-bisect is in progress
+ conflicted there are unresolved conflicts
+ resolved conflicts have been resolved
+ editing interactive rebase stopped to edit a commit
+ edited interactive rebase edit has been edited
+ splitting interactive rebase, commit is being split
+
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
@@ -454,6 +455,9 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1156,6 +1160,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
N_("show status concisely"), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', "branch", &s.show_branch,
N_("show branch information")),
+ OPT_SET_INT('S', "sequence", &status_format,
+ N_("show sequencer state"),
+ STATUS_FORMAT_SEQUENCER),
OPT_SET_INT(0, "porcelain", &status_format,
N_("machine-readable output"),
STATUS_FORMAT_PORCELAIN),
@@ -1216,6 +1223,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(&s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(&s);
+ break;
case STATUS_FORMAT_LONG:
s.verbose = verbose;
s.ignore_submodule_arg = ignore_submodule_arg;
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..996b454 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -781,7 +781,7 @@ static void show_merge_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- if (has_unmerged(s)) {
+ if (state->substate == WT_SUBSTATE_CONFLICTED) {
status_printf_ln(s, color, _("You have unmerged paths."));
if (advice_status_hints)
status_printf_ln(s, color,
@@ -802,11 +802,11 @@ static void show_am_in_progress(struct wt_status *s,
{
status_printf_ln(s, color,
_("You are in the middle of an am session."));
- if (state->am_empty_patch)
+ if (state->substate==WT_SUBSTATE_NOMINAL)
status_printf_ln(s, color,
_("The current patch is empty."));
if (advice_status_hints) {
- if (!state->am_empty_patch)
+ if (state->substate==WT_SUBSTATE_CONFLICTED)
status_printf_ln(s, color,
_(" (fix conflicts and then run \"git am --resolved\")"));
status_printf_ln(s, color,
@@ -867,9 +867,7 @@ static void show_rebase_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- struct stat st;
-
- if (has_unmerged(s)) {
+ if (state->substate == WT_SUBSTATE_CONFLICTED) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints) {
status_printf_ln(s, color,
@@ -879,19 +877,19 @@ static void show_rebase_in_progress(struct wt_status *s,
status_printf_ln(s, color,
_(" (use \"git rebase --abort\" to check out the original branch)"));
}
- } else if (state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
+ } else if (state->substate == WT_SUBSTATE_RESOLVED) {
status_printf_ln(s, color, _("You are currently rebasing."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (all conflicts fixed: run \"git rebase --continue\")"));
- } else if (split_commit_in_progress(s)) {
+ } else if (state->substate == WT_SUBSTATE_SPLITTING) {
status_printf_ln(s, color, _("You are currently splitting a commit during a rebase."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (Once your working directory is clean, run \"git rebase --continue\")"));
} else {
status_printf_ln(s, color, _("You are currently editing a commit during a rebase."));
- if (advice_status_hints && !s->amend) {
+ if (advice_status_hints && state->substate == WT_SUBSTATE_EDITING) {
status_printf_ln(s, color,
_(" (use \"git commit --amend\" to amend the current commit)"));
status_printf_ln(s, color,
@@ -907,7 +905,7 @@ static void show_cherry_pick_in_progress(struct wt_status *s,
{
status_printf_ln(s, color, _("You are currently cherry-picking."));
if (advice_status_hints) {
- if (has_unmerged(s))
+ if (state->substate == WT_SUBSTATE_CONFLICTED)
status_printf_ln(s, color,
_(" (fix conflicts and run \"git commit\")"));
else
@@ -928,34 +926,66 @@ static void show_bisect_in_progress(struct wt_status *s,
wt_status_print_trailer(s);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_get_state(struct wt_status *s , struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
struct stat st;
- memset(&state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
+ // Determine main sequencer activity
if (!stat(git_path("MERGE_HEAD"), &st)) {
- state.merge_in_progress = 1;
+ state->merge_in_progress = 1;
} else if (!stat(git_path("rebase-apply"), &st)) {
if (!stat(git_path("rebase-apply/applying"), &st)) {
- state.am_in_progress = 1;
- if (!stat(git_path("rebase-apply/patch"), &st) && !st.st_size)
- state.am_empty_patch = 1;
+ state->am_in_progress = 1;
+ if (stat(git_path("rebase-apply/patch"), &st) || st.st_size)
+ state->substate = WT_SUBSTATE_CONFLICTED;
} else {
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
- state.rebase_interactive_in_progress = 1;
+ state->rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
+ state->rebase_in_progress = 1;
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
- state.cherry_pick_in_progress = 1;
+ state->cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st))
- state.bisect_in_progress = 1;
+ state->bisect_in_progress = 1;
+
+ // Check for unmerged files
+ if (state->rebase_in_progress || state->rebase_interactive_in_progress ||
+ state->cherry_pick_in_progress || state->merge_in_progress) {
+ if (has_unmerged(s)) {
+ state->substate = WT_SUBSTATE_CONFLICTED;
+ } else {
+ state->substate = WT_SUBSTATE_RESOLVED;
+ }
+ }
+
+ // Interactive Rebase is more nuanced
+ if (state->rebase_interactive_in_progress && state->substate != WT_SUBSTATE_CONFLICTED) {
+ if (!stat(git_path("MERGE_MSG"), &st)) {
+ state->substate = WT_SUBSTATE_RESOLVED;
+ } else if (split_commit_in_progress(s)) {
+ state->substate = WT_SUBSTATE_SPLITTING;
+ } else {
+ if (s->amend) {
+ state->substate = WT_SUBSTATE_EDITED;
+ } else {
+ state->substate = WT_SUBSTATE_EDITING;
+ }
+ }
+ }
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(s, &state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -1192,6 +1222,53 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
fputc(s->null_termination ? '\0' : '\n', s->fp);
}
+static void wt_print_token(struct wt_status *s, const char *color, const char *token)
+{
+ color_fprintf(s->fp, color, "%s", token);
+ fputc(s->null_termination ? '\0' : '\n', s->fp);
+}
+
+static void wt_shortstatus_print_sequencer(struct wt_status *s)
+{
+ struct wt_status_state state;
+ const char *state_color = color(WT_STATUS_HEADER, s);
+
+ wt_status_get_state(s, &state);
+
+ if (state.merge_in_progress)
+ wt_print_token(s, state_color, "merge");
+ if (state.am_in_progress)
+ wt_print_token(s, state_color, "am");
+ if (state.rebase_in_progress)
+ wt_print_token(s, state_color, "rebase");
+ if (state.rebase_interactive_in_progress)
+ wt_print_token(s, state_color, "rebase-interactive");
+ if (state.cherry_pick_in_progress)
+ wt_print_token(s, state_color, "cherry-pick");
+ if (state.bisect_in_progress)
+ wt_print_token(s, state_color, "bisect");
+
+ switch (state.substate) {
+ case WT_SUBSTATE_NOMINAL:
+ break;
+ case WT_SUBSTATE_CONFLICTED:
+ wt_print_token(s, state_color, "conflicted");
+ break;
+ case WT_SUBSTATE_RESOLVED:
+ wt_print_token(s, state_color, "resolved");
+ break;
+ case WT_SUBSTATE_EDITED:
+ wt_print_token(s, state_color, "edited");
+ break;
+ case WT_SUBSTATE_EDITING:
+ wt_print_token(s, state_color, "editing");
+ break;
+ case WT_SUBSTATE_SPLITTING:
+ wt_print_token(s, state_color, "splitting");
+ break;
+ }
+}
+
void wt_shortstatus_print(struct wt_status *s)
{
int i;
@@ -1224,6 +1301,11 @@ void wt_shortstatus_print(struct wt_status *s)
}
}
+void wt_sequencer_print(struct wt_status *s)
+{
+ wt_shortstatus_print_sequencer(s);
+}
+
void wt_porcelain_print(struct wt_status *s)
{
s->use_color = 0;
diff --git a/wt-status.h b/wt-status.h
index 236b41f..3de4b26 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -59,6 +59,7 @@ struct wt_status {
unsigned colopts;
int null_termination;
int show_branch;
+ int show_sequencer;
/* These are computed during processing of the individual sections */
int commitable;
@@ -71,14 +72,23 @@ struct wt_status {
struct string_list ignored;
};
+enum wt_status_substate {
+ WT_SUBSTATE_NOMINAL = 0,
+ WT_SUBSTATE_CONFLICTED,
+ WT_SUBSTATE_RESOLVED,
+ WT_SUBSTATE_SPLITTING,
+ WT_SUBSTATE_EDITING,
+ WT_SUBSTATE_EDITED,
+};
+
struct wt_status_state {
int merge_in_progress;
int am_in_progress;
- int am_empty_patch;
int rebase_in_progress;
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ enum wt_status_substate substate;
};
void wt_status_prepare(struct wt_status *s);
@@ -86,6 +96,7 @@ void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
void wt_shortstatus_print(struct wt_status *s);
+void wt_sequencer_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
void status_printf_ln(struct wt_status *s, const char *color, const char *fmt, ...)
--
1.8.0.2.ge1a3bdd
^ permalink raw reply related
* Re: [PATCH] remote-testgit: properly check for errors
From: Felipe Contreras @ 2012-10-23 0:57 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Junio C Hamano, Jeff King, Shawn O. Pearce
In-Reply-To: <CAGdFq_gOb3GX1iZshGZahZEbj3RqQSEk8AN_hHXKyD5aHwfxYA@mail.gmail.com>
On Mon, Oct 22, 2012 at 11:01 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Mon, Oct 22, 2012 at 1:56 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
>> index 5f3ebd2..b8707e6 100644
>> --- a/git-remote-testgit.py
>> +++ b/git-remote-testgit.py
>> @@ -159,6 +159,11 @@ def do_import(repo, args):
>> ref = line[7:].strip()
>> refs.append(ref)
>>
>> + print "feature done"
>
> There's not enough context for me to see in which part of the code
> this is, import or export?
Isn't this enough?
>> @@ -159,6 +159,11 @@ def do_import(repo, args):
It's import.
> If you advertise 'feature done', shouldn't
> you also print 'done' when you finish writing the fast-export stream?
> If that's already the case feel free to ignore me :)
It's already there:
http://git.kernel.org/?p=git/git.git;a=blob;f=git-remote-testgit.py#l165
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
From: Nguyễn Thái Ngọc Duy @ 2012-10-23 2:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
These functions are called in sequencer.c, which is part of
libgit.a. This makes libgit.a potentially require builtin/merge.c for
external git commands.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I made some unrelated changes in sequencer.c and this problem shown
up. merge-recursive.c is probably not the best place for these
functions. I just don't want to create merge.c for them.
builtin/merge.c | 106 +----------------------------------------------------
cache.h | 3 --
merge-recursive.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
merge-recursive.h | 4 ++
sequencer.c | 2 +-
5 files changed, 115 insertions(+), 108 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 0ec8f0d..a96e8ea 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -628,59 +628,6 @@ static void write_tree_trivial(unsigned char *sha1)
die(_("git write-tree failed to write a tree"));
}
-static const char *merge_argument(struct commit *commit)
-{
- if (commit)
- return sha1_to_hex(commit->object.sha1);
- else
- return EMPTY_TREE_SHA1_HEX;
-}
-
-int try_merge_command(const char *strategy, size_t xopts_nr,
- const char **xopts, struct commit_list *common,
- const char *head_arg, struct commit_list *remotes)
-{
- const char **args;
- int i = 0, x = 0, ret;
- struct commit_list *j;
- struct strbuf buf = STRBUF_INIT;
-
- args = xmalloc((4 + xopts_nr + commit_list_count(common) +
- commit_list_count(remotes)) * sizeof(char *));
- strbuf_addf(&buf, "merge-%s", strategy);
- args[i++] = buf.buf;
- for (x = 0; x < xopts_nr; x++) {
- char *s = xmalloc(strlen(xopts[x])+2+1);
- strcpy(s, "--");
- strcpy(s+2, xopts[x]);
- args[i++] = s;
- }
- for (j = common; j; j = j->next)
- args[i++] = xstrdup(merge_argument(j->item));
- args[i++] = "--";
- args[i++] = head_arg;
- for (j = remotes; j; j = j->next)
- args[i++] = xstrdup(merge_argument(j->item));
- args[i] = NULL;
- ret = run_command_v_opt(args, RUN_GIT_CMD);
- strbuf_release(&buf);
- i = 1;
- for (x = 0; x < xopts_nr; x++)
- free((void *)args[i++]);
- for (j = common; j; j = j->next)
- free((void *)args[i++]);
- i += 2;
- for (j = remotes; j; j = j->next)
- free((void *)args[i++]);
- free(args);
- discard_cache();
- if (read_cache() < 0)
- die(_("failed to read the cache"));
- resolve_undo_clear();
-
- return ret;
-}
-
static int try_merge_strategy(const char *strategy, struct commit_list *common,
struct commit_list *remoteheads,
struct commit *head, const char *head_arg)
@@ -762,56 +709,6 @@ static int count_unmerged_entries(void)
return ret;
}
-int checkout_fast_forward(const unsigned char *head, const unsigned char *remote)
-{
- struct tree *trees[MAX_UNPACK_TREES];
- struct unpack_trees_options opts;
- struct tree_desc t[MAX_UNPACK_TREES];
- int i, fd, nr_trees = 0;
- struct dir_struct dir;
- struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
-
- refresh_cache(REFRESH_QUIET);
-
- fd = hold_locked_index(lock_file, 1);
-
- memset(&trees, 0, sizeof(trees));
- memset(&opts, 0, sizeof(opts));
- memset(&t, 0, sizeof(t));
- if (overwrite_ignore) {
- memset(&dir, 0, sizeof(dir));
- dir.flags |= DIR_SHOW_IGNORED;
- setup_standard_excludes(&dir);
- opts.dir = &dir;
- }
-
- opts.head_idx = 1;
- opts.src_index = &the_index;
- opts.dst_index = &the_index;
- opts.update = 1;
- opts.verbose_update = 1;
- opts.merge = 1;
- opts.fn = twoway_merge;
- setup_unpack_trees_porcelain(&opts, "merge");
-
- trees[nr_trees] = parse_tree_indirect(head);
- if (!trees[nr_trees++])
- return -1;
- trees[nr_trees] = parse_tree_indirect(remote);
- if (!trees[nr_trees++])
- return -1;
- for (i = 0; i < nr_trees; i++) {
- parse_tree(trees[i]);
- init_tree_desc(t+i, trees[i]->buffer, trees[i]->size);
- }
- if (unpack_trees(nr_trees, t, &opts))
- return -1;
- if (write_cache(fd, active_cache, active_nr) ||
- commit_locked_index(lock_file))
- die(_("unable to write new index file"));
- return 0;
-}
-
static void split_merge_strategies(const char *string, struct strategy **list,
int *nr, int *alloc)
{
@@ -1424,7 +1321,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
if (checkout_fast_forward(head_commit->object.sha1,
- commit->object.sha1)) {
+ commit->object.sha1,
+ overwrite_ignore)) {
ret = 1;
goto done;
}
diff --git a/cache.h b/cache.h
index a58df84..415c777 100644
--- a/cache.h
+++ b/cache.h
@@ -1265,9 +1265,6 @@ struct startup_info {
};
extern struct startup_info *startup_info;
-/* builtin/merge.c */
-int checkout_fast_forward(const unsigned char *from, const unsigned char *to);
-
int sane_execvp(const char *file, char *const argv[]);
#endif /* CACHE_H */
diff --git a/merge-recursive.c b/merge-recursive.c
index d882060..4d2422a 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -21,6 +21,9 @@
#include "merge-recursive.h"
#include "dir.h"
#include "submodule.h"
+#include "run-command.h"
+#include "resolve-undo.h"
+#include "unpack-trees.h"
static struct tree *shift_tree_object(struct tree *one, struct tree *two,
const char *subtree_shift)
@@ -2087,3 +2090,108 @@ int parse_merge_opt(struct merge_options *o, const char *s)
return -1;
return 0;
}
+
+static const char *merge_argument(struct commit *commit)
+{
+ if (commit)
+ return sha1_to_hex(commit->object.sha1);
+ else
+ return EMPTY_TREE_SHA1_HEX;
+}
+
+int try_merge_command(const char *strategy, size_t xopts_nr,
+ const char **xopts, struct commit_list *common,
+ const char *head_arg, struct commit_list *remotes)
+{
+ const char **args;
+ int i = 0, x = 0, ret;
+ struct commit_list *j;
+ struct strbuf buf = STRBUF_INIT;
+
+ args = xmalloc((4 + xopts_nr + commit_list_count(common) +
+ commit_list_count(remotes)) * sizeof(char *));
+ strbuf_addf(&buf, "merge-%s", strategy);
+ args[i++] = buf.buf;
+ for (x = 0; x < xopts_nr; x++) {
+ char *s = xmalloc(strlen(xopts[x])+2+1);
+ strcpy(s, "--");
+ strcpy(s+2, xopts[x]);
+ args[i++] = s;
+ }
+ for (j = common; j; j = j->next)
+ args[i++] = xstrdup(merge_argument(j->item));
+ args[i++] = "--";
+ args[i++] = head_arg;
+ for (j = remotes; j; j = j->next)
+ args[i++] = xstrdup(merge_argument(j->item));
+ args[i] = NULL;
+ ret = run_command_v_opt(args, RUN_GIT_CMD);
+ strbuf_release(&buf);
+ i = 1;
+ for (x = 0; x < xopts_nr; x++)
+ free((void *)args[i++]);
+ for (j = common; j; j = j->next)
+ free((void *)args[i++]);
+ i += 2;
+ for (j = remotes; j; j = j->next)
+ free((void *)args[i++]);
+ free(args);
+ discard_cache();
+ if (read_cache() < 0)
+ die(_("failed to read the cache"));
+ resolve_undo_clear();
+
+ return ret;
+}
+
+int checkout_fast_forward(const unsigned char *head,
+ const unsigned char *remote,
+ int overwrite_ignore)
+{
+ struct tree *trees[MAX_UNPACK_TREES];
+ struct unpack_trees_options opts;
+ struct tree_desc t[MAX_UNPACK_TREES];
+ int i, fd, nr_trees = 0;
+ struct dir_struct dir;
+ struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
+
+ refresh_cache(REFRESH_QUIET);
+
+ fd = hold_locked_index(lock_file, 1);
+
+ memset(&trees, 0, sizeof(trees));
+ memset(&opts, 0, sizeof(opts));
+ memset(&t, 0, sizeof(t));
+ if (overwrite_ignore) {
+ memset(&dir, 0, sizeof(dir));
+ dir.flags |= DIR_SHOW_IGNORED;
+ setup_standard_excludes(&dir);
+ opts.dir = &dir;
+ }
+
+ opts.head_idx = 1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.update = 1;
+ opts.verbose_update = 1;
+ opts.merge = 1;
+ opts.fn = twoway_merge;
+ setup_unpack_trees_porcelain(&opts, "merge");
+
+ trees[nr_trees] = parse_tree_indirect(head);
+ if (!trees[nr_trees++])
+ return -1;
+ trees[nr_trees] = parse_tree_indirect(remote);
+ if (!trees[nr_trees++])
+ return -1;
+ for (i = 0; i < nr_trees; i++) {
+ parse_tree(trees[i]);
+ init_tree_desc(t+i, trees[i]->buffer, trees[i]->size);
+ }
+ if (unpack_trees(nr_trees, t, &opts))
+ return -1;
+ if (write_cache(fd, active_cache, active_nr) ||
+ commit_locked_index(lock_file))
+ die(_("unable to write new index file"));
+ return 0;
+}
diff --git a/merge-recursive.h b/merge-recursive.h
index 58f3435..e01a9c0 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -64,4 +64,8 @@ int try_merge_command(const char *strategy, size_t xopts_nr,
const char **xopts, struct commit_list *common,
const char *head_arg, struct commit_list *remotes);
+int checkout_fast_forward(const unsigned char *from,
+ const unsigned char *to,
+ int overwrite_ignore);
+
#endif
diff --git a/sequencer.c b/sequencer.c
index e3723d2..be0cb8b 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -191,7 +191,7 @@ static int fast_forward_to(const unsigned char *to, const unsigned char *from)
struct ref_lock *ref_lock;
read_cache();
- if (checkout_fast_forward(from, to))
+ if (checkout_fast_forward(from, to, 1))
exit(1); /* the callee should have complained already */
ref_lock = lock_any_ref_for_update("HEAD", from, 0);
return write_ref_sha1(ref_lock, to, "cherry-pick");
--
1.8.0.rc3.18.g0d9b108
^ permalink raw reply related
* Re: Links broken in ref docs.
From: Scott Chacon @ 2012-10-23 5:11 UTC (permalink / raw)
To: Mike Norman; +Cc: Andrew Ardill, git
In-Reply-To: <CAJr+XPETQ2Jifns3_dfoB-sLLru2=Jkofb5RrBxLE4Fa9Aqp7A@mail.gmail.com>
So, this is due to the major AWS outage today. git-scm.com is hosted
on Heroku and thus on AWS. Heroku is continuing to bring up their
database systems in the wake of the massive AWS outage. Once that is
back online, git-scm.com will also be back online.
As for the git-fetch issue, we'll look into it once Heroku is back online.
Scott
On Mon, Oct 22, 2012 at 7:34 PM, Mike Norman <mknorman@gmail.com> wrote:
> This seems worse. The entire site is now down with an application
> error. Reporting this out of surprise and just in case the dev on the
> job has the site cached somehow and can't see the error. Image
> (hopefully) attached and the message is as appears below, in case the
> attachment gets stripped. (Tags for convenience and not part of
> error.)
>
> <errortext>
> Application Error
>
> An error occurred in the application and your page could not be
> served. Please try again in a few moments.
>
> If you are the application owner, check your logs for details.
> </errortext>
>
> Hope this helps,
> Mike Norman
> On Sun, Oct 21, 2012 at 9:45 PM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>> On 21 October 2012 18:31, Mike Norman <mknorman@gmail.com> wrote:
>>> Many links on scm-git.org/docs simply reload the page.
>>>
>>> For example, all of Sharing and Updating section simply reload the
>>> docs page. And tons others. Must be a broken link or routing problem.
>>> Repros on FF 14.0.1 and Chrome. Good luck!
>>>
>>
>> Including Scott Chacon as he manages this site (to my knowledge).
>>
>> Looking at the request, I am getting a 302:
>>
>> Request URL:http://git-scm.com/docs/git-fetch
>> Request Method:GET
>> Status Code:302 Moved Temporarily
>>
>> Maybe those pages are not done yet? That doesn't seem right as this is
>> simply the reference manual, but perhaps there is something else going
>> on here.
>>
>> On another (related) note, the wayback machine has some very
>> interesting entries for the scm-git.org domain [1] and it seems the
>> /doc directory is not indexed at all. Is this on purpose?
>>
>> Regards,
>>
>> Andrew Ardill
>>
>> [1] http://wayback.archive.org/web/*/http://git-scm.com/*
^ permalink raw reply
* [BUG] (git commit --patch --message $MESSAGE) disallows hunk editing
From: Max Nanasy @ 2012-10-23 5:48 UTC (permalink / raw)
To: git
Tested against v1.7.12.4
Steps to reproduce:
A. cd $DIRTY_WORKING_COPY
B. git commit --patch --message $MESSAGE
C. Stage this hunk? e
Expected behavior:
After step C, the hunk opens in the user's editor
Actual behavior:
After step C, the hunk is selected unedited (as if the user had entered "y")
AFAICT, this occurs because of the following code in
builtin/commit.c:parse_and_validate_options:
if (... || message.len || ...)
use_editor = 0;
...
if (!use_editor)
setenv("GIT_EDITOR", ":", 1);
Because --message is specified, GIT_EDITOR is set to ":", which
prevents the user from editing hunks, although the intent is most
likely to just prevent the user from editing the commit message.
^ permalink raw reply
* Re: [PATCH] git-status: show short sequencer state
From: Matthieu Moy @ 2012-10-23 6:05 UTC (permalink / raw)
To: Phil Hord
Cc: phil.hord, Junio C Hamano, konglu, Kong Lucien, git,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
In-Reply-To: <1350948569-28445-2-git-send-email-hordp@cisco.com>
Phil Hord <hordp@cisco.com> writes:
> + merge a git-merge is in progress
> + am a git-am is in progress
> + rebase a git-rebase is in progress
> + rebase-interactive a git-rebase--interactive is in progress
> + cherry-pick a git-cherry-pick is in progress
> + bisect a git-bisect is in progress
Avoid using git-foo syntax in documentation, it suggests that this is
valid command, which isn't true anymore. `git foo` seems the most common
syntax. Also, git-rebase--interactive is not user-visible => `git rebase
--interactive`.
> - if (state->am_empty_patch)
> + if (state->substate==WT_SUBSTATE_NOMINAL)
> status_printf_ln(s, color,
> _("The current patch is empty."));
This looks weird. First, spaces around == (here and below). Then, the
logic is unintuitive. The "if" suggests everything is allright, and the
message below is very specific. This at least deserves a comment.
> if (advice_status_hints) {
> - if (!state->am_empty_patch)
> + if (state->substate==WT_SUBSTATE_CONFLICTED)
Spaces around ==.
> +static void wt_print_token(struct wt_status *s, const char *color, const char *token)
> +{
> + color_fprintf(s->fp, color, "%s", token);
> + fputc(s->null_termination ? '\0' : '\n', s->fp);
> +}
The output format seems to be meant only for machine-consumption. Is
there any case when we'd want color? I'd say we can disable coloring
completely for this format (normally, color=auto does the right thing,
but I prefer being 100% sure I'll get no color when writing scripts)
> +static void wt_shortstatus_print_sequencer(struct wt_status *s)
[...]
> +void wt_sequencer_print(struct wt_status *s)
> +{
> + wt_shortstatus_print_sequencer(s);
> +}
> +
Why do you need this trivial wrapper?
Other than that, I like the idea (although I have no concrete use-case
in mind), but I didn't actually test the patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Git push slowly under 1000M/s network
From: Joey Jiao @ 2012-10-23 6:27 UTC (permalink / raw)
To: git
Hi Git Listeners,
I'm facing one problem when pushing to git repository via gerrit port.
Don't stop to look into the below content, as I doubt it might be a
git problem.
The pushing takes me 7mins~11mins each time every I had git gc on remote.
The remote server is 24 core with scsi disk. And the connection is
within 1000M/s intranet.
The pushing is only slowly on this kernel project, but faster on other
android projects, takes seconds only.
I tried on 4 core and 24 core clients to do the push, the time is
almost the same. So I think it's not the client problem.
The command I use as below. I also tried to pushing to git repository
directly, it is also slow, only some seconds benifit. So I think it
might be not the gerrit problem.
$ git push -v ssh://remote_url:29418/kernel/msm.git HEAD:refs/changes/33599
The stderr stops at remote: Resolving deltas: 0% (0/2) for 99% of the time.
I added some timestamp in the git source code, Like git version 1.8.0.
The receive_status called by send_pack inside send-pack.c takes the
99% of the time.
It looks like the client is waiting the pushing result status from
server although by checking server side, the real object has already
been upload succeed.
Below is the log after adding time info.
$ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
HEAD:refs/changes/33599 2>&1|tee -a log.txt
Pushing to ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
error: Time start packet_flush: Tue Oct 23 14:14:47 2012
error: Time finish packet_trace: Tue Oct 23 14:14:47 2012
error: Time finish safe_write: Tue Oct 23 14:14:47 2012
error: Time start receive_status: Tue Oct 23 14:14:47 2012
remote: Resolving deltas: 0% (0/2)
remote: (W) afafdad: no files changed, message updated
error: Time start packet_read_line: Tue Oct 23 14:24:41 2012
, len=10
error: Time packet_read_line: Tue Oct 23 14:24:41 2012
, len=22
error: Time packet_read_line: Tue Oct 23 14:24:41 2012
, len=0
error: Time finish receive_status: Tue Oct 23 14:24:41 2012
To ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
* [new branch] HEAD -> refs/changes/33599
real 9m56.928s
user 0m0.364s
sys 0m0.160s
--
-Joey Jiao
^ permalink raw reply
* git merge man page, upstream
From: Angelo Borsotti @ 2012-10-23 7:40 UTC (permalink / raw)
To: git
Hello,
the git merge man page, OPTIONS, <commit> ... states:
"If no commit is given from the command line, and if
merge.defaultToUpstream configuration variable is set, merge the
remote tracking branches that the current branch is configured to use
as its upstream. See also the configuration section of this manual
page."
Actually, in this case git merge merges the upstream branch, not the
remote tracking branch.
Proposed change:
"If no commit is given from the command line, and if
merge.defaultToUpstream configuration variable is set, merge the
upstream branches that the current branch has currently configured.
See also the configuration section of this manual page."
-Angelo Borsotti
^ permalink raw reply
* Re: git merge man page, upstream
From: Matthieu Moy @ 2012-10-23 7:51 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9BT3F1_yvf7jQQyT72_EWskFS4bEgXCkmJs7uZOPhEK8w@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Hello,
>
> the git merge man page, OPTIONS, <commit> ... states:
>
> "If no commit is given from the command line, and if
> merge.defaultToUpstream configuration variable is set, merge the
> remote tracking branches that the current branch is configured to use
> as its upstream. See also the configuration section of this manual
> page."
>
> Actually, in this case git merge merges the upstream branch, not the
> remote tracking branch.
It merges the upstream branch, which is a remote-tracking branch (notice
the - between remote and tracking, it's a branch that tracks a remote
branch, not a remote branch that tracks something).
I'll send a patch to fix that.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git merge man page, upstream
From: Angelo Borsotti @ 2012-10-23 9:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk3uhr5gp.fsf@grenoble-inp.fr>
Hi Matthieu,
the upstream branch can also be a local branch.
-Angelo
^ permalink raw reply
* git-pull suggests deprecated git-branch --set-upstream flag
From: Tomas Carnecky @ 2012-10-23 9:23 UTC (permalink / raw)
To: git
I just ran git pull, and it suggested that I should use `git branch
--set-upstream`. Yet when I used it, git-branch told me that the flag is
deprecated. Git version 1.8.0.
tom
^ permalink raw reply
* Re: Git push slowly under 1000M/s network
From: Joey Jiao @ 2012-10-23 10:11 UTC (permalink / raw)
To: git
In-Reply-To: <CAKOmCvp23fALGsDe4Ck7ZXpMJmOAq+YWCXPe_xb6GfQcjJi_kQ@mail.gmail.com>
Well, after checked pushing directly to git which takes only 6
seconds. So it should be not a issue of git in c. But might be an
issue with jgit or gerrit.
2012/10/23 Joey Jiao <joey.jiaojg@gmail.com>:
> Hi Git Listeners,
> I'm facing one problem when pushing to git repository via gerrit port.
> Don't stop to look into the below content, as I doubt it might be a
> git problem.
>
> The pushing takes me 7mins~11mins each time every I had git gc on remote.
> The remote server is 24 core with scsi disk. And the connection is
> within 1000M/s intranet.
> The pushing is only slowly on this kernel project, but faster on other
> android projects, takes seconds only.
> I tried on 4 core and 24 core clients to do the push, the time is
> almost the same. So I think it's not the client problem.
>
> The command I use as below. I also tried to pushing to git repository
> directly, it is also slow, only some seconds benifit. So I think it
> might be not the gerrit problem.
> $ git push -v ssh://remote_url:29418/kernel/msm.git HEAD:refs/changes/33599
> The stderr stops at remote: Resolving deltas: 0% (0/2) for 99% of the time.
>
> I added some timestamp in the git source code, Like git version 1.8.0.
> The receive_status called by send_pack inside send-pack.c takes the
> 99% of the time.
>
> It looks like the client is waiting the pushing result status from
> server although by checking server side, the real object has already
> been upload succeed.
>
> Below is the log after adding time info.
> $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> HEAD:refs/changes/33599 2>&1|tee -a log.txt
> Pushing to ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> error: Time start packet_flush: Tue Oct 23 14:14:47 2012
>
> error: Time finish packet_trace: Tue Oct 23 14:14:47 2012
>
> error: Time finish safe_write: Tue Oct 23 14:14:47 2012
>
> error: Time start receive_status: Tue Oct 23 14:14:47 2012
>
> remote: Resolving deltas: 0% (0/2)
> remote: (W) afafdad: no files changed, message updated
> error: Time start packet_read_line: Tue Oct 23 14:24:41 2012
> , len=10
> error: Time packet_read_line: Tue Oct 23 14:24:41 2012
> , len=22
> error: Time packet_read_line: Tue Oct 23 14:24:41 2012
> , len=0
> error: Time finish receive_status: Tue Oct 23 14:24:41 2012
>
> To ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
> * [new branch] HEAD -> refs/changes/33599
>
> real 9m56.928s
> user 0m0.364s
> sys 0m0.160s
> --
> -Joey Jiao
--
-Joey Jiao
^ permalink raw reply
* [PATCH] Document git-svn fetch --log-window-size parameter
From: Gunnlaugur Þór Briem @ 2012-10-23 10:33 UTC (permalink / raw)
To: git; +Cc: Gunnlaugur Þór Briem
The --log-window-size parameter to git-svn fetch is undocumented.
Minimally describe what it does and why the user might change it.
Signed-off-by: Gunnlaugur Þór Briem <gunnlaugur@gmail.com>
---
Documentation/git-svn.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index cfe8d2b..64756c9 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -146,6 +146,12 @@ Skip "branches" and "tags" of first level directories;;
------------------------------------------------------------------------
--
+--log-window-size=<n>;;
+ Fetch <n> log entries per request when scanning Subversion history.
+ The default is 100. For very large Subversion repositories, larger
+ values may be needed for 'clone'/'fetch' to complete in reasonable
+ time. But overly large values may lead to request timeouts.
+
'clone'::
Runs 'init' and 'fetch'. It will automatically create a
directory based on the basename of the URL passed to it;
--
1.7.12.3
^ permalink raw reply related
* [PATCH] Documentation: remote tracking branch -> remote-tracking branch
From: Matthieu Moy @ 2012-10-23 11:34 UTC (permalink / raw)
To: git, gitster; +Cc: angelo.borsotti, Matthieu Moy
In-Reply-To: <vpqk3uhr5gp.fsf@grenoble-inp.fr>
This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2
2010, Replace "remote tracking" with "remote-tracking"), but new
instances of remote tracking (without dash) were introduced in the
meantime.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Here's the patch.
I'm not opposed to dropping completely the remote-tracking part in the
case of merge (i.e. "remote-tracking branches that the current branch
is configured to use as its upstream" -> "upstream branch") on top of
that, but if we do this, merge-config.txt should be updated too).
Documentation/git-clone.txt | 4 ++--
Documentation/git-merge.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/merge-config.txt | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 6d98ef3..7fefdb0 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -196,9 +196,9 @@ objects from the source repository into a pack in the cloned repository.
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
Further fetches into the resulting repository will only update the
- remote tracking branch for the branch this option was used for the
+ remote-tracking branch for the branch this option was used for the
initial cloning. If the HEAD at the remote did not point at any
- branch when `--single-branch` clone was made, no remote tracking
+ branch when `--single-branch` clone was made, no remote-tracking
branch is created.
--recursive::
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 20f9228..d34ea3c 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -99,7 +99,7 @@ commit or stash your changes before running 'git merge'.
more than two parents (affectionately called an Octopus merge).
+
If no commit is given from the command line, and if `merge.defaultToUpstream`
-configuration variable is set, merge the remote tracking branches
+configuration variable is set, merge the remote-tracking branches
that the current branch is configured to use as its upstream.
See also the configuration section of this manual page.
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 22d2580..fe46c42 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -175,7 +175,7 @@ useful if you write an alias or script around 'git push'.
--recurse-submodules=check|on-demand::
Make sure all submodule commits used by the revisions to be
- pushed are available on a remote tracking branch. If 'check' is
+ pushed are available on a remote-tracking branch. If 'check' is
used git will verify that all submodule commits that changed in
the revisions to be pushed are available on at least one remote
of the submodule. If any commits are missing the push will be
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 861bd6f..9bb4956 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -9,11 +9,11 @@ merge.conflictstyle::
merge.defaultToUpstream::
If merge is called without any commit argument, merge the upstream
branches configured for the current branch by using their last
- observed values stored in their remote tracking branches.
+ observed values stored in their remote-tracking branches.
The values of the `branch.<current branch>.merge` that name the
branches at the remote named by `branch.<current branch>.remote`
are consulted, and then they are mapped via `remote.<remote>.fetch`
- to their corresponding remote tracking branches, and the tips of
+ to their corresponding remote-tracking branches, and the tips of
these tracking branches are merged.
merge.ff::
--
1.7.12.410.g5f38766
^ permalink raw reply related
* Re: git merge man page, upstream
From: Matthieu Moy @ 2012-10-23 11:35 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9CEbT=Y=yjw2tPSLiLibejDSheabcBPEpHCLa_TS+6Cpw@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> Hi Matthieu,
>
> the upstream branch can also be a local branch.
In this case, it's:
[branch "branch"]
remote = .
merge = refs/heads/master
which can arguably be considered as a special case of remote branch
whose location happens to be ".". But as said in the patch, I don't mind
if someone wants to drop the remote-tracking mention on top of my patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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