Many Pandora sale can be found
[url=http://www.cheappandorabuyshop.co.uk/] pandora charms[/url] is regarded to bring enjoy in addition to fend off awful sprits or maybe vibrations. The majority of the early cultures originating in early Egypt, The indian subcontinent, China and taiwan, A holiday in greece in addition to Italian capital numerous cultures presumed of which using attraction chains or maybe bracelets could carry enjoy towards consumer. Bicycles connected with using charm bracelets bracelets is usually as older seeing that people the world per se. Over the older situations persons helpful to have on attraction bracelets created from wood made drops, drops constructed from horn, cuboid, shells, for example. Furthermore, shells in addition to wood made drops are favorite to this day. http://www.cheappandorabuyshop.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/Many-Pandora-sale-can-be-found-tp7579574.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/5] blame: introduce $ as "end of file" in -L syntax
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Thomas Rast writes:
>>
>>> To save the user a lookup of the last line number, introduce $ as a
>>> shorthand for the last line. This is mostly useful to spell "until
>>> the end of the file" as '-L,$'.
>>
>> Doesn't "-L " or "-L ," do that already? If it were
>> to introduce "-L $-4," or "-L$-4,+2", I would understand why the
>> addition may be useful, but otherwise I do not think it adds much
>> value.
>
> It is a quiet-period so there is no need to rush, but did anything
> happened further on this series?
No, I've been busy :-(
The only open point is in the other email:
> >> Documentation/blame-options.txt | 19 +--
> >> Documentation/line-range-format.txt | 18 +++
> >> Makefile| 2 +
> >> builtin/blame.c | 99
> >> +++---
> >> line-log.c | 105
> >>
> >> line-log.h | 23
> >
> > Was this churn necessary?
> >
> > It is strange to move existing functions that will be tweaked to be
> > shared by two different codepaths (blame and line-log) to the new
> > user.
> [...]
>
> Even though I am moving from builtin/blame.c to line-log.c? I would
> otherwise have to call from a rather lib-ish file into a "front
You haven't sent any reply to this. Does that mean you agree? Would
you prefer the shared file to be named something like line-range.c?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Tue, Mar 12, 2013 at 5:17 PM, John Keeping wrote:
> On Tue, Mar 12, 2013 at 04:48:16PM -0600, Matt McClure wrote:
>> On Mar 12, 2013, at 4:16 PM, Junio C Hamano wrote:
>>
>> > Matt McClure writes:
>> >
>> > * If you are comparing two trees, and especially if your RHS is not
>> > HEAD, you will send everything to a temporary without
>> > symlinks. Any edit made by the user will be lost.
>>
>> I think you're suggesting to use a symlink any time the content of any
>> given RHS revision is the same as the working tree.
>>
>> I imagine that might confuse me as a user. It would create
>> circumstances where some files are symlinked and others aren't for
>> reasons that won't be straightforward.
>>
>> I imagine solving that case, I might instead implement a copy back to
>> the working tree with conflict detection/resolution. Some earlier
>> iterations of the directory diff feature used copy back without
>> conflict detection and created situations where I clobbered my own
>> changes by finishing a directory diff after making edits concurrently.
>
> The code to copy back working tree files is already there, it just
> triggers using the same logic as the creation of symlinks in the first
> place and doesn't attempt any conflict detection. I suspect that any
> more comprehensive solution will need to restrict the use of "git
> difftool -d" whenever the index contains unmerged entries or when there
> are both staged and unstaged changes, since the merge resolution will
> cause these states to be lost.
>
> The implementation of Junio's suggestion is relatively straightforward
> (this is untested, although t7800 passes, and can probably be improved
> by someone better versed in Perl). Does this work for your original
> scenario?
This is a nice straightforward approach.
As Junio mentioned, a good next step would be this patch
in combination with making the truly temporary files
created by dir-diff readonly.
Will that need a win32 platform check?
Does anyone want to take this and whip it into a proper patch?
> -- >8 --
> diff --git a/git-difftool.perl b/git-difftool.perl
> index 0a90de4..5f093ae 100755
> --- a/git-difftool.perl
> +++ b/git-difftool.perl
> @@ -83,6 +83,21 @@ sub exit_cleanup
> exit($status | ($status >> 8));
> }
>
> +sub use_wt_file
> +{
> + my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
> + my $null_sha1 = '0' x 40;
> +
> + if ($sha1 eq $null_sha1) {
> + return 1;
> + } elsif (not $symlinks) {
> + return 0;
> + }
> +
> + my $wt_sha1 = $repo->command_oneline('hash-object', "$workdir/$file");
> + return $sha1 eq $wt_sha1;
> +}
> +
> sub setup_dir_diff
> {
> my ($repo, $workdir, $symlinks) = @_;
> @@ -159,10 +174,10 @@ EOF
> }
>
> if ($rmode ne $null_mode) {
> - if ($rsha1 ne $null_sha1) {
> - $rindex .= "$rmode $rsha1\t$dst_path\0";
> - } else {
> + if (use_wt_file($repo, $workdir, $dst_path, $rsha1,
> $symlinks)) {
> push(@working_tree, $dst_path);
> + } else {
> + $rindex .= "$rmode $rsha1\t$dst_path\0";
> }
> }
> }
> --
> 1.8.2.rc2.4.g7799588
>
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] t2200: check that "add -u" limits itself to subdirectory
Jeff King writes: > This behavior is due to change in the future, but let's test > it anyway. Thanks. This should be merged regardless of PATCH 2/2 I think. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Benötigen Sie Finanzierung? Wir bieten direkte Finanzierung von bis zu 100 Millionen an erschwingliche Preise. Unsere zuverlässige und bequeme Finanzierung Dienstleistungen umfassen:- Konventionelle und persönliche Finanzierung für Einzelpersonen; Kommerzieller Begriff Darlehen für mittleren und großen Unternehmungen; Kleinunternehmen administration(SBA) Darlehen für kleine Unternehmungen und Start-up Unternehmenskredite; Investitionsdarlehen; und Immobilienfinanzierung. Kontaktieren Sie uns jetzt für weitere Details. Do you require funding? We provide direct funding of up to 100 million at affordable rates. Our reliable and convenient financing services include :- Conventional and Personal funding to individuals; Commercial term loans for medium and large scale business ventures; Small business administration(SBA) loan for small scale business ventures & start-up business loans; investment loans; and Real Estate financing. Contact us now for more details. This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting
On Tue, Mar 12, 2013 at 6:12 PM, Kevin Bracey wrote:
> Commit 718135e improved the merge error reporting for the resolve
> strategy's merge conflict and permission conflict cases, but led to a
> malformed "ERROR: in myfile.c" message in the case of a file added
> differently.
>
> This commit reverts that change, and uses an alternative approach without
> this flaw.
>
> Signed-off-by: Kevin Bracey
> ---
I wonder whether before these changes we should
update the style in this file to follow Documentation/CodingGuidelines.
Not in this patch, but in the file right now there's
this part that stands out:
if [ "$2" ]; then
echo "Removing $4"
I think that expression would read more clearly as:
if test -n "$2"
then
echo "Removing $4"
Ditto `if [ "$1" = '' ]` is better written as `test -z "$1"`.
Can you please send a patch to true these up?
It'd be especially nice if the style patch could come
first, followed by the fixes/features ;-)
> git-merge-one-file.sh | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
> index 0f164e5..78b07a8 100755
> --- a/git-merge-one-file.sh
> +++ b/git-merge-one-file.sh
> @@ -104,11 +104,13 @@ case "${1:-.}${2:-.}${3:-.}" in
> ;;
> esac
>
> + ret=0
> src1=$(git-unpack-file $2)
> src2=$(git-unpack-file $3)
> case "$1" in
> '')
> - echo "Added $4 in both, but differently."
> + echo "ERROR: Added $4 in both, but differently."
> + ret=1
> orig=$(git-unpack-file $2)
> create_virtual_base "$orig" "$src2"
> ;;
> @@ -121,10 +123,9 @@ case "${1:-.}${2:-.}${3:-.}" in
> # Be careful for funny filename such as "-L" in "$4", which
> # would confuse "merge" greatly.
> git merge-file "$src1" "$orig" "$src2"
> - ret=$?
> - msg=
> - if [ $ret -ne 0 ]; then
> - msg='content conflict'
> + if [ $? -ne 0 ]; then
> + echo "ERROR: Content conflict in $4"
> + ret=1
if test $? != 0
then
Also.. should this error not go to stderr?
I guess the existing script was not doing that,
but it seems like anything that says "ERROR" should go there.
> fi
>
> # Create the working tree file, using "our tree" version from the
> @@ -133,18 +134,11 @@ case "${1:-.}${2:-.}${3:-.}" in
> rm -f -- "$orig" "$src1" "$src2"
>
> if [ "$6" != "$7" ]; then
> - if [ -n "$msg" ]; then
> - msg="$msg, "
> - fi
> - msg="${msg}permissions conflict: $5->$6,$7"
> - ret=1
> - fi
> - if [ "$1" = '' ]; then
> + echo "ERROR: Permissions conflict: $5->$6,$7"
> ret=1
> fi
>
> if [ $ret -ne 0 ]; then
> - echo "ERROR: $msg in $4"
> exit 1
> fi
> exec git update-index -- "$4"
same notes as above. I think a style patch should come first.
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: respect add.updateroot config option
Jeff King writes: > For users who have read and accepted the warning, there is no way to > jump directly to the future behavior and silence the warning. I think the idea makes sense. The transition period is necessary for people who use different versions of Git (which includes anybody writting and distributing scripts), but for poor mortals who only use a single version of Git, it's nice to be able to jump to the future behavior once for all as soon as possible. Your patch doesn't advertise the option in the warning message, which I think is good. You may mention it the commit message that this is a deliberate choice. > +add.updateroot:: Detail: option names are normally camelCased => updateRoot. I think the option name needs a bit more thinking. Without reading the doc, [add] updateRoot = false would be a very tempting thing to try. Perhaps explicitly warning when add.updateroot is set to false would avoid possible confusion. In case you had missed it, here's a previous piece of discussion on the subject: http://thread.gmane.org/gmane.comp.version-control.git/216818/focus=216846 I liked David's suggestion of using future.* to mean "start using behavior from the future right now". > + which they were called. In a future version of git, this behavior Capital "Git". -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] difftool: Make directory diff symlink work tree
On Tue, Mar 12, 2013 at 08:26:21PM -0400, Matt McClure wrote: > On Tue, Mar 12, 2013 at 3:24 PM, John Keeping wrote: > > If so I think you want some new mode of operation for difftool instead > > of this patch which will also affect unrelated commands. > > Are you suggesting that difftool do the reset work above given a new > option or by default? I was suggesting something like the "--symlink-all" option discussed in the parallel thread, but it looks like we now have a better solution than that. John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tag: --force is quiet about new tags
Phil Hord venit, vidit, dixit 13.03.2013 05:21: > On Tue, Mar 12, 2013 at 11:33 PM, Junio C Hamano wrote: >> Phil Hord writes: >> >>> git tag --force is used to replace an existing tag with >>> a new reference. Git helpfully tells the user the old >>> ref when this happens. But if the tag name is new and does >>> not exist, git tells the user the old ref anyway (00). >>> >>> Teach git to ignore --force if the tag is new. Add a test >>> for this and also to ensure --force can replace tags at all. >>> >>> Signed-off-by: Phil Hord >>> --- >> >> I think we would still want to allow the operation to go through, >> even when the --force option is given, to create a new tag. I agree >> that the message should not say "Updated". So teaching Git not to >> issue the "Updated" message makes perfect sense. It is somewhat >> misleading to say we are teaching Git to ignore the option, though. >> >> Thanks. > > My phrasing was too ambiguous. What you described is exactly what the > patch does. --force is superfluous when the tag does not already > exist. It is only checked in two places, and one of those is to > decide whether to print the "Updated" message. How's this? > >Teach 'git tag --force' to suppress the update message if >the tag is new. Add a test for this and also to ensure >--force can replace tags at all. > > Phil Looks good to me, both the patch and the (updated) commit message. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: respect add.updateroot config option
On Wed, Mar 13, 2013 at 10:07:34AM +0100, Matthieu Moy wrote: > Jeff King writes: > > > For users who have read and accepted the warning, there is no way to > > jump directly to the future behavior and silence the warning. > > I think the idea makes sense. The transition period is necessary for > people who use different versions of Git (which includes anybody > writting and distributing scripts), but for poor mortals who only use a > single version of Git, it's nice to be able to jump to the future > behavior once for all as soon as possible. I think the biggest risk is from people who think they are safe to jump, and then find out that some script they depend on is not ready. Even if they do not even realize they are relying on it. Part of the point of the transition period is to get script authors to update their scripts, and to let the new versions trickle down to the users. > Your patch doesn't advertise the option in the warning message, which I > think is good. You may mention it the commit message that this is a > deliberate choice. Yes, it was deliberate. I can add a note. > > +add.updateroot:: > > Detail: option names are normally camelCased => updateRoot. Good point, thanks. > I think the option name needs a bit more thinking. Without reading the > doc, > > [add] > updateRoot = false > > would be a very tempting thing to try. Perhaps explicitly warning when > add.updateroot is set to false would avoid possible confusion. Yeah, that occurred to me, too, hence the note in the doc. Since it isn't advertised elsewhere, I had hoped that anybody who discovered it would see the note. I suppose we can warn when we see add.updateRoot set to anything but true. That feels a bit hacky, as it's possible the user could be overriding an earlier setting (although that is getting kind of crazy). > I liked David's suggestion of using future.* to mean "start using > behavior from the future right now". I do like that idea, as it makes the meaning of the variable more clear. I dunno. I am not all that excited about this patch, due to all of the caveats that we need to communicate to the user. The current warning has annoyed me a few times, but perhaps it is still too soon, and my fingers and brain just need retraining. I think a config option could help some people, but maybe it will end up hurting more. I'm inclined at this point to table the patch for now and see how I feel in a few weeks. I do think patch 1/2 makes sense regardless. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] nd/branch-show-rebase-bisect-state updates
This round fixes the design issue of read_and_strip_branch(), makes use of jc/reflog-reverse-walk and performs cheaper sha-1 check on detached commits. Nguyễn Thái Ngọc Duy (5): wt-status: move strbuf into read_and_strip_branch() wt-status: split wt_status_state parsing function out wt-status: move wt_status_get_state() out to wt_status_print() status: show more info than "currently not on any branch" branch: show more information when HEAD is detached builtin/branch.c| 26 +- t/t3203-branch-output.sh| 6 +- t/t6030-bisect-porcelain.sh | 2 +- t/t7406-submodule-update.sh | 6 +- t/t7512-status-help.sh | 52 ++- wt-status.c | 204 +++- wt-status.h | 7 +- 7 files changed, 214 insertions(+), 89 deletions(-) -- 1.8.1.2.536.gf441e6d -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] wt-status: move strbuf into read_and_strip_branch()
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 65 -
wt-status.h | 4 ++--
2 files changed, 32 insertions(+), 37 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index ef405d0..6cac27b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -969,41 +969,41 @@ static void show_bisect_in_progress(struct wt_status *s,
/*
* Extract branch information from rebase/bisect
*/
-static void read_and_strip_branch(struct strbuf *sb,
- const char **branch,
- const char *path)
+static char *read_and_strip_branch(const char *path)
{
+ struct strbuf sb = STRBUF_INIT;
unsigned char sha1[20];
- strbuf_reset(sb);
- if (strbuf_read_file(sb, git_path("%s", path), 0) <= 0)
- return;
+ if (strbuf_read_file(&sb, git_path("%s", path), 0) <= 0)
+ goto got_nothing;
- while (sb->len && sb->buf[sb->len - 1] == '\n')
- strbuf_setlen(sb, sb->len - 1);
- if (!sb->len)
- return;
- if (!prefixcmp(sb->buf, "refs/heads/"))
- *branch = sb->buf + strlen("refs/heads/");
- else if (!prefixcmp(sb->buf, "refs/"))
- *branch = sb->buf;
- else if (!get_sha1_hex(sb->buf, sha1)) {
+ while (&sb.len && sb.buf[sb.len - 1] == '\n')
+ strbuf_setlen(&sb, sb.len - 1);
+ if (!sb.len)
+ goto got_nothing;
+ if (!prefixcmp(sb.buf, "refs/heads/"))
+ strbuf_remove(&sb,0, strlen("refs/heads/"));
+ else if (!prefixcmp(sb.buf, "refs/"))
+ ;
+ else if (!get_sha1_hex(sb.buf, sha1)) {
const char *abbrev;
abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
- strbuf_reset(sb);
- strbuf_addstr(sb, abbrev);
- *branch = sb->buf;
- } else if (!strcmp(sb->buf, "detached HEAD")) /* rebase */
- ;
+ strbuf_reset(&sb);
+ strbuf_addstr(&sb, abbrev);
+ } else if (!strcmp(sb.buf, "detached HEAD")) /* rebase */
+ goto got_nothing;
else/* bisect */
- *branch = sb->buf;
+ ;
+ return strbuf_detach(&sb, NULL);
+
+got_nothing:
+ strbuf_release(&sb);
+ return NULL;
}
static void wt_status_print_state(struct wt_status *s)
{
const char *state_color = color(WT_STATUS_HEADER, s);
- struct strbuf branch = STRBUF_INIT;
- struct strbuf onto = STRBUF_INIT;
struct wt_status_state state;
struct stat st;
@@ -1018,27 +1018,22 @@ static void wt_status_print_state(struct wt_status *s)
state.am_empty_patch = 1;
} else {
state.rebase_in_progress = 1;
- read_and_strip_branch(&branch, &state.branch,
- "rebase-apply/head-name");
- read_and_strip_branch(&onto, &state.onto,
- "rebase-apply/onto");
+ state.branch =
read_and_strip_branch("rebase-apply/head-name");
+ state.onto = read_and_strip_branch("rebase-apply/onto");
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
state.rebase_interactive_in_progress = 1;
else
state.rebase_in_progress = 1;
- read_and_strip_branch(&branch, &state.branch,
- "rebase-merge/head-name");
- read_and_strip_branch(&onto, &state.onto,
- "rebase-merge/onto");
+ state.branch = read_and_strip_branch("rebase-merge/head-name");
+ state.onto = read_and_strip_branch("rebase-merge/onto");
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
state.cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st)) {
state.bisect_in_progress = 1;
- read_and_strip_branch(&branch, &state.branch,
- "BISECT_START");
+ state.branch = read_and_strip_branch("BISECT_START");
}
if (state.merge_in_progress)
@@ -1051,8 +1046,8 @@ static void wt_status_print_state(struct wt_status *s)
show_cherry_pick_in_progress(s, &state, state_color);
if (state.bisect_in_progress)
show_bisect_in_progress(s, &state, state_color);
- strbuf_release(&branch);
- strbuf_release(&onto);
+ free(state.branch);
+ free(state.onto);
}
void wt_status_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 81e1dcf..b8c3512 100644
--- a/wt-status.h
+++ b/wt-status.h
[PATCH v3 2/5] wt-status: split wt_status_state parsing function out
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 41 +++--
wt-status.h | 1 +
2 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 6cac27b..0d8989f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1001,40 +1001,45 @@ got_nothing:
return NULL;
}
-static void wt_status_print_state(struct wt_status *s)
+void wt_status_get_state(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));
-
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;
+ state->am_in_progress = 1;
if (!stat(git_path("rebase-apply/patch"), &st) &&
!st.st_size)
- state.am_empty_patch = 1;
+ state->am_empty_patch = 1;
} else {
- state.rebase_in_progress = 1;
- state.branch =
read_and_strip_branch("rebase-apply/head-name");
- state.onto = read_and_strip_branch("rebase-apply/onto");
+ state->rebase_in_progress = 1;
+ state->branch =
read_and_strip_branch("rebase-apply/head-name");
+ state->onto =
read_and_strip_branch("rebase-apply/onto");
}
} 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.branch = read_and_strip_branch("rebase-merge/head-name");
- state.onto = read_and_strip_branch("rebase-merge/onto");
+ state->rebase_in_progress = 1;
+ state->branch = read_and_strip_branch("rebase-merge/head-name");
+ state->onto = read_and_strip_branch("rebase-merge/onto");
} 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.branch = read_and_strip_branch("BISECT_START");
+ state->bisect_in_progress = 1;
+ state->branch = read_and_strip_branch("BISECT_START");
}
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ memset(&state, 0, sizeof(state));
+ wt_status_get_state(&state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
diff --git a/wt-status.h b/wt-status.h
index b8c3512..5ddcbf6 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -86,6 +86,7 @@ struct wt_status_state {
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
+void wt_status_get_state(struct wt_status_state *state);
void wt_shortstatus_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
--
1.8.1.2.536.gf441e6d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] wt-status: move wt_status_get_state() out to wt_status_print()
Signed-off-by: Nguyễn Thái Ngọc Duy
---
wt-status.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 0d8989f..17690d8 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1033,32 +1033,30 @@ void wt_status_get_state(struct wt_status_state *state)
}
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_print_state(struct wt_status *s,
+ struct wt_status_state *state)
{
const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
-
- memset(&state, 0, sizeof(state));
- wt_status_get_state(&state);
-
- if (state.merge_in_progress)
- show_merge_in_progress(s, &state, state_color);
- else if (state.am_in_progress)
- show_am_in_progress(s, &state, state_color);
- else if (state.rebase_in_progress ||
state.rebase_interactive_in_progress)
- show_rebase_in_progress(s, &state, state_color);
- else if (state.cherry_pick_in_progress)
- show_cherry_pick_in_progress(s, &state, state_color);
- if (state.bisect_in_progress)
- show_bisect_in_progress(s, &state, state_color);
- free(state.branch);
- free(state.onto);
+ if (state->merge_in_progress)
+ show_merge_in_progress(s, state, state_color);
+ else if (state->am_in_progress)
+ show_am_in_progress(s, state, state_color);
+ else if (state->rebase_in_progress ||
state->rebase_interactive_in_progress)
+ show_rebase_in_progress(s, state, state_color);
+ else if (state->cherry_pick_in_progress)
+ show_cherry_pick_in_progress(s, state, state_color);
+ if (state->bisect_in_progress)
+ show_bisect_in_progress(s, state, state_color);
}
void wt_status_print(struct wt_status *s)
{
const char *branch_color = color(WT_STATUS_ONBRANCH, s);
const char *branch_status_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ memset(&state, 0, sizeof(state));
+ wt_status_get_state(&state);
if (s->branch) {
const char *on_what = _("On branch ");
@@ -1077,7 +1075,10 @@ void wt_status_print(struct wt_status *s)
wt_status_print_tracking(s);
}
- wt_status_print_state(s);
+ wt_status_print_state(s, &state);
+ free(state.branch);
+ free(state.onto);
+
if (s->is_initial) {
status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial
commit"));
--
1.8.1.2.536.gf441e6d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] status: show more info than "currently not on any branch"
When a remote ref or a tag is checked out, HEAD is automatically detached. There is no user-friendly way to find out what ref is checked out in this case. This patch digs in reflog for this information and shows "HEAD detached from origin/master" or "HEAD detached at v1.8.0" instead of "currently not on any branch". When it cannot figure out the original ref, it shows an abbreviated SHA-1. "Currently not on any branch" would never display (unless reflog is pruned to near empty that the last checkout entry is lost). Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t7406-submodule-update.sh | 6 ++- t/t7512-status-help.sh | 52 -- wt-status.c | 89 +++-- wt-status.h | 4 +- 4 files changed, 125 insertions(+), 26 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index ea61761..a4ffea0 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -665,8 +665,10 @@ test_expect_success 'submodule add properly re-creates deeper level submodules' test_expect_success 'submodule update properly revives a moved submodule' ' (cd super && +H=$(git rev-parse --short HEAD) && git commit -am "pre move" && -git status >expect&& +H2=$(git rev-parse --short HEAD) && +git status | sed "s/$H/XXX/" >expect && H=$(cd submodule2; git rev-parse HEAD) && git rm --cached submodule2 && rm -rf submodule2 && @@ -675,7 +677,7 @@ test_expect_success 'submodule update properly revives a moved submodule' ' git config -f .gitmodules submodule.submodule2.path "moved/sub module" git commit -am "post move" && git submodule update && -git status >actual && +git status | sed "s/$H2/XXX/" >actual && test_cmp expect actual ) ' diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index d2da89a..da22088 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' ONTO=$(git rev-parse --short HEAD^^) && test_must_fail git rebase HEAD^ --onto HEAD^^ && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (fix conflicts and then run "git rebase --continue") # (use "git rebase --skip" to skip this patch) @@ -103,7 +103,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' ' echo three >main.txt && git add main.txt && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (all conflicts fixed: run "git rebase --continue") # @@ -135,7 +135,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' ONTO=$(git rev-parse --short rebase_i_conflicts) && test_must_fail git rebase -i rebase_i_conflicts && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (fix conflicts and then run "git rebase --continue") # (use "git rebase --skip" to skip this patch) @@ -161,7 +161,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' ' test_must_fail git rebase -i rebase_i_conflicts && git add main.txt && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (all conflicts fixed: run "git rebase --continue") # @@ -187,9 +187,10 @@ test_expect_success 'status when rebasing -i in edit mode' ' export FAKE_LINES && test_when_finished "git rebase --abort" && ONTO=$(git rev-parse --short HEAD~2) && + TGT=$(git rev-parse --short two_rebase_i) && git rebase -i HEAD~2 && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached from $TGT # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''. # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) @@ -214,8 +215,9 @@ test_expect_success 'status when splitting a commit' ' ONTO=$(git rev-parse --short HEAD~3) && git rebase -i HEAD~3 && git reset HEAD^ && + TGT=$(git rev-parse --short HEAD) && cat >expected <<-EOF && - # Not currently on any branch. + # HEAD detached at $TGT # You are
[PATCH v3 5/5] branch: show more information when HEAD is detached
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases? Is it detached because the user checks out a remote ref or a
tag (and which one)?
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c| 26 +-
t/t3203-branch-output.sh| 6 +++---
t/t6030-bisect-porcelain.sh | 2 +-
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 00d17d2..2ab0e4f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -18,6 +18,7 @@
#include "string-list.h"
#include "column.h"
#include "utf8.h"
+#include "wt-status.h"
static const char * const builtin_branch_usage[] = {
N_("git branch [options] [-r | -a] [--merged | --no-merged]"),
@@ -550,6 +551,29 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description(void)
+{
+ struct strbuf desc = STRBUF_INIT;
+ struct wt_status_state state;
+ memset(&state, 0, sizeof(state));
+ wt_status_get_state(&state, 1);
+ if (state.rebase_in_progress ||
+ state.rebase_interactive_in_progress)
+ strbuf_addf(&desc, _("(no branch, rebasing %s)"),
+ state.branch);
+ else if (state.bisect_in_progress)
+ strbuf_addf(&desc, _("(no branch, bisecting %s)"),
+ state.branch);
+ else if (state.detached_from)
+ strbuf_addf(&desc, _("(detached from %s)"),
+ state.detached_from);
+ else
+ strbuf_addstr(&desc, _("(no branch)"));
+ free(state.branch);
+ free(state.onto);
+ free(state.detached_from);
+ return strbuf_detach(&desc, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +581,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit,
ref_list->with_commit)) {
struct ref_item item;
- item.name = xstrdup(_("(no branch)"));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 76fe7e0..ba4f98e 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -94,13 +94,13 @@ test_expect_success 'git branch -v pattern does not show
branch summaries' '
test_must_fail git branch -v branch*
'
-cat >expect <<'EOF'
-* (no branch)
+test_expect_success 'git branch shows detached HEAD properly' '
+ cat >expect branch.output &&
- test_i18ngrep "* (no branch)" branch.output > /dev/null &&
+ test_i18ngrep "* (no branch, bisecting other)" branch.output >
/dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
--
1.8.1.2.536.gf441e6d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] status: hint the user about -uno if read_directory takes too long
This patch attempts to advertise -uno to the users who tolerate slow
"git status" on large repositories (or slow machines/disks). The 2
seconds limit is quite arbitrary but is probably long enough to start
using -uno.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 4
advice.c | 2 ++
advice.h | 1 +
t/t7060-wtstatus.sh | 2 ++
t/t7508-status.sh| 4
t/t7512-status-help.sh | 1 +
wt-status.c | 20 +++-
wt-status.h | 1 +
8 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bbba728..e91d06f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -178,6 +178,10 @@ advice.*::
the template shown when writing commit messages in
linkgit:git-commit[1], and in the help message shown
by linkgit:git-checkout[1] when switching branch.
+ statusUno::
+ If collecting untracked files in linkgit:git-status[1]
+ takes more than 2 seconds, hint the user that the option
+ `-uno` could be used to stop collecting untracked files.
commitBeforeMerge::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwriting local changes.
diff --git a/advice.c b/advice.c
index 780f58d..72b5c66 100644
--- a/advice.c
+++ b/advice.c
@@ -8,6 +8,7 @@ int advice_push_already_exists = 1;
int advice_push_fetch_first = 1;
int advice_push_needs_force = 1;
int advice_status_hints = 1;
+int advice_status_uno = 1;
int advice_commit_before_merge = 1;
int advice_resolve_conflict = 1;
int advice_implicit_identity = 1;
@@ -25,6 +26,7 @@ static struct {
{ "pushfetchfirst", &advice_push_fetch_first },
{ "pushneedsforce", &advice_push_needs_force },
{ "statushints", &advice_status_hints },
+ { "statusuno", &advice_status_uno },
{ "commitbeforemerge", &advice_commit_before_merge },
{ "resolveconflict", &advice_resolve_conflict },
{ "implicitidentity", &advice_implicit_identity },
diff --git a/advice.h b/advice.h
index fad36df..d7e03be 100644
--- a/advice.h
+++ b/advice.h
@@ -11,6 +11,7 @@ extern int advice_push_already_exists;
extern int advice_push_fetch_first;
extern int advice_push_needs_force;
extern int advice_status_hints;
+extern int advice_status_uno;
extern int advice_commit_before_merge;
extern int advice_resolve_conflict;
extern int advice_implicit_identity;
diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index f4f38a5..dd340d5 100755
--- a/t/t7060-wtstatus.sh
+++ b/t/t7060-wtstatus.sh
@@ -5,6 +5,7 @@ test_description='basic work tree status reporting'
. ./test-lib.sh
test_expect_success setup '
+ git config advice.statusuno false &&
test_commit A &&
test_commit B oneside added &&
git checkout A^0 &&
@@ -46,6 +47,7 @@ test_expect_success 'M/D conflict does not segfault' '
(
cd mdconflict &&
git init &&
+ git config advice.statusuno false
test_commit initial foo "" &&
test_commit modify foo foo &&
git checkout -b side HEAD^ &&
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index a79c032..9d6e4db 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -8,11 +8,13 @@ test_description='git status'
. ./test-lib.sh
test_expect_success 'status -h in broken repository' '
+ git config advice.statusuno false &&
mkdir broken &&
test_when_finished "rm -fr broken" &&
(
cd broken &&
git init &&
+ git config advice.statusuno false &&
echo "[status] showuntrackedfiles = CORRUPT" >>.git/config &&
test_expect_code 129 git status -h >usage 2>&1
) &&
@@ -25,6 +27,7 @@ test_expect_success 'commit -h in broken repository' '
(
cd broken &&
git init &&
+ git config advice.statusuno false &&
echo "[status] showuntrackedfiles = CORRUPT" >>.git/config &&
test_expect_code 129 git commit -h >usage 2>&1
) &&
@@ -780,6 +783,7 @@ test_expect_success 'status refreshes the index' '
test_expect_success 'setup status submodule summary' '
test_create_repo sm && (
cd sm &&
+ git config advice.statusuno false &&
>foo &&
git add foo &&
git commit -m "Add foo"
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index d2da89a..033a1b3 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -14,6 +14,7 @@ test_description='git status advice'
set_fake_editor
test_expect_success 'prepare for conflicts' '
+ git config advice.statusuno false &&
test_commit init main.txt init &&
git branch
Rename conflicts in the index
When a rename conflict occurs, the information about the conflict is written to stdout and the index is updated as if the conflict were a simpler conflict that did not involve renames. This doesn't give a lot of information to users after the fact - a status of "added in ours" does not provide a lot of details about what occurred. In reimplementations, we face a similar challenge. Unfortunately, we can't simply print the output to the console, we would like to provide this information back to the caller by some mechanism. My preference would be to return this information in the index - so that the results of "unpack trees" (if you will) was a single data structure (the index) and so that we could persist this information to disk. I've been considering the idea of an extension that contains more detailed data about conflicts, but I certainly wouldn't want to proceed without discussing this here further. I would propose that we store the data about the file in conflict as it occurred through the renames. For example, in a rename 1->2 conflict where A was renamed to both B and C, you would have a single conflict entry containing the data for A, B and C. This would allow us to provide more detailed information to the user - and allow them to (say) choose a single name to proceed with. Is this something that has value to core git as well? Alternately, is there something particularly stupid about this proposal? Thanks- -ed -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tag peeling peculiarities
I have been working on the pack-refs code [1] and noticed what looks
like a problem with the handling of peeled refs in the packed-refs file
and in the reference cache. In particular, the peeled versions of tags
outside of refs/tags are *not* stored in packed-refs, but after the
packed-refs file is read it is assumed that such tags cannot be peeled.
It is clear that annotated tags want to live under refs/tags, but there
are some ways to create them in other places (see below). It is not
clear to me whether the prohibition of tags outside of refs/tags should
be made more airtight or whether the peeling of tags outside of
refs/tags should be fixed.
Example:
~/tmp$ git init foo
Initialized empty Git repository in /home/mhagger/tmp/foo/.git/
~/tmp$ cd foo
~/tmp/foo$ git config user.name 'Lou User'
~/tmp/foo$ git config user.email 'lu...@exaple.com'
~/tmp/foo$
~/tmp/foo$ git commit --allow-empty -m "Initial commit"
[master (root-commit) 7e80ddd] Initial commit
~/tmp/foo$ git tag -m footag footag
~/tmp/foo$
~/tmp/foo$ # This is prohibited:
~/tmp/foo$ git update-ref refs/heads/foobranch $(git rev-parse footag)
error: Trying to write non-commit object
d9cdc84dd156ff83799f5226794711fbb2c8273a to branch refs/heads/foobranch
fatal: Cannot update the ref 'refs/heads/foobranch'.
~/tmp/foo$
~/tmp/foo$ # But this is allowed:
~/tmp/foo$ git update-ref refs/remotes/foo/bar $(git rev-parse footag)
~/tmp/foo$
~/tmp/foo$ # So is this:
~/tmp/foo$ git update-ref refs/yak/foobranch $(git rev-parse footag)
~/tmp/foo$
~/tmp/foo$ # Before packing, all tags are available in peel versions:
~/tmp/foo$ git show-ref -d
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/heads/master
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/remotes/foo/bar
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/remotes/foo/bar^{}
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/tags/footag
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/tags/footag^{}
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/yak/foobranch
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/yak/foobranch^{}
~/tmp/foo$
~/tmp/foo$ git pack-refs --all
~/tmp/foo$
~/tmp/foo$ # After packing, tags outside of refs/tags are not peeled any
more:
~/tmp/foo$ git show-ref -d
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/heads/master
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/remotes/foo/bar
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/tags/footag
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/tags/footag^{}
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/yak/foobranch
~/tmp/foo$
~/tmp/foo$ # Peeling the tags via "tag^0" works even after packing:
~/tmp/foo$ git rev-parse refs/yak/foobranch^0
7e80ddd68f0225a0ea221f7cddbacf050be5a265
~/tmp/foo$
~/tmp/foo$ # Here is another way to create a tag outside of refs/tags:
~/tmp/foo$ cd ..
~/tmp$ git clone foo foo-clone
Cloning into 'foo-clone'...
done.
~/tmp$ cd foo-clone
~/tmp/foo-clone$ git config --add remote.origin.fetch
'+refs/tags/*:refs/remotes/origin/tags/*'
~/tmp/foo-clone$ git fetch
>From /home/mhagger/tmp/foo
* [new tag] footag -> origin/tags/footag
~/tmp/foo-clone$
~/tmp/foo-clone$ # Again, the tag outside of refs/tags are not peeled
correctly after packing:
~/tmp/foo-clone$ git pack-refs --all
~/tmp/foo-clone$ git show-ref -d
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/heads/master
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/remotes/origin/HEAD
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/remotes/origin/master
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/remotes/origin/tags/footag
d9cdc84dd156ff83799f5226794711fbb2c8273a refs/tags/footag
7e80ddd68f0225a0ea221f7cddbacf050be5a265 refs/tags/footag^{}
Michael
[1] I am trying to fix the problem that peeled refs are lost whenever a
packed reference is deleted.
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] status: hint the user about -uno if read_directory takes too long
On 13.03.13 13:59, Nguyễn Thái Ngọc Duy wrote: > This patch attempts to advertise -uno to the users who tolerate slow > "git status" on large repositories (or slow machines/disks). The 2 > seconds limit is quite arbitrary but is probably long enough to start > using -uno. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > Documentation/config.txt | 4 > advice.c | 2 ++ > advice.h | 1 + > t/t7060-wtstatus.sh | 2 ++ > t/t7508-status.sh| 4 > t/t7512-status-help.sh | 1 + > wt-status.c | 20 +++- > wt-status.h | 1 + > 8 files changed, 34 insertions(+), 1 deletion(-) > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index bbba728..e91d06f 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -178,6 +178,10 @@ advice.*:: > the template shown when writing commit messages in > linkgit:git-commit[1], and in the help message shown > by linkgit:git-checkout[1] when switching branch. > + statusUno:: > + If collecting untracked files in linkgit:git-status[1] > + takes more than 2 seconds, hint the user that the option > + `-uno` could be used to stop collecting untracked files. Thanks, I like the idea could we make a "de-Luxe" version where statusUno is an integer, counting in milliseconds? /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] difftool: Make directory diff symlink working tree
On Wed, Mar 13, 2013 at 4:24 AM, David Aguilar wrote:
> This is a nice straightforward approach.
>
> As Junio mentioned, a good next step would be this patch
> in combination with making the truly temporary files
> created by dir-diff readonly.
>
> Will that need a win32 platform check?
> Does anyone want to take this and whip it into a proper patch?
An attempt:
>From 429ae282ffd7202b6d2fb024a92dea543b8af376 Mon Sep 17 00:00:00 2001
From: Matt McClure
Date: Wed, 13 Mar 2013 11:14:22 -0400
Subject: [PATCH] difftool: Make directory diff symlink working tree
...primarily so that a user can edit working tree files in his difftool.
difftool -d formerly knew how to symlink to the working tree when the
work tree contains uncommitted changes. In practice, prior to this
change, it would not symlink to the working tree in case there were no
uncommitted changes, even when the user invoked difftool with the form:
git difftool -d [--options] [--] [...]
This form is to view the changes you have in your working tree
relative to the named . You can use HEAD to compare it
with the latest commit, or a branch name to compare with the tip
of a different branch.
Instead, prior to this change, difftool would use the file's blob SHA1
to find its content in the index rather than use the working tree
content. This change teaches `git difftool` to compare the blob SHA1 to
the file's working tree blob SHA1 and use the working tree file if the
SHA1s are the same.
Author: John Keeping
Conversation:
http://thread.gmane.org/gmane.comp.version-control.git/217979/focus=218014
---
git-difftool.perl | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index 0a90de4..5f093ae 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -83,6 +83,21 @@ sub exit_cleanup
exit($status | ($status >> 8));
}
+sub use_wt_file
+{
+ my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
+ my $null_sha1 = '0' x 40;
+
+ if ($sha1 eq $null_sha1) {
+ return 1;
+ } elsif (not $symlinks) {
+ return 0;
+ }
+
+ my $wt_sha1 = $repo->command_oneline('hash-object', "$workdir/$file");
+ return $sha1 eq $wt_sha1;
+}
+
sub setup_dir_diff
{
my ($repo, $workdir, $symlinks) = @_;
@@ -159,10 +174,10 @@ EOF
}
if ($rmode ne $null_mode) {
- if ($rsha1 ne $null_sha1) {
- $rindex .= "$rmode $rsha1\t$dst_path\0";
- } else {
+ if (use_wt_file($repo, $workdir, $dst_path, $rsha1,
$symlinks)) {
push(@working_tree, $dst_path);
+ } else {
+ $rindex .= "$rmode $rsha1\t$dst_path\0";
}
}
}
--
1.8.1.5
--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
David Aguilar writes: >> The implementation of Junio's suggestion is relatively straightforward >> (this is untested, although t7800 passes, and can probably be improved >> by someone better versed in Perl). Does this work for your original >> scenario? > > This is a nice straightforward approach. > > As Junio mentioned, a good next step would be this patch in > combination with making the truly temporary files created by > dir-diff readonly. Even though I agree that the idea Matt McClure mentioned to run a three-way merge to take the modification back when the path checked out to the temporary tree as a temporary file (because it does not match the working tree version) gets edited by the user might be a better longer-term direction to go, marking the temporaries that the users should not modify clearly as such needs to be done in the shorter term. This thread wouldn't have had to happen if we had such a safety measure in the first place. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tag peeling peculiarities
On 03/13/2013 03:59 PM, Michael Haggerty wrote: > I have been working on the pack-refs code [1] and noticed what looks > like a problem with the handling of peeled refs in the packed-refs file > and in the reference cache. In particular, the peeled versions of tags > outside of refs/tags are *not* stored in packed-refs, but after the > packed-refs file is read it is assumed that such tags cannot be peeled. > > It is clear that annotated tags want to live under refs/tags, but there > are some ways to create them in other places (see below). It is not > clear to me whether the prohibition of tags outside of refs/tags should > be made more airtight or whether the peeling of tags outside of > refs/tags should be fixed. > > Example: > [...] I should have mentioned that I already understand the programmatic *cause* of the behavior that I described in my last email: * in pack-refs.c:handle_one_ref(), tags that are not in refs/tags are explicitly excluded from being peeled. * in refs.c:read_packed_refs(), if the packed-refs file starts with "# pack-refs with: peeled " then the REF_KNOWS_PEELED bit is set on *every* reference read from the file into the packed refs cache, whether or not it is under refs/tags. * in refs.c:peel_ref(), if a refs cache entry has its REF_KNOWS_PEELED bit set but its peeled field is empty, then it is assumed that the reference is unpeelable. What I am *not* clear about is which of these steps is incorrect, and also whether this problem will have any significant ill effects. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: respect add.updateroot config option
Jeff King writes: >> Your patch doesn't advertise the option in the warning message, which I >> think is good. You may mention it the commit message that this is a >> deliberate choice. > > Yes, it was deliberate. I can add a note. > >> > +add.updateroot:: >> >> Detail: option names are normally camelCased => updateRoot. > > Good point, thanks. > >> I think the option name needs a bit more thinking. Without reading the >> doc, >> >> [add] >> updateRoot = false >> >> would be a very tempting thing to try. Perhaps explicitly warning when >> add.updateroot is set to false would avoid possible confusion. This is essentially the same as Matthieu's add.use2dot0Behavior but with that "it is an error to explicitly set it to false" twist, it alleviates one of the worries. It still has the same "the user saw it mentioned on stackoverflow and sets it without understanding that the behaviour is getting changed" effect. Also it won't give chance for scripts to get fixed, even though I suspect that instances of "add -u/-A" without pathspec end users write in their custom scripts almost always would want to be tree-wide and it is a bug that they do not pass ":/" to them. The "future.*" (I'd rather call that "migration.*") approach with the "never set it to false" twist is probably OK from the "complaint avoidance" perspective. The user cannot later complain "I tried to squelch the advice but at the same time I ended up adding updated contents outside my diretory", without getting told "That is the documented behaviour, isn't it?" But I still think it is much less nice from "avoid hurting the users" perspective. If the way to squelch the user learns were to say "git add -u .", where the user explicitly says "take the updated contents from this directory and below", there is no room for confusion. We won't hear complaints either way, but with the "future.*" the reason why we won't hear complaints is because the users do not have excuse to complain. With the "require explicit .", it is because the users won't get hurt in the first place. > I dunno. I am not all that excited about this patch, due to all of the > caveats that we need to communicate to the user. The current warning has > annoyed me a few times, but perhaps it is still too soon, and my fingers > and brain just need retraining. I think a config option could help some > people, but maybe it will end up hurting more. I'm inclined at this > point to table the patch for now and see how I feel in a few weeks. > > I do think patch 1/2 makes sense regardless. These two concluding paragraphs match my current thinking. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] difftool: Make directory diff symlink working tree
On Wed, Mar 13, 2013 at 11:21:40AM -0400, Matt McClure wrote:
> On Wed, Mar 13, 2013 at 4:24 AM, David Aguilar wrote:
> > This is a nice straightforward approach.
> >
> > As Junio mentioned, a good next step would be this patch
> > in combination with making the truly temporary files
> > created by dir-diff readonly.
> >
> > Will that need a win32 platform check?
> > Does anyone want to take this and whip it into a proper patch?
>
> An attempt:
>
> From 429ae282ffd7202b6d2fb024a92dea543b8af376 Mon Sep 17 00:00:00 2001
> From: Matt McClure
> Date: Wed, 13 Mar 2013 11:14:22 -0400
> Subject: [PATCH] difftool: Make directory diff symlink working tree
>
> ...primarily so that a user can edit working tree files in his difftool.
Please don't continue the subject like this, look at some recent commits
in git.git to see how commits are normally formatted.
The subject here is also inaccurate since difftool already symlinks the
working tree in some situations.
> difftool -d formerly knew how to symlink to the working tree when the
> work tree contains uncommitted changes. In practice, prior to this
> change, it would not symlink to the working tree in case there were no
> uncommitted changes, even when the user invoked difftool with the form:
>
> git difftool -d [--options] [--] [...]
> This form is to view the changes you have in your working tree
> relative to the named . You can use HEAD to compare it
> with the latest commit, or a branch name to compare with the tip
> of a different branch.
>
> Instead, prior to this change, difftool would use the file's blob SHA1
> to find its content in the index rather than use the working tree
> content. This change teaches `git difftool` to compare the blob SHA1 to
> the file's working tree blob SHA1 and use the working tree file if the
> SHA1s are the same.
You don't need to say things like "formerly..." and "prior to this",
write in the imperative describing how the commit changes things. A
better commit message might be:
difftool -d: symlink working tree files matching RHS
Change the behaviour of git-difftool's directory diff mode so that
instead of symlinking to working tree files only when they have
unstaged changes we now symlink to any files where the working tree
matches the RHS of the diff.
This helps users who like to edit files in their diff tool and
expect to have those changes reflected in the working tree.
> Author: John Keeping
The correct way to credit authorship is via a "From: " header at the top
of the message. In this particular case, I think this change also
requires a documentation update and some test coverage, so it would be
appropriate for whoever adds those to take the credit for the commit and
add a "Based-on-patch-by: John Keeping " footer.
You should also add your own "Signed-off-by:" line.
If no-one else gets there first I'm hoping to have a bit of time to add
the documentation and test case in 4 hours or so.
> Conversation:
> http://thread.gmane.org/gmane.comp.version-control.git/217979/focus=218014
This isn't necessary, just reply to relevant message in that thread and
it will show up correctly in people's mail clients.
> ---
> git-difftool.perl | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/git-difftool.perl b/git-difftool.perl
> index 0a90de4..5f093ae 100755
> --- a/git-difftool.perl
> +++ b/git-difftool.perl
> @@ -83,6 +83,21 @@ sub exit_cleanup
> exit($status | ($status >> 8));
> }
>
> +sub use_wt_file
> +{
> + my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
> + my $null_sha1 = '0' x 40;
> +
> + if ($sha1 eq $null_sha1) {
> + return 1;
> + } elsif (not $symlinks) {
> + return 0;
> + }
> +
> + my $wt_sha1 = $repo->command_oneline('hash-object', "$workdir/$file");
> + return $sha1 eq $wt_sha1;
> +}
> +
> sub setup_dir_diff
> {
> my ($repo, $workdir, $symlinks) = @_;
> @@ -159,10 +174,10 @@ EOF
> }
>
> if ($rmode ne $null_mode) {
> - if ($rsha1 ne $null_sha1) {
> - $rindex .= "$rmode $rsha1\t$dst_path\0";
> - } else {
> + if (use_wt_file($repo, $workdir, $dst_path, $rsha1,
> $symlinks)) {
> push(@working_tree, $dst_path);
> + } else {
> + $rindex .= "$rmode $rsha1\t$dst_path\0";
> }
> }
> }
> --
> 1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/5] blame: introduce $ as "end of file" in -L syntax
Thomas Rast writes: >> Even though I am moving from builtin/blame.c to line-log.c? I would >> otherwise have to call from a rather lib-ish file into a "front > > You haven't sent any reply to this. Does that mean you agree? Would > you prefer the shared file to be named something like line-range.c? The latter, or if you do not want a churn, not moving it out of blame.c at all. Because "log -L" does not play well with other patch options, from the end-user's perspective, even though may does not have cmd_logL() entry point, I do not think line-log.c is any more library-ish than cmd_log() or cmd_blame(). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] status: hint the user about -uno if read_directory takes too long
Nguyễn Thái Ngọc Duy writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index bbba728..e91d06f 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -178,6 +178,10 @@ advice.*::
> the template shown when writing commit messages in
> linkgit:git-commit[1], and in the help message shown
> by linkgit:git-checkout[1] when switching branch.
> + statusUno::
> + If collecting untracked files in linkgit:git-status[1]
> + takes more than 2 seconds, hint the user that the option
> + `-uno` could be used to stop collecting untracked files.
It looks to me that the way this paragraph conveys information is
vastly different from all the others in the section. The section
begins with "by setting their corresponding variables to false
various advice messages can be squelched; here are the list of
variables and which advice message each of them controls", so the
description should be in "variable:: which advice message" form.
The noise this introduces to the test suite is a bit irritating and
makes us think twice if this really a good change.
> diff --git a/wt-status.c b/wt-status.c
> index ef405d0..6fde08b 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -540,7 +540,16 @@ void wt_status_collect(struct wt_status *s)
> wt_status_collect_changes_initial(s);
> else
> wt_status_collect_changes_index(s);
> - wt_status_collect_untracked(s);
> + if (s->show_untracked_files && advice_status_uno) {
> + struct timeval tv1, tv2;
> + gettimeofday(&tv1, NULL);
> + wt_status_collect_untracked(s);
> + gettimeofday(&tv2, NULL);
> + s->untracked_in_ms =
> + (uint64_t)tv2.tv_sec * 1000 + tv2.tv_usec / 1000 -
> + ((uint64_t)tv1.tv_sec * 1000 + tv1.tv_usec / 1000);
> + } else
> + wt_status_collect_untracked(s);
> }
This is not wrong per-se but it took me two reads to spot that this
is not "if advise is active, do the timer but do not collect;
otherwise do just collect as before". I wonder if we can structure
the code a bit better to make the timing bit less loud.
> static void wt_status_print_unmerged(struct wt_status *s)
> @@ -1097,6 +1106,15 @@ void wt_status_print(struct wt_status *s)
> wt_status_print_other(s, &s->untracked, _("Untracked files"),
> "add");
> if (s->show_ignored_files)
> wt_status_print_other(s, &s->ignored, _("Ignored
> files"), "add -f");
> + if (advice_status_uno && s->untracked_in_ms > 2000) {
> + status_printf_ln(s, GIT_COLOR_NORMAL,
> + _("It took %.2f seconds to collect
> untracked files."),
> + (float)s->untracked_in_ms / 1000);
> + status_printf_ln(s, GIT_COLOR_NORMAL,
> + _("If it happens often, you may want
> to use option -uno"));
> + status_printf_ln(s, GIT_COLOR_NORMAL,
> + _("to speed up by stopping displaying
> untracked files"));
> + }
"to speed up by stopping displaying untracked files" does not look
like giving a balanced suggestion. It is increasing the risk of
forgetting about newly created files the user may want to add, but
the risk is not properly warned.
I tend to agree that the new advice would help users if phrased in a
right way. Do we want them in COLOR_NORMAL, or do we want to make
them stand out a bit more (do we have COLOR_BLINK ;-)?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] git subtree: properly handle remote refs
One common use-case for git subtree is to use it only on taged commits from the
remote project. however the current implementation of gi-subtree can not be
used in that way. two orthogonal prevent this
the SHA used as the origin revision can be the SHA of a tag which isn't
available locally. This works correctly at merge time but will fail at split
time. The first patch uses the ^{} notation to make sure a correct commit SHA
is used instead of the SHA given as a parameter
the checks for the correctness of the target ref to pull or add checks that the
name matches a local ref (which is incorrect). The second patch use ls-remote
to validate the ref name given against the ones in the remote repository
Jérémy Rosen (2):
git-subtree: make sure the SHA saved as ancestor is a commit
git-subtree: use ls-remote to check the refspec passed to pull and
add
contrib/subtree/git-subtree.sh | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-subtree: make sure the SHA saved as ancestor is a commit
When adding or merging the first parameter might not be a commit, it can also
be a tag SHA.
This needs to be fixed by using the underlying commit or the ancestor finding
code will croak at split time
Signed-off-by: Jérémy Rosen
---
contrib/subtree/git-subtree.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..8b9d114 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -531,7 +531,7 @@ cmd_add_repository()
cmd_add_commit()
{
- revs=$(git rev-parse $default --revs-only "$@") || exit $?
+ revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
set -- $revs
rev="$1"
@@ -655,7 +655,7 @@ cmd_split()
cmd_merge()
{
- revs=$(git rev-parse $default --revs-only "$@") || exit $?
+ revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
ensure_clean
set -- $revs
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] git-subtree: use ls-remote to check the refspec passed to pull and add
ls-remote is the correct way to check that a parameter is a valid fetchable
target
Signed-off-by: Jérémy Rosen
---
contrib/subtree/git-subtree.sh | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8b9d114..61d4eab 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -503,13 +503,8 @@ cmd_add()
"cmd_add_commit" "$@"
elif [ $# -eq 2 ]; then
- # Technically we could accept a refspec here but we're
- # just going to turn around and add FETCH_HEAD under the
- # specified directory. Allowing a refspec might be
- # misleading because we won't do anything with any other
- # branches fetched via the refspec.
- git rev-parse -q --verify "$2^{commit}" >/dev/null ||
- die "'$2' does not refer to a commit"
+ git ls-remote --exit-code "$1" "$2" ||
+ die "'$2' is not a correct reference on '$1'"
"cmd_add_repository" "$@"
else
@@ -700,6 +695,8 @@ cmd_merge()
cmd_pull()
{
ensure_clean
+ git ls-remote --exit-code "$1" "$2" ||
+ die "'$2' is not a correct reference on '$1'"
git fetch "$@" || exit $?
revs=FETCH_HEAD
set -- $revs
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] wt-status: move strbuf into read_and_strip_branch()
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
You do not have anything to say above the S-o-b line? The primary
effect of this patch is to change the lifespan and ownership rule of
the piece of memory used for state.branch/state.onto and moving the
strbuf is a mere logical consequence of that change. It is not
explained why this change is a good idea.
> ---
> wt-status.c | 65
> -
> wt-status.h | 4 ++--
> 2 files changed, 32 insertions(+), 37 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index ef405d0..6cac27b 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -969,41 +969,41 @@ static void show_bisect_in_progress(struct wt_status *s,
> /*
> * Extract branch information from rebase/bisect
> */
> -static void read_and_strip_branch(struct strbuf *sb,
> - const char **branch,
> - const char *path)
> +static char *read_and_strip_branch(const char *path)
> {
> + struct strbuf sb = STRBUF_INIT;
> unsigned char sha1[20];
>
> - strbuf_reset(sb);
> - if (strbuf_read_file(sb, git_path("%s", path), 0) <= 0)
> - return;
> + if (strbuf_read_file(&sb, git_path("%s", path), 0) <= 0)
> + goto got_nothing;
>
> - while (sb->len && sb->buf[sb->len - 1] == '\n')
> - strbuf_setlen(sb, sb->len - 1);
> - if (!sb->len)
> - return;
> - if (!prefixcmp(sb->buf, "refs/heads/"))
> - *branch = sb->buf + strlen("refs/heads/");
> - else if (!prefixcmp(sb->buf, "refs/"))
> - *branch = sb->buf;
> - else if (!get_sha1_hex(sb->buf, sha1)) {
> + while (&sb.len && sb.buf[sb.len - 1] == '\n')
> + strbuf_setlen(&sb, sb.len - 1);
> + if (!sb.len)
> + goto got_nothing;
> + if (!prefixcmp(sb.buf, "refs/heads/"))
> + strbuf_remove(&sb,0, strlen("refs/heads/"));
> + else if (!prefixcmp(sb.buf, "refs/"))
> + ;
> + else if (!get_sha1_hex(sb.buf, sha1)) {
> const char *abbrev;
> abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
> - strbuf_reset(sb);
> - strbuf_addstr(sb, abbrev);
> - *branch = sb->buf;
> - } else if (!strcmp(sb->buf, "detached HEAD")) /* rebase */
> - ;
> + strbuf_reset(&sb);
> + strbuf_addstr(&sb, abbrev);
> + } else if (!strcmp(sb.buf, "detached HEAD")) /* rebase */
> + goto got_nothing;
> else/* bisect */
> - *branch = sb->buf;
> + ;
> + return strbuf_detach(&sb, NULL);
> +
> +got_nothing:
> + strbuf_release(&sb);
> + return NULL;
> }
>
> static void wt_status_print_state(struct wt_status *s)
> {
> const char *state_color = color(WT_STATUS_HEADER, s);
> - struct strbuf branch = STRBUF_INIT;
> - struct strbuf onto = STRBUF_INIT;
> struct wt_status_state state;
> struct stat st;
>
> @@ -1018,27 +1018,22 @@ static void wt_status_print_state(struct wt_status *s)
> state.am_empty_patch = 1;
> } else {
> state.rebase_in_progress = 1;
> - read_and_strip_branch(&branch, &state.branch,
> - "rebase-apply/head-name");
> - read_and_strip_branch(&onto, &state.onto,
> - "rebase-apply/onto");
> + state.branch =
> read_and_strip_branch("rebase-apply/head-name");
> + state.onto = read_and_strip_branch("rebase-apply/onto");
> }
> } else if (!stat(git_path("rebase-merge"), &st)) {
> if (!stat(git_path("rebase-merge/interactive"), &st))
> state.rebase_interactive_in_progress = 1;
> else
> state.rebase_in_progress = 1;
> - read_and_strip_branch(&branch, &state.branch,
> - "rebase-merge/head-name");
> - read_and_strip_branch(&onto, &state.onto,
> - "rebase-merge/onto");
> + state.branch = read_and_strip_branch("rebase-merge/head-name");
> + state.onto = read_and_strip_branch("rebase-merge/onto");
> } else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
> state.cherry_pick_in_progress = 1;
> }
> if (!stat(git_path("BISECT_LOG"), &st)) {
> state.bisect_in_progress = 1;
> - read_and_strip_branch(&branch, &state.branch,
> - "BISECT_START");
> + state.branch = read_and_strip_branch("BISECT_START");
> }
>
> if (state.merge_in_progress)
> @@ -1051,8 +1046,8 @@ static void wt_status_print_state(struct wt_status *s)
> show_cherry_pick_in_pro
Re: [PATCH v3 4/5] status: show more info than "currently not on any branch"
Nguyễn Thái Ngọc Duy writes: > When a remote ref or a tag is checked out, HEAD is automatically > detached. There is no user-friendly way to find out what ref is > checked out in this case. This patch digs in reflog for this > information and shows "HEAD detached from origin/master" or "HEAD > detached at v1.8.0" instead of "currently not on any branch". > > When it cannot figure out the original ref, it shows an abbreviated > SHA-1. "Currently not on any branch" would never display (unless > reflog is pruned to near empty that the last checkout entry is lost). > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- It does look like using the for_each_in_reverse() does make the caller less error prone (by the way, I'd love to see people review, poke holes and plug them in the implementation of reading the reflog file in reverse; I am not sure if it covered all the corner cases right). Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
Junio C Hamano writes: > David Aguilar writes: > >>> The implementation of Junio's suggestion is relatively straightforward >>> (this is untested, although t7800 passes, and can probably be improved >>> by someone better versed in Perl). Does this work for your original >>> scenario? >> >> This is a nice straightforward approach. >> >> As Junio mentioned, a good next step would be this patch in >> combination with making the truly temporary files created by >> dir-diff readonly. > > Even though I agree that the idea Matt McClure mentioned to run a > three-way merge to take the modification back when the path checked > out to the temporary tree as a temporary file (because it does not > match the working tree version) gets edited by the user might be a > better longer-term direction to go, marking the temporaries that the > users should not modify clearly as such needs to be done in the > shorter term. This thread wouldn't have had to happen if we had > such a safety measure in the first place. One thing I forgot to add. I suspect the patch in the thread will not work if the path needs smudge filter and end-of-line conversion, as it seems to just hash-object what is in the working tree (which should be _after_ these transformations) and compare with the object name. The comparison should go the other way around. Try to check out the object with these transformations applied, and compare the resulting file with what is in the working tree. Does the temporary checkout correctly apply the smudge filter and crlf conversion, by the way? If not, regardless of the topic in this thread, that may want to be fixed as well. I didn't check. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-am and CRLF
I recently tried to apply a patch-series to a repo that is unfortunately full of CRLF files, and was a bit surprised that it didn't work at all. So I made a small repro-case, and it seems CRLF new-lines is indeed the problem. Any clue how to fix it? The way I see it, we should simply be able top treat the CR as any other character, and succeed. But that doesn't seem to happen... git init test && ( cd test/ && git config core.autocrlf false && printf "%s\r\n%s\r\n" "foo" "bar" > test.txt && git add test.txt && git commit -m. && printf "%s\r\n%s\r\n%s\r\n" "foo" "baz" "bar" > test.txt && git commit -am. && git format-patch -1 && git reset --hard HEAD^ && git am 0001-.patch ) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Wed, Mar 13, 2013 at 09:45:47AM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > David Aguilar writes: > > > >>> The implementation of Junio's suggestion is relatively straightforward > >>> (this is untested, although t7800 passes, and can probably be improved > >>> by someone better versed in Perl). Does this work for your original > >>> scenario? > >> > >> This is a nice straightforward approach. > >> > >> As Junio mentioned, a good next step would be this patch in > >> combination with making the truly temporary files created by > >> dir-diff readonly. > > > > Even though I agree that the idea Matt McClure mentioned to run a > > three-way merge to take the modification back when the path checked > > out to the temporary tree as a temporary file (because it does not > > match the working tree version) gets edited by the user might be a > > better longer-term direction to go, marking the temporaries that the > > users should not modify clearly as such needs to be done in the > > shorter term. This thread wouldn't have had to happen if we had > > such a safety measure in the first place. > > One thing I forgot to add. I suspect the patch in the thread will > not work if the path needs smudge filter and end-of-line conversion, > as it seems to just hash-object what is in the working tree (which > should be _after_ these transformations) and compare with the object > name. The comparison should go the other way around. Try to check > out the object with these transformations applied, and compare the > resulting file with what is in the working tree. git-hash-object(1) implies that it will apply the clean filter and EOL conversion when it's given a path to a file in the working tree (as it is here). Is that not the case? John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tag peeling peculiarities
Michael Haggerty writes: > It is not > clear to me whether the prohibition of tags outside of refs/tags should > be made more airtight or whether the peeling of tags outside of > refs/tags should be fixed. Retroactively forbidding presense/creation of tags outside the designated refs/tags hierarchy will not fly. I think we should peel them when we are reading from "# pack-refs with: peeled" version. Theoretically, we could introduce "# pack-refs with: fully-peeled" that records peeled versions for _all_ annotated tags even in unusual places, but that would be introducing problems to existing versions of the software to cater to use cases that is not blessed officially, so I doubt it has much value. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
John Keeping writes: > git-hash-object(1) implies that it will apply the clean filter and EOL > conversion when it's given a path to a file in the working tree (as it > is here). Is that not the case? Applying clean to smudged contents _ought to_ recover clean version, but is that "ought to" something you would want to rely on? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-am and CRLF
On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund wrote: > I recently tried to apply a patch-series to a repo that is > unfortunately full of CRLF files, and was a bit surprised that it > didn't work at all. > > So I made a small repro-case, and it seems CRLF new-lines is indeed > the problem. Any clue how to fix it? The way I see it, we should > simply be able top treat the CR as any other character, and succeed. > But that doesn't seem to happen... > > git init test && > ( > cd test/ && > git config core.autocrlf false && > printf "%s\r\n%s\r\n" "foo" "bar" > test.txt && > git add test.txt && > git commit -m. && > printf "%s\r\n%s\r\n%s\r\n" "foo" "baz" "bar" > test.txt && > git commit -am. && > git format-patch -1 && > git reset --hard HEAD^ && > git am 0001-.patch > ) Does 'git am --keep-cr' help? Unfortunately the original information about line ending is lost once a patch is sent via email since RFC2822/822 dictates that the line ending in an email must be crlf. So by default, mailsplit strips it. -Brandon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] t2200: check that "add -u" limits itself to subdirectory
Jeff King writes: > We didn't seem to be testing this transition at all. I think it's sane > to do so now, and Junio's "now it is 2.0, let's switch" patch should > update the test. Yes, but I am not sure if this is testing the right thing. > +# Note that this is scheduled to change in Git 2.0, when > +# "git add -u" will become full-tree by default. > +test_expect_success 'update did not touch files at root' ' > + cat >expect <<-\EOF && > + check > + top > + EOF > + git diff-files --name-only >actual && > + test_cmp expect actual > +' The last "git add -u" we have beforet his block is this test piece: test_expect_success 'update from a subdirectory' ' ( cd dir1 && echo more >sub2 && git add -u sub2 ) ' That is not "git add -u" without pathspec, which is the only thing we are transitioning at Git 2.0 boundary. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-am and CRLF
On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey wrote: > On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund wrote: >> I recently tried to apply a patch-series to a repo that is >> unfortunately full of CRLF files, and was a bit surprised that it >> didn't work at all. >> >> So I made a small repro-case, and it seems CRLF new-lines is indeed >> the problem. Any clue how to fix it? The way I see it, we should >> simply be able top treat the CR as any other character, and succeed. >> But that doesn't seem to happen... >> >> git init test && >> ( >> cd test/ && >> git config core.autocrlf false && >> printf "%s\r\n%s\r\n" "foo" "bar" > test.txt && >> git add test.txt && >> git commit -m. && >> printf "%s\r\n%s\r\n%s\r\n" "foo" "baz" "bar" > test.txt && >> git commit -am. && >> git format-patch -1 && >> git reset --hard HEAD^ && >> git am 0001-.patch >> ) > > Does 'git am --keep-cr' help? > It does, how silly of me not to try that before posting. > Unfortunately the original information about line ending is lost once > a patch is sent via email since RFC2822/822 dictates that the line > ending in an email must be crlf. So by default, mailsplit strips it. Hmpf. I didn't transport my patches over e-mail, I simply used git-format-patch/git-am to transfer the patches from one git-svn clone to another. But since that's kind of an "abuse" of git-format-patch/git-am, perhaps just using --keep-cr is the right thing. Thanks anyway :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline
Am 13.03.2013 02:03, schrieb Duy Nguyen: > On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees > wrote: >> Hmmm...I don't see how filesystem changes since last invocation can solve >> the problem, or am I missing something? I think what you mean to say is that >> the daemon should keep track of the filesystem *state* of the working copy, >> or alternatively the deltas/changes to some known state (such as .git/index)? > > I think git process can keep track of filesystem state (and save it > down if necessary). [...] Ah, saving the state was the missing bits, thanks. However, AFAIK inotify doesn't work recursively, so the daemon would at least have to track the directory structure to be able to register / unregister inotify handlers as directories come and go. >> Consider 'git status; make; make clean; git status'...that's a *lot* of >> changes to process for nothing (potentially slowing down make). > > Yeah. In my opinion, the daemon should realize that at some point > accumulated changes are too much that it's not worth collecting > anymore, and drop them all. Git will do it the normal/slow way. After > that the daemon picks up again. We only optimize for the case when > little changes are made in filesystem. > That sounds reasonable... >> Then there's the issue of stale data in the cache. Modifying porcelain >> commands that use 'git status --porcelain' to compile their changesets will >> want 100% exact data. I'm not saying its not doable, but adding another >> platform specific, caching daemon to the tool chain doesn't exactly simplify >> things... >> >> But perhaps I'm too pessimistic (or just stigmatized by inherently slow and >> out-of-date TGitCache/TSvnCache on Windows :-) > > Thanks. I didn't know about TGitCache. Will dig it up. Maybe we can > learn something from it (or realize the daemon approach is futile > after all). > TGitCache/TSvnCache are the background processes in TortoiseGit/TortoiseSvn that keep track of filesystem state to display icon overlays in Windows Explorer. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-p4: support exclusively locked files
By default, newly added binary files are exclusively locked by Perforce:
'add default change (binary+l) *exclusive*'
This results in a 'Could not determine file type' error as the regex
expects
the line to end after the file type matching group. Some repositories are
also configured to always require exclusive locks, so may be a problem for
all revisions in some cases.
Signed-off-by: Danny Thomas
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 0682e61..ffba294 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -326,7 +326,7 @@ def getP4OpenedType(file):
# Returns the perforce file type for the given file.
result = p4_read_pipe(["opened", wildcard_encode(file)])
-match = re.match(".*\((.+)\)\r?$", result)
+match = re.match(".*\((.+)\)(?:.+)?\r?$", result)
if match:
return match.group(1)
else:
--
1.8.1.5
This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended recipient.
If you are not the intended recipient, disclosure, copying, re-distribution or
other use of any of this information is strictly prohibited. Please immediately
notify the sender and delete this transmission if you received this email in
error.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting
Kevin Bracey writes:
> Commit 718135e improved the merge error reporting for the resolve
> strategy's merge conflict and permission conflict cases, but led to a
> malformed "ERROR: in myfile.c" message in the case of a file added
> differently.
>
> This commit reverts that change, and uses an alternative approach without
> this flaw.
>
> Signed-off-by: Kevin Bracey
> ---
> git-merge-one-file.sh | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
> index 0f164e5..78b07a8 100755
> --- a/git-merge-one-file.sh
> +++ b/git-merge-one-file.sh
> @@ -104,11 +104,13 @@ case "${1:-.}${2:-.}${3:-.}" in
> ;;
> esac
>
> + ret=0
> src1=$(git-unpack-file $2)
> src2=$(git-unpack-file $3)
> case "$1" in
> '')
> - echo "Added $4 in both, but differently."
> + echo "ERROR: Added $4 in both, but differently."
> + ret=1
The problem you identified may be worth fixing, but I do not think
this change is correct.
This message is at the same severity level as the message on the
other arm of this case that says "Auto-merging $4". In that other
case arm, we are attempting a true three-way merge, and in this case
arm, we are attempting a similar three-way merge using your "virtual
base".
Neither has found any error in this case arm yet. The messages are
both "informational", not an error. I do not think you would want
to set ret=1 until you see content conflict.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Wed, Mar 13, 2013 at 10:40:55AM -0700, Junio C Hamano wrote: > John Keeping writes: > > > git-hash-object(1) implies that it will apply the clean filter and EOL > > conversion when it's given a path to a file in the working tree (as it > > is here). Is that not the case? > > Applying clean to smudged contents _ought to_ recover clean version, > but is that "ought to" something you would want to rely on? How does git-status figure out that file that has been touch'd does not have unstaged changes without relying on this? Surely this case is no different from that? John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rename conflicts in the index
Edward Thomson writes: > I would propose that we store the data about the file in conflict as it > occurred through the renames. For example, in a rename 1->2 conflict where > A was renamed to both B and C, you would have a single conflict entry > containing the data for A, B and C. This would allow us to provide more > detailed information to the user - and allow them to (say) choose a single > name to proceed with. > > Is this something that has value to core git as well? Alternately, is > there something particularly stupid about this proposal? I do not offhand see anything particularly stupid; a new optional index extension section CACHE_EXT_RENAME_CONFLICT might be a good addition. Is "one side moves A to B while the other side moves it to C" the only case, or is it just an example? Off the top of my head, "one side moves A to x while the other side moves B to x/y" would also be something we would want to know. I am sure there are other cases that need to be considered. I do not think we can discuss the design at the concrete level until the proposal spells out to cover all interesting cases in order for implementations to agree on the common semantics. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
John Keeping writes: > On Wed, Mar 13, 2013 at 10:40:55AM -0700, Junio C Hamano wrote: >> John Keeping writes: >> >> > git-hash-object(1) implies that it will apply the clean filter and EOL >> > conversion when it's given a path to a file in the working tree (as it >> > is here). Is that not the case? >> >> Applying clean to smudged contents _ought to_ recover clean version, >> but is that "ought to" something you would want to rely on? > > How does git-status figure out that file that has been touch'd does not > have unstaged changes without relying on this? Surely this case is no > different from that? I just checked. ce_modified_check_fs() does ce_compare_data() which does the same "hash the path and compare the resulting hash". So I think we are OK. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline
Karsten Blees writes: > However, AFAIK inotify doesn't work recursively, so the daemon > would at least have to track the directory structure to be able to > register / unregister inotify handlers as directories come and go. Yes, and you would need one inotify per directory but you do not have an infinite supply of outstanding inotify watch (wasn't the limit like 8k per a single uid or something?), so the daemon must be prepared to say "I'll watch this, that and that directories, but the consumers should check other directories themselves." FWIW, I share your suspicion that an effort in the direction this thread suggests may end up duplicating what the caching vfs layer already does, and doing so poorly. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Deletion of git repo causes incorrect block count on HFS+ case-sensitive
Hello, When I delete a git repo that I have cloned on my machine using 'rm -rf repo-name' I get an incorrect block count when I attempt a Disk Repair. I am running OS X 10.8.2 on a user installed SSD. The git version is 1.8.1.5. Checking file systemChecking Journaled HFS Plus volume. Detected a case-sensitive volume. Checking extents overflow file. Checking catalog file. Incorrect block count for file pack-8c0dc1a398a22c58ea1eba09de3ee9d935ad1ea3.pack (It should be 4865 instead of 12244) Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack (It should be 5889 instead of 12245) Incorrect block count for file pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack (It should be 6220 instead of 12245) Incorrect block count for file pack-286c1444bc32ee2ed0af1d15070e0e31f22ba0a8.pack (It should be 7937 instead of 12246) Checking multi-linked files. Checking catalog hierarchy. Checking extended attributes file. Checking volume bitmap. Volume bitmap needs minor repair for orphaned blocks Checking volume information. Invalid volume free block count (It should be 85306183 instead of 85282114) Repairing volume. Rechecking volume. Checking Journaled HFS Plus volume. Detected a case-sensitive volume. Checking extents overflow file. Checking catalog file. Checking multi-linked files. Checking catalog hierarchy. Checking extended attributes file. Checking volume bitmap. Checking volume information. The volume avicenna was repaired successfully. Volume repair complete.Updating boot support partitions for the volume as required. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.2
The latest feature release Git v1.8.2 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 42960ec7c2d8404af3d3f6d21f32f1e97e6e0a96 git-1.8.2.tar.gz db1ca968f492f7ad1d4e0c13d07f23c745d10b74 git-htmldocs-1.8.2.tar.gz a10083a2a1fe6b35919fd6765f25dec18f4fa752 git-manpages-1.8.2.tar.gz Also the following public repositories all have a copy of the v1.8.2 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.2 Release Notes Backward compatibility notes (this release) --- "git push $there tag v1.2.3" used to allow replacing a tag v1.2.3 that already exists in the repository $there, if the rewritten tag you are pushing points at a commit that is a descendant of a commit that the old tag v1.2.3 points at. This was found to be error prone and starting with this release, any attempt to update an existing ref under refs/tags/ hierarchy will fail, without "--force". When "git add -u" and "git add -A" that does not specify what paths to add on the command line is run from inside a subdirectory, the scope of the operation has always been limited to the subdirectory. Many users found this counter-intuitive, given that "git commit -a" and other commands operate on the entire tree regardless of where you are. In this release, these commands give a warning message that suggests the users to use "git add -u/-A ." when they want to limit the scope to the current directory; doing so will squelch the message, while training their fingers. Backward compatibility notes (for Git 2.0) -- When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the "simple" semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable "push.default" to change this. If you are an old-timer who is used to the "matching" semantics, you can set it to "matching" to keep the traditional behaviour. If you want to live in the future early, you can set it to "simple" today without waiting for Git 2.0. When "git add -u" and "git add -A", that does not specify what paths to add on the command line is run from inside a subdirectory, these commands will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. Because there will be no mechanism to make "git add -u" behave as if "git add -u .", it is important for those who are used to "git add -u" (without pathspec) updating the index only for paths in the current subdirectory to start training their fingers to explicitly say "git add -u ." when they mean it before Git 2.0 comes. Updates since v1.8.1 UI, Workflows & Features * Initial ports to QNX and z/OS UNIX System Services have started. * Output from the tests is coloured using "green is okay, yellow is questionable, red is bad and blue is informative" scheme. * Mention of "GIT/Git/git" in the documentation have been updated to be more uniform and consistent. The name of the system and the concept it embodies is "Git"; the command the users type is "git". All-caps "GIT" was merely a way to imitate "Git" typeset in small caps in our ASCII text only documentation and to be avoided. * The completion script (in contrib/completion) used to let the default completer to suggest pathnames, which gave too many irrelevant choices (e.g. "git add" would not want to add an unmodified path). It learnt to use a more git-aware logic to enumerate only relevant ones. * In bare repositories, "git shortlog" and other commands now read mailmap files from the tip of the history, to help running these tools in server settings. * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the "--format=" option of "git log" and friends can be disabled when the output is not sent to a terminal by prefixing them with "auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)". * Scripts can ask Git that wildcard patterns in pathspecs they give do not have any significance, i.e. take them as literal strings. * The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory. E.g. "foo/**/bar" matches "bar" in "foo" itself or in a subdirectory of "f
A note from the maintainer
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address . You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/?p=git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits. The last such
release was 1.8.2 done on Mar 13, 2013. You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.1.5. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When yo
What's cooking in git.git (Mar 2013, #04; Wed, 13)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the master is at v1.8.2. We have already many topics
lined up for the next cycle, so after a few days to calm down, we
will see exciting changes on 'master' starting from next week.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* ph/tag-force-no-warn-on-creation (2013-03-13) 1 commit
- tag: --force does not have to warn when creating tags
Will cook in 'next'.
--
[Stalled]
* po/help-guides (2013-03-03) 5 commits
- help doc: include --guide option description
- help.c: add list_common_guides_help() function
- help.c: add --guide option
- help.c: use OPT_COUNTUP
- show 'git help ' usage, with examples
Give more visibility to "concept guides" to help "git help" users.
Expecting a reroll.
$gmane/217384
* hv/config-from-strbuf (2013-03-10) 4 commits
- teach config parsing to read from strbuf
- config: make parsing stack struct independent from actual data source
- config: drop file pointer validity check in get_next_char()
- config: factor out config file stack management
Expecting a reroll.
$gmane/217811
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--
[Cooking]
* nd/branch-show-rebase-bisect-state (2013-03-13) 6 commits
- branch: show more information when HEAD is detached
- status: show more info than "currently not on any branch"
- wt-status: move wt_status_get_state() out to wt_status_print()
- wt-status: split wt_status_state parsing function out
- wt-status: move strbuf into read_and_strip_branch()
- Merge branch 'jc/reflog-reverse-walk' into nd/branch-show-rebase-bisect-state
(this branch uses jc/reflog-reverse-walk.)
The changes look sound, but some patches need better description.
* kb/p4merge (2013-03-13) 2 commits
- mergetools/p4merge: create a base if none available
- mergetools/p4merge: swap LOCAL and REMOTE
Looked reasonable.
Will merge to 'next'.
* jc/maint-push-refspec-default-doc (2013-03-08) 1 commit
- Documentation/git-push: clarify the description of defaults
Clarify in the documentation "what" gets pushed to "where" when the
command line to "git push" does not say these explicitly.
Will merge to 'next'.
* jc/reflog-reverse-walk (2013-03-08) 3 commits
- reflog: add for_each_reflog_ent_reverse() API
- for_each_recent_reflog_ent(): simplify opening of a reflog file
- for_each_reflog_ent(): extract a helper to process a single entry
(this branch is used by nd/branch-show-rebase-bisect-state.)
An internal function used to implement "git checkout @{-1}" was
hard to use correctly.
Will merge to 'next'.
* jk/alias-in-bare (2013-03-08) 3 commits
(merged to 'next' on 2013-03-09 at 2f9d72a)
+ setup: suppress implicit "." work-tree for bare repos
+ environment: add GIT_PREFIX to local_repo_env
+ cache.h: drop LOCAL_REPO_ENV_SIZE
An aliased command spawned from a bare repository that does not say
it is bare with "core.bare = yes" is treated as non-bare by mistake.
Will cook in 'next'.
* pw/p4-symlinked-root (2013-03-11) 3 commits
(merged to 'next' on 2013-03-12 at 559b926)
+ git p4: avoid expanding client paths in chdir
+ git p4 test: should honor symlink in p4 client root
+ git p4 test: make sure P4CONFIG relative path works
Will cook in 'next'.
* jc/add-2.0-delete-default (2013-03-08) 3 commits
- git add ... defaults to "-A"
- git add: start preparing for "git add ..." to default to "-A"
- builtin/add.c: simplify boolean variables
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
There seemed to be some interest in this topic, so resurrected and
rebased on top of recent documentation updates to propose a
possible transition plan.
Will merge to and cook in 'next' until G
[PATCH 0/2] difftool --dir-diff: symlink all files matching the working tree
Here's the proper patch. It grew into a series because I noticed a minor formatting error in the difftool documentation, which the first commit fixes. The content of the second patch is the same as was previously posted. John Keeping (2): git-difftool(1): fix formatting of --symlink description difftool --dir-diff: symlink all files matching the working tree Documentation/git-difftool.txt | 8 +--- git-difftool.perl | 21 ++--- t/t7800-difftool.sh| 14 ++ 3 files changed, 37 insertions(+), 6 deletions(-) -- 1.8.2.rc2.4.g7799588 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-difftool(1): fix formatting of --symlink description
Signed-off-by: John Keeping --- Documentation/git-difftool.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index e0e12e9..e575fea 100644 --- a/Documentation/git-difftool.txt +++ b/Documentation/git-difftool.txt @@ -74,8 +74,8 @@ with custom merge tool commands and has the same value as `$MERGED`. 'git difftool''s default behavior is create symlinks to the working tree when run in `--dir-diff` mode. + - Specifying `--no-symlinks` instructs 'git difftool' to create - copies instead. `--no-symlinks` is the default on Windows. +Specifying `--no-symlinks` instructs 'git difftool' to create copies +instead. `--no-symlinks` is the default on Windows. -x :: --extcmd=:: -- 1.8.2.rc2.4.g7799588 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] difftool --dir-diff: symlink all files matching the working tree
Some users like to edit files in their diff tool when using "git
difftool --dir-diff --symlink" to compare against the working tree but
difftool currently only created symlinks when a file contains unstaged
changes.
Change this behaviour so that symlinks are created whenever the
right-hand side of the comparison has the same SHA1 as the file in the
working tree.
Note that textconv filters are handled in the same way as by git-diff
and if a clean filter is not the inverse of its smudge filter we already
get a null SHA1 from "diff --raw" and will symlink the file without
going through the new hash-object based check.
Reported-by: Matt McClure
Signed-off-by: John Keeping
---
Documentation/git-difftool.txt | 4 +++-
git-difftool.perl | 21 ++---
t/t7800-difftool.sh| 14 ++
3 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index e575fea..8361e6e 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -72,7 +72,9 @@ with custom merge tool commands and has the same value as
`$MERGED`.
--symlinks::
--no-symlinks::
'git difftool''s default behavior is create symlinks to the
- working tree when run in `--dir-diff` mode.
+ working tree when run in `--dir-diff` mode and the right-hand
+ side of the comparison yields the same content as the file in
+ the working tree.
+
Specifying `--no-symlinks` instructs 'git difftool' to create copies
instead. `--no-symlinks` is the default on Windows.
diff --git a/git-difftool.perl b/git-difftool.perl
index 0a90de4..5f093ae 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -83,6 +83,21 @@ sub exit_cleanup
exit($status | ($status >> 8));
}
+sub use_wt_file
+{
+ my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
+ my $null_sha1 = '0' x 40;
+
+ if ($sha1 eq $null_sha1) {
+ return 1;
+ } elsif (not $symlinks) {
+ return 0;
+ }
+
+ my $wt_sha1 = $repo->command_oneline('hash-object', "$workdir/$file");
+ return $sha1 eq $wt_sha1;
+}
+
sub setup_dir_diff
{
my ($repo, $workdir, $symlinks) = @_;
@@ -159,10 +174,10 @@ EOF
}
if ($rmode ne $null_mode) {
- if ($rsha1 ne $null_sha1) {
- $rindex .= "$rmode $rsha1\t$dst_path\0";
- } else {
+ if (use_wt_file($repo, $workdir, $dst_path, $rsha1,
$symlinks)) {
push(@working_tree, $dst_path);
+ } else {
+ $rindex .= "$rmode $rsha1\t$dst_path\0";
}
}
}
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index eb1d3f8..8102ce1 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -370,6 +370,20 @@ test_expect_success PERL 'difftool --dir-diff' '
echo "$diff" | stdin_contains file
'
+write_script .git/CHECK_SYMLINKS <<\EOF &&
+#!/bin/sh
+test -L "$2/file" &&
+test -L "$2/file2" &&
+test -L "$2/sub/sub"
+echo $?
+EOF
+
+test_expect_success PERL,SYMLINKS 'difftool --dir-diff --symlink without
unstaged changes' '
+ result=$(git difftool --dir-diff --symlink \
+ --extcmd "./.git/CHECK_SYMLINKS" branch HEAD) &&
+ test "$result" = 0
+'
+
test_expect_success PERL 'difftool --dir-diff ignores --prompt' '
diff=$(git difftool --dir-diff --prompt --extcmd ls branch) &&
echo "$diff" | stdin_contains sub &&
--
1.8.2.rc2.4.g7799588
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Rename conflicts in the index
Junio C Hamano [mailto:gits...@pobox.com] wrote: > I do not offhand see anything particularly stupid; a new optional index > extension > section CACHE_EXT_RENAME_CONFLICT might be a good addition. > > Is "one side moves A to B while the other side moves it to C" the only case, > or is > it just an example? Off the top of my head, "one side moves A to x while the > other side moves B to x/y" would also be something we would want to know. I > am sure there are other cases that need to be considered. Yes, that was just an example. Certainly I was intending that all conflicts that arose from renames would end up here since one can't really reason why the merge tool created a conflict by looking at the index alone - even knowing the merge tool's similarity algorithms, this would be awfully expensive to piece back together, even if the index did contain non-zero stage entries for all the items that were involved in the conflicts. That said, my rather naive initial thought was that we could repeat *all* conflicts in this area. This would give tools that knew how to understand this the ability to go to a single place for conflict data, rather than producing some merge of high-stage entries that comprise non-rename conflicts and data from the rename conflict area for rename conflicts. Thanks- -ed -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Allow combined diff to ignore white-spaces
Currently, it's not possible to use the space-ignoring options (-b, -w,
--ignore-space-at-eol) with combined diff. It makes it pretty impossible
to read a merge between a branch that changed all tabs to spaces, and a
branch with functional changes.
Pass diff flags to diff engine, so that combined diff behaves as normal
diff does with spaces.
Also coalesce lines that are removed from both (or more) parents.
It also means that a conflict-less merge done using a ignore-* strategy
option will not show any conflict if shown in combined-diff using the
same option.
Signed-off-by: Antoine Pelisse
---
OK, I added some tests and coalesce similar lost lines (using the same flags
we used for diff.
combine-diff.c | 57 ++-
t/t4038-diff-combined.sh | 75 ++
2 files changed, 125 insertions(+), 7 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 35d41cd..0f33983 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -5,6 +5,7 @@
#include "diffcore.h"
#include "quote.h"
#include "xdiff-interface.h"
+#include "xdiff/xmacros.h"
#include "log-tree.h"
#include "refs.h"
#include "userdiff.h"
@@ -122,7 +123,47 @@ static char *grab_blob(const unsigned char *sha1, unsigned
int mode,
return blob;
}
-static void append_lost(struct sline *sline, int n, const char *line, int len)
+static int match_string_spaces(const char *line1, int len1,
+ const char *line2, int len2,
+ long flags)
+{
+ if (flags & XDF_WHITESPACE_FLAGS) {
+ for (; len1 > 0 && XDL_ISSPACE(line1[len1 - 1]); len1--);
+ for (; len2 > 0 && XDL_ISSPACE(line2[len2 - 1]); len2--);
+ }
+
+ if (!(flags & (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE)))
+ return (len1 == len2 && !memcmp(line1, line2, len1));
+
+ while (len1 > 0 && len2 > 0) {
+ len1--;
+ len2--;
+ if (XDL_ISSPACE(line1[len1]) || XDL_ISSPACE(line2[len2])) {
+ if ((flags & XDF_IGNORE_WHITESPACE_CHANGE) &&
+ (!XDL_ISSPACE(line1[len1]) ||
!XDL_ISSPACE(line2[len2])))
+ return 0;
+
+ for (; len1 > 0 && XDL_ISSPACE(line1[len1]); len1--);
+ for (; len2 > 0 && XDL_ISSPACE(line2[len2]); len2--);
+ }
+ if (line1[len1] != line2[len2])
+ return 0;
+ }
+
+ if (flags & XDF_IGNORE_WHITESPACE) {
+ // Consume remaining spaces
+ for (; len1 > 0 && XDL_ISSPACE(line1[len1 - 1]); len1--);
+ for (; len2 > 0 && XDL_ISSPACE(line2[len2 - 1]); len2--);
+ }
+
+ // We matched full line1 and line2
+ if (!len1 && !len2)
+ return 1;
+
+ return 0;
+}
+
+static void append_lost(struct sline *sline, int n, const char *line, int len,
long flags)
{
struct lline *lline;
unsigned long this_mask = (1ULnext_lost;
while (lline) {
- if (lline->len == len &&
- !memcmp(lline->line, line, len)) {
+ if (match_string_spaces(lline->line, lline->len,
+ line, len, flags)) {
lline->parent_map |= this_mask;
sline->next_lost = lline->next;
return;
@@ -162,6 +203,7 @@ struct combine_diff_state {
int n;
struct sline *sline;
struct sline *lost_bucket;
+ long flags;
};
static void consume_line(void *state_, char *line, unsigned long len)
@@ -201,7 +243,7 @@ static void consume_line(void *state_, char *line, unsigned
long len)
return; /* not in any hunk yet */
switch (line[0]) {
case '-':
- append_lost(state->lost_bucket, state->n, line+1, len-1);
+ append_lost(state->lost_bucket, state->n, line+1, len-1,
state->flags);
break;
case '+':
state->sline[state->lno-1].flag |= state->nmask;
@@ -215,7 +257,7 @@ static void combine_diff(const unsigned char *parent,
unsigned int mode,
struct sline *sline, unsigned int cnt, int n,
int num_parent, int result_deleted,
struct userdiff_driver *textconv,
-const char *path)
+const char *path, long flags)
{
unsigned int p_lno, lno;
unsigned long nmask = (1UL << n);
@@ -231,9 +273,10 @@ static void combine_diff(const unsigned char *parent,
unsigned int mode,
parent_file.ptr = grab_blob(parent, mode, &sz, textconv, path);
parent_file.size = sz;
memset(&xpp, 0, sizeof(xpp));
- xpp.flags = 0;
+
Re: Tag peeling peculiarities
On Wed, Mar 13, 2013 at 10:29:54AM -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > It is not
> > clear to me whether the prohibition of tags outside of refs/tags should
> > be made more airtight or whether the peeling of tags outside of
> > refs/tags should be fixed.
>
> Retroactively forbidding presense/creation of tags outside the
> designated refs/tags hierarchy will not fly. I think we should peel
> them when we are reading from "# pack-refs with: peeled" version.
>
> Theoretically, we could introduce "# pack-refs with: fully-peeled"
> that records peeled versions for _all_ annotated tags even in
> unusual places, but that would be introducing problems to existing
> versions of the software to cater to use cases that is not blessed
> officially, so I doubt it has much value.
I agree. The REF_KNOWS_PEELED thing is an optimization, so it's OK to
simply omit the optimization in the corner case, since we don't expect
it to happen often. So what happens now is a bug, but it is a bug in the
reader that mis-applies the optimization, and we can just fix the
reader.
I do not think there is any point in peeling while we are reading the
pack-refs file; it is no more expensive to do so later, and in most
cases we will not even bother peeling. We should simply omit the
REF_KNOWS_PEELED bit so that later calls to peel_ref do not follow the
optimization code path. Something like this:
diff --git a/refs.c b/refs.c
index 175b9fc..ee498c8 100644
--- a/refs.c
+++ b/refs.c
@@ -824,7 +824,10 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
refname = parse_ref_line(refline, sha1);
if (refname) {
- last = create_ref_entry(refname, sha1, flag, 1);
+ int this_flag = flag;
+ if (prefixcmp(refname, "refs/tags/"))
+ this_flag &= ~REF_KNOWS_PEELED;
+ last = create_ref_entry(refname, sha1, this_flag, 1);
add_ref(dir, last);
continue;
}
I think with this patch, though, that upload-pack would end up having to
read the object type of everything under refs/heads to decide whether it
needs to be peeled (and in most cases, it does not, making the initial
ref advertisement potentially much more expensive). How do we want to
handle that? Should we teach upload-pack not to bother advertising peels
outside of refs/tags? That would break people who expect tag
auto-following to work for refs outside of refs/tags, but I am not sure
that is a sane thing to expect.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Deletion of git repo causes incorrect block count on HFS+ case-sensitive
On Wed, Mar 13, 2013 at 11:45 AM, Ismail Tabtabai wrote: > Hello, > > When I delete a git repo that I have cloned on my machine using 'rm -rf > repo-name' I get an incorrect block count when I attempt a Disk Repair. > > I am running OS X 10.8.2 on a user installed SSD. The git version is 1.8.1.5. This is not a git issue. I would recommend inspecting your hardware; this could be a disk going bad. There's not much git can do to fix a broken HFS+ filesystem or faulty hardware. If anything, it's an HFS+ / Apple bug, though that is less likely than a bad disk. If you haven't already, you should probably start doing backups. I hope that helps. > Checking file systemChecking Journaled HFS Plus volume. > Detected a case-sensitive volume. > Checking extents overflow file. > Checking catalog file. > Incorrect block count for file > pack-8c0dc1a398a22c58ea1eba09de3ee9d935ad1ea3.pack > (It should be 4865 instead of 12244) > Incorrect block count for file > pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack > (It should be 5889 instead of 12245) > Incorrect block count for file > pack-db61a037ad0e043e801d8ba1db98b1af14d466af.pack > (It should be 6220 instead of 12245) > Incorrect block count for file > pack-286c1444bc32ee2ed0af1d15070e0e31f22ba0a8.pack > (It should be 7937 instead of 12246) > Checking multi-linked files. > Checking catalog hierarchy. > Checking extended attributes file. > Checking volume bitmap. > Volume bitmap needs minor repair for orphaned blocks > Checking volume information. > Invalid volume free block count > (It should be 85306183 instead of 85282114) > Repairing volume. > Rechecking volume. > Checking Journaled HFS Plus volume. > Detected a case-sensitive volume. > Checking extents overflow file. > Checking catalog file. > Checking multi-linked files. > Checking catalog hierarchy. > Checking extended attributes file. > Checking volume bitmap. > Checking volume information. > The volume avicenna was repaired successfully. > Volume repair complete.Updating boot support partitions for the volume as > required. It looks like it repaired itself. bad blocks? -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestion for difftool behaviour during a merge conflict
On Wed, Mar 13, 2013 at 11:48 AM, Øystein Walle wrote: > When a merge is ongoing and there are conflicts, 'git difftool' will > output the exact same --cc-style diff output as 'git diff' will without > further explanation. This has lead to some confusion: A couple of weeks > ago a person asked on #git why his difftool wasn't working. After a long > while we realized difftool's behaviour after invocations such as 'git > difftool HEAD~ HEAD' would work as expected but 'git difftool' "simply > wouldn't". > > With that in mind I have three suggestions on improving 'git difftool': > > - Show a three-way diff between the versions (local, remote, merge) >using the user's configured difftool. Diffing against the version >containing the markers will generate some extra noise in the difftool >and might be confusing, but it's similar in behaviour to how 'git >difftool' normally works. > > - Prompt the user if they want to launch 'git mergetool' instead since >a merge is ongoing. Reasonable but it might be awkward if the user is >asked whether the conflict was resolved or not when all they wanted >to do was to visually diff something. > > - Add a notice to stderr saying that a --cc-style diff output is shown >instead; or document the behaviour in the man page. Definitely the >simplest option. > > I'm willing to try to take a stab at either of these but I wanted to > bring it up first. There is of course an implicit fourth option which is > to do nothing, and that I'm wrong about this :) Thanks for bringing this up. I think the simplest first step would be to detect this state, print a message saying that difftool cannot be used during a merge, and suggest mergetool instead. We would need to be careful to still allow difftool and only trigger this behavior when the cc-style diff would be printed. I have a feeling that this happens deep in git-diff. git-difftool--helper is driven by git-diff via the GIT_EXTERNAL_DIFF mechanism, and that mechanism is probably not triggered when in this state, so we may need to add another breadcrumb that we can build upon. > Best regards, > Øystein Walle cheers, -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] contrib/subtree: general updates
Less ambitious patch series this time. James and Michael's patches add if clauses that use the bashism 'if []' rather than 'if test'. I've left them as they are to match the other if clauses within the git-subtree.sh file. I remember reading a comment on the list about matching the local style being more important than the overall project's style. I'm happy to change them otherwise. James Roper (1): contrib/subtree: Teach push to use --force option Matt Hoffman (1): contrib/subtree: Replace invisible carriage return with a visible \r Michael Hart (1): contrib/subtree: Teach push to abort if split fails Paul Cartwright (1): contrib/subtree: Fix typo (s/incldued/included/) contrib/subtree/git-subtree.sh | 16 ++-- contrib/subtree/git-subtree.txt | 7 ++- 2 files changed, 20 insertions(+), 3 deletions(-) -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] contrib/subtree: Teach push to abort if split fails
From: Michael Hart If the subtree split fails it doesn't return the SHA that should be pushed to the other repository. Added a check to ensure that split succeeds before trying to push and display an error message. Signed-off-by: Paul Campbell --- contrib/subtree/git-subtree.sh | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 8a23f58..c68cc6f 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -715,7 +715,12 @@ cmd_push() repository=$1 refspec=$2 echo "git push using: " $repository $refspec - git push $repository $(git subtree split --prefix=$prefix):refs/heads/$refspec + rev=$(git subtree split --prefix=$prefix) + if [ -n "$rev" ]; then + git push $repository $rev:refs/heads/$refspec + else + die "Couldn't push, 'git subtree split' failed." + fi else die "'$dir' must already exist. Try 'git subtree add'." fi -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] contrib/subtree: Teach push to use --force option
From: James Roper Allow the --force option to be passed to the child push command. Signed-off-by: Paul Campbell --- contrib/subtree/git-subtree.sh | 9 - contrib/subtree/git-subtree.txt | 5 + 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index c68cc6f..2d9b071 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -26,6 +26,8 @@ b,branch= create a new branch from the split subtree ignore-joins ignore prior --rejoin commits onto= try connecting new tree to an existing one rejoinmerge the new branch back into HEAD + options for 'push' +f,force use force push options for 'add', 'merge', 'pull' and 'push' squashmerge subtree changes as a single commit " @@ -84,6 +86,7 @@ while [ $# -gt 0 ]; do -b) branch="$1"; shift ;; -P) prefix="$1"; shift ;; -m) message="$1"; shift ;; + -f|--force) force=1 ;; --no-prefix) prefix= ;; --onto) onto="$1"; shift ;; --no-onto) onto= ;; @@ -712,12 +715,16 @@ cmd_push() die "You must provide " fi if [ -e "$dir" ]; then + push_opts= + if [ "$force" == "1" ]; then + push_opts="$push_opts --force" + fi repository=$1 refspec=$2 echo "git push using: " $repository $refspec rev=$(git subtree split --prefix=$prefix) if [ -n "$rev" ]; then - git push $repository $rev:refs/heads/$refspec + git push $push_opts $repository $rev:refs/heads/$refspec else die "Couldn't push, 'git subtree split' failed." fi diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index 7ba853e..97dd3c9 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -255,6 +255,11 @@ OPTIONS FOR split '--rejoin' when you split, because you don't want the subproject's history to be part of your project anyway. +OPTIONS FOR push + +-f:: +--force:: +Uses 'git push --force'. EXAMPLE 1. Add command -- -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] contrib/subtree: Fix typo (s/incldued/included/)
From: Paul Cartwright Signed-off-by: Paul Campbell --- contrib/subtree/git-subtree.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index 97dd3c9..e1bfa61 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -275,7 +275,7 @@ git-extensions repository in ~/git-extensions/: name You can omit the --squash flag, but doing so will increase the number -of commits that are incldued in your local repository. +of commits that are included in your local repository. We now have a ~/git-extensions/git-subtree directory containing code from the master branch of git://github.com/apenwarr/git-subtree.git -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] contrib/subtree: Replace invisible carriage return with a visible \r
From: Matt Hoffman The ctrl-M (^M) character used for the carriage return (CR) is not visible in all (most) text editors and is often silently converted to a new line (NL) or CR/NL combo. 'say' is a wrapper for echo with accepts the option -e to interperet escaped characters. \r becomes a CR, yet is not munged by text editors. Signed-off-by: Paul Campbell Conflicts: git-subtree.sh --- contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 2d9b071..5314bd0 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -595,7 +595,7 @@ cmd_split() eval "$grl" | while read rev parents; do revcount=$(($revcount + 1)) - say -n "$revcount/$revmax ($createcount) " + say -ne "$revcount/$revmax ($createcount)\r" debug "Processing commit: $rev" exists=$(cache_get $rev) if [ -n "$exists" ]; then -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] contrib/subtree: Replace invisible carriage return with a visible \r
On Wed, Mar 13, 2013 at 10:32 PM, Paul Campbell wrote: > From: Matt Hoffman > > The ctrl-M (^M) character used for the carriage return (CR) is not visible > in all (most) text editors and is often silently converted to a new > line (NL) or CR/NL combo. > > 'say' is a wrapper for echo with accepts the option -e to interperet > escaped characters. \r becomes a CR, yet is not munged by text > editors. > > Signed-off-by: Paul Campbell > > Conflicts: > git-subtree.sh Oops. Meant to replace this Conflict line. > --- > contrib/subtree/git-subtree.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh > index 2d9b071..5314bd0 100755 > --- a/contrib/subtree/git-subtree.sh > +++ b/contrib/subtree/git-subtree.sh > @@ -595,7 +595,7 @@ cmd_split() > eval "$grl" | > while read rev parents; do > revcount=$(($revcount + 1)) > - say -n "$revcount/$revmax ($createcount) > " > + say -ne "$revcount/$revmax ($createcount)\r" > debug "Processing commit: $rev" > exists=$(cache_get $rev) > if [ -n "$exists" ]; then > -- > 1.8.2 > -- Paul [W] Campbell -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] contrib/subtree: Replace invisible carriage return with a visible \r
From: Matt Hoffman The ctrl-M (^M) character used for the carriage return (CR) is not visible in all (most) text editors and is often silently converted to a new line (NL) or CR/NL combo. 'say' is a wrapper for echo with accepts the option -e to interperet escaped characters. \r becomes a CR, yet is not munged by text editors. Signed-off-by: Paul Campbell --- Rerolled with the Conflicts lines removed. contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 2d9b071..5314bd0 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -595,7 +595,7 @@ cmd_split() eval "$grl" | while read rev parents; do revcount=$(($revcount + 1)) - say -n "$revcount/$revmax ($createcount) " + say -ne "$revcount/$revmax ($createcount)\r" debug "Processing commit: $rev" exists=$(cache_get $rev) if [ -n "$exists" ]; then -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow combined diff to ignore white-spaces
Antoine Pelisse writes:
> Currently, it's not possible to use the space-ignoring options (-b, -w,
> --ignore-space-at-eol) with combined diff. It makes it pretty impossible
> to read a merge between a branch that changed all tabs to spaces, and a
> branch with functional changes.
>
> Pass diff flags to diff engine, so that combined diff behaves as normal
> diff does with spaces.
> Also coalesce lines that are removed from both (or more) parents.
>
> It also means that a conflict-less merge done using a ignore-* strategy
> option will not show any conflict if shown in combined-diff using the
> same option.
>
> Signed-off-by: Antoine Pelisse
> ---
> OK, I added some tests and coalesce similar lost lines (using the same flags
> we used for diff.
>
> combine-diff.c | 57 ++-
> t/t4038-diff-combined.sh | 75
> ++
> 2 files changed, 125 insertions(+), 7 deletions(-)
>
> diff --git a/combine-diff.c b/combine-diff.c
> index 35d41cd..0f33983 100644
> --- a/combine-diff.c
> +++ b/combine-diff.c
> @@ -5,6 +5,7 @@
> #include "diffcore.h"
> #include "quote.h"
> #include "xdiff-interface.h"
> +#include "xdiff/xmacros.h"
> #include "log-tree.h"
> #include "refs.h"
> #include "userdiff.h"
> @@ -122,7 +123,47 @@ static char *grab_blob(const unsigned char *sha1,
> unsigned int mode,
> return blob;
> }
>
> -static void append_lost(struct sline *sline, int n, const char *line, int
> len)
> +static int match_string_spaces(const char *line1, int len1,
> +const char *line2, int len2,
> +long flags)
> +{
> + if (flags & XDF_WHITESPACE_FLAGS) {
> + for (; len1 > 0 && XDL_ISSPACE(line1[len1 - 1]); len1--);
> + for (; len2 > 0 && XDL_ISSPACE(line2[len2 - 1]); len2--);
> + }
This says "any XDF_WHITESPACE_FLAGS causes the trailing blanks
ignored", which is correct: --ignore-space-at-eol, -b or -w are all
we have. OK.
> + if (!(flags & (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE)))
> + return (len1 == len2 && !memcmp(line1, line2, len1));
If --ignore-space-at-eol is the only one given, or none of the
whitespace flags is given, then we can just do memcmp(). OK.
The remainder of the function is only used when either -b or -w is
(or both are) in effect.
> + while (len1 > 0 && len2 > 0) {
> + len1--;
> + len2--;
Scanning from the tail end of the strings...
> + if (XDL_ISSPACE(line1[len1]) || XDL_ISSPACE(line2[len2])) {
> + if ((flags & XDF_IGNORE_WHITESPACE_CHANGE) &&
> + (!XDL_ISSPACE(line1[len1]) ||
> !XDL_ISSPACE(line2[len2])))
> + return 0;
If --ignore-space-change and one side is blank while the other not,
then these cannot be the same. If we see blank on both sides, that
is fine under --ignore-whitespace, too.
> + for (; len1 > 0 && XDL_ISSPACE(line1[len1]); len1--);
> + for (; len2 > 0 && XDL_ISSPACE(line2[len2]); len2--);
Then, strip the blanks, if any, so that the next comparison is done
for the last non-blank char from both sides. OK.
> + }
> + if (line1[len1] != line2[len2])
> + return 0;
And we can say "not same" as soon as we find differences. Rinse
and repeat.
> + }
> +
> + if (flags & XDF_IGNORE_WHITESPACE) {
> + // Consume remaining spaces
No C++/C99 comments in our codebase, please.
> + for (; len1 > 0 && XDL_ISSPACE(line1[len1 - 1]); len1--);
> + for (; len2 > 0 && XDL_ISSPACE(line2[len2 - 1]); len2--);
If we are ignoring all whitespaces, we can simply discard them. OK.
I wonder what happens when --ignore-space-change is in effect but
not --ignore-all-space? The loop must have exited because one (or
both) of len1 and len2 went down to zero. If both are zero, we
obviously have a match, and otherwise, one has blanks at the
beginning and the other does not. Wait, is that really true? Yes,
because if len1 == 0 && len2 != 0, line2[len2] cannot be blank
(otherwise len2 would be zero because we have a loop to eat a run of
blanks).
OK, sounds good.
> + }
> +
> + // We matched full line1 and line2
Likewise for "//".
> + if (!len1 && !len2)
> + return 1;
> +
> + return 0;
> +}
> +static void append_lost(struct sline *sline, int n, const char *line, int
> len, long flags)
> {
> struct lline *lline;
> unsigned long this_mask = (1UL< @@ -133,8 +174,8 @@ static void append_lost(struct sline *sline, int n, const
> char *line, int len)
> if (sline->lost_head) {
> lline = sline->next_lost;
> while (lline) {
> - if (lline->len == len &&
> - !memcmp(lline->line, line, len)) {
> + if (match_string_spaces(lline->lin
Re: [PATCH] Allow combined diff to ignore white-spaces
Antoine Pelisse writes: > OK, I added some tests and coalesce similar lost lines (using the same flags > we used for diff. Hmph, why doesn't this pass its own tests? > +test_expect_success 'check combined output (no ignore space)' ' > + git show | test_i18ngrep "^-\s*eol spaces" && What kind of grep pattern is "\s*"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANN] git-arr 0.11
Hi! I wanted to let you know about git-arr, which is a git repository browser that can generate static HTML instead of having to run dynamically. It is smaller, with less features and a different set of tradeoffs than gitweb or cgit, but if you have a reduced environment, the static generation can be useful. You can find more details on http://blitiri.com.ar/p/git-arr/, and see an example of the generated output at http://blitiri.com.ar/git/. It's written in Python, uses the Bottle web framework, and is open source under the MIT licence. Please note it's new and there are still some rough edges that I obviously intend to fix, but it's been working fine for my use cases, so all feedback is welcome :) Thanks a lot! Alberto -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
binPHkdTDR1Av.bin Description: iso-8859-1
[PATCH] setup.c: Remove duplicate code from prefix_pathspec()
Only check for ',' explicitly and handle both ')' and '\0' in the else
branch. strcspn() can only return ',', ')' and '\0' at this point so the
new code is completely equivalent to what we had before.
This also fixes following GCC warning:
setup.c: In function ‘get_pathspec’:
setup.c:207:8: warning: ‘nextat’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
setup.c:205:15: note: ‘nextat’ was declared here
Signed-off-by: Lukas Fleischer
---
This removes the only warning that currently occurs when building the
next branch.
Junio: Feel free to squash this into Andrew's patch (805da4dee15b,
"setup.c: stop prefix_pathspec() from looping past the end of string").
setup.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/setup.c b/setup.c
index d2335a8..94c1e61 100644
--- a/setup.c
+++ b/setup.c
@@ -207,12 +207,11 @@ static const char *prefix_pathspec(const char *prefix,
int prefixlen, const char
*copyfrom && *copyfrom != ')';
copyfrom = nextat) {
size_t len = strcspn(copyfrom, ",)");
- if (copyfrom[len] == '\0')
- nextat = copyfrom + len;
- else if (copyfrom[len] == ')')
- nextat = copyfrom + len;
- else if (copyfrom[len] == ',')
+ if (copyfrom[len] == ',')
nextat = copyfrom + len + 1;
+ else
+ /* handle ')' and '\0' */
+ nextat = copyfrom + len;
if (!len)
continue;
for (i = 0; i < ARRAY_SIZE(pathspec_magic); i++)
--
1.8.2.rc2.352.g908df73
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] contrib/subtree: general updates
Paul Campbell writes: > James and Michael's patches add if clauses that use the > bashism 'if []' rather than 'if test'. "Bashism"...? I dunno how portable is, but "[" is an old unix alias for "test" ... it certainly predates bash... -miles -- Occam's razor split hairs so well, I bought the whole argument! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] contrib/subtree: general updates
Miles Bader writes: > Paul Campbell writes: >> James and Michael's patches add if clauses that use the >> bashism 'if []' rather than 'if test'. > > "Bashism"...? I dunno how portable is, but "[" is an old unix alias > for "test" ... it certainly predates bash... Correct. [[ ... ]] is new and spelling out "test" indeed is more traditionalist than [ ... ], but for contrib/subtree/ that does not work with anything but bash, I do not think such a rewrite has much merit in the first place. Being consistently "bash script" (as opposed to being old-style) is more appropriate for it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] difftool --dir-diff: symlink all files matching the working tree
On Wed, Mar 13, 2013 at 1:33 PM, John Keeping wrote:
> Some users like to edit files in their diff tool when using "git
> difftool --dir-diff --symlink" to compare against the working tree but
> difftool currently only created symlinks when a file contains unstaged
> changes.
>
> Change this behaviour so that symlinks are created whenever the
> right-hand side of the comparison has the same SHA1 as the file in the
> working tree.
>
> Note that textconv filters are handled in the same way as by git-diff
> and if a clean filter is not the inverse of its smudge filter we already
> get a null SHA1 from "diff --raw" and will symlink the file without
> going through the new hash-object based check.
>
> Reported-by: Matt McClure
> Signed-off-by: John Keeping
> ---
> Documentation/git-difftool.txt | 4 +++-
> git-difftool.perl | 21 ++---
> t/t7800-difftool.sh| 14 ++
> 3 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
> index e575fea..8361e6e 100644
> --- a/Documentation/git-difftool.txt
> +++ b/Documentation/git-difftool.txt
> @@ -72,7 +72,9 @@ with custom merge tool commands and has the same value as
> `$MERGED`.
> --symlinks::
> --no-symlinks::
> 'git difftool''s default behavior is create symlinks to the
> - working tree when run in `--dir-diff` mode.
> + working tree when run in `--dir-diff` mode and the right-hand
> + side of the comparison yields the same content as the file in
> + the working tree.
> +
> Specifying `--no-symlinks` instructs 'git difftool' to create copies
> instead. `--no-symlinks` is the default on Windows.
> diff --git a/git-difftool.perl b/git-difftool.perl
> index 0a90de4..5f093ae 100755
> --- a/git-difftool.perl
> +++ b/git-difftool.perl
> @@ -83,6 +83,21 @@ sub exit_cleanup
> exit($status | ($status >> 8));
> }
>
> +sub use_wt_file
> +{
> + my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
> + my $null_sha1 = '0' x 40;
> +
> + if ($sha1 eq $null_sha1) {
> + return 1;
> + } elsif (not $symlinks) {
> + return 0;
> + }
> +
> + my $wt_sha1 = $repo->command_oneline('hash-object', "$workdir/$file");
> + return $sha1 eq $wt_sha1;
> +}
> +
> sub setup_dir_diff
> {
> my ($repo, $workdir, $symlinks) = @_;
> @@ -159,10 +174,10 @@ EOF
> }
>
> if ($rmode ne $null_mode) {
> - if ($rsha1 ne $null_sha1) {
> - $rindex .= "$rmode $rsha1\t$dst_path\0";
> - } else {
> + if (use_wt_file($repo, $workdir, $dst_path, $rsha1,
> $symlinks)) {
> push(@working_tree, $dst_path);
> + } else {
> + $rindex .= "$rmode $rsha1\t$dst_path\0";
> }
> }
> }
> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
> index eb1d3f8..8102ce1 100755
> --- a/t/t7800-difftool.sh
> +++ b/t/t7800-difftool.sh
> @@ -370,6 +370,20 @@ test_expect_success PERL 'difftool --dir-diff' '
> echo "$diff" | stdin_contains file
> '
>
> +write_script .git/CHECK_SYMLINKS <<\EOF &&
Tiny nit. Is there any downside to leaving this file
at the root instead of inside the .git dir?
> +#!/bin/sh
> +test -L "$2/file" &&
> +test -L "$2/file2" &&
> +test -L "$2/sub/sub"
> +echo $?
> +EOF
> +
> +test_expect_success PERL,SYMLINKS 'difftool --dir-diff --symlink without
> unstaged changes' '
> + result=$(git difftool --dir-diff --symlink \
> + --extcmd "./.git/CHECK_SYMLINKS" branch HEAD) &&
> + test "$result" = 0
> +'
> +
How about something like this?
+ echo 0 >expect &&
+ git difftool --dir-diff --symlink \
+ --extcmd ./CHECK_SYMLINKS branch HEAD >actual &&
+ test_cmp expect actual
(sans gmail whitespace damage) so that we can keep it chained with &&.
Ah.. it seems your branch is based on master, perhaps?
There's stuff cooking in next for difftool's tests.
I'm not sure if this patch is based on top of them.
Can you rebase the tests so that the chaining is done like it is in 'next'?
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tag peeling peculiarities
On 03/13/2013 10:58 PM, Jeff King wrote:
> On Wed, Mar 13, 2013 at 10:29:54AM -0700, Junio C Hamano wrote:
>
>> Michael Haggerty writes:
>>
>>> It is not
>>> clear to me whether the prohibition of tags outside of refs/tags should
>>> be made more airtight or whether the peeling of tags outside of
>>> refs/tags should be fixed.
>>
>> Retroactively forbidding presense/creation of tags outside the
>> designated refs/tags hierarchy will not fly. I think we should peel
>> them when we are reading from "# pack-refs with: peeled" version.
>>
>> Theoretically, we could introduce "# pack-refs with: fully-peeled"
>> that records peeled versions for _all_ annotated tags even in
>> unusual places, but that would be introducing problems to existing
>> versions of the software to cater to use cases that is not blessed
>> officially, so I doubt it has much value.
I think that instead of changing "peeled" to "fully-peeled", it would be
better to add "fully-peeled" as an additional keyword, like
# pack-refs with: peeled fully-peeled
Old readers would still see the "peeled" keyword and ignore the
fully-peeled keyword, and would be able to read the file correctly. See
below for more discussion.
> I agree. The REF_KNOWS_PEELED thing is an optimization, so it's OK to
> simply omit the optimization in the corner case, since we don't expect
> it to happen often. So what happens now is a bug, but it is a bug in the
> reader that mis-applies the optimization, and we can just fix the
> reader.
>
> I do not think there is any point in peeling while we are reading the
> pack-refs file; it is no more expensive to do so later, and in most
> cases we will not even bother peeling. We should simply omit the
> REF_KNOWS_PEELED bit so that later calls to peel_ref do not follow the
> optimization code path. Something like this:
>
> diff --git a/refs.c b/refs.c
> index 175b9fc..ee498c8 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -824,7 +824,10 @@ static void read_packed_refs(FILE *f, struct ref_dir
> *dir)
>
> refname = parse_ref_line(refline, sha1);
> if (refname) {
> - last = create_ref_entry(refname, sha1, flag, 1);
> + int this_flag = flag;
> + if (prefixcmp(refname, "refs/tags/"))
> + this_flag &= ~REF_KNOWS_PEELED;
> + last = create_ref_entry(refname, sha1, this_flag, 1);
> add_ref(dir, last);
> continue;
> }
It would also be possible to set the REF_KNOWS_PEELED for any entries
for which a peeled reference happens to be present in the packed-refs
file, though the code would never be triggered if the current writer is
not changed.
> I think with this patch, though, that upload-pack would end up having to
> read the object type of everything under refs/heads to decide whether it
> needs to be peeled (and in most cases, it does not, making the initial
> ref advertisement potentially much more expensive). How do we want to
> handle that? Should we teach upload-pack not to bother advertising peels
> outside of refs/tags? That would break people who expect tag
> auto-following to work for refs outside of refs/tags, but I am not sure
> that is a sane thing to expect.
Here is analysis of our options as I see them:
1. Accept that tags outside of refs/tags are not reliably advertised in
their peeled form. Document this deficiency and either:
a. Don't even bother trying to peel refs outside of refs/tags (the
status quo).
b. Change the pack-refs writer to write all peeled refs, but leave
the reader unchanged. This is a low-risk option that would cause
old and new clients to do the right thing when reading a full
packed-refs file, but an old or new client reading a non-full
packed-refs file would not realize that it is non-full and would
fail to advertise all peeled refs. Minor disadvantage: pack-refs
becomes slower.
2. Insist that tags outside of refs/tags are reliably advertised. I
see three ways to do it:
a. Without changing the packed-refs contents. This would require
upload-pack to read *all* references outside of refs/tags. (This
is what Peff's patch does.)
b. Write all peeled refs to packed-refs without changing the
packed-refs header. This would hardly help, as upload-pack
would still have to read all non-tag references outside of
refs/tags to be sure that none are tags.
c. Add a new keyword to the top of the packed-refs file as
described above. Then
* Old writer, new reader: the reader would know that some
peeled refs might be missing. upload-pack would have to
resolve refs outside of refs/tags, but could optionally write
a new-format packed-refs file to avoid repeating the work.
* New writer, new reader: the reader would know that all refs
are peeled properly and would not
Re: Tag peeling peculiarities
On Thu, Mar 14, 2013 at 05:41:58AM +0100, Michael Haggerty wrote: > Here is analysis of our options as I see them: > > 1. Accept that tags outside of refs/tags are not reliably advertised in >their peeled form. Document this deficiency and either: > >a. Don't even bother trying to peel refs outside of refs/tags (the > status quo). When you say "not reliably advertised" you mean from upload-pack, right? What about other callers? From my reading of peel_ref, anybody who calls it to get a packed ref may actually get a wrong answer. So this is not just about tag auto-following over fetch, but about other places, too (however, a quick grep does not make it look like this other places are all that commonly used). Another fun fact: upload-pack did not use peel_ref until recently (435c833, in v1.8.1). So while it is tempting to say "well, this was always broken, and nobody cared", it was not really; it is a fairly recent regression in 435c833. >b. Change the pack-refs writer to write all peeled refs, but leave > the reader unchanged. This is a low-risk option that would cause > old and new clients to do the right thing when reading a full > packed-refs file, but an old or new client reading a non-full > packed-refs file would not realize that it is non-full and would > fail to advertise all peeled refs. Minor disadvantage: pack-refs > becomes slower. This seems sane. The missing thing is a flag to tell the reader that it was written by a newer version; I see you dealt with that case below. I don't think pack-refs being a little bit slower matters. Checking the types to peel is not even that much work; it's just that it adds up when you do it for every no-op fetch's ref advertisement. But we can assume that writing happens a lot less than reading; that is the point of storing the peeled information in the first place. If that assumption is not correct in some scenario, then those people should probably not be packing their refs at all, so I think we can discount them from this discussion. > 2. Insist that tags outside of refs/tags are reliably advertised. I >see three ways to do it: > >a. Without changing the packed-refs contents. This would require > upload-pack to read *all* references outside of refs/tags. (This > is what Peff's patch does.) FWIW, this is what upload-pack used to do before I switched it to use peel_ref. The savings are measurable, though they are not ground-breaking. Still, I think your "fully-packed" proposal above lets us keep the improvement without too much effort. >b. Write all peeled refs to packed-refs without changing the > packed-refs header. This would hardly help, as upload-pack > would still have to read all non-tag references outside of > refs/tags to be sure that none are tags. Right, this seems silly; the new reader does extra work for compatibility with an older writer, but the normal case is to use the same version. The obvious optimization is to add a flag that says "hey, I was written by a new writer". And that is your "fully-packed" proposal, covered below. >c. Add a new keyword to the top of the packed-refs file as > described above. Then > > * Old writer, new reader: the reader would know that some > peeled refs might be missing. upload-pack would have to > resolve refs outside of refs/tags, but could optionally write > a new-format packed-refs file to avoid repeating the work. I think that is OK. For the most part, this is a temporary situation that happens when you are moving from an older to a newer version of git. If you are switching back and forth between versions, then we are correct, but you don't get the benefit of the micro-optimization, which seems fair. > * New writer, new reader: the reader would know that all refs > are peeled properly and would not have to read any objects. This is the common case I think we should be optimizing for. And obviously the outcome here is good. It's also fine without adding the "fully-packed" flag, though. > * Old writer, old reader: status quo; peeled refs are advertised > incompletely. Right. We can't fix those without a time machine, though. > * New writer, old reader: This is the interesting case. The > current code in Git would read the header and see "peeled" but > ignore "fully-peeled". But the line-reading code would > nevertheless happily read and record peeled references no > matter what namespace they live in. It would also advertise > them correctly. One would have to check historical versions > and other clients to see whether they would also behave well. Right. So we have pretty sane backwards-compatible behavior. I think if other implementations are not happy seeing a new tag, they are wrong. The whole point of the "#"-tags is for future expansion. Looking over libgit
Re: Tag peeling peculiarities
On Thu, Mar 14, 2013 at 01:24:48AM -0400, Jeff King wrote:
> So the only question is how much work we want to put into making sure
> the new reader handles the old writer correctly. Doing 2c is obviously
> more rigorous, and it is not that much work to add the fully-packed
> flag, but I kind of wonder if anybody even cares. We can just say "it's
> a bug fix; run `git pack-refs` again if you care" and call it a day
> (i.e., 1b).
Urgh, for some reason I kept writing "fully-packed" but obviously I
meant "fully-peeled". Hopefully you figured it out.
Just as a quick sketch of how much work is in involved in 2c, I think
the complete solution would look like this (but note I haven't tested
this at all):
diff --git a/pack-refs.c b/pack-refs.c
index f09a054..261a6a6 100644
--- a/pack-refs.c
+++ b/pack-refs.c
@@ -27,6 +27,7 @@ static int handle_one_ref(const char *path, const unsigned
char *sha1,
int flags, void *cb_data)
{
struct pack_refs_cb_data *cb = cb_data;
+ struct object *o;
int is_tag_ref;
/* Do not pack the symbolic refs */
@@ -39,14 +40,12 @@ static int handle_one_ref(const char *path, const unsigned
char *sha1,
return 0;
fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
- if (is_tag_ref) {
- struct object *o = parse_object(sha1);
- if (o->type == OBJ_TAG) {
- o = deref_tag(o, path, 0);
- if (o)
- fprintf(cb->refs_file, "^%s\n",
- sha1_to_hex(o->sha1));
- }
+ o = parse_object(sha1);
+ if (o->type == OBJ_TAG) {
+ o = deref_tag(o, path, 0);
+ if (o)
+ fprintf(cb->refs_file, "^%s\n",
+ sha1_to_hex(o->sha1));
}
if ((cb->flags & PACK_REFS_PRUNE) && !do_not_prune(flags)) {
@@ -128,7 +127,7 @@ int pack_refs(unsigned int flags)
die_errno("unable to create ref-pack file structure");
/* perhaps other traits later as well */
- fprintf(cbdata.refs_file, "# pack-refs with: peeled \n");
+ fprintf(cbdata.refs_file, "# pack-refs with: peeled fully-peeled \n");
for_each_ref(handle_one_ref, &cbdata);
if (ferror(cbdata.refs_file))
diff --git a/refs.c b/refs.c
index 175b9fc..770abf4 100644
--- a/refs.c
+++ b/refs.c
@@ -808,6 +808,7 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
struct ref_entry *last = NULL;
char refline[PATH_MAX];
int flag = REF_ISPACKED;
+ int fully_peeled = 0;
while (fgets(refline, sizeof(refline), f)) {
unsigned char sha1[20];
@@ -818,13 +819,18 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
const char *traits = refline + sizeof(header) - 1;
if (strstr(traits, " peeled "))
flag |= REF_KNOWS_PEELED;
+ if (strstr(traits, " fully-peeled "))
+ fully_peeled = 1;
/* perhaps other traits later as well */
continue;
}
refname = parse_ref_line(refline, sha1);
if (refname) {
- last = create_ref_entry(refname, sha1, flag, 1);
+ int this_flag = flag;
+ if (!fully_peeled && prefixcmp(refname, "refs/tags/"))
+ this_flag &= ~REF_KNOWS_PEELED;
+ last = create_ref_entry(refname, sha1, this_flag, 1);
add_ref(dir, last);
continue;
}
So it's really not that much code. The bigger question is whether we
want to have to carry the "fully-peeled" tag forever, and how other
implementations would treat it.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting
On 13/03/2013 19:57, Junio C Hamano wrote: Kevin Bracey writes: - echo "Added $4 in both, but differently." + echo "ERROR: Added $4 in both, but differently." + ret=1 The problem you identified may be worth fixing, but I do not think this change is correct. This message is at the same severity level as the message on the other arm of this case that says "Auto-merging $4". In that other case arm, we are attempting a true three-way merge, and in this case arm, we are attempting a similar three-way merge using your "virtual base". Neither has found any error in this case arm yet. The messages are both "informational", not an error. I do not think you would want to set ret=1 until you see content conflict. I disagree here. At the minute, it does set ret to 1 (but further down the code - bringing it up here next to the "ERROR" print clarifies that), and will report the merge as failed, conflict in the 3-way merge or not. Which I think is correct. We have to stop for user inspection here. We do have a fake base; we can't trust the 3-way merge with it. The virtual 3-way merge will take ABCDE and ABDE and produce ABCDE without conflict. That's flat wrong if the real base they failed to tell Git about was ABCDE. Despite being useful, I'm still slightly uncomfortable that it can produce something without any conflict markers. The user really needs to look at properly. (And one interesting related glitch, or at least thing that puzzled me when it happened. This is from memory, so may be slightly mistaken, but what seemed to happen was that if you have rerere enabled, then mergetool tends to say "nothing to merge", because it relies on "rerere remaining", which relies on conflict markers. I think you could still force a mergetool up by specifying the specific file though.) Maybe the virtual base itself should be different. Maybe it should put a ??? marker in place of every unique line. So you get: Left ABCEFGH Right XABCDEFJH -> Merge result <|X>ABC<|D>EFH VBase ?ABC?EF??H That actually feels like it may be the correct answer here. And it's effectively what P4Merge does in its "2-way" mode I failed to invoke. (At least for the result view). Kevin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From 59fb432e17a1aae9de26bbaaca7f09cc7f03b471 Mon Sep 17 00:00:00 2001
From: Eric Cousineau
Date: Thu, 14 Mar 2013 01:19:53 -0500
Subject: [PATCH] submodule-foreach: Added in --post-order= per Jens
Lehmann's suggestion
Signed-off-by: Eric Cousineau
---
Made the scope of the patch only relate to --post-order.
Would we want to rename this to just --post= ?
Anywho, here it is running in a test setup, where the structure is:
a
- b
- - d
- c
$ git submodule foreach --recursive --post-order 'echo Post $name' 'echo
Pre $path'
Entering 'b'
Pre b
Entering 'b/d'
Pre d
Entering 'b/d'
Post d
Entering 'b'
Post b
Entering 'c'
Pre c
Entering 'c'
Post c
An interesting note is that it fails with 'git submodule foreach
--post-order', but not 'git submodule foreach --post-order=', since it
simply interprets that as an empty command.
If that is important, I could add in a check for $# when parsing the
argument for --post-order=*.
git-submodule.sh | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..9b70bc2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -10,7 +10,7 @@ USAGE="[--quiet] add [-b ] [-f|--force]
[--name ] [--reference
or: $dashless [--quiet] init [--] [...]
or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference ] [--merge]
[--recursive] [--] [...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit
] [commit] [--] [...]
- or: $dashless [--quiet] foreach [--recursive]
+ or: $dashless [--quiet] foreach [--recursive]
[--post-order=]
or: $dashless [--quiet] sync [--recursive] [--] [...]"
OPTIONS_SPEC=
. git-sh-setup
@@ -434,6 +434,8 @@ Use -f if you really want to add it." >&2
cmd_foreach()
{
# parse $args after "submodule ... foreach".
+# Gratuitous (empty) local's to prevent recursive bleeding
+local recursive= post_order=
while test $# -ne 0
do
case "$1" in
@@ -443,6 +445,15 @@ cmd_foreach()
--recursive)
recursive=1
;;
+--post-order)
+test "$#" = "1" && usage
+post_order="$2"
+shift
+;;
+--post-order=*)
+# Will skip empty commands
+post_order=${1#*=}
+;;
-*)
usage
;;
@@ -453,7 +464,7 @@ cmd_foreach()
shift
done
-toplevel=$(pwd)
+local toplevel=$(pwd)
# dup stdin so that it can be restored when running the external
# command in the subshell (and a recursive call to this function)
@@ -465,18 +476,36 @@ cmd_foreach()
die_if_unmatched "$mode"
if test -e "$sm_path"/.git
then
-say "$(eval_gettext "Entering '\$prefix\$sm_path'")"
+local name prefix path message epitaph
+message="$(eval_gettext "Entering '\$prefix\$sm_path'")"
+epitaph="$(eval_gettext "Stopping at '\$sm_path'; script
returned non-zero status.")"
name=$(module_name "$sm_path")
(
prefix="$prefix$sm_path/"
clear_local_git_env
# we make $path available to scripts ...
path=$sm_path
+
+sm_eval() {
+say "$message"
+eval "$@" || die "$epitaph"
+}
+
cd "$sm_path" &&
-eval "$@" &&
+sm_eval "$@" &&
if test -n "$recursive"
then
-cmd_foreach "--recursive" "$@"
+if test -n "$post_order"
+then
+# Tried keeping flags as a variable, but was
having difficulty
+cmd_foreach --recursive --post-order
"$post_order" "$@"
+else
+cmd_foreach --recursive "$@"
+fi
+fi &&
+if test -n "$post_order"
+then
+sm_eval "$post_order"
fi
) <&3 3<&- ||
die "$(eval_gettext "Stopping at '\$sm_path'; script
returned non-zero status.")"
--
1.8.2.rc1.24.g06d67b8.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] config: factor out config file stack management
On Tue, Mar 12, 2013 at 03:04:56PM -0400, Jeff King wrote: > On Tue, Mar 12, 2013 at 04:44:35PM +0100, Heiko Voigt wrote: > > > > Can we throw in a comment at the top here with the expected usage? In > > > particular, do_config_from is expecting the caller to have filled in > > > certain fields (at this point, top->f and top->name), but there is > > > nothing to make that clear. > > > > Of course. Will do that in the next iteration. How about I squash this in: > > [...] > > +/* The fields data, name and the source specific callbacks of top need > > + * to be initialized before calling this function. > > + */ > > static int do_config_from_source(struct config_source *top, config_fn_t > > fn, voi > > I think that is OK, but it may be even better to list the fields by > name. Also, our multi-line comment style is: > > /* >* Multi-line comment. >*/ Ok will do both. > > I would add that to the third patch: > > > > config: make parsing stack struct independent from actual data source > > > > because that contains the final modification to config_file/config_source. > > It does not matter to the end result, but I find it helps with reviewing > when the comment is added along with the function, and then expanded as > the function is changed. It helps to understand the effects of later > patches if they need to tweak comments. To make the series more clear to others who read it later, I will add the comment from the beginning. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] teach config parsing to read from strbuf
On Tue, Mar 12, 2013 at 03:29:59PM -0400, Jeff King wrote: > On Tue, Mar 12, 2013 at 05:42:54PM +0100, Heiko Voigt wrote: > > > > Your series does not actually add any callers of the new function. The > > > obvious "patch 5/4" would be to plumb it into "git config --blob", and > > > then we can just directly test it there (there could be other callers > > > besides reading from a blob, of course, but I think the point of the > > > series is to head in that direction). > > > > Since this is a split of the series mentioned above there are no real > > callers yet. The main reason for the split was that I wanted to reduce > > the review burden of one big series into multiple reviews of smaller > > chunks. If you think it is useful to add the --blob option I can also > > test from there. It could actually be useful to look at certain > > .gitmodules options from the submodule script. > > I am on the fence. I do not want to create more work for you, but I do > think it may come in handy, if only for doing submodule things from > shell. And it is hopefully not a very large patch. I'd say try it, and > if starts looking like it will be very ugly, the right thing may be to > leave it until somebody really wants it. Thats what I will do: Try it and see where I get. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] t2200: check that "add -u" limits itself to subdirectory
On Wed, Mar 13, 2013 at 10:44:25AM -0700, Junio C Hamano wrote: > > +# Note that this is scheduled to change in Git 2.0, when > > +# "git add -u" will become full-tree by default. > > +test_expect_success 'update did not touch files at root' ' > > + cat >expect <<-\EOF && > > + check > > + top > > + EOF > > + git diff-files --name-only >actual && > > + test_cmp expect actual > > +' > > The last "git add -u" we have beforet his block is this test piece: > > test_expect_success 'update from a subdirectory' ' > ( > cd dir1 && > echo more >sub2 && > git add -u sub2 > ) > ' > > That is not "git add -u" without pathspec, which is the only thing > we are transitioning at Git 2.0 boundary. Oops, you're right. I just saw the "cd" and totally missed the pathspec. The correct test should be: -- >8 -- Subject: [PATCH] t2200: check that "add -u" limits itself to subdirectory This behavior is due to change in the future, but let's test it anyway. That helps make sure we do not accidentally switch the behavior too soon while we are working in the area, and it means that we can easily verify the change when we do make it. Signed-off-by: Jeff King --- t/t2200-add-update.sh | 16 1 file changed, 16 insertions(+) diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh index 4cdebda..c317254 100755 --- a/t/t2200-add-update.sh +++ b/t/t2200-add-update.sh @@ -80,6 +80,22 @@ test_expect_success 'change gets noticed' ' ' +# Note that this is scheduled to change in Git 2.0, when +# "git add -u" will become full-tree by default. +test_expect_success 'non-limited update in subdir leaves root alone' ' + ( + cd dir1 && + echo even more >>sub2 && + git add -u + ) && + cat >expect <<-\EOF && + check + top + EOF + git diff-files --name-only >actual && + test_cmp expect actual +' + test_expect_success SYMLINKS 'replace a file with a symlink' ' rm foo && -- 1.8.2.rc2.7.gef06216 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
