Re: [PATCH] Drop some dashes from built-in invocations in scripts

[Michael Forney]

On 8/5/17, Junio C Hamano  wrote:
> Michael Forney  writes:
>> On 8/5/17, Junio C Hamano  wrote:
>>> Have you made sure that all of these scripts, before calling
>>> 'git-foo' in the current code, update their PATH so that these found
>>> in the bog standard place (i.e. GIT_EXEC_PATH)?
>>>
>>> The reason I ask is because we can rest assured these changes will
>>> be a no-regression improvement if you did so.  I do not offhand
>>> think of a reason why these scripts wouldn't be doing so, but it
>>> never hurts to make sure.
>>
>> I just checked and all the scripts make some other call to a built-in
>> with `git foo`, so I think it should be safe.
>
> As long as they are the same "foo"'s, then the check you did is
> perfectly fine.  The (unlikely I would think) case that can lead to
> a regression is if these script deliberately used `git-foo` to find
> them on $PATH, which can be different from 'git foo' that is found
> by 'git' in its own binary (as all of them are built-ins), and that
> is why I asked.

Ah. Well, it looks like all but git-merge-resolve.sh run `.
git-sh-setup`, so we know that GIT_EXEC_PATH must in their PATH (and
at the front unless the script was invoked directly).

git-merge-resolve.sh does not do this, so I suppose if the user ran
$GIT_EXEC_PATH/git-merge-resolve directly, and also had a custom
git-merge-index executable in their PATH, that would switch to running
the git merge-index built-in instead.

Re: reftable [v5]: new ref storage format

[Shawn Pearce]

5th iteration of the reftable storage format.

You can read a rendered version of this here:
https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md

Significant changes from v4:
- Supported Michael Haggerty's multi-level index.
- Restart table now appears at start of block, instead of end.
- The `restart_offset` is now 3-bytes, instead of 4-bytes.
- Footer stores `obj_id_len` abbreviation used by obj blocks.

- Clarified log-only files can exist.
- Clarified use of `position` for byte in file, `offset` for byte in block.
- Clarified peeling, and reference name encoding as bag of bytes.
- Corrected extensions.reftable value to be `true`.


# reftable

[TOC]

## Overview

### Problem statement

Some repositories contain a lot of references (e.g.  android at 866k,
rails at 31k).  The existing packed-refs format takes up a lot of
space (e.g.  62M), and does not scale with additional references.
Lookup of a single reference requires linearly scanning the file.

Atomic pushes modifying multiple references require copying the
entire packed-refs file, which can be a considerable amount of data
moved (e.g. 62M in, 62M out) for even small transactions (2 refs
modified).

Repositories with many loose references occupy a large number of disk
blocks from the local file system, as each reference is its own file
storing 41 bytes (and another file for the corresponding reflog).
This negatively affects the number of inodes available when a large
number of repositories are stored on the same filesystem.  Readers can
be penalized due to the larger number of syscalls required to traverse
and read the `$GIT_DIR/refs` directory.

### Objectives

- Near constant time lookup for any single reference, even when the
  repository is cold and not in process or kernel cache.
- Near constant time verification a SHA-1 is referred to by at least
  one reference (for allow-tip-sha1-in-want).
- Efficient lookup of an entire namespace, such as `refs/tags/`.
- Support atomic push with `O(size_of_update)` operations.
- Combine reflog storage with ref storage for small transactions.
- Separate reflog storage for base refs and historical logs.

### Description

A reftable file is a portable binary file format customized for
reference storage. References are sorted, enabling linear scans,
binary search lookup, and range scans.

Storage in the file is organized into blocks.  Prefix compression
is used within a single block to reduce disk space.  Block size is
tunable by the writer.

### Performance

Space used, packed-refs vs. reftable:

repository | packed-refs | reftable | % original | avg ref  | avg obj
---|:|-:|---:|-:|:
android|  62.2 M |   34.4 M | 55.2%  | 33 bytes | 8 bytes
rails  |   1.8 M |1.1 M | 57.7%  | 29 bytes | 6 bytes
git|  78.7 K |   44.0 K | 60.0%  | 50 bytes | 6 bytes
git (heads)|   332 b |274 b | 83.1%  | 34 bytes | 0 bytes

Scan (read 866k refs), by reference name lookup (single ref from 866k
refs), and by SHA-1 lookup (refs with that SHA-1, from 866k refs):

format  | cache | scan| by name| by SHA-1
|--:|:|---:|---:
packed-refs | cold  |  402 ms | 409,660.1 usec | 412,535.8 usec
packed-refs | hot   | |   6,844.6 usec |  20,110.1 usec
reftable| cold  |  112 ms |  33.9 usec | 323.2 usec
reftable| hot   | |  20.2 usec | 320.8 usec

Space used for 149,932 log entries for 43,061 refs,
reflog vs. reftable:

format| size  | avg entry
--|--:|---:
$GIT_DIR/logs | 173 M | 1209 bytes
reftable  |   5 M |   37 bytes

## Details

### Peeling

References stored in a reftable are peeled, a record for an annotated
(or signed) tag records both the tag object, and the object it refers
to.

### Reference name encoding

Reference names are an uninterpreted sequence of bytes that must pass
[git-check-ref-format][ref-fmt] as a valid reference name.

[ref-fmt]: https://git-scm.com/docs/git-check-ref-format

### Network byte order

All multi-byte, fixed width fields are in network byte order.

### Ordering

Blocks are lexicographically ordered by their first reference.

### Directory/file conflicts

The reftable format accepts both `refs/heads/foo` and
`refs/heads/foo/bar` as distinct references.

This property is useful for retaining log records in reftable, but may
confuse versions of Git using `$GIT_DIR/refs` directory tree to
maintain references.  Users of reftable may choose to continue to
reject `foo` and `foo/bar` type conflicts to prevent problems for
peers.

## File format

### Structure

A reftable file has the following high-level structure:

first_block {
  header
  first_ref_block
}
ref_blocks*
ref_index?
obj_blocks*
obj_index?
log_blocks*
log_index?
footer

A log-only file omits the `ref_blocks`, `ref_index`, 

Re: [PATCH] Drop some dashes from built-in invocations in scripts

[Junio C Hamano]

Michael Forney  writes:

> On 8/5/17, Junio C Hamano  wrote:
>> Have you made sure that all of these scripts, before calling
>> 'git-foo' in the current code, update their PATH so that these found
>> in the bog standard place (i.e. GIT_EXEC_PATH)?
>>
>> The reason I ask is because we can rest assured these changes will
>> be a no-regression improvement if you did so.  I do not offhand
>> think of a reason why these scripts wouldn't be doing so, but it
>> never hurts to make sure.
>
> I just checked and all the scripts make some other call to a built-in
> with `git foo`, so I think it should be safe.

As long as they are the same "foo"'s, then the check you did is
perfectly fine.  The (unlikely I would think) case that can lead to
a regression is if these script deliberately used `git-foo` to find
them on $PATH, which can be different from 'git foo' that is found
by 'git' in its own binary (as all of them are built-ins), and that
is why I asked.

Thanks.

Re: [PATCH] Drop some dashes from built-in invocations in scripts

[Johannes Schindelin]

Hi Junio,

On Sat, 5 Aug 2017, Junio C Hamano wrote:

> Michael Forney  writes:
> 
> > This way, they still work even if the built-in symlinks aren't
> > installed.
> >
> > Signed-off-by: Michael Forney 
> > ---
> > It looks like there was an effort to do this a number of years ago (through
> > `make remove-dashes`). These are just a few I noticed were still left in the
> > .sh scripts.
> 
> Thanks for working on this.  
> 
> Have you made sure that all of these scripts, before calling
> 'git-foo' in the current code, update their PATH so that these found
> in the bog standard place (i.e. GIT_EXEC_PATH)?

The scripts do not update their PATH. `git` does, before they are called.

For example, if you call `git stash`, the `git` executable will first
figure out that `stash` is not a builtin (unless you run with the
experimental patch series that still has not seen much review, more is the
shame, including on myself), and then call the dashed form. At this point,
`git` will already have added the exec path to the PATH variable so that
`git-stash` is found. So then `git-stash` runs, and does not even need to
take pains to adjust the PATH variable again! Magic!

;-)

Ciao,
Dscho

[ANNOUNCE] Git for Windows 2.14.0

[Johannes Schindelin]

Dear Git users,

It is my pleasure to announce that Git for Windows 2.14.0 is available from:

https://git-for-windows.github.io/

Changes since Git for Windows v2.13.3 (July 13th 2017)

New Features

  * Comes with Git v2.14.0.
  * Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
git-for-windows/busybox-w32/commit/9480dca7c].
  * Comes with Git Credential Manager v1.12.0.
  * It is now possible to switch between Secure Channel and OpenSSL for
Git's HTTPS transport by setting the http.sslBackend config
variable to "openssl" or "schannel"; This is now also the method
used by the installer (rather than copying libcurl-4.dll files
around).
  * The experimental option --show-ignored-directory was added to git
status to show only the name of ignored directories when the option
--untracked=all is used.
  * Git for Windows releases now also include an experimental
BusyBox-based MinGit.

Bug Fixes

  * Repository-local aliases are now resolved again in worktrees.
  * CamelCased aliases were broken in v2.13.3; This has been fixed
again.
  * The 32-bit Git binaries are now built against the same dependencies
that are shipped with Git for Windows.

Filename | SHA-256
 | ---
Git-2.14.0-64-bit.exe | 
89799b4474bb62b2a266ed52fbe2f1e5d78598af61a7ef62c1ef94e2ac8de863
Git-2.14.0-32-bit.exe | 
74e5d76e6297fe1243d9a3e015b659bba032eecc1e538735b47e48325428e156
PortableGit-2.14.0-64-bit.7z.exe | 
7188ac81c9c48c8219355a0dae68461f99bab1976e9a5ab81b10bd994a83334e
PortableGit-2.14.0-32-bit.7z.exe | 
02e5d5f1bf611b6e0049743d4adf5ea7f4fb060e29809068cbba3b410632e01d
MinGit-2.14.0-64-bit.zip | 
56fab49a484bec42b733b2ed6335803fd2c9aa2a4cc24ab99863f543b764f507
MinGit-2.14.0-32-bit.zip | 
a886cbe1d2c9cb5e1aa3e4ea92ab34878e101de3a3e2bed7f25059d376ec4eaa
MinGit-2.14.0-busybox-64-bit.zip | 
6102ac14721b79d5f950924cd6938b9d57d8cabd6b29e5209074c98b9ff1698f
MinGit-2.14.0-busybox-32-bit.zip | 
28fb513ad3891fb5d8f751370adf0e63b7c0d1f7b400260e07957b9d32767330
Git-2.14.0-64-bit.tar.bz2 | 
5a25702165218491fd6fc13e19016ecf0a7b703554194d14e817295c93b80be2
Git-2.14.0-32-bit.tar.bz2 | 
64baf1e284ecbbab38bc287747c6b4d76c5ef70f48def03044b440d24188a919

Ciao,
Johannes

Re: [PATCH] Drop some dashes from built-in invocations in scripts

[Michael Forney]

On 8/5/17, Junio C Hamano  wrote:
> Have you made sure that all of these scripts, before calling
> 'git-foo' in the current code, update their PATH so that these found
> in the bog standard place (i.e. GIT_EXEC_PATH)?
>
> The reason I ask is because we can rest assured these changes will
> be a no-regression improvement if you did so.  I do not offhand
> think of a reason why these scripts wouldn't be doing so, but it
> never hurts to make sure.

I just checked and all the scripts make some other call to a built-in
with `git foo`, so I think it should be safe.

Re: [PATCH] Drop some dashes from built-in invocations in scripts

[Junio C Hamano]

Michael Forney  writes:

> This way, they still work even if the built-in symlinks aren't
> installed.
>
> Signed-off-by: Michael Forney 
> ---
> It looks like there was an effort to do this a number of years ago (through
> `make remove-dashes`). These are just a few I noticed were still left in the
> .sh scripts.

Thanks for working on this.  

Have you made sure that all of these scripts, before calling
'git-foo' in the current code, update their PATH so that these found
in the bog standard place (i.e. GIT_EXEC_PATH)?

The reason I ask is because we can rest assured these changes will
be a no-regression improvement if you did so.  I do not offhand
think of a reason why these scripts wouldn't be doing so, but it
never hurts to make sure.

>
>  git-merge-octopus.sh  | 2 +-
>  git-merge-one-file.sh | 8 
>  git-merge-resolve.sh  | 2 +-
>  git-stash.sh  | 2 +-
>  git-submodule.sh  | 6 +++---
>  5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
> index bcf0d92ec..6c390d6c2 100755
> --- a/git-merge-octopus.sh
> +++ b/git-merge-octopus.sh
> @@ -100,7 +100,7 @@ do
>   if test $? -ne 0
>   then
>   gettextln "Simple merge did not work, trying automatic merge."
> - git-merge-index -o git-merge-one-file -a ||
> + git merge-index -o git-merge-one-file -a ||
>   OCTOPUS_FAILURE=1
>   next=$(git write-tree 2>/dev/null)
>   fi
> diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
> index 424b034e3..9879c5939 100755
> --- a/git-merge-one-file.sh
> +++ b/git-merge-one-file.sh
> @@ -115,16 +115,16 @@ case "${1:-.}${2:-.}${3:-.}" in
>   ;;
>   esac
>  
> - src1=$(git-unpack-file $2)
> - src2=$(git-unpack-file $3)
> + src1=$(git unpack-file $2)
> + src2=$(git unpack-file $3)
>   case "$1" in
>   '')
>   echo "Added $4 in both, but differently."
> - orig=$(git-unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
> + orig=$(git unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
>   ;;
>   *)
>   echo "Auto-merging $4"
> - orig=$(git-unpack-file $1)
> + orig=$(git unpack-file $1)
>   ;;
>   esac
>  
> diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
> index c9da747fc..343fe7bcc 100755
> --- a/git-merge-resolve.sh
> +++ b/git-merge-resolve.sh
> @@ -45,7 +45,7 @@ then
>   exit 0
>  else
>   echo "Simple merge failed, trying Automatic merge."
> - if git-merge-index -o git-merge-one-file -a
> + if git merge-index -o git-merge-one-file -a
>   then
>   exit 0
>   else
> diff --git a/git-stash.sh b/git-stash.sh
> index 9b6c2da7b..9aa09c3a3 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -573,7 +573,7 @@ apply_stash () {
>  
>   if test -n "$u_tree"
>   then
> - GIT_INDEX_FILE="$TMPindex" git-read-tree "$u_tree" &&
> + GIT_INDEX_FILE="$TMPindex" git read-tree "$u_tree" &&
>   GIT_INDEX_FILE="$TMPindex" git checkout-index --all &&
>   rm -f "$TMPindex" ||
>   die "$(gettext "Could not restore untracked files from stash 
> entry")"
> diff --git a/git-submodule.sh b/git-submodule.sh
> index e131760ee..ffa2d6648 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -864,7 +864,7 @@ cmd_summary() {
>   test $status != A && test $ignore_config = all 
> && continue
>   fi
>   # Also show added or modified modules which are checked 
> out
> - GIT_DIR="$sm_path/.git" git-rev-parse --git-dir 
> >/dev/null 2>&1 &&
> + GIT_DIR="$sm_path/.git" git rev-parse --git-dir 
> >/dev/null 2>&1 &&
>   printf '%s\n' "$sm_path"
>   done
>   )
> @@ -898,11 +898,11 @@ cmd_summary() {
>   missing_dst=
>  
>   test $mod_src = 16 &&
> - ! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_src^0 
> >/dev/null &&
> + ! GIT_DIR="$name/.git" git rev-parse -q --verify $sha1_src^0 
> >/dev/null &&
>   missing_src=t
>  
>   test $mod_dst = 16 &&
> - ! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_dst^0 
> >/dev/null &&
> + ! GIT_DIR="$name/.git" git rev-parse -q --verify $sha1_dst^0 
> >/dev/null &&
>   missing_dst=t
>  
>   display_name=$(git submodule--helper relative-path "$name" 
> "$wt_prefix")

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  writes:

> We've talked how this UX should look before on-list. Rather than
> re-hashing the arguments I had before I thought it was useful to present
> it as a table. Here's how the patch looks now:
>
> 
> |+--+---+-+-+-|
> | cmd| creates new? | moves | copies? | ...with 
> config? | checks out? |
> 
> |+--+---+-+-+-|
> | branch   | Y| N | N   | N 
>   | N   |
> | checkout | Y| N | N   | N 
>   | Y   |
> | checkout -b   | Y| N | Y   | N 
>   | Y   |
> | branch -m| Y| Y | N   | Y 
>   | Y   |
> | NEW: branch -c   | Y| N | Y   | Y 
>   | Y   |
> 
> |+--+---+-+-+-|

I actually consider "branch" to *never* invoking a checkout.  Even
when "git branch -m A B" happens to be done when your checked out
branch is A and you end up being on B.  That is not a "checkout".

Really from the end-user's point of view that is not a checkout.
The user renamed the branch A and the same conceptual entity, which
is a branch, is now called B.  If that branch was what was checked
out (IOW, if that branch was what would be grown by one commit if
the user did "git commit"), then now that branch's name is B.  It is
natural if you ask "symbolic-ref HEAD" what branch is checked out
after renaming A to B (and A happened to be what was checked out),
the answer chould be B.

It's like the city you live in changed the name of the street your
house is on.  You do not call movers, you do not do anything, but
your address changes.

> I.e. have "branch -c " but just make it not checkout the new
> thing. What you're describing above sounds to me like:
>
> 
> |---+--+---+-+-+-|
> | cmd   | creates new? | moves | 
> copies? | ...with config? | checks out? |
> [... stuff above this point is the same ...]
> | branch -m   | Y| Y | N
>| Y   | Y   |
> [... so is branch -m but included for context ...]
> | NEW: checkout --super-b -b   | Y| N | Y
>| Y   | Y   |
> 
> |---+--+---+-+-+-|

You are talking backwards.  I do not want "branch -c A B", even when
A happens to be what is checked out, to check out branch B.  You and
Sahil were who wanted to check out branch B while doing so, and I
just tried to guess why you two wanted to have such a behaviour that
did not make much sense to me.  And my guess was "perhaps they want
a way to create a new branch starting from another branch, and check
it out, and do so in a single end-user operation".  

I am not particulary interested in such an operation; in my guess,
you two are.  And the "super-b" thing was a suggestion to you two:
If you so desperately want such an operation, then don't make
"branch --copy A B" that operation.  Such an operation better fits
in "checkout", not "branch".

If you are not interested in such an operation, then that is fine.
Do not add the "super-b" mode to "checkout".

But I won't defend a "branch --copy A B" that checks out B when
users and other people like Ramsay think that such a behaviour is
illogical, because I do think it is, too.

Re: [PATCH] Drop some dashes from built-in invocations in scripts

[Johannes Schindelin]

Hi Michael,

On Fri, 4 Aug 2017, Michael Forney wrote:

> This way, they still work even if the built-in symlinks aren't
> installed.
> 
> Signed-off-by: Michael Forney 
> ---
> It looks like there was an effort to do this a number of years ago (through
> `make remove-dashes`). These are just a few I noticed were still left in the
> .sh scripts.

I am very much in favor of this patch. It also helps with things like
building Git in Visual Studio (where hard-linking builtins is not part of
the process).

See also
https://github.com/git-for-windows/git/compare/2006e3973ce6%5E...2006e3973ce6%5E2

Thanks,
Johannes

Re: reftable [v4]: new ref storage format

[Shawn Pearce]

On Tue, Aug 1, 2017 at 6:51 PM, Michael Haggerty  wrote:
> On Tue, Aug 1, 2017 at 4:27 PM, Shawn Pearce  wrote:
>> On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty  
>> wrote:
>>> On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce  wrote:
 4th iteration of the reftable storage format.
 [...]
>>>
>>> Before we commit to Shawn's reftable proposal, I wanted to explore
>>> what a contrasting design that is not block based would look like.
>>
>> I forgot to look at a 1k chunk size, as you suggested that might also
>> be suitable. Here is the more complete experiment table:
>>
>>| size   | seek_cold | seek_hot  |
>> mh  1k | 29.4 M | 20.6 usec | 10.7 usec |   <== Row fixed
>> mh  4k | 28.3 M | 24.5 usec | 14.5 usec |
>> sp  4k | 29.2 M | 63.0 usec |  5.8 usec |
>> sp 64k | 27.7 M | 35.6 usec | 23.3 usec |

I modified reftable to use a mutli-level index as recommended by
Michael Haggerty, and re-ran the above table:

fmt |  bs | idx  |  size  | seek_cold | seek_hot  |
|-|--||---|---|
 mh |  1k | 4 lv | 29.4 M | 20.1 usec |  7.1 usec |
 sp |  1k | 4 lv | 30.7 M | 21.0 usec |  5.5 usec |

 mh |  4k | 2 lv | 28.3 M | 23.4 usec | 11.2 usec |
 sp |  4k | 2 lv | 29.2 M | 19.9 usec |  5.4 usec |

 sp |  4k | 1 lv | 29.2 M | 62.9 usec |  5.6 usec |
 sp | 64k | 1 lv | 27.7 M | 35.6 usec | 21.6 usec |

fmt:  mh = Michael's proposal, sp = Shawn's reftable
bs:  chunk size or block size in bytes
idx:  how many levels of index
size:  total file size in bytes

I can't explain the slightly slower sp-1k-4lv vs. mh-1k-4lv cold_seek
in the first two rows. It might simply be the larger footer read
slowing down JGit. Its reliably flipped in the next two (at 4k).

reftable is more efficient in seek_hot at finding and parsing a
reference. For multi-level indexes both sp and mh implementations used
a lazy caching strategy that caches index blocks along the path to the
ref, but doesn't cache the final ref block. The tests amortized this
by performing 60,000 lookups on the same ref.

>> At least in this case, the 1k block size seems like a good tradeoff.

With the multi-level index now in reftable, it seems like reftable at
4k, 2 level index is a better tradeoff. It aligns with the most common
filesystem block size, and has lower seek times, both cold and hot.
Its slightly larger than Michael's alternative proposal (+921 K), but
compresses better than reftable at 1k (-1.5 M).

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Ævar Arnfjörð Bjarmason]

On Thu, Aug 03 2017, Junio C. Hamano jotted:

> Sahil Dua  writes:
>
>> Ah! I had skipped this reply from Ramsay earlier.
>>
>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
>> ...
  I personally do not think "branch --copy master backup" while on
  "master" that switches to "backup" is a good UI, and I *will* say
  "I told you so" when users complain after we merge this down to
  'master'.
>>>
>>> I wouldn't normally comment on an issue like this because I am
>>> not very good at specifying, designing and evaluating UIs (so
>>> who in their right mind would listen to me). ;-)
>>>
>>> FWIW, I suspect that I would not like using this interface either
>>> and would, therefore, not use it.
>>
>> Does that mean you'd use it when "branch --copy feature-branch
>> new-feature-branch" in the case when you would want to start working
>> on a new branch (to modify or experiment with your current feature
>> branch) on top of a branch keeping intact all the configuration and
>> logs?
>
> I am not Ramsay, but your choice of branch names in your question,
> i.e. "branch --copy feature new-feature", is what we do not agree
> with in the first place, especially when we are *on* the "feature"
> branch.
>
> We view "copy A B" as a way to make a back-up of A in B.  I.e. We
> want to keep working on A, but just in case we screw up badly, make
> a backup copy of A in B, so that we can recover by a "branch --move
> B A" later if needed.  So touching B is the last thing we want to do
> after "copy A B" operation---hence we do not want to switch to B.
>
> That is not to say that you are wrong to wish to create a new
> branch, check it out and start working on it with a single command.
> We already have such a command all Git users are accustomed to,
> which is "git checkout -b new-feature-branch feature-branch".
>
> That existing command does not copy things other than the commit
> object name from "feature-branch", and I do not think it should by
> default.  But I do not think it is wrong to extend it with a new
> option (think of it as "checkout --super-b" ;-) to copy other things
> like branch descriptions etc.
>
> So from that point of view, your new feature conceptually fits a lot
> better to "git checkout", and does not belong to "git branch".  That
> is why I do not think "git branch --copy A B" while you are on A
> should check out B after creating the copy.

We've talked how this UX should look before on-list. Rather than
re-hashing the arguments I had before I thought it was useful to present
it as a table. Here's how the patch looks now:


|+--+---+-+-+-|
| cmd| creates new? | moves | copies? | ...with 
config? | checks out? |

|+--+---+-+-+-|
| branch   | Y| N | N   | N   
| N   |
| checkout | Y| N | N   | N   
| Y   |
| checkout -b   | Y| N | Y   | N   
| Y   |
| branch -m| Y| Y | N   | Y   
| Y   |
| NEW: branch -c   | Y| N | Y   | Y   
| Y   |

|+--+---+-+-+-|

In previous discussion my understanding was that you preferred the
following (as an ad-hoc word-diff)


|+--+---+-+-+-|
| cmd| creates new? | moves | copies? | ...with 
config? | checks out? |
[... stuff above this point is the same ...]
| NEW: branch -c   | Y| N | Y   | Y   
| {-Y, +N}|

|+--+---+-+-+-|

I.e. have "branch -c " but just make it not checkout the new
thing. What you're describing above sounds to me like:


|---+--+---+-+-+-|
| cmd   | creates new? | moves | 
copies? | ...with config? | checks out? |
[... stuff above this point is the same ...]
| branch -m   | Y| Y | N  
 | Y   | Y   |
[... so is branch -m but included for context ...]
| NEW: checkout --super-b -b   | Y| N | Y  
 | Y   | Y   |

|---+--+---+-+-+-|

As (IIRC) noted in some earlier mail of mine: I don't disagree with what
you're suggesting, and this horror of a checkout/branch UX is not
something anyone would have made from 

bug: git stash list --format='%gd' --date=format:'…'

[Stephen Talley]

Synopsis:

When expanding '%gd' placeholder (reflog selector), git substitutes 
user-specified --date format, which mangles the reflog.

Description:

I was writing a script that expects a stash reflog and a date on stdin:

% git stash list --format='%gd%n%ad'
stash@{0}
Sat Aug 5 13:26:30 2017 -0400
stash@{1}
Sat Aug 5 13:18:54 2017 -0400
…

Since this date is going to be presented to the user, I wanted to apply my own 
date format:

% git stash list --format='%gd%n%ad' --date=format:%Y/%m/%d
stash@{2017/08/05}
2017/08/05
stash@{2017/08/05}
2017/08/05
…

Unfortunately this mangles the reflog as well (e.g. "stash@{2017/08/05}"), 
making it useless when passed back to git.

Apparently stashes can be referenced by date, which is fine I suppose.  But 
those dates should never be subject to user-defined formatting via 
--date=format:….

I'd expect the above command to instead output:

% git stash list --format='%gd%n%ad' --date=format:%Y/%m/%d
stash@{0}
2017/08/05
stash@{1}
2017/08/05
…

or at least always use the ISO date format:

% git stash list --format='%gd%n%ad'
stash@{2017-08-05 13:26:30 -0400}
2017-08-05 13:26:30 -0400
stash@{2017-08-05 13:18:54 -0400}
2017-08-05 13:18:54 -0400
…

Steve

Re: [GSoC][PATCH 08/13] submodule: port submodule subcommand 'summary' from shell to C

[Prathamesh Chavan]

On Sat, Aug 5, 2017 at 10:25 PM, Christian Couder
 wrote:
> On Sat, Aug 5, 2017 at 12:28 PM, Prathamesh Chavan  wrote:
>> On Tue, Aug 1, 2017 at 4:57 AM, Christian Couder
>>  wrote:
>>> On Mon, Jul 31, 2017 at 10:56 PM, Prathamesh Chavan  
>>> wrote:
>>>
>> We can avoid it to behave same for "" and NULL, by checking if diff_cmd
>> is "cmd_diff_files", since its value is set NULL by this case.
>>
>> ret = compute_summary_module_list(strcmp(diff_cmd, "diff-files") ?
>> NULL: sb.buf, );
>> strbuf_release();
>
> It looks error prone, more fagile and less efficient to me.

I think by using enum { DIFF_INDEX, DIFF_FILES },
we can avoid using strcmp() here, and make it more efficient
not only here but also in other parts of the code, since
all such steps involving strcmp could be removed.

Thanks,
Prathamesh Chavan

Re: [GSoC][PATCH 08/13] submodule: port submodule subcommand 'summary' from shell to C

[Christian Couder]

On Sat, Aug 5, 2017 at 12:28 PM, Prathamesh Chavan  wrote:
> On Tue, Aug 1, 2017 at 4:57 AM, Christian Couder
>  wrote:
>> On Mon, Jul 31, 2017 at 10:56 PM, Prathamesh Chavan  
>> wrote:
>>
> We can avoid it to behave same for "" and NULL, by checking if diff_cmd
> is "cmd_diff_files", since its value is set NULL by this case.
>
> ret = compute_summary_module_list(strcmp(diff_cmd, "diff-files") ?
> NULL: sb.buf, );
> strbuf_release();

It looks error prone, more fagile and less efficient to me.

> instead of:
> ret = compute_summary_module_list(sb.len ? sb.buf : NULL, );
> if (sb.len)
> strbuf_release();

I think it is ok to call strbuf_release() many times, so the "if
(sb.len)" check above is not needed.

Assalamu`Alaikum.

[Mohammad Ouattara]

Greetings from Dr. mohammad ouattara.
 
Assalamu`Alaikum.
 
My Name is Dr. mohammad ouattara, I am a banker by profession. I'm from 
Ouagadougou, Burkina Faso, West Africa. My reason for contacting you is to 
transfer an abandoned $14.6M to your account.
 
The owner of this fund died since 2004 with his Next Of Kin. I want to present 
you to the bank as the Next of Kin/beneficiary of this fund.
 
Further details of the transaction shall be forwarded to you as soon as I 
receive your return mail indicating your interest.

1) YOUR FULL NAME...
(2) YOUR AGE AND SEX
(3) YOUR CONTACT ADDRESS..
(4) YOUR PRIVATE PHONE N0..
(5) FAX NUMBER..
(6) YOUR COUNTRY OF ORIGIN..
(7) YOUR OCCUPATION.

Have a great day,
Dr. mohammad ouattara.
  
 

Re: [GSoC][PATCH 08/13] submodule: port submodule subcommand 'summary' from shell to C

[Prathamesh Chavan]

On Tue, Aug 1, 2017 at 4:57 AM, Christian Couder
 wrote:
> On Mon, Jul 31, 2017 at 10:56 PM, Prathamesh Chavan  wrote:
>
>> * variable head was no longer used in module_summary() and instead the strbuf
>>   was utilized.
>
> Good but there might be a few problems in the way it is used. See below.
>
>> +static int compute_summary_module_list(char *head, struct summary_cb *info)
>> +{
>> +   struct argv_array diff_args = ARGV_ARRAY_INIT;
>> +   struct rev_info rev;
>> +   struct module_cb_list list = MODULE_CB_LIST_INIT;
>> +
>> +   argv_array_push(_args, info->diff_cmd);
>> +   if (info->cached)
>> +   argv_array_push(_args, "--cached");
>> +   argv_array_pushl(_args, "--ignore-submodules=dirty", "--raw",
>> +NULL);
>> +   if (head)
>> +   argv_array_push(_args, head);
>> +   argv_array_push(_args, "--");
>> +   if (info->argc)
>> +   argv_array_pushv(_args, info->argv);
>> +
>> +   git_config(git_diff_basic_config, NULL);
>> +   init_revisions(, info->prefix);
>> +   gitmodules_config();
>> +   rev.abbrev = 0;
>> +   precompose_argv(diff_args.argc, diff_args.argv);
>> +
>> +   diff_args.argc = setup_revisions(diff_args.argc, diff_args.argv,
>> +, NULL);
>> +   rev.diffopt.output_format = DIFF_FORMAT_NO_OUTPUT | 
>> DIFF_FORMAT_CALLBACK;
>> +   rev.diffopt.format_callback = submodule_summary_callback;
>> +   rev.diffopt.format_callback_data = 
>> +
>> +   if (!info->cached) {
>> +   if (!strcmp(info->diff_cmd, "diff-index"))
>> +   setup_work_tree();
>> +   if (read_cache_preload() < 0) {
>> +   perror("read_cache_preload");
>> +   return -1;
>> +   }
>> +   } else if (read_cache() < 0) {
>> +   perror("read_cache");
>> +   return -1;
>> +   }
>> +
>> +   if (!strcmp(info->diff_cmd, "diff-index"))
>> +   run_diff_index(, info->cached);
>> +   else
>> +   run_diff_files(, 0);
>> +   prepare_submodule_summary(info, );
>> +
>> +   free(head);
>
> It is a bit strange to have this function free() an argument it is passed.
>
>> +   return 0;
>> +
>
> Spurious new line.
>
>> +}
>> +
>> +static int module_summary(int argc, const char **argv, const char *prefix)
>> +{
>> +   struct summary_cb info = SUMMARY_CB_INIT;
>> +   int cached = 0;
>> +   char *diff_cmd = "diff-index";
>> +   int for_status = 0;
>> +   int quiet = 0;
>> +   int files = 0;
>> +   int summary_limits = -1;
>> +   struct child_process cp_rev = CHILD_PROCESS_INIT;
>> +   struct strbuf sb = STRBUF_INIT;
>
> [...]
>
>> +   if (!capture_command(_rev, , 0)) {
>> +   strbuf_strip_suffix(, "\n");
>> +   if (argc) {
>> +   argv++;
>> +   argc--;
>> +   }
>> +   } else if (!argc || !strcmp(argv[0], "HEAD")) {
>> +   /* before the first commit: compare with an empty tree */
>> +   struct stat st;
>> +   struct object_id oid;
>> +   if (fstat(0, ) < 0 || index_fd(oid.hash, 0, , 2, 
>> prefix, 3))
>> +   die("Unable to add %s to database", oid.hash);
>> +   strbuf_addstr(, oid_to_hex());
>> +   if (argc) {
>> +   argv++;
>> +   argc--;
>> +   }
>> +   } else {
>> +   strbuf_addstr(, "HEAD");
>> +   }
>> +
>> +   if (files) {
>> +   if (cached)
>> +   die(_("The --cached option cannot be used with the 
>> --files option"));
>> +   diff_cmd = "diff-files";
>> +
>> +   strbuf_reset();
>
> strbuf_reset() does not free the memory allocated to sb.buf...
>
>> +   sb.buf = NULL;
>
> ...then this makes sure that the memory previously allocated to sb.buf
> will not be free()d.
>
> Maybe instead of the above 2 lines just: strbuf_release()
> Or maybe just don't set sb.buf to NULL.
>
>> +   }
>> +
>> +   info.argc = argc;
>> +   info.argv = argv;
>> +   info.prefix = prefix;
>> +   info.cached = !!cached;
>> +   info.for_status = !!for_status;
>> +   info.quiet = quiet;
>> +   info.files = files;
>> +   info.summary_limits = summary_limits;
>> +   info.diff_cmd = diff_cmd;
>> +
>> +   return compute_summary_module_list(strbuf_detach(, NULL), );
>
> Maybe you could pass: "sb.len > 0 ? strbuf_detach(, NULL) : NULL"
> This way if sb has previously been released or reset, NULL will be passed.
>
> I would suggest though to just pass sb.buf and to strbuf_release()
> after calling compute_summary_module_list() and before returning from
> module_summary() instead of having 

Hello Beautiful,

[Jack]

Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.

[PATCH] Drop some dashes from built-in invocations in scripts

[Michael Forney]

This way, they still work even if the built-in symlinks aren't
installed.

Signed-off-by: Michael Forney 
---
It looks like there was an effort to do this a number of years ago (through
`make remove-dashes`). These are just a few I noticed were still left in the
.sh scripts.

 git-merge-octopus.sh  | 2 +-
 git-merge-one-file.sh | 8 
 git-merge-resolve.sh  | 2 +-
 git-stash.sh  | 2 +-
 git-submodule.sh  | 6 +++---
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index bcf0d92ec..6c390d6c2 100755
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -100,7 +100,7 @@ do
if test $? -ne 0
then
gettextln "Simple merge did not work, trying automatic merge."
-   git-merge-index -o git-merge-one-file -a ||
+   git merge-index -o git-merge-one-file -a ||
OCTOPUS_FAILURE=1
next=$(git write-tree 2>/dev/null)
fi
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 424b034e3..9879c5939 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -115,16 +115,16 @@ case "${1:-.}${2:-.}${3:-.}" in
;;
esac
 
-   src1=$(git-unpack-file $2)
-   src2=$(git-unpack-file $3)
+   src1=$(git unpack-file $2)
+   src2=$(git unpack-file $3)
case "$1" in
'')
echo "Added $4 in both, but differently."
-   orig=$(git-unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
+   orig=$(git unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
;;
*)
echo "Auto-merging $4"
-   orig=$(git-unpack-file $1)
+   orig=$(git unpack-file $1)
;;
esac
 
diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
index c9da747fc..343fe7bcc 100755
--- a/git-merge-resolve.sh
+++ b/git-merge-resolve.sh
@@ -45,7 +45,7 @@ then
exit 0
 else
echo "Simple merge failed, trying Automatic merge."
-   if git-merge-index -o git-merge-one-file -a
+   if git merge-index -o git-merge-one-file -a
then
exit 0
else
diff --git a/git-stash.sh b/git-stash.sh
index 9b6c2da7b..9aa09c3a3 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -573,7 +573,7 @@ apply_stash () {
 
if test -n "$u_tree"
then
-   GIT_INDEX_FILE="$TMPindex" git-read-tree "$u_tree" &&
+   GIT_INDEX_FILE="$TMPindex" git read-tree "$u_tree" &&
GIT_INDEX_FILE="$TMPindex" git checkout-index --all &&
rm -f "$TMPindex" ||
die "$(gettext "Could not restore untracked files from stash 
entry")"
diff --git a/git-submodule.sh b/git-submodule.sh
index e131760ee..ffa2d6648 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -864,7 +864,7 @@ cmd_summary() {
test $status != A && test $ignore_config = all 
&& continue
fi
# Also show added or modified modules which are checked 
out
-   GIT_DIR="$sm_path/.git" git-rev-parse --git-dir 
>/dev/null 2>&1 &&
+   GIT_DIR="$sm_path/.git" git rev-parse --git-dir 
>/dev/null 2>&1 &&
printf '%s\n' "$sm_path"
done
)
@@ -898,11 +898,11 @@ cmd_summary() {
missing_dst=
 
test $mod_src = 16 &&
-   ! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_src^0 
>/dev/null &&
+   ! GIT_DIR="$name/.git" git rev-parse -q --verify $sha1_src^0 
>/dev/null &&
missing_src=t
 
test $mod_dst = 16 &&
-   ! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_dst^0 
>/dev/null &&
+   ! GIT_DIR="$name/.git" git rev-parse -q --verify $sha1_dst^0 
>/dev/null &&
missing_dst=t
 
display_name=$(git submodule--helper relative-path "$name" 
"$wt_prefix")
-- 
2.13.3