date:20150703

On Fri, Jul 3, 2015 at 11:51 PM, Junio C Hamano gits...@pobox.com wrote:
 Nguyễn Thái Ngọc Duy  pclo...@gmail.com writes:

 Once we know the number of objects in the input pack, we allocate an
 array of nr_objects of struct delta_entry. On x86-64, this struct is
 32 bytes long. The union delta_base, which is part of struct
 delta_entry, provides enough space to store either ofs-delta (8 bytes)
 or ref-delta (20 bytes).

 Sorry for responding to a patch 7000+ messages ago, but some kind
 folks at Google were puzzled by this code, and I think they found a
 small bug.

  static void fix_unresolved_deltas(struct sha1file *f, int nr_unresolved)
  {
 - struct delta_entry **sorted_by_pos;
 + struct ref_delta_entry **sorted_by_pos;
   int i, n = 0;

   /*
 @@ -1282,28 +1344,25 @@ static void fix_unresolved_deltas(struct sha1file 
 *f, int nr_unresolved)
* resolving deltas in the same order as their position in the pack.
*/
   sorted_by_pos = xmalloc(nr_unresolved * sizeof(*sorted_by_pos));
 - for (i = 0; i  nr_deltas; i++) {
 - if (objects[deltas[i].obj_no].real_type != OBJ_REF_DELTA)
 - continue;
 - sorted_by_pos[n++] = deltas[i];
 - }
 + for (i = 0; i  nr_ref_deltas; i++)
 + sorted_by_pos[n++] = ref_deltas[i];
   qsort(sorted_by_pos, n, sizeof(*sorted_by_pos), delta_pos_compare);

 You allocate an array of nr_unresolved (which is the sum of
 nr_ref_deltas and nr_ofs_deltas in the new world order with patch)
 entries, fill only the first nr_ref_deltas entries of it, and then
 sort that first n (= nr_ref_deltas) entries.  The qsort and the
 subsequent loop only looks at the first n entries, so nothing is
 filling or reading these nr_ofs_deltas entres at the end.

 I do not see any wrong behaviour other than temporary wastage of
 nr_ofs_deltas pointers that would be caused by this, but this
 allocation is misleading.

 Also, the old code before this change had to use 'i' and 'n' because
 some of the things we see in the (old) deltas[] array we scanned
 with 'i' would not make it into the sorted_by_pos[] array in the old
 world order, but now because you have only ref delta in a separate
 ref_deltas[] array, they increment lockstep.  That also puzzled me
 while re-reading this code.

 Perhaps something like this is needed?

Yeah I can see the confusion when reading the code without checking
its history. You probably want to kill the argument nr_unresolved too
because it's not needed anymore after your patch.

So what's the bug you mentioned? All I got from the above was wastage
and confusion, no bug.
-- 
Duy
--
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 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

2015-07-03 Thread Shawn Pearce

On Fri, Jul 3, 2015 at 11:07 AM, Jeff King p...@peff.net wrote:
I wondered briefly whether this impacted the keepalives we added to
`upload-pack` in 05e9515; those are implemented as 0-byte data packets,
which we send during the potentially long counting/delta-compression
phase before we send out pack data. It works there because the packets
actually contain a single sideband byte, so they are never mistaken for
a flush packet.

Interesting. I didn't know about 05e9515. This is a great hack. We
have similar issues in our server-server system at $DAY_JOB, they use
--quiet as no human is watching. So we did a different hack for the
same reason.

Related, I recently ran into a case where I think we should do the same
for pushes. After receiving the pack, `index-pack` may chew on the
result for literally minutes (try pushing up the entire linux.git
history sometime). We say nothing at all on the wire until we've
finished that, run check_everything_connected, and run all hooks. Some
clients (or intermediates on the connection) may give up after a few
minutes of silence.

I think we should have:

1. Some progress eye-candy from the server to tell us that something
is happening, and how close we are to finishing (basically
index-pack -v).

JGit receive-pack has done this for years. We output a progress
monitor for the resolving delta phase, and the counting during the
graph connectivity check, as JGit being in Java is slow as snot and
cannot digest the linux kernel instantly.

2. When progress is disabled, similar keepalive packets saying nope,
no output yet.

Yea this is a problem so I think JGit ignores the client's request for
quiet here and shovels progress messages anyway as a hack to force
keep-alive. Never considered the empty side-band message that 05e9515
introduces.

For (2), hopefully we can implement it in the same way, and rely on
empty sideband-0 packets. I haven't tested it in practice, though (I
have some very rough patches for (1) already).

sideband-0 is not going to work for JGit clients.

JGit clients are strict about the sideband stream being 1,2,3 and fail
hard if they get any other stream from the server[1].

[1]
https://eclipse.googlesource.com/jgit/jgit/+/master/org.eclipse.jgit/src/org/eclipse/jgit/transport/SideBandInputStream.java#169
--
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] rebase: return non-zero error code if format-patch fails

Clemens Buchacher clemens.buchac...@intel.com writes:

 Since e481af06 (rebase: Handle cases where format-patch fails) we
 notice if format-patch fails and return immediately from
 git-rebase--am. We save the return value with ret=$?, but then we
 return $?, which is usually zero in this case.

 Fix this by returning $ret instead.

Sounds sensible.


 Cc: Andrew Wong andrew.k...@gmail.com
 Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com
 Reviewed-by: Jorge Nunes jorge.nu...@intel.com

Where was this review made?  I may have missed a recent discussion,
and that is why I am asking, because Reviewed-by: lines that cannot
be validated by going back to the list archive does not add much
value.

Thanks.

 ---
  git-rebase--am.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/git-rebase--am.sh b/git-rebase--am.sh
 index f923732..9ae898b 100644
 --- a/git-rebase--am.sh
 +++ b/git-rebase--am.sh
 @@ -78,7 +78,7 @@ else
  
   As a result, git cannot rebase them.
   EOF
 - return $?
 + return $ret
   fi
  
   git am $git_am_opt --rebasing --resolvemsg=$resolvemsg \
--
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 name-rev not accepting abbreviated SHA with --stdin

Sitaram Chamarty sitar...@gmail.com writes:

 On 06/25/2015 05:41 AM, Junio C Hamano wrote:
 Sitaram Chamarty sitar...@gmail.com writes:
 
 This *is* documented, but I'm curious why this distinction is made.
 
 I think it is from mere laziness, and also in a smaller degree
 coming from an expectation that --stdin would be fed by another
 script like rev-list where feeding full 40-hex is less work than
 feeding unique abbreviated prefix.

 Makes sense; thanks.  Maybe if I feel really adventurous I will,
 one day, look at the code :-)

Sorry, but I suspect this is not 100% laziness; it is meant to read
text that has object names sprinkled in and output text with object
names substituted.  I suspect that this was done to prevent a short
string that may look like an object name like deadbabe from getting
converted into an unrelated commit object name.

--
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] log: add log.follow config option

Matthieu Moy matthieu@grenoble-inp.fr writes:

 David Turner dtur...@twopensource.com writes:

 Twitter's history is almost completely linear, so it's useful for us.  

 Since it looks like the patch won't be useful outside of our context,
 I'll just rewrite it to check the pathspec count, and not upstream it
 until follow becomes more general.

 As long as it's an opt-in and that the documentation states the
 limitations clearly enough, I think it makes sense to me to have this
 upstream.

Perhaps.  But at least log -- 1 2 and log -- should not be broken
for those that set the configuration.

Unless you are counting these as also limitations, that is.
--
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/4] list-object: add get_commit_count function

On Fri, Jul 03, 2015 at 10:49:40AM -0700, Junio C Hamano wrote:

 Lawrence Siebert lawrencesieb...@gmail.com writes:
 
  Moving commit counting from rev-list into list-object which is a step
  toward letting git log do counting as well.
 
  Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
  ---
 
 No way.  Look at the things provided by list-objects.c API.  They
 are not about formatting outputs.  printf() calls do not belong
 there.

Moreover, if we are going to provide an abstracted function to show the
commit count, we would also need to provide one to _create_ the count.
IOW, this get_commit_count, wherever it goes, should be accompanied by
the matching code that is put into show_commit in patch 2.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

Jeff King p...@peff.net writes:

 On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:

 There is a slight complication on sending an empty line without any
 termination, though ;-)  The reader that calls packet_read() cannot
 tell such a payload from a flush packet, I think.
 
 *That* may be something we want to document.

 Usually flush packets are , and an empty data packet
 is 0004. Or are you talking about some kind of flush inside the
 pkt-data stream?

Neither.  At the wire level there is a difference, but the callers
of most often used function in pkt-line API, packet_read(), says

while (1) {
len = packet_read();
if (!len) {
/* flush */
break;
}
... do things on the len bytes received ...
... and then on to the next packet ...
}

I think the least intrusive change to the caller side would be
to teach packet_read() to keep a static and let the callers do
this:

while (1) {
len = packet_read();
if (!len  packet_last_was_flush()) {
/* flush */
break;
}
... do things on the len bytes received ...
... and then on to the next packet ...
}

even though that looks very ugly.

len = packet_read(..., flag);
if (!len  (flag  PKT_LAST_WAS_FLUSH)) {
/* flush */
...

might be better.
--
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 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

On Fri, Jul 03, 2015 at 11:43:33AM -0700, Shawn Pearce wrote:

  For (2), hopefully we can implement it in the same way, and rely on
  empty sideband-0 packets. I haven't tested it in practice, though (I
  have some very rough patches for (1) already).
 
 sideband-0 is not going to work for JGit clients.

Er, sorry, mental hiccup. It is 0-length sideband-1 packets that I
meant. The same as for upload-pack keepalives.

 JGit clients are strict about the sideband stream being 1,2,3 and fail
 hard if they get any other stream from the server[1].

I think git does, too.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] l10n: de.po: translate 65 new messages

2015-07-03 Thread Ralf Thielow

Am 3. Juli 2015 um 17:50 schrieb Ralf Thielow ralf.thie...@gmail.com:
 Translate 65 new messages came from git.pot update
 in 64f23b0 (l10n: git.pot: v2.5.0 round 1 (65 new,
 15 removed)).

 Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
 ---
  #: dir.c:1945
  msgid Untracked cache is disabled on this system.
 -msgstr 
 +msgstr Cache für unversionierten Dateien ist auf diesem System deaktiviert.


Just saw this typo, should be unversionierte Dateien. Will be fixed
in a reroll.
--
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 v5 3/4] status: give more information during rebase -i

Matthieu Moy matthieu@grenoble-inp.fr writes:

 I would agree with more strict is it was about rejecting the input (to
 catch errors), but here we're still accepting it without complaining

Yes, by more strict, I meant that I would prefer to keep things we
do not understand as intact as possible, while transforming what we
do understand into whatever shape we deem appropriate.

 Actually, there's a hidden benefit in accepting not-well-formatted
 input: it mimicks the shell equivalent closer, which means that we're
 close to replacing the shell's collapse_todo_ids and expand_todo_ids in
 C which would avoid C/shell duplication.

;-)

But as I said above, that is a mere would prefer preference, so I
can go either way.
--
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] pager: do not leak GIT_PAGER_IN_USE to the pager

On Fri, Jul 03, 2015 at 10:18:45AM -0700, Junio C Hamano wrote:

 Since 2e6c01e2, we export GIT_PAGER_IN_USE so that a process that

I imagine you mean 2e6c012e here.

 becomes the upstream of the spawned pager can still tell that we
 have spawned the pager and decide to do colored output even when
 its output no longer goes to a terminal (i.e. isatty(1)).
 
 But we forgot to clear it from the enviornment of the spawned pager.
 This is not a problem in a sane world, but if you have a handful of
 thousands Git users in your organization, somebody is bound to do
 strange things, e.g. typing !ENTER instead of 'q' to get control
 back from $LESS.  GIT_PAGER_IN_USE is still set in that subshell
 spawned by less, and all sorts of interesting things starts
 happening, e.g. git diff | cat starts coloring its output.
 
 We can clear the environment variable in the half of the fork that
 runs the pager to avoid the confusion.

I think this is a reasonable fix. I guess it would be possible that some
pager would want to react differently depending on the variable, but I
could not think of a useful case. And certainly your pager, being the
pager itself, can assume that the pager is in use. ;) At the very worst,
somebody can set GIT_PAGER=GIT_PAGER_IN_USE=1 my-pager if they truly
want to do something bizarre.

So,

Acked-by: Jeff King p...@peff.net

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] index-pack: kill union delta_base to save memory

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

 Once we know the number of objects in the input pack, we allocate an
 array of nr_objects of struct delta_entry. On x86-64, this struct is
 32 bytes long. The union delta_base, which is part of struct
 delta_entry, provides enough space to store either ofs-delta (8 bytes)
 or ref-delta (20 bytes).

Sorry for responding to a patch 7000+ messages ago, but some kind
folks at Google were puzzled by this code, and I think they found a
small bug.

  static void fix_unresolved_deltas(struct sha1file *f, int nr_unresolved)
  {
 - struct delta_entry **sorted_by_pos;
 + struct ref_delta_entry **sorted_by_pos;
   int i, n = 0;
  
   /*
 @@ -1282,28 +1344,25 @@ static void fix_unresolved_deltas(struct sha1file *f, 
 int nr_unresolved)
* resolving deltas in the same order as their position in the pack.
*/
   sorted_by_pos = xmalloc(nr_unresolved * sizeof(*sorted_by_pos));
 - for (i = 0; i  nr_deltas; i++) {
 - if (objects[deltas[i].obj_no].real_type != OBJ_REF_DELTA)
 - continue;
 - sorted_by_pos[n++] = deltas[i];
 - }
 + for (i = 0; i  nr_ref_deltas; i++)
 + sorted_by_pos[n++] = ref_deltas[i];
   qsort(sorted_by_pos, n, sizeof(*sorted_by_pos), delta_pos_compare);

You allocate an array of nr_unresolved (which is the sum of
nr_ref_deltas and nr_ofs_deltas in the new world order with patch)
entries, fill only the first nr_ref_deltas entries of it, and then
sort that first n (= nr_ref_deltas) entries.  The qsort and the
subsequent loop only looks at the first n entries, so nothing is
filling or reading these nr_ofs_deltas entres at the end.

I do not see any wrong behaviour other than temporary wastage of
nr_ofs_deltas pointers that would be caused by this, but this
allocation is misleading.

Also, the old code before this change had to use 'i' and 'n' because
some of the things we see in the (old) deltas[] array we scanned
with 'i' would not make it into the sorted_by_pos[] array in the old
world order, but now because you have only ref delta in a separate
ref_deltas[] array, they increment lockstep.  That also puzzled me
while re-reading this code.

Perhaps something like this is needed?


 builtin/index-pack.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 48fa472..d6c48cd 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1334,7 +1334,7 @@ static int delta_pos_compare(const void *_a, const void 
*_b)
 static void fix_unresolved_deltas(struct sha1file *f, int nr_unresolved)
 {
struct ref_delta_entry **sorted_by_pos;
-   int i, n = 0;
+   int i;
 
/*
 * Since many unresolved deltas may well be themselves base objects
@@ -1346,12 +1346,12 @@ static void fix_unresolved_deltas(struct sha1file *f, 
int nr_unresolved)
 * before deltas depending on them, a good heuristic is to start
 * resolving deltas in the same order as their position in the pack.
 */
-   sorted_by_pos = xmalloc(nr_unresolved * sizeof(*sorted_by_pos));
+   sorted_by_pos = xmalloc(nr_ref_deltas * sizeof(*sorted_by_pos));
for (i = 0; i  nr_ref_deltas; i++)
-   sorted_by_pos[n++] = ref_deltas[i];
-   qsort(sorted_by_pos, n, sizeof(*sorted_by_pos), delta_pos_compare);
+   sorted_by_pos[i] = ref_deltas[i];
+   qsort(sorted_by_pos, nr_ref_deltas, sizeof(*sorted_by_pos), 
delta_pos_compare);
 
-   for (i = 0; i  n; i++) {
+   for (i = 0; i  nr_ref_deltas; i++) {
struct ref_delta_entry *d = sorted_by_pos[i];
enum object_type type;
struct base_data *base_obj = alloc_base_data();

--
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/4] list-object: add get_commit_count function

Lawrence Siebert lawrencesieb...@gmail.com writes:

 Moving commit counting from rev-list into list-object which is a step
 toward letting git log do counting as well.

 Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
 ---

No way.  Look at the things provided by list-objects.c API.  They
are not about formatting outputs.  printf() calls do not belong
there.

--
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 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

On Fri, Jul 03, 2015 at 10:45:59AM -0700, Junio C Hamano wrote:

  Usually flush packets are , and an empty data packet
  is 0004. Or are you talking about some kind of flush inside the
  pkt-data stream?
 
 Neither.  At the wire level there is a difference, but the callers
 of most often used function in pkt-line API, packet_read(), says
 
   while (1) {
   len = packet_read();
   if (!len) {
   /* flush */
   break;
   }
   ... do things on the len bytes received ...
   ... and then on to the next packet ...
   }

Ah, I see. Yeah, that is a problem. The solutions you proposed seem like
good workarounds to me, but we are unfortunately stuck with existing
clients and servers which did not behave that way.

I wondered briefly whether this impacted the keepalives we added to
`upload-pack` in 05e9515; those are implemented as 0-byte data packets,
which we send during the potentially long counting/delta-compression
phase before we send out pack data. It works there because the packets
actually contain a single sideband byte, so they are never mistaken for
a flush packet.

Related, I recently ran into a case where I think we should do the same
for pushes. After receiving the pack, `index-pack` may chew on the
result for literally minutes (try pushing up the entire linux.git
history sometime). We say nothing at all on the wire until we've
finished that, run check_everything_connected, and run all hooks.  Some
clients (or intermediates on the connection) may give up after a few
minutes of silence.

I think we should have:

  1. Some progress eye-candy from the server to tell us that something
 is happening, and how close we are to finishing (basically
 index-pack -v).

  2. When progress is disabled, similar keepalive packets saying nope,
 no output yet.

For (2), hopefully we can implement it in the same way, and rely on
empty sideband-0 packets. I haven't tested it in practice, though (I
have some very rough patches for (1) already).

-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

CLAIM!!!...

2015-07-03 Thread Bingo

Dear Winner,

Your email address attached to ticket number 7-27-31-37-43 WON One Million  
British Pound in the BINGO LOTTO INTERNATIONAL. Email to (bingo...@aim.com) for 
claim. 

Congratulations once again.

Yours Faithfully,
Mr. 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 v2 08/23] checkout: fix bug with --to and relative HEAD

On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
 Given git checkout --to path HEAD~1, the new worktree's HEAD should
 begin life at the current branch's HEAD~1, however, it actually ends up
 at HEAD~2. The happens because:

 1. git-checkout resolves HEAD~1

 2. to satisfy is_git_directory, prepare_linked_worktree() creates a
HEAD in the new worktree with the value of the resolved HEAD~1

 3. git-checkout re-invokes itself with the same arguments within the
new worktree to populate the worktree

 4. the sub git-checkout resolves HEAD~1 relative to its own HEAD,
which is the resolved HEAD~1 from the original invocation,
resulting unexpectedly and incorrectly in HEAD~2 (relative to the
original)

 Fix this by unconditionally assigning the current worktree's HEAD as the
 value of the new worktree's HEAD.

Good catch!

 @@ -924,9 +925,11 @@ static int prepare_linked_checkout(const struct 
 checkout_opts *opts,
  * value would do because this value will be ignored and
  * replaced at the next (real) checkout.
  */

This comment any valid value would do.. will be ignored is proved incorrect.

 +   if (!resolve_ref_unsafe(HEAD, 0, rev, NULL))
 +   die(_(unable to resolve HEAD));
 strbuf_reset(sb);
 strbuf_addf(sb, %s/HEAD, sb_repo.buf);
 -   write_file(sb.buf, 1, %s\n, sha1_to_hex(new-commit-object.sha1));
 +   write_file(sb.buf, 1, %s\n, sha1_to_hex(rev));
 strbuf_reset(sb);
 strbuf_addf(sb, %s/commondir, sb_repo.buf);
 write_file(sb.buf, 1, ../..\n);
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/23] worktree: introduce add command

On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
  COMMANDS
  
 +add path branch::
 +
 +Check out `branch` into a separate working directory, `path`, creating
 +`path` if necessary. The new working directory is linked to the current
 +repository, sharing everything except working directory specific files
 +such as HEAD, index, etc. If `path` already exists, it must be empty.

Side note, must be empty is an implementation limitation. I think
the two-way merge employed by git-checkout can deal with dirty path
and only perform the checkout if there is no data loss. But we can
leave this for later.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 16/23] worktree: add -b/-B options

On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
 One of git-worktree's roles is to populate the new worktree, much like
 git-checkout, and thus, for convenience, ought to support several of the
 same shortcuts. Toward this goal, add -b/-B options to create a new
 branch and check it out in the new worktree.

There are some other  ref manipulation options we can bring over like
--orphan and --track. But you can totally leave them out and we can
add them back when people actually need them.
-- 
Duy
--
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] l10n: de.po: translate 65 new messages

2015-07-03 Thread Ralf Thielow

Translate 65 new messages came from git.pot update
in 64f23b0 (l10n: git.pot: v2.5.0 round 1 (65 new,
15 removed)).

Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
 po/de.po | 186 ---
 1 file changed, 95 insertions(+), 91 deletions(-)

diff --git a/po/de.po b/po/de.po
index d52184c..8d56d19 100644
--- a/po/de.po
+++ b/po/de.po
@@ -539,19 +539,19 @@ msgstr 
 #: diff.c:3570
 #, c-format
 msgid Failed to parse --submodule option parameter: '%s'
 msgstr Fehler beim Parsen des --submodule Optionsparameters: '%s'
 
 #: dir.c:1852
 msgid failed to get kernel name and information
-msgstr 
+msgstr Fehler beim Sammeln von Namen und Informationen zum Kernel
 
 #: dir.c:1945
 msgid Untracked cache is disabled on this system.
-msgstr 
+msgstr Cache für unversionierten Dateien ist auf diesem System deaktiviert.
 
 #: gpg-interface.c:129 gpg-interface.c:200
 msgid could not run gpg.
 msgstr konnte gpg nicht ausführen
 
 #: gpg-interface.c:141
 msgid gpg did not accept the data
@@ -593,15 +593,15 @@ msgstr Vorhandene Git-Kommandos in '%s'
 
 #: help.c:214
 msgid git commands available from elsewhere on your $PATH
 msgstr Vorhandene Git-Kommandos irgendwo in Ihrem $PATH
 
 #: help.c:246
 msgid These are common Git commands used in various situations:
-msgstr 
+msgstr Allgemeine Git-Kommandos, verwendet in verschiedenen Situationen:
 
 #: help.c:311
 #, c-format
 msgid 
 '%s' appears to be a git command, but we were not\n
 able to execute it. Maybe git-%s is broken?
 msgstr 
@@ -1089,50 +1089,51 @@ msgid Internal error
 msgstr Interner Fehler
 
 #: remote.c:1723 remote.c:1766
 msgid HEAD does not point to a branch
 msgstr HEAD zeigt auf keinen Branch
 
 #: remote.c:1732
-#, fuzzy, c-format
+#, c-format
 msgid no such branch: '%s'
-msgstr Kein solcher Branch '%s'
+msgstr Kein solcher Branch: '%s'
 
 #: remote.c:1735
-#, fuzzy, c-format
+#, c-format
 msgid no upstream configured for branch '%s'
 msgstr Kein Upstream-Branch für Branch '%s' konfiguriert.
 
 #: remote.c:1741
-#, fuzzy, c-format
+#, c-format
 msgid upstream branch '%s' not stored as a remote-tracking branch
-msgstr Upstream-Branch '%s' ist nicht als Remote-Tracking-Branch gespeichert
+msgstr Upstream-Branch '%s' nicht als Remote-Tracking-Branch gespeichert
 
 #: remote.c:1756
 #, c-format
 msgid push destination '%s' on remote '%s' has no local tracking branch
-msgstr 
+msgstr Ziel für \push\ '%s' auf Remote-Repository '%s' hat keinen lokal 
+gefolgten Branch
 
 #: remote.c:1771
-#, fuzzy, c-format
+#, c-format
 msgid branch '%s' has no remote for pushing
 msgstr Branch '%s' hat keinen Upstream-Branch gesetzt
 
 #: remote.c:1782
 #, c-format
 msgid push refspecs for '%s' do not include '%s'
-msgstr 
+msgstr Push-Refspecs für '%s' beinhalten nicht '%s'
 
 #: remote.c:1795
 msgid push has no destination (push.default is 'nothing')
-msgstr 
+msgstr kein Ziel für \push\ (push.default ist 'nothing')
 
 #: remote.c:1817
 msgid cannot resolve 'simple' push to a single destination
-msgstr 
+msgstr kann einzelnes Ziel für \push\ im Modus 'simple' nicht auflösen
 
 #: remote.c:2124
 #, c-format
 msgid Your branch is based on '%s', but the upstream is gone.\n
 msgstr Ihr Branch basiert auf '%s', aber Upstream-Branch wurde entfernt.\n
 
 #: remote.c:2128
@@ -1463,17 +1464,17 @@ msgid Can't revert as initial commit
 msgstr Kann nicht als allerersten Commit einen Revert ausführen.
 
 #: sequencer.c:1124
 msgid Can't cherry-pick into empty head
 msgstr Kann nicht als allerersten Commit einen Cherry-Pick ausführen.
 
 #: setup.c:243
-#, fuzzy, c-format
+#, c-format
 msgid failed to read %s
-msgstr Fehler beim Löschen von %s
+msgstr Fehler beim Lesen von %s
 
 #: sha1_name.c:453
 msgid 
 Git normally never creates a ref that ends with 40 hex characters\n
 because it will be ignored when you just specify 40-hex. These refs\n
 may be created by mistake. For example,\n
 \n
@@ -1604,27 +1605,27 @@ msgid no such user
 msgstr kein solcher Benutzer
 
 #: wrapper.c:564
 msgid unable to get current working directory
 msgstr Konnte aktuelles Arbeitsverzeichnis nicht bekommen.
 
 #: wrapper.c:575
-#, fuzzy, c-format
+#, c-format
 msgid could not open %s for writing
 msgstr Konnte '%s' nicht zum Schreiben öffnen.
 
 #: wrapper.c:587
-#, fuzzy, c-format
+#, c-format
 msgid could not write to %s
-msgstr Konnte nicht nach %s schreiben
+msgstr Konnte nicht nach '%s' schreiben.
 
 #: wrapper.c:593
-#, fuzzy, c-format
+#, c-format
 msgid could not close %s
-msgstr konnte %s nicht parsen
+msgstr Konnte '%s' nicht schließen.
 
 #: wt-status.c:150
 msgid Unmerged paths:
 msgstr Nicht zusammengeführte Pfade:
 
 #: wt-status.c:177 wt-status.c:204
 #, c-format
@@ -2120,17 +2121,16 @@ msgid Could not open '%s' for writing.
 msgstr Konnte '%s' nicht zum Schreiben öffnen.
 
 #: builtin/add.c:209
 msgid Could not write patch
 msgstr Konnte Patch nicht schreiben
 
 #: builtin/add.c:212
-#, fuzzy
 msgid editing patch failed
-msgstr Konnte

Re: [PATCH 00/12] Improve git-am test coverage

2015-07-03 Thread Stefan Beller

On Thu, Jul 2, 2015 at 11:16 AM, Paul Tan pyoka...@gmail.com wrote:
 Increase test coverage of git-am.sh to help prevent regressions that could 
 arise
 from the rewrite of git-am.sh to C. This patch series, along with
 pt/am-foreign, improved test coverage as measured by kcov from 56.5%[1] to
 67.3%[2].

 No tests for git-am's interactive mode, though, as test_terminal does not seem
 to attach a pseudo-tty to stdin(?), thus making git-am's test -t 0 check 
 fail.

 This is part of my GSoC project to rewrite git-am.sh to a C builtin[3].

The whole series looks good to me.


 [1] 
 http://pyokagan.github.io/git/20150430132408-a75942b//kcov-merged/git-am.eb79278e.html
 [2] 
 http://pyokagan.github.io/git/20150702173751-2fdae08//kcov-merged/git-am.eb79278e.html
 [3] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1


 Paul Tan (12):
   t4150: am.messageid really adds the message id
   t4150: am fails if index is dirty
   t4151: am --abort will keep dirty index intact
   t4150: am refuses patches when paused
   t4150: am --resolved fails if index has no changes
   t4150: am --resolved fails if index has unmerged entries
   t4150: am with applypatch-msg hook
   t4150: am with pre-applypatch hook
   t4150: am with post-applypatch hook
   t4150: tests for am --[no-]scissors
   t3418: non-interactive rebase --continue with rerere enabled
   t3901: test git-am encoding conversion

  t/t3418-rebase-continue.sh |  19 
  t/t3901-i18n-patch.sh  |  62 
  t/t4150-am.sh  | 228 
 +
  t/t4151-am-abort.sh|  15 +++
  4 files changed, 324 insertions(+)

 --
 2.5.0.rc1.81.gfe77482

--
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] pager: do not leak GIT_PAGER_IN_USE to the pager

Since 2e6c01e2, we export GIT_PAGER_IN_USE so that a process that
becomes the upstream of the spawned pager can still tell that we
have spawned the pager and decide to do colored output even when
its output no longer goes to a terminal (i.e. isatty(1)).

But we forgot to clear it from the enviornment of the spawned pager.
This is not a problem in a sane world, but if you have a handful of
thousands Git users in your organization, somebody is bound to do
strange things, e.g. typing !ENTER instead of 'q' to get control
back from $LESS.  GIT_PAGER_IN_USE is still set in that subshell
spawned by less, and all sorts of interesting things starts
happening, e.g. git diff | cat starts coloring its output.

We can clear the environment variable in the half of the fork that
runs the pager to avoid the confusion.

Signed-off-by: Junio C Hamano gits...@pobox.com
---

 * Arguably, git diff | cat that is colored is much minor problem
   than that the user keep using that subshell from pager without
   realizing.  The user may run more git commands that spawn a pager
   and do the !ENTER infinite times creating a deep process tree
   and then logout many number of times.

 pager.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pager.c b/pager.c
index 98b2682..070dc11 100644
--- a/pager.c
+++ b/pager.c
@@ -78,6 +78,7 @@ void setup_pager(void)
argv_array_push(pager_process.env_array, LESS=FRX);
if (!getenv(LV))
argv_array_push(pager_process.env_array, LV=-c);
+   argv_array_push(pager_process.env_array, GIT_PAGER_IN_USE);
if (start_command(pager_process))
return;
 
--
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] --count feature for git shortlog

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

 On Tue, Jun 30, 2015 at 02:10:49PM +0200, Johannes Schindelin wrote:
 On 2015-06-29 18:46, Lawrence Siebert wrote:
 
  I appreciate your help. Okay, That all makes sense.
  
  I would note that something like:
   git shortlog -s $FILENAME:  | cut -f 1 | paste -sd+ - | bc
  
  seems like it run much faster then:
  
   git log --oneline $FILENAME | wc -l
 
 How does it compare to `git rev-list -- $FILENAME | wc -l`?

 Or even `git rev-list --count HEAD -- $FILENAME`.

Ahh, OK.  I didn't know we already had rev-list --count.

Then please disregard the suggestion to add the option to log; it
still holds true that the option does not belong to shortlog, but
I do think how many changes were made to this path statistics
driven by a script should use rev-list plumbing, and if it already
has --count option, that is perfect ;-)

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: [PUB]What's cooking in git.git (Jul 2015, #01; Wed, 1)

Matthieu Moy matthieu@grenoble-inp.fr writes:

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

 * ad/bisect-terms (2015-06-29) 10 commits
 ...
  The bottom part has been quite well cooked.  Perhaps split it into
  two topisc and merge the earlier ones to 'next' before the rest
  settles.  Michael's idea to make 'good/bad' more intelligent does
  have certain attractiveness ($gname/272867).

 I think it makes sense to merge the first patches soon:

  - bisect: don't mix option parsing and non-trivial code
  - bisect: simplify the addition of new bisect terms
  - bisect: replace hardcoded bad|good by variables
  - Documentation/bisect: revise overall content
  - Documentation/bisect: move getting help section to the end
  - bisect: correction of typo

 I have nothing to add on the last ones, but they can cook in pu a bit
 longer.

 Do you expect anything from my side?

Not at this moment.  Thanks for helping this topic move forward.
--
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 name-rev not accepting abbreviated SHA with --stdin

On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty sitar...@gmail.com wrote:
 Jokes apart, I'm not sure the chances of *both* those things happening
 -- an accidental hash-like string in the text *and* it matching an
 existing hash -- are high enough to bother.  If it can be done without
 too much code, it probably should.

To be fair to the original implementor, I think we didn't have an API to ask
do we have a committish object with this name? with an abbreviated SHA-1.
All we had was do we have an object with this name?.

As the only answer the command can give is an exteneded SHA-1 for
committish, it is understandable that hitting blobs and trees (which typically
are much more numerous than committishes) with false positives would have
been a real risk the implementation wanted to avoid.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 18/23] checkout: retire --to option