tiffany jewellery can be mastered immediately

[nuatureiod]

tiffany jewellery http://www.buytiffanyandcostore.co.uk   possesses
currently employed brand names you'll find singular person in be anxious in
addition to build a a lot of unique a number of earrings just as usual
sterling silver armlet to help sterling silver necklaces earrings. For
anyone who is contemplating having that distinct artisan Tiffany ornaments
then you definately certainly will probably cellular phone intended for in
order to develop many electric power from the search intended for specialist
Tiffany below wholesale necklaces provides. There are various models of gems
in your really encourage, in contrast it truly is delicate to get a finest
matched 1. anyone of the most extremely strong ornaments get there absent
having quite a few different types in addition to things to do.

http://www.buytiffanyandcostore.co.uk/



--
View this message in context: 
http://git.661346.n2.nabble.com/tiffany-jewellery-can-be-mastered-immediately-tp7579572.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

Many Pandora sale can be found

[meifeiwur]

[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

[Thomas Rast]

Junio C Hamano gits...@pobox.com writes:

 Junio C Hamano gits...@pobox.com writes:

 Thomas Rast tr...@student.ethz.ch 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 '-Lbegin,$'.

 Doesn't -L begin or -L begin, 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

[David Aguilar]

On Tue, Mar 12, 2013 at 5:17 PM, John Keeping j...@keeping.me.uk 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 gits...@pobox.com wrote:

  Matt McClure matthewlmccl...@gmail.com 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

[Matthieu Moy]

Jeff King p...@peff.net 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]

[direkte Finanzierung]

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

[David Aguilar]

On Tue, Mar 12, 2013 at 6:12 PM, Kevin Bracey ke...@bracey.fi 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 ke...@bracey.fi
 ---

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

[Matthieu Moy]

Jeff King p...@peff.net 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

[John Keeping]

On Tue, Mar 12, 2013 at 08:26:21PM -0400, Matt McClure wrote:
 On Tue, Mar 12, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk 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

[Michael J Gruber]

Phil Hord venit, vidit, dixit 13.03.2013 05:21:
 On Tue, Mar 12, 2013 at 11:33 PM, Junio C Hamano gits...@pobox.com wrote:
 Phil Hord ho...@cisco.com 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 ho...@cisco.com
 ---

 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

[Jeff King]

On Wed, Mar 13, 2013 at 10:07:34AM +0100, Matthieu Moy wrote:

 Jeff King p...@peff.net 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

[Nguyễn Thái Ngọc Duy]

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()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 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
@@ -79,8 +79,8 @@ struct wt_status_state {
int 

[PATCH v3 2/5] wt-status: split wt_status_state parsing function out

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 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()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
 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

[Nguyễn Thái Ngọc Duy]

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 pclo...@gmail.com
---
 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 currently splitting a commit while rebasing branch 
'\''split_commit'\'' on '\''$ONTO'\''.
#   (Once 

[PATCH v3 5/5] branch: show more information when HEAD is detached

[Nguyễn Thái Ngọc Duy]

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 pclo...@gmail.com
---
 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 EOF 
+* (detached from $(git rev-parse --short HEAD^0))
   branch-one
   branch-two
   master
 EOF
-test_expect_success 'git branch shows detached HEAD properly' '
git checkout HEAD^0 
git branch actual 
test_i18ncmp expect actual
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..9b6f0d0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing 
.git/BISECT_START not modified if
cp .git/BISECT_START saved 
test_must_fail git bisect start $HASH4 foo -- 
git branch  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

[Nguyễn Thái Ngọc Duy]

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 pclo...@gmail.com
---
 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 21
) 
@@ -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 21
) 
@@ -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 conflicts 
test_commit on_master main.txt on_master 
diff --git 

Rename conflicts in the index

[Edward Thomson]

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

[Michael Haggerty]

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

[Torsten Bögershausen]

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 pclo...@gmail.com
 ---
  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

[Matt McClure]

On Wed, Mar 13, 2013 at 4:24 AM, David Aguilar dav...@gmail.com 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 matthewlmccl...@gmail.com
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] commit [--] [path...]
This form is to view the changes you have in your working tree
relative to the named commit. 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 j...@keeping.me.uk

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

[Junio C Hamano]

David Aguilar dav...@gmail.com 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

[Michael Haggerty]

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

[Junio C Hamano]

Jeff King p...@peff.net 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

[John Keeping]

On Wed, Mar 13, 2013 at 11:21:40AM -0400, Matt McClure wrote:
 On Wed, Mar 13, 2013 at 4:24 AM, David Aguilar dav...@gmail.com 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 matthewlmccl...@gmail.com
 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] commit [--] [path...]
 This form is to view the changes you have in your working tree
 relative to the named commit. 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 j...@keeping.me.uk

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 j...@keeping.me.uk 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

[Junio C Hamano]

Thomas Rast tr...@inf.ethz.ch 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

[Junio C Hamano]

Nguyễn Thái Ngọc Duy  pclo...@gmail.com 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

[Jérémy Rosen]

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

[Jérémy Rosen]

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 jeremy.ro...@openwide.fr
---
 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

[Jérémy Rosen]

ls-remote is the correct way to check that a parameter is a valid fetchable 
target


Signed-off-by: Jérémy Rosen jeremy.ro...@openwide.fr
---
 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()

[Junio C Hamano]

Nguyễn Thái Ngọc Duy  pclo...@gmail.com writes:

 Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com

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_progress(s, state, state_color);
   if (state.bisect_in_progress)
   show_bisect_in_progress(s, state, state_color);
 - strbuf_release(branch);
 -

Re: [PATCH v3 4/5] status: show more info than currently not on any branch

[Junio C Hamano]

Nguyễn Thái Ngọc Duy  pclo...@gmail.com 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 pclo...@gmail.com
 ---

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]

Junio C Hamano gits...@pobox.com writes:

 David Aguilar dav...@gmail.com 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

[Erik Faye-Lund]

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

[John Keeping]

On Wed, Mar 13, 2013 at 09:45:47AM -0700, Junio C Hamano wrote:
 Junio C Hamano gits...@pobox.com writes:
 
  David Aguilar dav...@gmail.com 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

[Junio C Hamano]

Michael Haggerty mhag...@alum.mit.edu 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

[Junio C Hamano]

John Keeping j...@keeping.me.uk 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

[Brandon Casey]

On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund kusmab...@gmail.com 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

[Junio C Hamano]

Jeff King p...@peff.net 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

[Erik Faye-Lund]

On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey draf...@gmail.com wrote:
 On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund kusmab...@gmail.com 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

[Karsten Blees]

Am 13.03.2013 02:03, schrieb Duy Nguyen:
 On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees karsten.bl...@gmail.com 
 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

[Danny Thomas]

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 dtho...@blackboard.com
---
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

[Junio C Hamano]

Kevin Bracey ke...@bracey.fi 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 ke...@bracey.fi
 ---
  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

[John Keeping]

On Wed, Mar 13, 2013 at 10:40:55AM -0700, Junio C Hamano wrote:
 John Keeping j...@keeping.me.uk 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

[Junio C Hamano]

Edward Thomson ethom...@microsoft.com 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

[Junio C Hamano]

John Keeping j...@keeping.me.uk writes:

 On Wed, Mar 13, 2013 at 10:40:55AM -0700, Junio C Hamano wrote:
 John Keeping j...@keeping.me.uk 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

[Junio C Hamano]

Karsten Blees karsten.bl...@gmail.com 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

[Ismail Tabtabai]

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

[Junio C Hamano]

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 foo.

 * When giving arguments without -- disambiguation, object names
   

A note from the maintainer

[Junio C Hamano]

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 git@vger.kernel.org.  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 you send a

What's cooking in git.git (Mar 2013, #04; Wed, 13)

[Junio C Hamano]

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 guide' 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 pathspec... defaults to -A
 - git add: start preparing for git add pathspec... 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 Git 2.0.


* 

[PATCH 0/2] difftool --dir-diff: symlink all files matching the working tree

[John Keeping]

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

[John Keeping]

Signed-off-by: John Keeping j...@keeping.me.uk
---
 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 command::
 --extcmd=command::
-- 
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

[John Keeping]

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 matthewlmccl...@gmail.com
Signed-off-by: John Keeping j...@keeping.me.uk
---
 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

[Edward Thomson]

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

[Antoine Pelisse]

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 apeli...@gmail.com
---
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 = (1ULn);
@@ -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-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 

Re: Tag peeling peculiarities

[Jeff King]

On Wed, Mar 13, 2013 at 10:29:54AM -0700, Junio C Hamano wrote:

 Michael Haggerty mhag...@alum.mit.edu 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

[David Aguilar]

On Wed, Mar 13, 2013 at 11:45 AM, Ismail Tabtabai itabta...@me.com 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

[David Aguilar]

On Wed, Mar 13, 2013 at 11:48 AM, Øystein Walle oys...@gmail.com 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 ref ref
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

[Paul Campbell]

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

[Paul Campbell]

From: Michael Hart mich...@adslot.com

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 pcampb...@kemitix.net
---
 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

[Paul Campbell]

From: James Roper jro...@vz.net

Allow the --force option to be passed to the child push command.

Signed-off-by: Paul Campbell pcampb...@kemitix.net
---
 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 repository refspec
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/)

[Paul Campbell]

From: Paul Cartwright paul.cartwri...@ziilabs.com

Signed-off-by: Paul Campbell pcampb...@kemitix.net
---
 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

[Paul Campbell]

From: Matt Hoffman matt.hoff...@quantumretail.com

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 pcampb...@kemitix.net

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

[Paul Campbell]

On Wed, Mar 13, 2013 at 10:32 PM, Paul Campbell pcampb...@kemitix.net wrote:
 From: Matt Hoffman matt.hoff...@quantumretail.com

 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 pcampb...@kemitix.net

 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

[Paul Campbell]

From: Matt Hoffman matt.hoff...@quantumretail.com

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 pcampb...@kemitix.net
---

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

[Junio C Hamano]

Antoine Pelisse apeli...@gmail.com 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 apeli...@gmail.com
 ---
 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 = (1ULn);
 @@ -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-line, lline-len,
 + line, len, flags)) {
   

Re: [PATCH] Allow combined diff to ignore white-spaces

[Junio C Hamano]

Antoine Pelisse apeli...@gmail.com 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

[Alberto Bertogli]

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]

[fmh]

binPHkdTDR1Av.bin
Description: iso-8859-1

[PATCH] setup.c: Remove duplicate code from prefix_pathspec()

[Lukas Fleischer]

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 g...@cryptocrack.de
---
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

[Miles Bader]

Paul Campbell pcampb...@kemitix.net 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: Tag peeling peculiarities

[Michael Haggerty]

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 mhag...@alum.mit.edu 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 have to read any objects.

  * Old writer, old reader: status 

Re: Tag peeling peculiarities

[Jeff King]

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
libgit2, it seems to ignore the #-line completely, so I think it 

Re: Tag peeling peculiarities

[Jeff King]

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