Re: [ANNOUNCE] git-sizer: compute various size-related metrics for your Git repository

[Johannes Schindelin]

Hi Michael,

On Fri, 16 Mar 2018, Michael Haggerty wrote:

> What makes a Git repository unwieldy to work with and host? It turns
> out that the respository's on-disk size in gigabytes is only part of
> the story. From our experience at GitHub, repositories cause problems
> because of poor internal layout at least as often as because of their
> overall size. For example,
> 
> * blobs or trees that are too large
> * large blobs that are modified frequently (e.g., database dumps)
> * large trees that are modified frequently
> * trees that expand to unreasonable size when checked out (e.g., "Git
> bombs" [2])
> * too many tiny Git objects
> * too many references
> * other oddities, such as giant octopus merges, super long reference
> names or file paths, huge commit messages, etc.
> 
> `git-sizer` [1] is a new open-source tool that computes various
> size-related statistics for a Git repository and points out those that
> are likely to cause problems or inconvenience to its users.

Thank you very much for sharing this tool.

I packaged this as a MSYS2 package for use in Git for Windows' SDKs. You
can install it via

pacman -Sy mingw-w64-x86_64-git-sizer

(obviously, if you are in a 32-bit SDK you want to replace x86_64 by i686)

Note: I am simply re-bundling the binaries you post to the GitHub
releases; The main purpose is to make it easier for users to include this
in their custom installers.

Second note: I briefly considered including this tool in Git for Windows,
but it does increase the size of the installer by a full megabyte, and
therefore I decided to keep it as SDK-only, optional package.

Thanks!
Dscho

Re: [ANNOUNCE] git-sizer: compute various size-related metrics for your Git repository

[Michael Haggerty]

On Fri, Mar 16, 2018 at 10:29 PM, Jeff King  wrote:
> On Fri, Mar 16, 2018 at 09:01:42PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> One thing that can make repositories very pathological is if the ratio
>> of trees to commits is too low.
>>
>> I was dealing with a repo the other day that had several thousand files
>> all in the same root directory, and no subdirectories.
>
> We've definitely run into this problem before (CocoaPods/Specs, for
> example). The metric that would hopefully show this off is "what is the
> tree object with the most entries". Or possibly "what is the average
> number of entries in a tree object".

I find that the best metric for determining this sort of problem is
"Overall repository size -> Trees -> Total tree entries". If you have
a big directory that is being changed frequently, the *real* problem
is that every commit has to rewrite the whole tree, with all of its
many entries. So "Total tree entries" (or equivalently, the total tree
size) skyrockets. And this means that a history traversal has to
*expand* all of those trees again. So a repository that is problematic
for this reason will have a very large number of tree entries.

If you want to detect a bad repository layout like this *before* it
becomes a problem, then probably something like "average tree entries
per commit" might be a good leading indicator of a problem.

Michael

Re: [ANNOUNCE] git-sizer: compute various size-related metrics for your Git repository

[Jeff King]

On Fri, Mar 16, 2018 at 09:01:42PM +0100, Ævar Arnfjörð Bjarmason wrote:

> Suggestion for a thing to add to it, I don't have the time on the Go
> tuits:
> 
> One thing that can make repositories very pathological is if the ratio
> of trees to commits is too low.
> 
> I was dealing with a repo the other day that had several thousand files
> all in the same root directory, and no subdirectories.

We've definitely run into this problem before (CocoaPods/Specs, for
example). The metric that would hopefully show this off is "what is the
tree object with the most entries". Or possibly "what is the average
number of entries in a tree object".

That's not the _whole_ story, because the really pathological case is
when you then touch that giant tree a lot. But if you assume the paths
touched by commits are reasonably distributed over the tree, then having
a huge number of entries in one tree will also mean that more commits
will touch that tree. Sort of a vaguely quadratic problem.

Doing it at the root is obviously the worst case, but the same thing can
happen if you have "foo/bar" as a huge tree, and every single commit
needs to touch some variant of "foo/bar/baz".

That's why I suspect some "average per tree object" may show this type
of problem, because you'd have a lot of near-identical copies of that
giant tree if it's being modified a lot.

> But it's not something where you can just say having more trees is
> better, because on the other end of the spectrume we can imagine a repo
> like linux.git where each file like COPYING instead exists at
> C/O/P/Y/I/N/G, that would also be pathological.
> 
> It would be very interesting to do some tests to see what the optimal
> value would be.

I suspect there's some math that could give us the solution. You want
approximately equal-sized trees, so maybe log(N) levels?

-Peff

Re: [ANNOUNCE] git-sizer: compute various size-related metrics for your Git repository

[Ævar Arnfjörð Bjarmason]

On Fri, Mar 16 2018, Michael Haggerty jotted:

> What makes a Git repository unwieldy to work with and host? It turns
> out that the respository's on-disk size in gigabytes is only part of
> the story. From our experience at GitHub, repositories cause problems
> because of poor internal layout at least as often as because of their
> overall size. For example,
>
> * blobs or trees that are too large
> * large blobs that are modified frequently (e.g., database dumps)
> * large trees that are modified frequently
> * trees that expand to unreasonable size when checked out (e.g., "Git
> bombs" [2])
> * too many tiny Git objects
> * too many references
> * other oddities, such as giant octopus merges, super long reference
> names or file paths, huge commit messages, etc.
>
> `git-sizer` [1] is a new open-source tool that computes various
> size-related statistics for a Git repository and points out those that
> are likely to cause problems or inconvenience to its users.

This is a very useful tool. I've been using it to get insight into some
bad repositories.

Suggestion for a thing to add to it, I don't have the time on the Go
tuits:

One thing that can make repositories very pathological is if the ratio
of trees to commits is too low.

I was dealing with a repo the other day that had several thousand files
all in the same root directory, and no subdirectories.

This meant that doing `git log -- ` was very expensive. I wrote a
bit about this on this related ticket the other day:
https://gitlab.com/gitlab-org/gitlab-ce/issues/42104#note_54933512

But it's not something where you can just say having more trees is
better, because on the other end of the spectrume we can imagine a repo
like linux.git where each file like COPYING instead exists at
C/O/P/Y/I/N/G, that would also be pathological.

It would be very interesting to do some tests to see what the optimal
value would be.

I also suspect it's not really about the commit / tree ratio, but that
you have some reasonable amount of nested trees per file, *and* that
changes to them are reasonably spread out. I.e. it doesn't help if you
have a doc/ and a src/ directory if 99% of your commits change src/, and
if you're doing 'git log -- src/something.c'.

Which is all a very long-winded way of saying that I don't know what the
general rule is, but I have some suspicions, but having all your files
in the root is definitely bad.

[ANNOUNCE] git-sizer: compute various size-related metrics for your Git repository

[Michael Haggerty]

What makes a Git repository unwieldy to work with and host? It turns
out that the respository's on-disk size in gigabytes is only part of
the story. From our experience at GitHub, repositories cause problems
because of poor internal layout at least as often as because of their
overall size. For example,

* blobs or trees that are too large
* large blobs that are modified frequently (e.g., database dumps)
* large trees that are modified frequently
* trees that expand to unreasonable size when checked out (e.g., "Git
bombs" [2])
* too many tiny Git objects
* too many references
* other oddities, such as giant octopus merges, super long reference
names or file paths, huge commit messages, etc.

`git-sizer` [1] is a new open-source tool that computes various
size-related statistics for a Git repository and points out those that
are likely to cause problems or inconvenience to its users.

I tried to make the output of `git-sizer` "opinionated" and easy to
interpret. Example output for the Linux kernel is appended below. I
also made it memory-efficient and resistant against git bombs.

I've written a blog post [3] about `git-sizer` with more explanation
and examples, and the main project page [1] has a long README with
some information about what the individual metrics mean and tips for
fixing problems.

I also put quite a bit of effort into making `git-sizer` fast. It does
its work (including figuring out path names for large objects) based
on a single traversal of the repository history using `git rev-list
--objects --reverse [...]`, followed by using the output of `git
cat-file --batch` or `git cat-file --batch-check` to get information
about individual objects.

On that subject, let me share some more technical details. `git-sizer`
is written in Go. I prototyped several ways of extracting object
information, which is critical to the performance because `git-sizer`
has to read all of the reachable non-blob objects in the repository.
The results surprised me:

| Mechanism for accessing Git data| Time   |
| --- | -: |
| `libgit2/git2go`| 25.5 s |
| `libgit2/git2go` with `ManagedTree` optimization| 18.9 s |
| `src-d/go-git`  | 63.0 s |
| Git command line client |  6.6 s |

It was almost a factor of four faster to read and parse the output of
Git plumbing commands (mainly `git for-each-ref`, `git rev-list
--objects`, `git cat-file --batch-check`, and `git cat-file --batch`)
than it was to use the Go bindings to libgit2. (I expect that part of
the reason is that Go's peculiar stack layout makes it quite expensive
to call out to C.) Even after Carlos Martin implemented an
experimental `ManagedTree` optimization that removed the need to call
C for every entry in a tree, it was still not competitive with the Git
CLI. `go-git`, which is a Git implementation in pure Go, was even
slower. So the final version of `git-sizer` calls `git` for accessing
the repository.

Feedback is welcome, including about the weightings [4] that I use to
compute the "level of concern" of the various metrics.

Have fun,
Michael

[1] https://github.com/github/git-sizer
[2] https://kate.io/blog/git-bomb/
[3] 
https://blog.github.com/2018-03-05-measuring-the-many-sizes-of-a-git-repository/
[4] 
https://github.com/github/git-sizer/blob/2e9a30f241ac357f2af01d42f0dd51fbbbae4b0b/sizes/output.go#L330-L401

$ git-sizer --verbose
Processing blobs: 1652370
Processing trees: 3396199
Processing commits: 722647
Matching commits to trees: 722647
Processing annotated tags: 534
Processing references: 539
| Name | Value | Level of concern   |
|  | - | -- |
| Overall repository size  |   ||
| * Commits|   ||
|   * Count|   723 k   | *  |
|   * Total size   |   525 MiB | ** |
| * Trees  |   ||
|   * Count|  3.40 M   | ** |
|   * Total size   |  9.00 GiB |    |
|   * Total tree entries   |   264 M   | *  |
| * Blobs  |   ||
|   * Count|  1.65 M   | *  |
|   * Total size   |  55.8 GiB | *  |
| * Annotated tags |   ||
|   * Count|   534 ||
| * References |   ||
|   * Co

Re: Git Repository Migration

[Ævar Arnfjörð Bjarmason]

On Wed, Dec 6, 2017 at 3:02 PM, Saurabh Dixit <isaurabhdi...@gmail.com> wrote:
> Hi,
>
> I am new here. I just wondered if the Merge Requests (aka., Pull
> Requests on GitHub) are also imported or cloned while
> cloning/importing a Git repository, say from GitHub to BitBucket.
> While I consider that, it may not be possible because of the URL to a
> remote is already set and cannot be altered while the Import/Clone ( I
> could be wrong at the assumption); I am curious to know what actually
> goes behind the scene.

For Github in particular you can check out the pull refs and push them
to your new hosting provider:
https://help.github.com/articles/checking-out-pull-requests-locally/

But that's just the refs, you won't get any of the discussion around
the pull requests or other "issues" etc.

Git Repository Migration

[Saurabh Dixit]

Hi,

I am new here. I just wondered if the Merge Requests (aka., Pull
Requests on GitHub) are also imported or cloned while
cloning/importing a Git repository, say from GitHub to BitBucket.
While I consider that, it may not be possible because of the URL to a
remote is already set and cannot be altered while the Import/Clone ( I
could be wrong at the assumption); I am curious to know what actually
goes behind the scene.

Best regards,

Saurabh Dixit
Opensource Enthusiast

RE: Creating remote git repository?

[Randall S. Becker]

On December 14, 2016 1:01 AM, essam Ganadily wrote:
> given that git is an old and mature product i wounder why there is no
> command line (git.exe in windows) way of creating a remote git repository?
> 
> "git remote create repo myreponame"

Why not run the commands mkdir myreponame; cd myreponame; git init  under 
an SSH command on the destination host. That should get you what you want.
Cheers,
Randall

-- Brief whoami: NonStop developer since approximately 
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.

Re: Creating remote git repository?

[Konstantin Khomoutov]

On Wed, 14 Dec 2016 09:00:42 +0300
essam Ganadily <doctore...@gmail.com> wrote:

> given that git is an old and mature product i wounder why there is no
> command line (git.exe in windows) way of creating a remote git
> repository?
> 
> "git remote create repo myreponame"
> 
> frankly speaking i know that our friends in the linux kernel project
> never felt the need to create remote repository because they probably
> rarely need that but i guess their merciful hearts could have some
> feeling for the rest of us?

Also asked and answered (by me) over there at git-users [1].

1. https://groups.google.com/d/msg/git-users/twgkOYV6kX4/FED559TPDQAJ

Creating remote git repository?

[essam Ganadily]

given that git is an old and mature product i wounder why there is no
command line (git.exe in windows) way of creating a remote git
repository?

"git remote create repo myreponame"

frankly speaking i know that our friends in the linux kernel project
never felt the need to create remote repository because they probably
rarely need that but i guess their merciful hearts could have some
feeling for the rest of us?

[PATCH 02/16] hash-object: always try to set up the git repository

[Jeff King]

When "hash-object" is run without "-w", we don't need to be
in a git repository at all; we can just hash the object and
write its sha1 to stdout. However, if we _are_ in a git
repository, we would want to know that so we can follow the
normal rules for respecting config, .gitattributes, etc.

This happens to work at the top-level of a git repository
because we blindly read ".git/config", but as the included
test shows, it does not work when you are in a subdirectory.

The solution is to just do a "gentle" setup in this case. We
already take care to use prefix_filename() on any filename
arguments we get (to handle the "-w" case), so we don't need
to do anything extra to handle the side effects of repo
setup.

An alternative would be to specify RUN_SETUP_GENTLY for this
command in git.c, and then die if "-w" is set but we are not
in a repository. However, the error messages generated at
the time of setup_git_directory() are more detailed, so it's
better to find out which mode we are in, and then call the
appropriate function.

Signed-off-by: Jeff King <p...@peff.net>
---
 builtin/hash-object.c  | 13 -
 t/t1007-hash-object.sh | 11 +++
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/builtin/hash-object.c b/builtin/hash-object.c
index f7d3567..9028e1f 100644
--- a/builtin/hash-object.c
+++ b/builtin/hash-object.c
@@ -87,6 +87,7 @@ int cmd_hash_object(int argc, const char **argv, const char 
*prefix)
int stdin_paths = 0;
int no_filters = 0;
int literally = 0;
+   int nongit = 0;
unsigned flags = HASH_FORMAT_CHECK;
const char *vpath = NULL;
const struct option hash_object_options[] = {
@@ -107,12 +108,14 @@ int cmd_hash_object(int argc, const char **argv, const 
char *prefix)
argc = parse_options(argc, argv, NULL, hash_object_options,
 hash_object_usage, 0);
 
-   if (flags & HASH_WRITE_OBJECT) {
+   if (flags & HASH_WRITE_OBJECT)
prefix = setup_git_directory();
-   prefix_length = prefix ? strlen(prefix) : 0;
-   if (vpath && prefix)
-   vpath = prefix_filename(prefix, prefix_length, vpath);
-   }
+   else
+   prefix = setup_git_directory_gently();
+
+   prefix_length = prefix ? strlen(prefix) : 0;
+   if (vpath && prefix)
+   vpath = prefix_filename(prefix, prefix_length, vpath);
 
git_config(git_default_config, NULL);
 
diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh
index c89faa6..acca9ac 100755
--- a/t/t1007-hash-object.sh
+++ b/t/t1007-hash-object.sh
@@ -123,6 +123,17 @@ test_expect_success 'check that appropriate filter is 
invoke when --path is used
test "$file1_sha" = "$path1_sha"
 '
 
+test_expect_success 'gitattributes also work in a subdirectory' '
+   mkdir subdir &&
+   (
+   cd subdir &&
+   subdir_sha0=$(git hash-object ../file0) &&
+   subdir_sha1=$(git hash-object ../file1) &&
+   test "$file0_sha" = "$subdir_sha0" &&
+   test "$file1_sha" = "$subdir_sha1"
+   )
+'
+
 test_expect_success 'check that --no-filters option works' '
nofilters_file1=$(git hash-object --no-filters file1) &&
test "$file0_sha" = "$nofilters_file1" &&
-- 
2.10.0.230.g6f8d04b

Re: git-apply does not work in a sub-directory of a Git repository

[Junio C Hamano]

Duy Nguyen  writes:

> But your suggestion is good and I can't think of any better. We could
> introduce pathspec as ftiler after "--", but it does not look elegant,
> and it overlaps with --include/--exclude.

I was imagining that we would allow the magic pathspec syntax used
in --include/--exclude command line option parameter.  Nobody sane
uses glob special characters in their pathnames and those that do
deserve whatever breakage that comes to them.

> Perhaps we can start to warn people if --include is specified but has
> no effect for a cycle or two, then we can do as you suggested?

I do not think I'd be against going in that direction.
--
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-apply does not work in a sub-directory of a Git repository

[Duy Nguyen]

On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano  wrote:
> So a better alternative may be to conditionally disable the "Paths
> outside are not touched regardless of --include" logic, i.e. we
> exclude paths outside by default just as before, but if there is at
> least one explicit "--include" given, we skip this "return 0".
>
> That way, we do not have to commit to turning --include/--exclude to
> pathspec (which I agree is a huge change in behaviour that may not
> be a good idea) and we do not have to add "--full-tree" that is only
> understood by "apply" but not other commands that operate on the
> current directory by default.

Suppose I don't like git-apply's default behavior, I make an alias.ap
= "apply --include=*". So far so good, but when I want to limit paths
back to "subdir" (it does not have to be the same as cwd), how do I do
it without typing resorting to typing "git apply" explicitly ? I don't
see an option to cancel out --include=*. For "git ap --exclude=*
--include=subdir" to have that effect, we need to change

for (i = 0; i < limit_by_name.nr; i++) {

in use_patch() to

for (i = limit_by_name.nr - 1; i >= 0; i--) {

Simple change, but not exactly harmless.

Off topic, but --include/--exclude should be able to deal with
relative path like --include=../*.c or --include=./*. I guess nobody
has complained about it, so it's not needed.
-- 
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: git-apply does not work in a sub-directory of a Git repository

[Duy Nguyen]

On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano  wrote:
 The include/exclude mechanism does use wildmatch() but does not use
 the pathspec mechanism (it predates the pathspec machinery that was
 made reusable in places like this).  We should be able to

 $ cd d/e/e/p/d/i/r
 $ git apply --include=:/ ../../../../../../../patch

 to lift this limitation.  IOW, we can think of the use_patch() to
 include only the paths in the subdirectory we are in by default, but
 we can make it allow --include/--exclude command line option to
 override that default.
>>
>> I went with a new option instead of changing --include.
>
> It might be a "workable" band-aid, but would be an unsatisfying UI
> if it were the endgame state.  You do not say "git grep --whole" (by
> the way, "whole" is a bad option name, as you cannot tell "100% of
> *what*" you are referring to--what you are widening is the limit
> based on the location in the directory structure, so the option name
> should have some hint about it, e.g. "full-tree" or something) and
> this command will become an odd-man-out.
>
> I haven't thought things through, but thinking out aloud a few
> points...
>
>   An existing user/script may be working in a subdirectory of a huge
>   working tree and relies on the current behaviour that outside world
>   is excluded by default, and may be passing --exclude to further
>   limit the extent of damage by applying the patch to a subset of
>   paths in the current directory that itself is also huge.  And that
>   use case would not be harmed by such a change.
>
>   On the other hand, an existing user/script would not be passing an
>   "--include" that names outside the current subdirectory to force
>   them to be included, because it is known for the past 10 years not
>   to have any effect at all.

Real-world .gitignore patterns have taught me that even if it does not
have any effect, it might still be present in some scripts, waiting
for a chance to bite me.

> So a better alternative may be to conditionally disable the "Paths
> outside are not touched regardless of --include" logic, i.e. we
> exclude paths outside by default just as before, but if there is at
> least one explicit "--include" given, we skip this "return 0".
>
> That way, we do not have to commit to turning --include/--exclude to
> pathspec (which I agree is a huge change in behaviour that may not
> be a good idea) and we do not have to add "--full-tree" that is only
> understood by "apply" but not other commands that operate on the
> current directory by default.

But your suggestion is good and I can't think of any better. We could
introduce pathspec as ftiler after "--", but it does not look elegant,
and it overlaps with --include/--exclude.

Perhaps we can start to warn people if --include is specified but has
no effect for a cycle or two, then we can do as you suggested?
-- 
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: git-apply does not work in a sub-directory of a Git repository

[Junio C Hamano]

Junio C Hamano  writes:

> So a better alternative may be to conditionally disable the "Paths
> outside are not touched regardless of --include" logic, i.e. we
> exclude paths outside by default just as before, but if there is at
> least one explicit "--include" given, we skip this "return 0".
>
> That way, we do not have to commit to turning --include/--exclude to
> pathspec (which I agree is a huge change in behaviour that may not
> be a good idea) and we do not have to add "--full-tree" that is only
> understood by "apply" but not other commands that operate on the
> current directory by default.

And the necessary change to do so may look like this.  With this:

$ git show >P
$ git reset --hard HEAD^
$ cd t
$ git apply -v ../P
$ git apply -v --include=\* ../P

seem to work as expected.

diff --git a/builtin/apply.c b/builtin/apply.c
index c99..1af3f7e 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -1955,8 +1955,8 @@ static int use_patch(struct patch *p)
const char *pathname = p->new_name ? p->new_name : p->old_name;
int i;
 
-   /* Paths outside are not touched regardless of "--include" */
-   if (0 < prefix_length) {
+   /* Paths outside are not touched when there is no explicit "--include" 
*/
+   if (!has_include && 0 < prefix_length) {
int pathlen = strlen(pathname);
if (pathlen <= prefix_length ||
memcmp(prefix, pathname, prefix_length))
--
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-apply does not work in a sub-directory of a Git repository

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano  wrote:
>>> The include/exclude mechanism does use wildmatch() but does not use
>>> the pathspec mechanism (it predates the pathspec machinery that was
>>> made reusable in places like this).  We should be able to
>>>
>>> $ cd d/e/e/p/d/i/r
>>> $ git apply --include=:/ ../../../../../../../patch
>>>
>>> to lift this limitation.  IOW, we can think of the use_patch() to
>>> include only the paths in the subdirectory we are in by default, but
>>> we can make it allow --include/--exclude command line option to
>>> override that default.
>
> I went with a new option instead of changing --include.

It might be a "workable" band-aid, but would be an unsatisfying UI
if it were the endgame state.  You do not say "git grep --whole" (by
the way, "whole" is a bad option name, as you cannot tell "100% of
*what*" you are referring to--what you are widening is the limit
based on the location in the directory structure, so the option name
should have some hint about it, e.g. "full-tree" or something) and
this command will become an odd-man-out.

I haven't thought things through, but thinking out aloud a few
points...

  An existing user/script may be working in a subdirectory of a huge
  working tree and relies on the current behaviour that outside world
  is excluded by default, and may be passing --exclude to further
  limit the extent of damage by applying the patch to a subset of
  paths in the current directory that itself is also huge.  And that
  use case would not be harmed by such a change.

  On the other hand, an existing user/script would not be passing an
  "--include" that names outside the current subdirectory to force
  them to be included, because it is known for the past 10 years not
  to have any effect at all.

So a better alternative may be to conditionally disable the "Paths
outside are not touched regardless of --include" logic, i.e. we
exclude paths outside by default just as before, but if there is at
least one explicit "--include" given, we skip this "return 0".

That way, we do not have to commit to turning --include/--exclude to
pathspec (which I agree is a huge change in behaviour that may not
be a good idea) and we do not have to add "--full-tree" that is only
understood by "apply" but not other commands that operate on the
current directory by default.

I agree that the "excluded because the path is outside cwd" should
be reported just like we show notices when applying a hunk with
offset, and that the "excluded because the path is outside cwd"
should be documented.
--
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-apply does not work in a sub-directory of a Git repository

[Junio C Hamano]

Duy Nguyen  writes:

>> The include/exclude mechanism does use wildmatch() but does not use
>> the pathspec mechanism (it predates the pathspec machinery that was
>> made reusable in places like this).  We should be able to
>>
>> $ cd d/e/e/p/d/i/r
>> $ git apply --include=:/ ../../../../../../../patch
>>
>> to lift this limitation.  IOW, we can think of the use_patch() to
>> include only the paths in the subdirectory we are in by default, but
>> we can make it allow --include/--exclude command line option to
>> override that default.
>
> Interesting. Disabling that comment block seems to work ok. So
> git-apply works more like git-grep, automatically narrowing to current
> subdir, rather than full-tree like git-status.

We used to have one argument when choosing between "limit to cwd" vs
"work on full-tree" defaults, i.e. "a full-tree thing can easily be
limited to cwd by passing '.' as a pathspec, but limited-to-cwd thing
cannot be widened" before we introduced the magic "full-tree" pathspec.

This "limit to cwd" behaviour of "git apply" predates that by
several years.

> git-apply.txt should
> probably mention about this because (at least to me) it sounds more
> naturally that if I give a patch, git-apply should apply the whole
> patch.

Yes, documentation update is necessary.

> We probably should show a warning if everything file is filtered out
> too because silence usually means "good" from a typical unix command.

We should give an informational message if _anything_ is filtered
out, I would say.

--
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-apply does not work in a sub-directory of a Git repository

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

+Brian who also had issues with git-apply.

On Thu, Mar 24, 2016 at 5:49 PM, Duy Nguyen  wrote:
> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano  wrote:
>> Junio C Hamano  writes:
>>
>>> See
>>>
>>>   http://thread.gmane.org/gmane.comp.version-control.git/288316/focus=288321
>>>
>>> I agree it is bad that it silently ignores the path outside the
>>> directory.  When run with --verbose, we should say "Skipped X that
>>> is outside the directory." or something like that, just like we
>>> issue notices when we applied with offset, etc.

Implemented in [04/04] apply: report patch skipping in verbose mode.

>> Another thing we may want to do is to loosen (or redo) the logic
>> in builtin/apply.c::use_patch()
>>
>> static int use_patch(struct patch *p)
>> {
>> const char *pathname = p->new_name ? p->new_name : 
>> p->old_name;
>> int i;
>>
>> /* Paths outside are not touched regardless of "--include" */
>> if (0 < prefix_length) {
>> int pathlen = strlen(pathname);
>> if (pathlen <= prefix_length ||
>> memcmp(prefix, pathname, prefix_length))
>> return 0;
>> }
>>
>> The include/exclude mechanism does use wildmatch() but does not use
>> the pathspec mechanism (it predates the pathspec machinery that was
>> made reusable in places like this).  We should be able to
>>
>> $ cd d/e/e/p/d/i/r
>> $ git apply --include=:/ ../../../../../../../patch
>>
>> to lift this limitation.  IOW, we can think of the use_patch() to
>> include only the paths in the subdirectory we are in by default, but
>> we can make it allow --include/--exclude command line option to
>> override that default.

I went with a new option instead of changing --include. Making it
pathspec can still bite people. And pathspec is not exactly compatible
with wildmatch either. This is in

  [03/04] apply: add --whole to apply git patch without prefix filtering

> git-apply.txt should
> probably mention about this because (at least to me) it sounds more
> naturally that if I give a patch, git-apply should apply the whole
> patch.

  [02/04] git-apply.txt: mention the behavior inside a subdir

> We probably should show a warning if everything file is filtered out
> too because silence usually means "good" from a typical unix command.
> It could be guarded with advice config key, and should only show if it
> looks like there are matching paths on worktree, but filtered out.

I'm holding this back. Too much heuristics.
--
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: git-apply does not work in a sub-directory of a Git repository

[Duy Nguyen]

On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano  wrote:
> Junio C Hamano  writes:
>
>> See
>>
>>   http://thread.gmane.org/gmane.comp.version-control.git/288316/focus=288321
>>
>> I agree it is bad that it silently ignores the path outside the
>> directory.  When run with --verbose, we should say "Skipped X that
>> is outside the directory." or something like that, just like we
>> issue notices when we applied with offset, etc.
>
> Another thing we may want to do is to loosen (or redo) the logic
> in builtin/apply.c::use_patch()
>
> static int use_patch(struct patch *p)
> {
> const char *pathname = p->new_name ? p->new_name : 
> p->old_name;
> int i;
>
> /* Paths outside are not touched regardless of "--include" */
> if (0 < prefix_length) {
> int pathlen = strlen(pathname);
> if (pathlen <= prefix_length ||
> memcmp(prefix, pathname, prefix_length))
> return 0;
> }
>
> The include/exclude mechanism does use wildmatch() but does not use
> the pathspec mechanism (it predates the pathspec machinery that was
> made reusable in places like this).  We should be able to
>
> $ cd d/e/e/p/d/i/r
> $ git apply --include=:/ ../../../../../../../patch
>
> to lift this limitation.  IOW, we can think of the use_patch() to
> include only the paths in the subdirectory we are in by default, but
> we can make it allow --include/--exclude command line option to
> override that default.

Interesting. Disabling that comment block seems to work ok. So
git-apply works more like git-grep, automatically narrowing to current
subdir, rather than full-tree like git-status. git-apply.txt should
probably mention about this because (at least to me) it sounds more
naturally that if I give a patch, git-apply should apply the whole
patch.

We probably should show a warning if everything file is filtered out
too because silence usually means "good" from a typical unix command.
It could be guarded with advice config key, and should only show if it
looks like there are matching paths on worktree, but filtered out.
Hmm?

> That way, the plain-vanilla use would still retain the "when working
> in subdirectory, we only touch that subdirectory" behaviour, which
> existing scripts may depend on, but users can loosen the default as
> necessary.
-- 
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: git-apply does not work in a sub-directory of a Git repository

[Mehul Jain]

On Wed, Mar 23, 2016 at 8:51 PM, Junio C Hamano  wrote:
> I think we do have --no-index (which is why I am largely ignoring
> the rest of your message as uninformed speculation for now).

--no-index command line flag is there for git-apply but unfortunately not
documented.

Also *auto-completion* for "git apply --no-index" doesn't work.

That is

git apply --no-i

should be auto completed and give

   git apply --no-index.

Probably following change will remove this problem.

diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 45ec47f..860dae0 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -886,7 +886,7 @@ _git_apply ()
;;
--*)
__gitcomp "
-   --stat --numstat --summary --check --index
+   --stat --numstat --summary --check --index --no-index
--cached --index-info --reverse --reject --unidiff-zero
--apply --no-add --exclude=
--ignore-whitespace --ignore-space-change
--
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-apply does not work in a sub-directory of a Git repository

[Junio C Hamano]

Junio C Hamano  writes:

> See
>
>   http://thread.gmane.org/gmane.comp.version-control.git/288316/focus=288321
>
> I agree it is bad that it silently ignores the path outside the
> directory.  When run with --verbose, we should say "Skipped X that
> is outside the directory." or something like that, just like we
> issue notices when we applied with offset, etc.

Another thing we may want to do is to loosen (or redo) the logic
in builtin/apply.c::use_patch()

static int use_patch(struct patch *p)
{
const char *pathname = p->new_name ? p->new_name : p->old_name;
int i;

/* Paths outside are not touched regardless of "--include" */
if (0 < prefix_length) {
int pathlen = strlen(pathname);
if (pathlen <= prefix_length ||
memcmp(prefix, pathname, prefix_length))
return 0;
}

The include/exclude mechanism does use wildmatch() but does not use
the pathspec mechanism (it predates the pathspec machinery that was
made reusable in places like this).  We should be able to

$ cd d/e/e/p/d/i/r
$ git apply --include=:/ ../../../../../../../patch

to lift this limitation.  IOW, we can think of the use_patch() to
include only the paths in the subdirectory we are in by default, but
we can make it allow --include/--exclude command line option to
override that default.

That way, the plain-vanilla use would still retain the "when working
in subdirectory, we only touch that subdirectory" behaviour, which
existing scripts may depend on, but users can loosen the default as
necessary.
--
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-apply does not work in a sub-directory of a Git repository

[Junio C Hamano]

Duy Nguyen  writes:

> 1) add --no-index to force git-apply ignore .git, --git (or some other
> name) to apply patches as if running from topdir, add a config key to
> choose default behavior

I think we do have --no-index (which is why I am largely ignoring
the rest of your message as uninformed speculation for now).

See

  http://thread.gmane.org/gmane.comp.version-control.git/288316/focus=288321

I agree it is bad that it silently ignores the path outside the
directory.  When run with --verbose, we should say "Skipped X that
is outside the directory." or something like that, just like we
issue notices when we applied with offset, etc.

--
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-apply does not work in a sub-directory of a Git repository

[Duy Nguyen]

On Wed, Mar 23, 2016 at 5:14 AM, Stefan Beller  wrote:
>> Hello everyone,
>> As you observed, patch wasn't applied. Is it intended behaviour of
>> git-apply? Usually to apply the patch I have to copy it to top directory
>> and then use git-apply.
>>
>> I tried out git-am to apply the patch ("git format-patch" was used to
>> make patch) while being in the "outgoing" sub-directory and it worked
>> fine. So why does git-apply show this kind of behaviour?
>
>
> Think of git-apply as a specialized version of 'patch', which would also
> error out if there are path issues. (Inside outgoing/ there is no file found 
> at
> ./main)
>
> git-am is the porcelain command which is what is recommended to users
> who interact with Git and patches.

git-am is about patches in mailbox form, not plain patches, isn't it?
In that view, it's not a replacement for git-apply.

How about we start deprecating the old behavior?

1) add --no-index to force git-apply ignore .git, --git (or some other
name) to apply patches as if running from topdir, add a config key to
choose default behavior
2) when git-apply is run without --git, --index or --cached from a
subdir and the said config key is not set, start warning and
recommending --no-index
3) wait X years
4)switch default behavior to --git (if run inside a git repo)
-- 
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: git-apply does not work in a sub-directory of a Git repository

[Stefan Beller]

On Tue, Mar 22, 2016 at 5:10 AM, Mehul Jain <mehul.jain2...@gmail.com> wrote:
> Hello everyone,
>
> Recently while using git-apply, I observed that if git-apply is used in a
> sub-directory of a Git repository then it silently dies without doing
> anything.
>
> Here's what I did
>
> ~ $mkdir example
> ~ $cd example
> example $git init
> Initialized empty Git repository in /home/mj/example/.git/
> example $echo main >main
> example $git add main
> example $git commit -m 'main'
> [master (root-commit) 97aeda3] main
>  1 file changed, 1 insertion(+)
>  create mode 100644 main
> example $git checkout -b feature
> Switched to a new branch 'feature'
> example $echo modified >main
> example $git add main
> example $git commit -m 'modified'
> [feature 2551fa2] modified
>  1 file changed, 1 insertion(+), 1 deletion(-)
> example $mkdir outgoing
> example $git diff master >outgoing/feature.patch
> example $git checkout master
> Switched to branch 'master'
> example $cd outgoing/
> outgoing $git apply feature.patch
> outgoing $cd ..
> example $cat main
> main
>
> As you observed, patch wasn't applied. Is it intended behaviour of
> git-apply? Usually to apply the patch I have to copy it to top directory
> and then use git-apply.
>
> I tried out git-am to apply the patch ("git format-patch" was used to
> make patch) while being in the "outgoing" sub-directory and it worked
> fine. So why does git-apply show this kind of behaviour?
>
> Thanks,
> Mehul


Think of git-apply as a specialized version of 'patch', which would also
error out if there are path issues. (Inside outgoing/ there is no file found at
./main)

git-am is the porcelain command which is what is recommended to users
who interact with Git and patches.
--
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-apply does not work in a sub-directory of a Git repository

[Mehul Jain]

Hello everyone,

Recently while using git-apply, I observed that if git-apply is used in a
sub-directory of a Git repository then it silently dies without doing
anything.

Here's what I did

~ $mkdir example
~ $cd example
example $git init
Initialized empty Git repository in /home/mj/example/.git/
example $echo main >main
example $git add main
example $git commit -m 'main'
[master (root-commit) 97aeda3] main
 1 file changed, 1 insertion(+)
 create mode 100644 main
example $git checkout -b feature
Switched to a new branch 'feature'
example $echo modified >main
example $git add main
example $git commit -m 'modified'
[feature 2551fa2] modified
 1 file changed, 1 insertion(+), 1 deletion(-)
example $mkdir outgoing
example $git diff master >outgoing/feature.patch
example $git checkout master
Switched to branch 'master'
example $cd outgoing/
outgoing $git apply feature.patch
outgoing $cd ..
example $cat main
main

As you observed, patch wasn't applied. Is it intended behaviour of
git-apply? Usually to apply the patch I have to copy it to top directory
and then use git-apply.

I tried out git-am to apply the patch ("git format-patch" was used to
make patch) while being in the "outgoing" sub-directory and it worked
fine. So why does git-apply show this kind of behaviour?

Thanks,
Mehul
--
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

[Q] Import SVN tags into a local Git repository?

[Sedat Dilek]

[ Please CC me as I am not subscribed to this ML ]

Hi,

I have here the problem that I build LLVM/Clang out of the official
LLVM Git repositories.

But version-tagging is done in the LLVM SVN repositories (see announce
in [0] "[3.8 Release] RC3 has been tagged").

The according Git repositories have "release_38" branches (see [1]..[3]).

For building LLVM/Clang v3.8.0rc2 I used official tarballs and for
v3.8.0rc3 I built from Git as there were no source-tarballs published
(maintainers wait for all prebuilt-toolchains to be done first).

I got two statements of responsible maintainers.
(Hans is the release-manager and Anton is the LLVM-Git-repo-maintainer).
Please, read yourself.

So, my question is...
Can I import "llvm/tags/RELEASE_380/rc3/" SVN-tag into my local Git
repository (see [6])?
If YES, how can I do that?

One side-effect is...
...that my generated clang binary shows a "final" release in the
version-string (see post-scriptum).

JUST FYI:
On my Ubuntu/precise AMD64 I have git v2.7.2 and svn v1.6.17 installed.

If you need more informations, please let me know.

Regards,
- Sedat -

[0] http://lists.llvm.org/pipermail/llvm-dev/2016-February/095756.html
[1] https://github.com/llvm-mirror/llvm/tree/release_38
[2] https://github.com/llvm-mirror/clang/tree/release_38
[3] https://github.com/llvm-mirror/compiler-rt/tree/release_38
[4] http://lists.llvm.org/pipermail/llvm-dev/2016-February/095780.html
[5] http://lists.llvm.org/pipermail/llvm-dev/2016-February/095798.html
[6] 
http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
[7] http://llvm.org/pre-releases/3.8.0/rc2/

P.S.: Version mumbo-jumbo ("3.8.0rc3" built out of llvm.git#release_38
and "3.8.0rc2" from official tarballs).

[ 3.8.0rc3 ]

$ clang -v
clang version 3.8.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

[ 3.8.0rc2 ]

$ LC_ALL=C clang -v
clang version 3.8.0 (tags/RELEASE_380/rc2)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

- EOT -
--
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: Advice regarding inherited git repository

[Danielle]

> You probably should create a sandbox branch, for your own sanity.
> Because git is distributed, each separate repository is implicitly a
> branch. So if you did something like:
> 
>   1. Commit all the changes on the main site to "master". Push the
>  result to some common remote.
> 
>   2. Commit all the changes in the sandbox to its "master". Do _not_
>  push to the remote.
> 
>   3. Pull the changes from the remote into the sandbox. If they're 
worth
>  adding to the main site, push them up. If not, leave them there.
> 
> That works; "master" in the sandbox has the experimental changes, but
> you don't have to push them anywhere.  However, you are one accidental
> "git push" away from sending all of those experimental features to 
your
> remote "master". So it's easy enough to make step 1.5 "git checkout -b
> sandbox-cruft" in the sandbox repository, so git knows not to ever 
push
> it to "master".
> 
> In general, I'd also say you may benefit from splitting the changes in
> each repository into as many separate logical commits as you can (and
> possibly even to separate topic branches that you can merge
> independently). Given that you inherited this, that's _probably_ too
> much work. But if you do want to try it, I recommend "git add -p" for
> picking out individual hunks.
> 
> -Peff
> 


Thanks for answering!

I've done the above, but it caused some problems, some of which I 
haven't solved yet. What I have now is a master branch with the site in 
both repositories; and in the sandbox an additional devel branch with 
the changes done. I want to split the devel branch into the actual 
features being explored, and then merge each into master and push when 
done. The main trouble with that seems to be the settings.php file, 
which should be backed up but certainly shouldn't go from one site to 
another. Removing it from the repository caused some problems, even when 
keeping a local cache for some reason (it got lost when switching 
branches and gave me a bad moment until I figured it out). Any 
suggestions?

Add -p will certainly help in the feature branches, thanks for 
suggesting it!

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

Re: Advice regarding inherited git repository

[Jeff King]

On Tue, Jan 05, 2016 at 05:42:15PM +, Danielle wrote:

> I inherited a web site and a git repository. the git repository is cloned 
> to the website and a sandbox website (two clones). No commits have been 
> done in more than 6 months. The main site has been updated a lot of times, 
> the sandbox has lots of test and exploratory code. To bring things up to 
> date, I thought of staging and committing all the files in the main site 
> and pushing to the remote repository, and then fetching into the sandbox 
> clone and merging what is needed (which will be sooo not trivial). Does 
> this make sense? Or would it be better to create a sandbox branch somehow? 
> I'm used to working with SVN, no real git experience, so I would 
> appreciate any advice on how to manage this.

You probably should create a sandbox branch, for your own sanity.
Because git is distributed, each separate repository is implicitly a
branch. So if you did something like:

  1. Commit all the changes on the main site to "master". Push the
 result to some common remote.

  2. Commit all the changes in the sandbox to its "master". Do _not_
 push to the remote.

  3. Pull the changes from the remote into the sandbox. If they're worth
 adding to the main site, push them up. If not, leave them there.

That works; "master" in the sandbox has the experimental changes, but
you don't have to push them anywhere.  However, you are one accidental
"git push" away from sending all of those experimental features to your
remote "master". So it's easy enough to make step 1.5 "git checkout -b
sandbox-cruft" in the sandbox repository, so git knows not to ever push
it to "master".

In general, I'd also say you may benefit from splitting the changes in
each repository into as many separate logical commits as you can (and
possibly even to separate topic branches that you can merge
independently). Given that you inherited this, that's _probably_ too
much work. But if you do want to try it, I recommend "git add -p" for
picking out individual hunks.

-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

Advice regarding inherited git repository

[Danielle]

Hi all,

I inherited a web site and a git repository. the git repository is cloned 
to the website and a sandbox website (two clones). No commits have been 
done in more than 6 months. The main site has been updated a lot of times, 
the sandbox has lots of test and exploratory code. To bring things up to 
date, I thought of staging and committing all the files in the main site 
and pushing to the remote repository, and then fetching into the sandbox 
clone and merging what is needed (which will be sooo not trivial). Does 
this make sense? Or would it be better to create a sandbox branch somehow? 
I'm used to working with SVN, no real git experience, so I would 
appreciate any advice on how to manage this.

Thanks in advance,
Danielle

--
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 repository modified after migration

[Yang Yu]

I migrated a 11G git repository converted from svn on a host with
Debian 8.2, reiserfs, git 2.1.4 to a host with Ubuntu 12.04.5 LTS,
xfs, git 2.6.4. After the migration, `git status` showing a good
amount of files modified.

I did the transfer with
1) `rsync -azP`, after noticing the modified files I ran `rsync -avH
--delete` but it did not correct the problem
2) tar zcf, then on the destination download the tar.gz (served by
nginx) with wget

Both had the same result. But the original repository was still clean.

I did some comparison between "modified" and original files
a) same hash (md5sum, shasum)
b) same permission (-rw-r--r-- 1 )
c) same encoding and line termination (UTF-8 Unicode (with BOM) text,
with CRLF line terminators)
d) no git attributes for either


On the destination host, I ran `git checkout` on each of those
modified files. After one pass I got less modified files. Repeating
`git checkout` on remaining files for a few more times, finally I got
a clean repository on the destination host.

What could have caused git to consider those files as modified? And
why multiple `git checkout` again the same file was necessary?

Thanks.


Yang
--
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_WORK_TREE not set as expected when changing git repository from a script using a git alias

[Gabriel Ganne]

Hi,

Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
v2.5.1) the following workflow I use seems broken :

I wrote a script to list all git repositories that can be found from
where I am, and then call for each repository a given command.

Given the following tree, where "a" & "b" are git repositories,
├── a
│   ├── a_file
│   └── b
│   └── b_file

If I call the script from a git alias, the content of "a" will be
listed as untracked files from "b".
This is true only when called using the alias.

For example :
$ git all status # called from repository a
 [a]
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)

b/

nothing added to commit but untracked files present (use "git add" to track)
 [b]
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

deleted:../b_file

Untracked files:
  (use "git add ..." to include in what will be committed)

../a_file
./

no changes added to commit (use "git add" and/or "git commit -a"

I am afraid I did not understand the commit
d95138e695d99d32dcad528a2a7974f434c51e79, and do not know how to fix
this.
I am working around the issue by setting GIT_WORK_TREE manually.

I attached a sample with my example, the script, and the alias I used.

Best regards,

--
Gabriel Ganne


git_all_issue.tar.gz
Description: GNU Zip compressed data

Re: GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

[Duy Nguyen]

On Fri, Dec 4, 2015 at 10:54 AM, Gabriel Ganne  wrote:
> Hi,
>
> Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
> v2.5.1) the following workflow I use seems broken :

You are not the first one bitten [1] by that commit. A fix is being
worked on [2]. Sorry for the trouble.

[1] http://thread.gmane.org/gmane.comp.version-control.git/281608
[2] http://article.gmane.org/gmane.comp.version-control.git/281960
-- 
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

Signed tags and git repository

[Stephen & Linda Smith]

I've been following commits to the linux and git repostitories for some time.   
I used signed tags for
projects that I'm working on.   

I know that the linux and git repositories have signed tags, but I'm not able 
to verify 
them because my key isn't signed by anyone that leads back to one of the git or 
linux 
maintainers. Of course I live in a technical desert since there seems to be no 
one that I
can find who lives in Phoenix, AZ that has a relationship to one of those two 
git repositories.

What have others done when they want their keys signed so they can be part of 
the 
web of trust? Does either of those two projects have a formal way of 
establishing these
relationships?

sps
--
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: Signed tags and git repository

[Johannes Löthberg]

On 25/11, Stephen & Linda Smith wrote:

I know that the linux and git repositories have signed tags, but I'm not able 
to verify
them because my key isn't signed by anyone that leads back to one of the git or 
linux
maintainers.


Your key would only have to be signed for others to be able to verify 
/your/ signatures through the Web of Trust.


You don't even need the Web of Trust though, you can just verify the 
signature and then check that the key used to make the signature is the 
correct one, then you could either sign the key if you know that the key 
belongs to the right person and want to make the signature public, or 
make a local signature which is local to your keyring and won't be sent 
to eg keyservers. Or just mark the key as trusted overall.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature

Re: Signed tags and git repository

[Stephen & Linda Smith]

On Thursday, November 26, 2015 04:56:00 AM Johannes Löthberg wrote:

> You don't even need the Web of Trust though, you can just verify the 
> signature and then check that the key used to make the signature is the 
> correct one, 

Ok, but if I don't have a link to the Web or Trust, how do I know that "the
key used to make sure the signature is the correct one" (i.e. trusted).

sps


signature.asc
Description: This is a digitally signed message part.

Local git repository url

[Vambara, JayaPrakash (Infosys)]

Hi Team,

I am trying to setup a local git repository and manage it from local Jenkins 
set-up. So, both Jenkins and git are on my local desktop.

However, I am trying to give the Repository URL but with no luck.

My repository is in D drive in location D:\Git-Try

I tried to configure this Repository URL as --- file:///d/Git-Try  also 
file:///D:\Git-Try , but was not successful.

Can you please let me know what should be the Repository URL.

I have created the db in above location, pushed few files and commited them as 
well.

Thanks and Regards,
V. JayaPrakash
+91 9573457665

This e-mail and any files transmitted with it are 
confidential and may be protected by legal privilege. 
If you are not the intended recipient, please notify 
the sender and delete the e-mail from your system. 
This e-mail has been scanned for malicious content but 
the internet is inherently insecure and EDF Energy plc 
cannot accept any liability for the integrity of this 
message or its attachments. No employee or agent of EDF 
Energy plc or any related company is authorised to 
conclude any binding agreement on behalf of EDF Energy 
plc or any related company by e-mail. 

All e-mails sent and received by EDF Energy plc are 
monitored to ensure compliance with the company's 
information security policy.  Executable and script 
files are not permitted through the EDF Energy plc mail 
gateway.  EDF Energy does not accept or send mails above 
30 Mb in size.

EDF Energy plc
Registered in England and Wales No. 2366852
Registered Office: 40 Grosvenor Place, London SW1X 7EN

--
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: Local git repository url

[Jacob Keller]

On Thu, Nov 19, 2015 at 3:06 AM, Konstantin Khomoutov
<kostix+...@007spb.ru> wrote:
> On Thu, 19 Nov 2015 10:48:51 +
> "Vambara, JayaPrakash (Infosys)" <jayaprakash.vamb...@edfenergy.com>
> wrote:
>
>> I am trying to setup a local git repository and manage it from local
>> Jenkins set-up. So, both Jenkins and git are on my local desktop.
>>
>> However, I am trying to give the Repository URL but with no luck.
>>
>> My repository is in D drive in location D:\Git-Try
>>
>> I tried to configure this Repository URL as --- file:///d/Git-Try
>>  also file:///D:\Git-Try , but was not successful.
>>
>> Can you please let me know what should be the Repository URL.
>>
>> I have created the db in above location, pushed few files and
>> commited them as well.
>
> Try D:/Git-test first.
>
> Otherwise it might heavily depend on how Jenkins interprets those URLs
> and whether it even uses stock Git to access the repository (and not
> something else like JGit).
>

Jenkins Git plugin uses Git-for-Windows CLI by default. You should be
safe using any URL which works for git CLI locally. If not, I suggest
filing a bug against the Jenkins git plugin to help ensure it gets
fixed :)

Regards,
Jake
--
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: Local git repository url

[Konstantin Khomoutov]

On Thu, 19 Nov 2015 10:48:51 +
"Vambara, JayaPrakash (Infosys)" <jayaprakash.vamb...@edfenergy.com>
wrote:

> I am trying to setup a local git repository and manage it from local
> Jenkins set-up. So, both Jenkins and git are on my local desktop.
> 
> However, I am trying to give the Repository URL but with no luck.
> 
> My repository is in D drive in location D:\Git-Try
> 
> I tried to configure this Repository URL as --- file:///d/Git-Try
>  also file:///D:\Git-Try , but was not successful.
> 
> Can you please let me know what should be the Repository URL.
> 
> I have created the db in above location, pushed few files and
> commited them as well.

Try D:/Git-test first.

Otherwise it might heavily depend on how Jenkins interprets those URLs
and whether it even uses stock Git to access the repository (and not
something else like JGit).

To first rule out an issue with Jenkins you might just try cloning that
Git repo (local to local -- Git is fine with it).  Once you figure out
an URL which works for native Git (I assume you're talking about Git
for Windows), you can try to stick it to Jenkins and see it it works.
--
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] SVNGit - Checkout Git repository by SVN Client

[Yi, EungJun]

Hello, all.

I just have started to develop SVNGit, the servlet library in pure
Java for SVN Client to checkout Git repository. The project is hosted
at https://github.com/naver/svngit.

Since the project is at very early stage, SVNGit unstably supports
only a few SVN commands: checkout, update and log.

SVNGit is based on SVNKit to accept HTTP(DAV) requests from SVN client
and uses JGit to access Git repository.

If you have interest in my project, please download it and test with
your Git repositories. I will be very happy if you give me a comment,
a bug report and/or a pullrequest.

Thank you for reading.
--
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] [kernel] completion: silence fatal: Not a git repository error

[John Szakmeister]

It is possible that a user is trying to run a git command and fail to realize
that they are not in a git repository or working tree.  When trying to complete
an operation, __git_refs would fall to a degenerate case and attempt to use
git for-each-ref, which would emit the error.

Let's fix this by shunting the error message coming from git for-each-ref.

Signed-off-by: John Szakmeister j...@szakmeister.net
---
 contrib/completion/git-completion.bash | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 5ea5b82..31b4739 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -388,7 +388,8 @@ __git_refs ()
;;
*)
echo HEAD
-   git for-each-ref --format=%(refname:short) -- 
refs/remotes/$dir/ | sed -e s#^$dir/##
+   git for-each-ref --format=%(refname:short) -- \
+   refs/remotes/$dir/ 2/dev/null | sed -e s#^$dir/##
;;
esac
 }
-- 
2.0.1

--
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] [kernel] completion: silence fatal: Not a git repository error

[John Szakmeister]

On Tue, Oct 14, 2014 at 6:49 AM, John Szakmeister j...@szakmeister.net wrote:
 It is possible that a user is trying to run a git command and fail to realize
 that they are not in a git repository or working tree.  When trying to 
 complete
 an operation, __git_refs would fall to a degenerate case and attempt to use
 git for-each-ref, which would emit the error.

 Let's fix this by shunting the error message coming from git for-each-ref.

 Signed-off-by: John Szakmeister j...@szakmeister.net
 ---

Sorry for the [kernel] in the subject.  I must have forgotten to
remove that off of my format-patch invocation.  If you need me to
resubmit without it, I can do that.

Thanks!

-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] [kernel] completion: silence fatal: Not a git repository error

[Junio C Hamano]

John Szakmeister j...@szakmeister.net writes:

 It is possible that a user is trying to run a git command and fail to realize
 that they are not in a git repository or working tree.  When trying to 
 complete
 an operation, __git_refs would fall to a degenerate case and attempt to use
 git for-each-ref, which would emit the error.

 Let's fix this by shunting the error message coming from git for-each-ref.

Hmph, do you mean this one?

$ cd /var/tmp ;# not a git repository
$ git checkout TAB

-

$ git checkout fatal: Not a git repository (or any of the parent 
directories): .git
HEAD 

I agree it is ugly, but would it be an improvement for the end user,
who did not realize that she was not in a directory where git checkout
makes sense, not to tell her that she is not in a git repository in
some 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] [kernel] completion: silence fatal: Not a git repository error

[John Szakmeister]

On Tue, Oct 14, 2014 at 2:29 PM, Junio C Hamano gits...@pobox.com wrote:
 John Szakmeister j...@szakmeister.net writes:

 It is possible that a user is trying to run a git command and fail to realize
 that they are not in a git repository or working tree.  When trying to 
 complete
 an operation, __git_refs would fall to a degenerate case and attempt to use
 git for-each-ref, which would emit the error.

 Let's fix this by shunting the error message coming from git for-each-ref.

 Hmph, do you mean this one?

 $ cd /var/tmp ;# not a git repository
 $ git checkout TAB

 -

 $ git checkout fatal: Not a git repository (or any of the parent 
 directories): .git
 HEAD

 I agree it is ugly, but would it be an improvement for the end user,
 who did not realize that she was not in a directory where git checkout
 makes sense, not to tell her that she is not in a git repository in
 some way?

I had thought about that too, but I think--for me--it comes down to two things:

1) We're not intentionally trying to inform the user anywhere else
that they are not in a git repo.  We simply fail to complete anything,
which I think is an established behavior.
2) It mingles with the stuff already on the command line, making it
confusing to know what you typed.  Then you end up ctrl-c'ing your way
out of it and starting over--which is the frustrating part.

For me, I thought it better to just be more well-behaved.  I've also
run across this issue when I legitimately wanted to do something--I
wish I could remember what it was--with a remote repo and didn't
happen to be in a git working tree.  It was frustrating to see this
error message then too, for the same reason as above.  I use tab
completion quite extensively, so spitting things like this out making
it difficult to move forward is a problem.

Would it be better to check that $dir is non-empty and then provide
the extra bits of information?  We could then avoid giving the user
anything in that 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: [PATCH] [kernel] completion: silence fatal: Not a git repository error

[Junio C Hamano]

John Szakmeister j...@szakmeister.net writes:

 On Tue, Oct 14, 2014 at 2:29 PM, Junio C Hamano gits...@pobox.com wrote:
 ...
 Hmph, do you mean this one?

 $ cd /var/tmp ;# not a git repository
 $ git checkout TAB

 -

 $ git checkout fatal: Not a git repository (or any of the parent 
 directories): .git
 HEAD

 I agree it is ugly, but would it be an improvement for the end user,
 who did not realize that she was not in a directory where git checkout
 makes sense, not to tell her that she is not in a git repository in
 some way?

 I had thought about that too, but I think--for me--it comes down to two 
 things:

 1) We're not intentionally trying to inform the user anywhere else
 that they are not in a git repo.  We simply fail to complete anything,
 which I think is an established behavior.
 2) It mingles with the stuff already on the command line, making it
 confusing to know what you typed.  Then you end up ctrl-c'ing your way
 out of it and starting over--which is the frustrating part.

It is not that I am unsympathetic.  It's just it looks to me that
the patch is potentially adding one more failed step by hiding the
error message to further frustrate the user.

$ git checkout TAB
... completes nothing; puzzled but decides not to be worried for now
$ git checkout masterRET
fatal: not a git repository

As you noticed, however, we do not show the ugly error message by
design.  It is not done consistently, either (happens only when we
try to complete refnames).

I was just hoping that somebody (not necessarily you) could suggest
a way to do better than hide the error message only because it looks
ugly (iow, perhaps show it not in the middle of the command line,
and do so more consistently).  Yes I would imagine it would be a lot
harder, but the end user experience _might_ become so much better to
make it worthwhile.  I dunno.

I am not strongly opposed to queuing the 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

[ANNOUNCE] git-as-svn: subversion frontend server for git repository

[Marat Radchenko]

Some time ago I complained [1] about troubles using Git
on a project with high ratio of non-programmers.

Since then, a conclusion was made: Git is too complex.
While Git provides many nice advanced stuff, its simplest
workflow isn't simple enough.

So we examined other options:

  * Splitting project in two repos (Git + SVN). It was
thought to be the worst idea because we lost commit
atomicity

  * Use GitHub SVN integration [2]. Rejected due to security
considerations: our closed-source project isn't allowed to be
hosted outside.

  * Use GitHub Enterprise: rejected due to pricing

  * Use SubGit [3]: rejected because of its architecture.

Then, a lost'n'forgotten git_svn_server [4] was found. After playing
with it, we found out that its approach can work, though several
decisions (Python and extensive forking of `git`) made it very slow.

So we thought we're programmers, after all.

And that's when *git-as-svn* [5] was born. It is a daemon that sits
on top of Git repository and talks svn:// protocol.

Features supported:

  * checkout/update

  * log

  * blame

 
  * commit (!)  
 

 
  * rename detection (though a bit slow yet)
 

 
  * svn:eol-style   
 

 
  * Git pre-receive hooks   
 

 
  * simple or LDAP authentication   
 

 
  * partial checkout
 

 
  * sparse working copy (svn --depth/--set-depth)   
 

 
  * git submodules  
 

 
Current limitations:
 

 
  * Only a single Git branch from a single repository

  * Needs at least one commit in Git

  * Parses whole history on startup and doesn't cache it anywhere

  * You must not do 'inverted merges'. Old HEAD must be reachable from
new HEAD by first-parent traversal.

[1]: http://marc.info/?l=gitm=13980018802
[2]: https://help.github.com/articles/support-for-subversion-clients
[3]: http://subgit.com/
[4]: http://git.q42.co.uk/git_svn_server.git
[5]: https://github.com/bozaro/git-as-svn/
--
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: [ANNOUNCE] git-as-svn: subversion frontend server for git repository

[Junio C Hamano]

Marat Radchenko ma...@slonopotamus.org writes:

 Some time ago I complained [1] about troubles using Git
 on a project with high ratio of non-programmers.
 ...
 Then, a lost'n'forgotten git_svn_server [4] was found.
 ...

Interesting.

 Current limitations:
 ...
   * You must not do 'inverted merges'. Old HEAD must be reachable from
 new HEAD by first-parent traversal.

I am not sure what you mean by this to properly assess how
significant this limitation is.  Care to draw a simple picture?
--
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: [ANNOUNCE] git-as-svn: subversion frontend server for git repository

[Marat Radchenko]

On Tue, Sep 09, 2014 at 09:49:03AM -0700, Junio C Hamano wrote:
 Marat Radchenko ma...@slonopotamus.org writes:
 
  Some time ago I complained [1] about troubles using Git
  on a project with high ratio of non-programmers.
  ...
  Then, a lost'n'forgotten git_svn_server [4] was found.
  ...
 
 Interesting.

Actually, no. As I said, git_svn_server made several ineffective
architectural choices. It can be viewed as a proof-of-concept work though.

  Current limitations:
  ...
* You must not do 'inverted merges'. Old HEAD must be reachable from
  new HEAD by first-parent traversal.
 
 I am not sure what you mean by this to properly assess how
 significant this limitation is.  Care to draw a simple picture?

SVN doesn't support nonlinear history (except merge-info crutch).

Thus, we only expose main history line to SVN where main means
reachable through first-parent traversal from branch tip.

To keep SVN history consistent, commits that once became visible to SVN
have to remain visible. This limitation will be removed when git-as-svn
gets persistent storage and will be able to remember what *was* main line.

Imagine you had following history:

--- time ---

A -- B -- C

Now you merge (via Git) a feature branch:

A -- B -- C -- G
 \/
  D -- E --- F

For SVN, history will look this way:

A -- B -- C -- F

We might introduce merge-info support for this one day.

And now the *bad* case. You have the same initial history but do *inverted 
merge*:

A -- D -- E -- F -- G'
 \ /
  B -- C -/
   ^
   |
Previous branch tip

That's where things brake because for SVN, history transforms from

A -- B -- C

to

A -- D -- E -- F -- G'

And all users who checked out revisions B  C get their working copies screwed.

This also means that push --force also must not be performed.

Quoting my initial post [1] about inverted merges (you might call them
merges with swapped parents).

 I call it swapped/reverse merge problem.

 In short:
 1. Hack, hack, hack
 2. Commit
 3. Push, woops, reject (non-ff)
 4. Pull
 5. Push

 The root of evil is step #4 that creates a merge commit with swapped 
 parents - 
 local commits become first parent, remote commits become second. If one would 
 want to 
 make proper parent order, he would have to: 1. git fetch
 2. git checkout origin/master -b tmp
 3. git merge master
 4. git push
 5. git checkout master
 6. git merge origin/master
 7. git branch -d tmp
 
 And all this branch dance produces exactly the same commit (content-wise) as 
 simple
 pull, push sequence with the only difference in parent order. And things 
 become
 even worse if comeone pushes more commits to remote repo while you perform 
 this
 dance.

 We can't expect all developers (especially, designers and artist) to do it. 
 They
 don't want to use branches and just work on mainline. This is especially 
 important on
 early development stages when new features (that designers' work depends 
 upon) are
 added every day.

 Additionally, many git-related tools depend on first-parent convention and 
 show wrong
 graphs/diffs.

[1] http://marc.info/?l=gitm=13980018802
--
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: [ANNOUNCE] git-as-svn: subversion frontend server for git repository

[Junio C Hamano]

Marat Radchenko ma...@slonopotamus.org writes:

* You must not do 'inverted merges'. Old HEAD must be reachable from
  new HEAD by first-parent traversal.
 
 I am not sure what you mean by this to properly assess how
 significant this limitation is.  Care to draw a simple picture?

 SVN doesn't support nonlinear history (except merge-info crutch).
 ...
 And now the *bad* case. You have the same initial history but do *inverted 
 merge*:

That is a bad way to answer a question that asks what do you mean
by an 'inverted merge', which is not in our normal lexicon? ;-)

You must not merge the current tip of SVN server *into* the
work you did on top of a past state you obtained from the
SVN server.  Check out the current state from the SVN side,
and merge your work into it instead.

or something like that is what people would understand without
introducing a new/unused word to the world.  And

 A -- D -- E -- F -- G'
  \ /
   B -- C -/
^
|
 Previous branch tip

this illustrates the topology you meant reasonably well, especially
if you marked D, E and F as your own work (as opposed to what the
server side did in the meantime while you worked, i.e. B and C).

Thanks for a clarification.


--
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: Error fatal: not a git repository after auto packing

[Duy Nguyen]

On Tue, Aug 12, 2014 at 5:56 AM, Luke Campagnola
luke.campagn...@gmail.com wrote:
 Greetings,

 I have been working happily with git for a couple of years, and ran
 into a mysterious issue today: after running a git-pull during which I
 saw the message Auto packing the repository for optimum performance.
 I now receive the error Fatal: not a git repository when running any
 git commands, and a little investigation revealed that my .git/refs
 directory has gone missing, presumably because the refs were all
 combined into .git/packed-refs. To restore access to the repository,
 all I needed was to `mkdir .git/refs`. Is this a known bug?

Not to me.

 It seems
 like either git should tolerate the absence of a .git/refs directory,
 or the auto packer should not remove it.

I tried to clone from vispy.git, running 'git gc' manually and
'pack-refs' (which should be in charge of removing empty dirs with
v1.9.1. Things worked fine. Looked at
refs.c:try_remove_empty_parents() as well. Still could not find any
bug there.. So no good news. I don't suppose that if you run git gc
again, it would remove $GIT_DIR/refs one more time?
-- 
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: Error fatal: not a git repository after auto packing

[Dennis Kaarsemaker]

On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote:
 
 raven:/home/luke/vispy (transform-cache)$ git checkout master
 Switched to branch 'master'
 Deleted 103 .pyc files
 Deleted 11 empty directories

This looks like you have a local post-checkout hook that deletes empty
directories. Fix that hook to not do anything in .git and it should be
fine.
-- 
Dennis Kaarsemaker
www.kaarsemaker.net

--
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: Error fatal: not a git repository after auto packing

[Luke Campagnola]

On Tue, Aug 12, 2014 at 12:11 PM, Dennis Kaarsemaker
den...@kaarsemaker.net wrote:
 On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote:

 raven:/home/luke/vispy (transform-cache)$ git checkout master
 Switched to branch 'master'
 Deleted 103 .pyc files
 Deleted 11 empty directories

 This looks like you have a local post-checkout hook that deletes empty
 directories. Fix that hook to not do anything in .git and it should be
 fine.

Of course you are correct. Sorry for the noise.
--
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

Error fatal: not a git repository after auto packing

[Luke Campagnola]

Greetings,

I have been working happily with git for a couple of years, and ran
into a mysterious issue today: after running a git-pull during which I
saw the message Auto packing the repository for optimum performance.
I now receive the error Fatal: not a git repository when running any
git commands, and a little investigation revealed that my .git/refs
directory has gone missing, presumably because the refs were all
combined into .git/packed-refs. To restore access to the repository,
all I needed was to `mkdir .git/refs`. Is this a known bug? It seems
like either git should tolerate the absence of a .git/refs directory,
or the auto packer should not remove it.

I am using git 1.9.1 on kubuntu 14.04. The surrounding console output follows:

raven:/home/luke/vispy (transform-cache)$ git commit -a
[transform-cache 15a0fe3] Optimizations for grid_large
 6 files changed, 91 insertions(+), 52 deletions(-)

raven:/home/luke/vispy (transform-cache)$ git push lcampagn transform-cache
Counting objects: 114, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (31/31), done.
Writing objects: 100% (31/31), 4.00 KiB | 0 bytes/s, done.
Total 31 (delta 25), reused 0 (delta 0)
To g...@github.com:lcampagn/vispy.git
   24b37a6..15a0fe3  transform-cache - transform-cache

raven:/home/luke/vispy (transform-cache)$ git fetch vispy
remote: Counting objects: 78, done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 78 (delta 34), reused 0 (delta 0)
Unpacking objects: 100% (78/78), done.
From https://github.com/vispy/vispy
   ec740af..fd8aa37  master - vispy/master
Auto packing the repository for optimum performance. You may also
run git gc manually. See git help gc for more information.
Counting objects: 5349, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5315/5315), done.
Writing objects: 100% (5349/5349), done.
Total 5349 (delta 3977), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.

raven:/home/luke/vispy (transform-cache)$ git checkout master
Switched to branch 'master'
Deleted 103 .pyc files
Deleted 11 empty directories

raven:/home/luke/vispy$ git pull vispy master
fatal: Not a git repository (or any of the parent directories): .git

raven:/home/luke/vispy$ git status
fatal: Not a git repository (or any of the parent directories): .git

raven:/home/luke/vispy$ ls -al .git
total 288
drwxr-xr-x   6 luke luke   4096 Aug 11 17:09 .
drwxr-xr-x   9 luke luke   4096 Aug 11 09:25 ..
-rw-r--r--   1 luke luke601 Aug 11 12:22 COMMIT_EDITMSG
-rw-rw-r--   1 luke luke   1088 Aug 11 09:21 config
-rw-r--r--   1 luke luke 73 Mar  2 08:41 description
-rw-r--r--   1 luke luke323 Aug 11 16:56 FETCH_HEAD
-rw-r--r--   1 luke luke337 Mar  3 10:18 GIT_COLA_MSG
-rw-r--r--   1 luke luke 193478 Aug 11 11:14 gitk.cache
-rw-rw-r--   1 luke luke 23 Aug 11 17:09 HEAD
drwxr-xr-x   2 luke luke   4096 Mar  8 07:30 hooks
-rw-rw-r--   1 luke luke  31104 Aug 11 17:09 index
drwxr-xr-x   2 luke luke   4096 Aug 11 16:57 info
drwxr-xr-x   3 luke luke   4096 Aug 11 16:56 logs
drwxr-xr-x 105 luke luke   4096 Aug 11 16:57 objects
-rw-rw-r--   1 luke luke 41 Aug 11 09:25 ORIG_HEAD
-rw-rw-r--   1 luke luke   8210 Aug 11 16:56 packed-refs
--
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] Windows: Allow using UNC path for git repository

[Junio C Hamano]

Stepan Kasal ka...@ucw.cz writes:

 From: Cezary Zawadka czawa...@gmail.com
 Date: Tue, 13 Jul 2010 16:17:43 +0200

 [efl: moved MinGW-specific part to compat/]
 [jes: fixed compilation on non-Windows]

 Eric Sunshine fixed mingw_offset_1st_component() to return consistently foo
 for UNC //machine/share/foo, cf
 http://groups.google.com/group/msysgit/browse_thread/thread/c0af578549b5dda0

 Author: Eric Sunshine sunsh...@sunshineco.com
 Signed-off-by: Cezary Zawadka czawa...@gmail.com
 Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
 Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
 Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
 Signed-off-by: Stepan Kasal ka...@ucw.cz
 ---

 Hello,
 this is another patch that lived in msysGit for years, at least from
 Jul 13, 2010.  It was there in two parts, first sketch by Cezary and
 a fix from Eric Sunshine, but I decided to submit the combined
 version.

 Let me note that this patch should not affect any non-Windows
 platform.  The chnage of offset_1st_component() to a simple macro is
 ok, because has_dos_drive_prefix() is 0 there.

As I do not think anybody takes the address of the function, I agree
it should be a no-op for non-Windows platform.

It would be nice if somebody in the S-o-b chain can double-check
that the combined version is sane.  I didn't read the mingw.c part
carefully enough for me to say returning 0 upon error is sane with
confidence, for example.

Thanks.

 Regards,
   Stepan

  cache.h   |  1 -
  compat/mingw.c| 24 
  compat/mingw.h|  2 ++
  git-compat-util.h |  4 
  path.c|  7 ---
  5 files changed, 30 insertions(+), 8 deletions(-)

 diff --git a/cache.h b/cache.h
 index ebe9a40..0961fb5 100644
 --- a/cache.h
 +++ b/cache.h
 @@ -781,7 +781,6 @@ int normalize_path_copy(char *dst, const char *src);
  int longest_ancestor_length(const char *path, struct string_list *prefixes);
  char *strip_path_suffix(const char *path, const char *suffix);
  int daemon_avoid_alias(const char *path);
 -int offset_1st_component(const char *path);
  
  /* object replacement */
  #define LOOKUP_REPLACE_OBJECT 1
 diff --git a/compat/mingw.c b/compat/mingw.c
 index e9892f8..a0e13bc 100644
 --- a/compat/mingw.c
 +++ b/compat/mingw.c
 @@ -1823,3 +1823,27 @@ pid_t waitpid(pid_t pid, int *status, int options)
   errno = EINVAL;
   return -1;
  }
 +
 +int mingw_offset_1st_component(const char *path)
 +{
 + int offset = 0;
 + if (has_dos_drive_prefix(path))
 + offset = 2;
 +
 + /* unc paths */
 + else if (is_dir_sep(path[0])  is_dir_sep(path[1])) {
 +
 + /* skip server name */
 + char *pos = strpbrk(path + 2, \\/);
 + if (!pos)
 + return 0; /* Error: malformed unc path */
 +
 + do {
 + pos++;
 + } while (*pos  !is_dir_sep(*pos));
 +
 + offset = pos - path;
 + }
 +
 + return offset + is_dir_sep(path[offset]);
 +}
 diff --git a/compat/mingw.h b/compat/mingw.h
 index e033e72..3eaf822 100644
 --- a/compat/mingw.h
 +++ b/compat/mingw.h
 @@ -339,6 +339,8 @@ static inline char *mingw_find_last_dir_sep(const char 
 *path)
   return ret;
  }
  #define find_last_dir_sep mingw_find_last_dir_sep
 +int mingw_offset_1st_component(const char *path);
 +#define offset_1st_component mingw_offset_1st_component
  #define PATH_SEP ';'
  #define PRIuMAX I64u
  #define PRId64 I64d
 diff --git a/git-compat-util.h b/git-compat-util.h
 index d493a8c..ec41cfb 100644
 --- a/git-compat-util.h
 +++ b/git-compat-util.h
 @@ -270,6 +270,10 @@ extern char *gitbasename(char *);
  #define has_dos_drive_prefix(path) 0
  #endif
  
 +#ifndef offset_1st_component
 +#define offset_1st_component(path) (is_dir_sep((path)[0]))
 +#endif
 +
  #ifndef is_dir_sep
  #define is_dir_sep(c) ((c) == '/')
  #endif
 diff --git a/path.c b/path.c
 index f9c5062..bc804a3 100644
 --- a/path.c
 +++ b/path.c
 @@ -823,10 +823,3 @@ int daemon_avoid_alias(const char *p)
   }
   }
  }
 -
 -int offset_1st_component(const char *path)
 -{
 - if (has_dos_drive_prefix(path))
 - return 2 + is_dir_sep(path[2]);
 - return is_dir_sep(path[0]);
 -}
 -- 
 1.9.2.msysgit.0.490.ga07b726

 -- 
--
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] Windows: Allow using UNC path for git repository

[Stepan Kasal]

Hello,

On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote:
 It would be nice if somebody in the S-o-b chain can double-check
 that the combined version is sane.  [...]

Combined was an unfortunate word.  There was a pair of successive
commits in msysgit all the time.  I just decided to submit them
squashed together.  I haven't changed the code, just created a new
commit message.

That said, reviewing the function is always useful, of course.

Stepan
--
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] Windows: Allow using UNC path for git repository

[Junio C Hamano]

Stepan Kasal ka...@ucw.cz writes:

 Hello,

 On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote:
 It would be nice if somebody in the S-o-b chain can double-check
 that the combined version is sane.  [...]

 Combined was an unfortunate word.  There was a pair of successive
 commits in msysgit all the time.  I just decided to submit them
 squashed together.  I haven't changed the code, just created a new
 commit message.

 That said, reviewing the function is always useful, of course.

I did mis-read your message.  As the patch shows the current state
that exists in msysgit that people are happy about, the function has
already been reviewed by stakeholders, and I would be happy to apply
it.

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

[PATCH] Windows: Allow using UNC path for git repository

[Stepan Kasal]

From: Cezary Zawadka czawa...@gmail.com
Date: Tue, 13 Jul 2010 16:17:43 +0200

[efl: moved MinGW-specific part to compat/]
[jes: fixed compilation on non-Windows]

Eric Sunshine fixed mingw_offset_1st_component() to return consistently foo
for UNC //machine/share/foo, cf
http://groups.google.com/group/msysgit/browse_thread/thread/c0af578549b5dda0

Author: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Cezary Zawadka czawa...@gmail.com
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
Signed-off-by: Stepan Kasal ka...@ucw.cz
---

Hello,
this is another patch that lived in msysGit for years, at least from
Jul 13, 2010.  It was there in two parts, first sketch by Cezary and
a fix from Eric Sunshine, but I decided to submit the combined
version.

Let me note that this patch should not affect any non-Windows
platform.  The chnage of offset_1st_component() to a simple macro is
ok, because has_dos_drive_prefix() is 0 there.

Regards,
  Stepan

 cache.h   |  1 -
 compat/mingw.c| 24 
 compat/mingw.h|  2 ++
 git-compat-util.h |  4 
 path.c|  7 ---
 5 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/cache.h b/cache.h
index ebe9a40..0961fb5 100644
--- a/cache.h
+++ b/cache.h
@@ -781,7 +781,6 @@ int normalize_path_copy(char *dst, const char *src);
 int longest_ancestor_length(const char *path, struct string_list *prefixes);
 char *strip_path_suffix(const char *path, const char *suffix);
 int daemon_avoid_alias(const char *path);
-int offset_1st_component(const char *path);
 
 /* object replacement */
 #define LOOKUP_REPLACE_OBJECT 1
diff --git a/compat/mingw.c b/compat/mingw.c
index e9892f8..a0e13bc 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1823,3 +1823,27 @@ pid_t waitpid(pid_t pid, int *status, int options)
errno = EINVAL;
return -1;
 }
+
+int mingw_offset_1st_component(const char *path)
+{
+   int offset = 0;
+   if (has_dos_drive_prefix(path))
+   offset = 2;
+
+   /* unc paths */
+   else if (is_dir_sep(path[0])  is_dir_sep(path[1])) {
+
+   /* skip server name */
+   char *pos = strpbrk(path + 2, \\/);
+   if (!pos)
+   return 0; /* Error: malformed unc path */
+
+   do {
+   pos++;
+   } while (*pos  !is_dir_sep(*pos));
+
+   offset = pos - path;
+   }
+
+   return offset + is_dir_sep(path[offset]);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index e033e72..3eaf822 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -339,6 +339,8 @@ static inline char *mingw_find_last_dir_sep(const char 
*path)
return ret;
 }
 #define find_last_dir_sep mingw_find_last_dir_sep
+int mingw_offset_1st_component(const char *path);
+#define offset_1st_component mingw_offset_1st_component
 #define PATH_SEP ';'
 #define PRIuMAX I64u
 #define PRId64 I64d
diff --git a/git-compat-util.h b/git-compat-util.h
index d493a8c..ec41cfb 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -270,6 +270,10 @@ extern char *gitbasename(char *);
 #define has_dos_drive_prefix(path) 0
 #endif
 
+#ifndef offset_1st_component
+#define offset_1st_component(path) (is_dir_sep((path)[0]))
+#endif
+
 #ifndef is_dir_sep
 #define is_dir_sep(c) ((c) == '/')
 #endif
diff --git a/path.c b/path.c
index f9c5062..bc804a3 100644
--- a/path.c
+++ b/path.c
@@ -823,10 +823,3 @@ int daemon_avoid_alias(const char *p)
}
}
 }
-
-int offset_1st_component(const char *path)
-{
-   if (has_dos_drive_prefix(path))
-   return 2 + is_dir_sep(path[2]);
-   return is_dir_sep(path[0]);
-}
-- 
1.9.2.msysgit.0.490.ga07b726

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

Migration from Github hosted git repository to local server.

[shyam218]

Hi All,

Could some one help me on this please,we have few repositories in the Github
and out of them couple of them are using encryption with
git-encrypt(https://github.com/shadowhand/git-encrypt)using this they have
encrypted the whole repo.

Now,we got a requirement to move all those repositories to In house
server,just for preserving the source code from hosting in third party tool.

Anybody help me in migrating them with out loosing any history and i really
appreciate if some one can give a detailed steps on how to decrypt the
encrypted file(procedure mentioned in the git-encrypt wasn't helpful
(https://github.com/shadowhand/git-encrypt) and the link for decryption
mentioned in it is also not working)

Regards,
Shyam.



--
View this message in context: 
http://git.661346.n2.nabble.com/Migration-from-Github-hosted-git-repository-to-local-server-tp7605713.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: git-draw - draws nearly the full content of a tiny git repository as a graph

[Stefan Näwe]

Am 29.01.2014 22:21, schrieb Flo:
 I just want to present a small tool I wrote. I use it at work to have
 a tool visualizing the Git basic concepts and data structures which
 are really really really simple (Linus' words). That helps me
 teaching my colleagues about Git and answering their questions when
 Git did not behave as they expected.
 
 https://github.com/sensorflo/git-draw/wiki

This looks really promising!

Stefan
-- 

/dev/random says: Famous last words - Jesus Christ: Father, beam me up.
python -c print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
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-draw - draws nearly the full content of a tiny git repository as a graph

[John Szakmeister]

On Wed, Jan 29, 2014 at 4:21 PM, Flo sensor...@gmail.com wrote:
 I just want to present a small tool I wrote. I use it at work to have
 a tool visualizing the Git basic concepts and data structures which
 are really really really simple (Linus' words). That helps me
 teaching my colleagues about Git and answering their questions when
 Git did not behave as they expected.

 https://github.com/sensorflo/git-draw/wiki

Very nice!  Thank you!

I tried it on a couple of my test repos that I use when teaching
people and it appears you need to munge branch names that contain
hyphens in the generated dot file, or dot fails to parse the file.

Otherwise, it's a neat tool.  Thanks again!

-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

git-draw - draws nearly the full content of a tiny git repository as a graph

[Flo]

I just want to present a small tool I wrote. I use it at work to have
a tool visualizing the Git basic concepts and data structures which
are really really really simple (Linus' words). That helps me
teaching my colleagues about Git and answering their questions when
Git did not behave as they expected.

https://github.com/sensorflo/git-draw/wiki
--
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: Problem setting up a shared git repository

[Johannes Sixt]

Am 9/5/2013 23:43, schrieb Eyal Zinder:
 I'm trying to setup a distributed development repository with a central
 repository acting as the production copy.  I'm doing so on a Windows
 file share with no SSH / HTTP accessibility.  Basically each developer
 will have their own copy of the project, and the shared drive should
 have a copy of the master copy (prod/master branch), along with the
 work-tree files.
 
 The idea is that any developer should be able to do independent
 development, staged commits, etc.. then push to the central (origin)
 repository, and production scripts will reflect these changes upon a
 push.
 
 I got pretty close to this setup by creating a bare repository on the
 file share server (f:\GitDBs\foo.git), then cloning the bare repository
 onto the production path like so: git clone f:\GitDBs\foo.git foo

The setup sounds reasonable.

 I cloned the bare repository just the same onto my local dev path.. and
 proceeded with development. This worked fine, and I was able to push /
 pull changes into origin (bare repo), and then I would go to my prod
 (f:\foo) repository (clone of bare f:\GitDBs\foo.git), then pull the
 changes..

So far my understanding is that your production directory only ever issues
pulls from the bare repository. That is OK.

 The problem I faced later on was in parallel development, when changes
 were made to a file in one repository, and at the same time other
 changes made to the same file in another repository..  I couldh't push
 changes from the dev\foo to prod\foo or to origin..

Define couldn't push. What are the error messages? Is it important that
it is *the same file* to which changes were made at the same time?

Do you have receive.denyNonFastForwards set in the bare repository?

 I'm completely lost at the moment.. I try to set --git-dir or
 --work-tree and I get mixed results..

Don't do that, it should not be necessary in your setup.

-- Hannes
--
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: Problem setting up a shared git repository

[Konstantin Khomoutov]

On Thu, 5 Sep 2013 14:43:52 -0700 (PDT)
Eyal Zinder ezin...@yahoo.com wrote:

[...]
 The problem I faced later on was in parallel development, when
 changes were made to a file in one repository, and at the same time
 other changes made to the same file in another repository..  I
 couldh't push changes from the dev\foo to prod\foo or to origin..
[...]

Did Git tell you the push failed because of non-fast-forward update?
--
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

Problem setting up a shared git repository

[Eyal Zinder]

I hope it's not too inappropriate to send a random question your way, but I've 
exhausted all other means and am quite lost at the moment.. 

I'm trying to setup a distributed development repository with a central 
repository acting as the production copy.  I'm doing so on a Windows file share 
with no SSH / HTTP accessibility.  Basically each developer will have their own 
copy of the project, and the shared drive should have a copy of the master copy 
(prod/master branch), along with the work-tree files.  

The idea is that any developer should be able to do independent development, 
staged commits, etc.. then push to the central (origin) repository, and 
production scripts will reflect these changes upon a push.  

I got pretty close to this setup by creating a bare repository on the file 
share server (f:\GitDBs\foo.git), then cloning the bare repository onto the 
production path like so: 
git clone f:\GitDBs\foo.git foo  

I cloned the bare repository just the same onto my local dev path.. and 
proceeded with development. This worked fine, and I was able to push / pull 
changes into origin (bare repo), and then I would go to my prod (f:\foo) 
repository (clone of bare f:\GitDBs\foo.git), then pull the changes.. 

The problem I faced later on was in parallel development, when changes were 
made to a file in one repository, and at the same time other changes made to 
the same file in another repository..  I couldh't push changes from the dev\foo 
to prod\foo or to origin.. 

I'm completely lost at the moment.. I try to set --git-dir or --work-tree and I 
get mixed results.. either the setting is not allowed when working in bare 
repositories, or I can't run certain operations from the work-tree and 
git-dir.. like git status, which in a split git-dir / work-tree environment 
(on windows), returns an error which specifies the operation is invalid in a 
bare repository, or specifies that the work-tree is not recognized as a 
repository... :( 

Please help me.. 
I'm new to Git, but love it already.. I would hate it if I had to work without 
it.. 

Thank you in advance for all your help!


- Eyal
--
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

[PATCHv3 06/16] bash prompt: return early from __git_ps1() when not in a git repository

[SZEDER Gábor]

... to gain one level of indentation for the bulk of the function.

(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 201 ---
 1 file changed, 101 insertions(+), 100 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 3c5e62bb..a915b04c 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -341,121 +341,122 @@ __git_ps1 ()
#In PC mode PS1 always needs to be set
PS1=$ps1pc_start$ps1pc_end
fi
+   return
+   fi
+
+   local r=
+   local b=
+   local step=
+   local total=
+   if [ -d $g/rebase-merge ]; then
+   b=$(cat $g/rebase-merge/head-name 2/dev/null)
+   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
+   total=$(cat $g/rebase-merge/end 2/dev/null)
+   if [ -f $g/rebase-merge/interactive ]; then
+   r=|REBASE-i
+   else
+   r=|REBASE-m
+   fi
else
-   local r=
-   local b=
-   local step=
-   local total=
-   if [ -d $g/rebase-merge ]; then
-   b=$(cat $g/rebase-merge/head-name 2/dev/null)
-   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
-   total=$(cat $g/rebase-merge/end 2/dev/null)
-   if [ -f $g/rebase-merge/interactive ]; then
-   r=|REBASE-i
+   if [ -d $g/rebase-apply ]; then
+   step=$(cat $g/rebase-apply/next 2/dev/null)
+   total=$(cat $g/rebase-apply/last 2/dev/null)
+   if [ -f $g/rebase-apply/rebasing ]; then
+   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
+   r=|REBASE
+   elif [ -f $g/rebase-apply/applying ]; then
+   r=|AM
else
-   r=|REBASE-m
-   fi
-   else
-   if [ -d $g/rebase-apply ]; then
-   step=$(cat $g/rebase-apply/next 2/dev/null)
-   total=$(cat $g/rebase-apply/last 2/dev/null)
-   if [ -f $g/rebase-apply/rebasing ]; then
-   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
-   r=|REBASE
-   elif [ -f $g/rebase-apply/applying ]; then
-   r=|AM
-   else
-   r=|AM/REBASE
-   fi
-   elif [ -f $g/MERGE_HEAD ]; then
-   r=|MERGING
-   elif [ -f $g/CHERRY_PICK_HEAD ]; then
-   r=|CHERRY-PICKING
-   elif [ -f $g/REVERT_HEAD ]; then
-   r=|REVERTING
-   elif [ -f $g/BISECT_LOG ]; then
-   r=|BISECTING
+   r=|AM/REBASE
fi
+   elif [ -f $g/MERGE_HEAD ]; then
+   r=|MERGING
+   elif [ -f $g/CHERRY_PICK_HEAD ]; then
+   r=|CHERRY-PICKING
+   elif [ -f $g/REVERT_HEAD ]; then
+   r=|REVERTING
+   elif [ -f $g/BISECT_LOG ]; then
+   r=|BISECTING
+   fi
 
-   test -n $b ||
-   b=$(git symbolic-ref HEAD 2/dev/null) || {
-   detached=yes
-   b=$(
-   case ${GIT_PS1_DESCRIBE_STYLE-} in
-   (contains)
-   git describe --contains HEAD ;;
-   (branch)
-   git describe --contains --all HEAD ;;
-   (describe)
-   git describe HEAD ;;
-   (* | default)
-   git describe --tags --exact-match HEAD 
;;
-   esac 2/dev/null) ||
+   test -n $b ||
+   b=$(git symbolic-ref HEAD 2/dev/null) || {
+   detached=yes
+   b=$(
+   case ${GIT_PS1_DESCRIBE_STYLE-} in
+   (contains)
+   git describe --contains HEAD ;;
+   (branch)
+   git describe --contains --all HEAD ;;
+   

Re: Suggestion: add option in git-p4 to preserve user in Git repository

[Deirdre Connolly]

Olivier, did you upload your hacked version anywhere? 
I also need something like this.




--
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 v2 05/13] bash prompt: return early from __git_ps1() when not in a git repository

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

... to gain one level of indentation for the bulk of the function.

(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 201 ---
 1 file changed, 101 insertions(+), 100 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 07a6218d..96b496cc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -341,121 +341,122 @@ __git_ps1 ()
#In PC mode PS1 always needs to be set
PS1=$ps1pc_start$ps1pc_end
fi
+   return
+   fi
+
+   local r=
+   local b=
+   local step=
+   local total=
+   if [ -d $g/rebase-merge ]; then
+   b=$(cat $g/rebase-merge/head-name 2/dev/null)
+   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
+   total=$(cat $g/rebase-merge/end 2/dev/null)
+   if [ -f $g/rebase-merge/interactive ]; then
+   r=|REBASE-i
+   else
+   r=|REBASE-m
+   fi
else
-   local r=
-   local b=
-   local step=
-   local total=
-   if [ -d $g/rebase-merge ]; then
-   b=$(cat $g/rebase-merge/head-name 2/dev/null)
-   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
-   total=$(cat $g/rebase-merge/end 2/dev/null)
-   if [ -f $g/rebase-merge/interactive ]; then
-   r=|REBASE-i
+   if [ -d $g/rebase-apply ]; then
+   step=$(cat $g/rebase-apply/next 2/dev/null)
+   total=$(cat $g/rebase-apply/last 2/dev/null)
+   if [ -f $g/rebase-apply/rebasing ]; then
+   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
+   r=|REBASE
+   elif [ -f $g/rebase-apply/applying ]; then
+   r=|AM
else
-   r=|REBASE-m
-   fi
-   else
-   if [ -d $g/rebase-apply ]; then
-   step=$(cat $g/rebase-apply/next 2/dev/null)
-   total=$(cat $g/rebase-apply/last 2/dev/null)
-   if [ -f $g/rebase-apply/rebasing ]; then
-   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
-   r=|REBASE
-   elif [ -f $g/rebase-apply/applying ]; then
-   r=|AM
-   else
-   r=|AM/REBASE
-   fi
-   elif [ -f $g/MERGE_HEAD ]; then
-   r=|MERGING
-   elif [ -f $g/CHERRY_PICK_HEAD ]; then
-   r=|CHERRY-PICKING
-   elif [ -f $g/REVERT_HEAD ]; then
-   r=|REVERTING
-   elif [ -f $g/BISECT_LOG ]; then
-   r=|BISECTING
+   r=|AM/REBASE
fi
+   elif [ -f $g/MERGE_HEAD ]; then
+   r=|MERGING
+   elif [ -f $g/CHERRY_PICK_HEAD ]; then
+   r=|CHERRY-PICKING
+   elif [ -f $g/REVERT_HEAD ]; then
+   r=|REVERTING
+   elif [ -f $g/BISECT_LOG ]; then
+   r=|BISECTING
+   fi
 
-   test -n $b ||
-   b=$(git symbolic-ref HEAD 2/dev/null) || {
-   detached=yes
-   b=$(
-   case ${GIT_PS1_DESCRIBE_STYLE-} in
-   (contains)
-   git describe --contains HEAD ;;
-   (branch)
-   git describe --contains --all HEAD ;;
-   (describe)
-   git describe HEAD ;;
-   (* | default)
-   git describe --tags --exact-match HEAD 
;;
-   esac 2/dev/null) ||
+   test -n $b ||
+   b=$(git symbolic-ref HEAD 2/dev/null) || {
+   detached=yes
+   b=$(
+   case ${GIT_PS1_DESCRIBE_STYLE-} in
+   (contains)
+   git describe --contains HEAD ;;
+   (branch)
+   git 

Re: Is there a library for monitoring a git repository for any changes?

[Magnus Bäck]

On Thursday, June 06, 2013 at 23:16 EDT,
 Robert Martin rdmart...@gmail.com wrote:

 I want to work on a visualization program for git. I was hoping there
 was a library that would allow me to monitor a git repo for changes.
 Consider it like inotify, but for a git repository (in fact, I think
 it would probably have inotify under the hood).
 
 This hypothetical library would trigger an event any time the
 repository was modified, i.e. any time the graph that represents
 history was changed.
 
 Is there such a library? If not, is there a better way to monitor the
 repository so that I wouldn't need to write it myself? Would anyone
 else be interested if I wrote it myself?

'git ls-remote'? Either run periodically or, if the monitored git is
local, triggered via inotify. If you have control over the git perhaps
a post-receive hook would be useful too.

-- 
Magnus Bäck
ba...@google.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

Is there a library for monitoring a git repository for any changes?

[Robert Martin]

Hi git,

I want to work on a visualization program for git. I was hoping there
was a library that would allow me to monitor a git repo for changes.
Consider it like inotify, but for a git repository (in fact, I think
it would probably have inotify under the hood).

This hypothetical library would trigger an event any time the
repository was modified, i.e. any time the graph that represents
history was changed.

Is there such a library? If not, is there a better way to monitor the
repository so that I wouldn't need to write it myself? Would anyone
else be interested if I wrote it myself?

Cheers,


Robert
--
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-p4: Importing a Git repository into Perforce without rebasing

[Enrico Weigelt]

Hi,

snip

perhaps you should give Perfoce's git-bridge a try.


cu
-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Mobile: +49 (151) 27565287
Fax: +49 (30) 3464615-59

enrico.weig...@vnc.biz; www.vnc.de 
--
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-p4: Importing a Git repository into Perforce without rebasing

[Thomas Berg]

Hi,

On Tue, Feb 19, 2013 at 3:40 AM, Russell Myers mez...@russellmyers.com wrote:
 I'm trying to take a Git repository which has never been in Perforce
 and push it to Perforce and having difficulty.
[...]
 I know that I could create another Git repository that has some
 commits in it cloned from Perforce and rebase on top of that; however,
 the repository I'm trying to import is rather large and rebasing would
 require me to change many merge commits. I'd like to avoid doing this.
 The repository has many thousands of commits in it.

So your history is not linear and contains merges.

 In short my question is this: Using git-p4, is there a way to push a
 Git repository into Perforce without rebasing on top of commits coming
 from Perforce?

No, this is not supported. Non-linear history would be a problem for
git-p4 too, so that alone wouldn't solve your problem. git-p4 does not
have the logic needed to submit merges back to Perforce.

- Thomas
--
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-p4: Importing a Git repository into Perforce without rebasing

[Russell Myers]

Hello,

I'm trying to take a Git repository which has never been in Perforce
and push it to Perforce and having difficulty.

It would appear that git-p4 requires that a repository is cloned using
git p4 clone in order to use it to push back to Perforce. That would
not be the case here as the repository in question has never been
tracked by Perforce.

I know that I could create another Git repository that has some
commits in it cloned from Perforce and rebase on top of that; however,
the repository I'm trying to import is rather large and rebasing would
require me to change many merge commits. I'd like to avoid doing this.
The repository has many thousands of commits in it.

In short my question is this: Using git-p4, is there a way to push a
Git repository into Perforce without rebasing on top of commits coming
from Perforce?

Thanks,

Russell Myers
--
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: Pushing a git repository to a new server

[Michael J Gruber]

Jeff King venit, vidit, dixit 12.02.2013 21:42:
 On Tue, Feb 12, 2013 at 12:28:53PM +0100, Michael J Gruber wrote:
 
 I'm not sure providers like GitHub would fancy an interface which allows
 the programmatic creation of repos (giving a new meaning to fork
 bomb). But I bet you know better ;-)
 
 You can already do that:
 
   http://developer.github.com/v3/repos/#create

Nice.

I knew you knew ;)

 We rate-limit API requests, and I imagine we might do something similar
 with create-over-git. But that is exactly the kind of implementation
 detail that can go into a custom create-repo script.
 
 An alternative would be to teach git (the client) about repo types and
 how to create them. After all, a repo URL ssh://host/path gives a
 clear indication that ssh host git init path will create a repo.
 
 But that's the point of a microformat. It _doesn't_ always work, because
 the server may not allow arbitrary commands, or may have special
 requirements on top of the init. You can make the microformat be git
 init path, and servers can intercept calls to git init and translate
 them into custom magic. But I think the world is a little simpler if we
 define a new service type (alongside git-upload-pack, git-receive-pack,
 etc), and let clients request it. Then it's clear what the client is
 trying to do, it's easy for servers to hook into it, we can request it
 over http, etc. And it can be extended over time to take more fields
 (like repo description, etc).
 
 I'm really not suggesting anything drastic. The wrapper case for ssh
 would be as simple as a 3-line shell script which calls git init under
 the hood, but it provides one level of indirection that makes
 replacing/hooking it much simpler for servers. So the parts that are in
 stock git would not be much work (most of the work would be on _calling_
 it, but that is the same for adding a call to git init).
 
 I think the main reason the idea hasn't gone anywhere is that nobody
 really cares _that_ much. People just don't create repositories that
 often. I feel like this is one of those topics that comes up once a
 year, and then nothing happens on it, because people just make their
 repo manually and then stop caring about it.
 
 Just my two cents, of course. :)

Most repos are probably created by a local git init or git clone, or
by clicking a button on a provider's web interface. The need for
git-create-repo seems to be restricted to:

- command line folks who use a provider for it's hosting service and
don't fancy a web interface for repo creation

- noobs who need to get their head wrapped around local, remote,
push/pull 'n' stuff...

For the server side git-create-repo to take off we would probably need
two things (besides the client support):

- Implement and ship a git-create-repo which makes this work for git
over ssh seamlessly. (Will take some to trickle down to servers in the
wild.)

- Get a large provider to offer this.

Gitosis/Gitolite are probably to follow easily. I'm beginning to like
idea ;)

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: git svn init throws Not a git repository (or any of the parent directories): .git

[Konstantin Khomoutov]

On Wed, 13 Feb 2013 14:01:36 +0100
amccl...@gmail.com amccl...@gmail.com wrote:

 I have problem with git svn init:
 When I execute
 git svn init svn+ssh://usern...@example.com/path/repo
 I see:
 fatal: Not a git repository (or any of the parent directories): .git
 Already at toplevel, but .git not found
  at /usr/lib/git-core/git-svn line 342

Are you doing `git init` first before running `git svn init ...`?
--
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: Pushing a git repository to a new server

[Michael J Gruber]

Jeff King venit, vidit, dixit 11.02.2013 17:27:
 On Mon, Feb 11, 2013 at 02:57:51AM -0500, Ethan Reesor wrote:
 
 On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
 kostix+...@007spb.ru wrote:
 What's wrong with
 $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
 $ git push --all git@remotehost:MyOtherRepo.git
 ?

 Nothing, I just wanted to make myself a command to do that for me.
 
 We talked about this a long time ago. One problem is that it's
 inherently unportable, as the procedure to make a repo is potentially
 different on every server (and certainly that is the case between a
 regular user running stock git and something like GitHub or Google Code;
 I imagine even gitolite has some special procedures for creating repos,
 too).
 
 One proposal made in the previous discussion was to define a microformat
 for repository administration commands. So that you could connect and
 say git admin-create-repo /path/to/MyRepo.git, and the server-provided
 admin-create-repo command would take care of the details. Then stock git
 could forward it to git init --bare, GitHub could do the same and
 create the necessary database records, etc.

 And once that standardized method was in place, it would be easy to add
 a --create option to git push to request an admin-create-repo
 before pushing.
 
 I still think that's a reasonable way forward, but nobody was interested
 enough to start writing code for it.
 
 -Peff
 

I'm not sure providers like GitHub would fancy an interface which allows
the programmatic creation of repos (giving a new meaning to fork
bomb). But I bet you know better ;-)

An alternative would be to teach git (the client) about repo types and
how to create them. After all, a repo URL ssh://host/path gives a
clear indication that ssh host git init path will create a repo. I'm
wondering whether it's more likely to convince providers (the server
side) or more is gained by covering the simpler cases client-side (our
side).

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: Pushing a git repository to a new server

[Jeff King]

On Tue, Feb 12, 2013 at 12:28:53PM +0100, Michael J Gruber wrote:

 I'm not sure providers like GitHub would fancy an interface which allows
 the programmatic creation of repos (giving a new meaning to fork
 bomb). But I bet you know better ;-)

You can already do that:

  http://developer.github.com/v3/repos/#create

We rate-limit API requests, and I imagine we might do something similar
with create-over-git. But that is exactly the kind of implementation
detail that can go into a custom create-repo script.

 An alternative would be to teach git (the client) about repo types and
 how to create them. After all, a repo URL ssh://host/path gives a
 clear indication that ssh host git init path will create a repo.

But that's the point of a microformat. It _doesn't_ always work, because
the server may not allow arbitrary commands, or may have special
requirements on top of the init. You can make the microformat be git
init path, and servers can intercept calls to git init and translate
them into custom magic. But I think the world is a little simpler if we
define a new service type (alongside git-upload-pack, git-receive-pack,
etc), and let clients request it. Then it's clear what the client is
trying to do, it's easy for servers to hook into it, we can request it
over http, etc. And it can be extended over time to take more fields
(like repo description, etc).

I'm really not suggesting anything drastic. The wrapper case for ssh
would be as simple as a 3-line shell script which calls git init under
the hood, but it provides one level of indirection that makes
replacing/hooking it much simpler for servers. So the parts that are in
stock git would not be much work (most of the work would be on _calling_
it, but that is the same for adding a call to git init).

I think the main reason the idea hasn't gone anywhere is that nobody
really cares _that_ much. People just don't create repositories that
often. I feel like this is one of those topics that comes up once a
year, and then nothing happens on it, because people just make their
repo manually and then stop caring about it.

Just my two cents, of course. :)

-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: Pushing a git repository to a new server

[Jeff King]

On Mon, Feb 11, 2013 at 02:57:51AM -0500, Ethan Reesor wrote:

 On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
 kostix+...@007spb.ru wrote:
  What's wrong with
  $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
  $ git push --all git@remotehost:MyOtherRepo.git
  ?
 
 Nothing, I just wanted to make myself a command to do that for me.

We talked about this a long time ago. One problem is that it's
inherently unportable, as the procedure to make a repo is potentially
different on every server (and certainly that is the case between a
regular user running stock git and something like GitHub or Google Code;
I imagine even gitolite has some special procedures for creating repos,
too).

One proposal made in the previous discussion was to define a microformat
for repository administration commands. So that you could connect and
say git admin-create-repo /path/to/MyRepo.git, and the server-provided
admin-create-repo command would take care of the details. Then stock git
could forward it to git init --bare, GitHub could do the same and
create the necessary database records, etc.

And once that standardized method was in place, it would be easy to add
a --create option to git push to request an admin-create-repo
before pushing.

I still think that's a reasonable way forward, but nobody was interested
enough to start writing code for it.

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

Re: Pushing a git repository to a new server

[Ethan Reesor]

On Mon, Feb 11, 2013 at 11:27 AM, Jeff King p...@peff.net wrote:
[...]
 We talked about this a long time ago. One problem is that it's
 inherently unportable, as the procedure to make a repo is potentially
 different on every server (and certainly that is the case between a
 regular user running stock git and something like GitHub or Google Code;
 I imagine even gitolite has some special procedures for creating repos,
 too).

I was more interested in creating something for my self rather than
making any changes to the mainstream git.
--
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: Pushing a git repository to a new server

[Ethan Reesor]

On Mon, Feb 11, 2013 at 7:45 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
[...]
 OK, here's the sketch.
 On the server, in the home directory of your git user, you create a
 wrapper around git-receive-pack, like this:

 # mkdir ~git/git-shell-commands
 # cat ~git/git-shell-commands/git-receive-new-repo
 #!/bin/sh

 set -e -u

 if [ $# -ne 1 ]; then
 echo 'Missing required argument: directory' 2
 exit 1
 fi

 mkdir $1  git init --quiet --bare $1  git-receive-pack $1
 ^D
 # chmod +x $_

 Then, on the client side, to push a new repo, you just do

 $ git push --receive-pack=git-receive-new-repo --all git@server:repo.git

 This will make `git push` to spawn not just `git receive-pack dir` as
 it usually does but your wrapper, which would first create and
 initialize a bare repository and then spawn `git receive-pack` on it
 which would then communicate with the client side and receive
 everything from it.

 You could then create a client-side wrapper script or a Git alias for
 such creative pushing, like this:

 $ git config --add --global alias.push-new-repo \
   'push --receive-pack=git-receive-new-repo --all'

 So the whole client call is now reduced to

 $ git push-new-repo git@server:repo.git

Thanks, that's what I was going for.
--
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: Pushing a git repository to a new server

[Konstantin Khomoutov]

On Sun, Feb 10, 2013 at 04:00:56PM -0500, Ethan Reesor wrote:

 I'm looking to make a command to push a git repo to a new server. The
 way I just did it is as follows:
 
 localhost git clone --bare /path/to/MyRepo /path/to/tmpdir/MyRepo.git
 localhost tar xz /path/to/tmpdir/MyRepo.git | ssh myuser@remotehost
 tar cz \~/  # If I don't escape '~', my local machine expands it
 localhost ssh myuser@remotehost
 remotehost sudo chown -R git:git MyRepo.git

What's wrong with
$ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
$ git push --all git@remotehost:MyOtherRepo.git
?

 The reason I had to use my user is the git user's shell is git-prompt

There's no such thing as git-prompt.  The restricted login shell for
SSH-only access typically used for such a virtual Git user is
git-shell.

 and ~git/git-shell-commands is empty. I have repos set up using
 'git@remotehost:MyOtherRepo.git' as the remote and everything works.
 
 How do I make a git command that can talk to the server using
 git-prompt like the other commands do?

It's not really clear what do you want to achieve.
The reason the git-shell shell is *restricted* (read its manual page)
is to shrink the surface of possible attacks in the case the shell
account used for accessing Git repos over SSH is compromized (the key or
password stolen, for instance).  This is achieved by only allowing
commands like git-upload-pack etc in the shell (no general file
manipulation commands etc).  So what creating git command that can
talk to the server using git-prompt ... would really buy you?

I think the way to go is to start using gitolite [1] or implement by
hand a subset of what it does (a custom login shell which is allowed to
do certain things in a special area of the filesystem designated to keep
Git repositories) or just set up a special account on the server
(git-admin, for instance) which would have a regular login shell set
for it and would be in the same group as the user git (or even have
the same UID) so that they could share the files they create (subject to
active umasks of processes run as both users though).

1. https://github.com/sitaramc/gitolite

--
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: Pushing a git repository to a new server

[Ethan Reesor]

On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
 What's wrong with
 $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
 $ git push --all git@remotehost:MyOtherRepo.git
 ?

Nothing, I just wanted to make myself a command to do that for me.

 The reason I had to use my user is the git user's shell is git-prompt

 There's no such thing as git-prompt.  The restricted login shell for
 SSH-only access typically used for such a virtual Git user is
 git-shell.

Sorry, git-prompt is something I made for myself. I meant git-shell.

 It's not really clear what do you want to achieve.
 The reason the git-shell shell is *restricted* (read its manual page)
 is to shrink the surface of possible attacks in the case the shell
 account used for accessing Git repos over SSH is compromized (the key or
 password stolen, for instance).  This is achieved by only allowing
 commands like git-upload-pack etc in the shell (no general file
 manipulation commands etc).  So what creating git command that can
 talk to the server using git-prompt ... would really buy you?

I want to create a git-command that 1) creates a bare version of the
current repo, 2) and uploads it to the specified path on my server
(using tar, but that's not the point).

My problem is that I have no idea how things like git-push works via a
user with git-shell. Can you only run certain git commands, like
git-upload-pack? Because I tried running 'ssh git@server git status'
and that failed.

 I think the way to go is to start using gitolite [1] or implement by
 hand a subset of what it does (a custom login shell which is allowed to
 do certain things in a special area of the filesystem designated to keep
 Git repositories) or just set up a special account on the server
 (git-admin, for instance) which would have a regular login shell set
 for it and would be in the same group as the user git (or even have
 the same UID) so that they could share the files they create (subject to
 active umasks of processes run as both users though).

I thought about the secondary user idea. I decided that trying to make
my own command would be more fun.


-- 
Ethan Reesor (Gmail)
--
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: add option in git-p4 to preserve user in Git repository

[Pete Wyckoff]

sh...@keba.be wrote on Thu, 10 Jan 2013 22:38 -0500:
 I'm in a situation where I don't have P4 admin rights to use the
 --preserve-user option of git-p4. However, I would like to keep user
 information in the associated Git branch.
 
 Would it be possible to add an option for this?

The --preserve-user option is used to submit somebody else's work
from git to p4.  It does p4 change -f to edit the author of the
change after it has been submitted to p4.  P4 requires admin
privileges to do that.

Changes that are imported _from_ p4 to git do have the correct
author information.

Can you explain a bit more what you're looking for?

-- Pete
--
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: add option in git-p4 to preserve user in Git repository

[Olivier Delalleau]

2013/1/12 Pete Wyckoff p...@padd.com:
 sh...@keba.be wrote on Thu, 10 Jan 2013 22:38 -0500:
 I'm in a situation where I don't have P4 admin rights to use the
 --preserve-user option of git-p4. However, I would like to keep user
 information in the associated Git branch.

 Would it be possible to add an option for this?

 The --preserve-user option is used to submit somebody else's work
 from git to p4.  It does p4 change -f to edit the author of the
 change after it has been submitted to p4.  P4 requires admin
 privileges to do that.

 Changes that are imported _from_ p4 to git do have the correct
 author information.

 Can you explain a bit more what you're looking for?

 -- Pete

Hi,

Sorry I wasn't clear enough. When git p4 submit submits changes from
Git to P4, it also edits the Git history and replaces the Git commits'
authors by the information from the Perforce account submitting the
changes. The advantage is that both the P4 and Git repositories share
the same author information, but in my case I would like to keep in
the Git repository the original authors (because the P4 account I'm
using to submit to P4 is shared by all Git users).

Hope it makes more sense now :)

-=- Olivier
--
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: add option in git-p4 to preserve user in Git repository

[Pete Wyckoff]

sh...@keba.be wrote on Sat, 12 Jan 2013 14:44 -0500:
 2013/1/12 Pete Wyckoff p...@padd.com:
  sh...@keba.be wrote on Thu, 10 Jan 2013 22:38 -0500:
  I'm in a situation where I don't have P4 admin rights to use the
  --preserve-user option of git-p4. However, I would like to keep user
  information in the associated Git branch.
 
  Would it be possible to add an option for this?
 
  The --preserve-user option is used to submit somebody else's work
  from git to p4.  It does p4 change -f to edit the author of the
  change after it has been submitted to p4.  P4 requires admin
  privileges to do that.
 
  Changes that are imported _from_ p4 to git do have the correct
  author information.
 
  Can you explain a bit more what you're looking for?
 
 Sorry I wasn't clear enough. When git p4 submit submits changes from
 Git to P4, it also edits the Git history and replaces the Git commits'
 authors by the information from the Perforce account submitting the
 changes. The advantage is that both the P4 and Git repositories share
 the same author information, but in my case I would like to keep in
 the Git repository the original authors (because the P4 account I'm
 using to submit to P4 is shared by all Git users).

Ah, I see what you're looking for now.  It's certainly possible
to keep a mapping in the git side to remember who really wrote
each change that went into p4, but there's nothing set up to do
that now.  And it would be a fair amount of work, with many
little details.

You could put the true name in the commit message, like
we do signed-off-by messages: Author: Real Coder r...@my.com.
That would keep the proper attribution, but not work with git
log --author, e.g.; you'd have to use --grep='Real Coder'
instead.

-- Pete
--
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: add option in git-p4 to preserve user in Git repository

[Olivier Delalleau]

2013/1/12 Pete Wyckoff p...@padd.com:
 sh...@keba.be wrote on Sat, 12 Jan 2013 14:44 -0500:
 2013/1/12 Pete Wyckoff p...@padd.com:
  sh...@keba.be wrote on Thu, 10 Jan 2013 22:38 -0500:
  I'm in a situation where I don't have P4 admin rights to use the
  --preserve-user option of git-p4. However, I would like to keep user
  information in the associated Git branch.
 
  Would it be possible to add an option for this?
 
  The --preserve-user option is used to submit somebody else's work
  from git to p4.  It does p4 change -f to edit the author of the
  change after it has been submitted to p4.  P4 requires admin
  privileges to do that.
 
  Changes that are imported _from_ p4 to git do have the correct
  author information.
 
  Can you explain a bit more what you're looking for?

 Sorry I wasn't clear enough. When git p4 submit submits changes from
 Git to P4, it also edits the Git history and replaces the Git commits'
 authors by the information from the Perforce account submitting the
 changes. The advantage is that both the P4 and Git repositories share
 the same author information, but in my case I would like to keep in
 the Git repository the original authors (because the P4 account I'm
 using to submit to P4 is shared by all Git users).

 Ah, I see what you're looking for now.  It's certainly possible
 to keep a mapping in the git side to remember who really wrote
 each change that went into p4, but there's nothing set up to do
 that now.  And it would be a fair amount of work, with many
 little details.

 You could put the true name in the commit message, like
 we do signed-off-by messages: Author: Real Coder r...@my.com.
 That would keep the proper attribution, but not work with git
 log --author, e.g.; you'd have to use --grep='Real Coder'
 instead.

Ok, thanks. I actually manage to hack my way around it, restoring the
author information with git filter-branch and overriding the remote
p4 tracking branch with git update-ref. Did some limited testing and
it seems to work -- hopefully I won't have nasty surprises down the
road ;)

-=- Olivier
--
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

Suggestion: add option in git-p4 to preserve user in Git repository

[Olivier Delalleau]

Hi,

I'm in a situation where I don't have P4 admin rights to use the
--preserve-user option of git-p4. However, I would like to keep user
information in the associated Git branch.

Would it be possible to add an option for this?

Thanks,

-=- Olivier
--
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 repository and Maven project

[Aleks]

Can you help to clarify such question.
We have 2 different projects.
Name of first project say server.
Second - client.
Every project has own maven build structure.
Server produces the war archive for deployment.
The Client project produces the client jar for testing Server application.
Aside from these projects we should store different artefacts like 
prototypes for developing pages for server project.

There are two opinions about approach to arrangement git repository.

1) Create one repository https://git.org/my-project/src
Create 3 separate folders inside of src directory. So we will have such 
structure :

root of repository https://git.org/my-project/src/
contains 2 different maven projects and folder for prototypes files
https://git.org/my-project/src/server
https://git.org/my-project/src/client
https://git.org/my-project/src/prototypes

2)Create for every maven project and prototypes separate repository.
https://git.org/my-server/src
https://git.org/my-client/src
https://git.org/prototypes/src

The root of maven project begins from src folder in every repository ( 
https://git.org/my-server/src and https://git.org/my-client/src)
The xml files and images of prototypes will be inside of 
https://git.org/prototypes/src

I believe the second approach more proper git-approach.
Such approach allows team to use such advanced git features like 
branging, merging, stash etc.


What approach is proper?


--

Best regards
Aleks

--
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: DWIM .git repository discovery

[Drew Northup]

On Wed, Sep 26, 2012 at 7:02 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano gits...@pobox.com wrote:
 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 I often find myself attempting to examine another repository,
 especially in projects that are closely related but put in different
 git repos. It's usually just a diff or log command

 git log --patch ../path/to/another/repo/path/to/file.c

 I personally do not think it is _too_ bad to internally do

 (cd ../path/to/another/repo/path/to 
  git log --patch file.c)


 As long as the .git discovery and path rewriting can be done
 automatically, that'd be nice. But..

I do not think that it should be the job of Git to guess how you would
like your paths recannonicalized. That is truly a pathway to insanity.

 but I doubt it is worth the numerous implications (I am not talking
 about implementation complexity at all, but the conceptual burden).

 For example, where in the working tree of the other project should
 the command run?  The output from log -p happens to be always
 relative to the top of the working tree, but that does not
 necessarily hold true for other subcommands.

And for us to presume that changing how all of those operate now by
default would be a good idea is most definitely folly.

 Returned paths should always be relative to cwd (well except diff/log
 which are prefixed by [ab]/). cd'ing internally like above makes it
 more confusing imo. Take grep for example, I find it natural for git
 grep foo -- ../other/repo/bar/ to return ../other/repo/bar/foo.c
 

In Junio's example it would be relative to the working directory—of
the subshell. Neither the shell nor Git is in a position to clean that
up much if at all.

 Prefix currently does not take ../blah form, but I see no reasons
 why it can't/shouldn't. $(cwd) is most likely outside the other
 project's working directory. An exception running from inside a
 submodule and examining the parent repository.

Is hacking the master project code from inside of a submodule what
this is actually about?

 For too long relative paths, we could even display in :/ pathspec
 notation. Users who don't recognize them either look up documentation,
 or gradually learn to drop the :/ part, even without know what it's
 for.

 Repo modification commands like git-add could cause greater confusion
 (I added and committed it (on the other repo), but when I pushed (on
 this repo), the changes aren't there). We could and probably should
 avoid dwim-ing these cases.

I think you just made a decent case for not doing too much DWIM
here. DWIM is a very fraught concept because you are assuming that
everybody is going to want to do things exactly (or nearly so) the way
you do.

 I think that this is a road to insanity; anybody who thinks along
 this line is already on the other side of the line, I would have to
 say ;-).

 We could go slowly and stop before being diagnosed insane. I mean the
 trick can be opted in for a command subset where it makes sense to do
 so.

I would recommend stopping now then.

-- 
-Drew Northup
--
As opposed to vegetable or mineral error?
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
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: DWIM .git repository discovery

[Nguyen Thai Ngoc Duy]

On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup n1xim.em...@gmail.com wrote:
 I personally do not think it is _too_ bad to internally do

 (cd ../path/to/another/repo/path/to 
  git log --patch file.c)


 As long as the .git discovery and path rewriting can be done
 automatically, that'd be nice. But..

 I do not think that it should be the job of Git to guess how you would
 like your paths recannonicalized. That is truly a pathway to insanity.

I believe we are doing that. We move cwd internally to top worktree,
so we rewrite (well, prefix) all paths.

 Returned paths should always be relative to cwd (well except diff/log
 which are prefixed by [ab]/). cd'ing internally like above makes it
 more confusing imo. Take grep for example, I find it natural for git
 grep foo -- ../other/repo/bar/ to return ../other/repo/bar/foo.c
 

 In Junio's example it would be relative to the working directory—of
 the subshell. Neither the shell nor Git is in a position to clean that
 up much if at all.

That's implementation details.

 Prefix currently does not take ../blah form, but I see no reasons
 why it can't/shouldn't. $(cwd) is most likely outside the other
 project's working directory. An exception running from inside a
 submodule and examining the parent repository.

 Is hacking the master project code from inside of a submodule what
 this is actually about?

Hacking, no. Examining, yes. And in my case, no submodules. It's gnome
projects where a bunch of libraries (in their own repositories) may be
needed for an application. I stay in the application directory but
from time to time I'll need to look outside in other repositories.
-- 
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: DWIM .git repository discovery

[Junio C Hamano]

Drew Northup n1xim.em...@gmail.com writes:

 I think that this is a road to insanity; anybody who thinks along
 this line is already on the other side of the line, I would have to
 say ;-).

 We could go slowly and stop before being diagnosed insane. I mean the
 trick can be opted in for a command subset where it makes sense to do
 so.

 I would recommend stopping now then.

Likewise.  Didn't I already diagnose it as insane? ;-)
--
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: DWIM .git repository discovery

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 26.09.2012 06:21:
 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
 
 I often find myself attempting to examine another repository,
 especially in projects that are closely related but put in different
 git repos. It's usually just a diff or log command

 git log --patch ../path/to/another/repo/path/to/file.c
 
 I personally do not think it is _too_ bad to internally do
 
   (cd ../path/to/another/repo/path/to 
git log --patch file.c)
 
 but I doubt it is worth the numerous implications (I am not talking
 about implementation complexity at all, but the conceptual burden).

Yeah, but doing the above from an alias or help script should be fine
and can be tailored to your use case. Say, a script like

arg1=$1
shift
cd $(dirname $arg1)
git $@ $(basename $args1)

should cover a couple of use cases already. (Error checking is for the
faint of heart only.)

 For example, where in the working tree of the other project should
 the command run?  The output from log -p happens to be always
 relative to the top of the working tree, but that does not
 necessarily hold true for other subcommands.
 
 A worse thing is that there is an oddball case diff[ --no-index]
 that changes behaviour depending on the pathspec points at inside or
 outside the repository.
 
 I think that this is a road to insanity; anybody who thinks along
 this line is already on the other side of the line, I would have to
 say ;-).
 

Don't we all just walk on the line?

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: DWIM .git repository discovery

[Nguyen Thai Ngoc Duy]

On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano gits...@pobox.com wrote:
 Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 I often find myself attempting to examine another repository,
 especially in projects that are closely related but put in different
 git repos. It's usually just a diff or log command

 git log --patch ../path/to/another/repo/path/to/file.c

 I personally do not think it is _too_ bad to internally do

 (cd ../path/to/another/repo/path/to 
  git log --patch file.c)


As long as the .git discovery and path rewriting can be done
automatically, that'd be nice. But..

 but I doubt it is worth the numerous implications (I am not talking
 about implementation complexity at all, but the conceptual burden).

 For example, where in the working tree of the other project should
 the command run?  The output from log -p happens to be always
 relative to the top of the working tree, but that does not
 necessarily hold true for other subcommands.

Returned paths should always be relative to cwd (well except diff/log
which are prefixed by [ab]/). cd'ing internally like above makes it
more confusing imo. Take grep for example, I find it natural for git
grep foo -- ../other/repo/bar/ to return ../other/repo/bar/foo.c


Prefix currently does not take ../blah form, but I see no reasons
why it can't/shouldn't. $(cwd) is most likely outside the other
project's working directory. An exception running from inside a
submodule and examining the parent repository.

For too long relative paths, we could even display in :/ pathspec
notation. Users who don't recognize them either look up documentation,
or gradually learn to drop the :/ part, even without know what it's
for.

Repo modification commands like git-add could cause greater confusion
(I added and committed it (on the other repo), but when I pushed (on
this repo), the changes aren't there). We could and probably should
avoid dwim-ing these cases.

A good way to make it clear you're accessing another repository is
prompt (y/n) from users. I don't think pressing Ctrl-C to abort the
command is too much hassle (the command would fail anyway with
outside repository message, without dwim).

 A worse thing is that there is an oddball case diff[ --no-index]
 that changes behaviour depending on the pathspec points at inside or
 outside the repository.

Yep. But not many commands do this fortunately (diff and grep only?)

 I think that this is a road to insanity; anybody who thinks along
 this line is already on the other side of the line, I would have to
 say ;-).

We could go slowly and stop before being diagnosed insane. I mean the
trick can be opted in for a command subset where it makes sense to do
so.
-- 
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

DWIM .git repository discovery

[Nguyen Thai Ngoc Duy]

Hi,

I often find myself attempting to examine another repository,
especially in projects that are closely related but put in different
git repos. It's usually just a diff or log command

git log --patch ../path/to/another/repo/path/to/file.c

cd'ing out is nuisance for one-shot commands, even setting --git-dir
is because i'd need to repeat the path. I think when we detect paths
outside repository, we could try to discover new repository that
contain those paths, the adjust $GIT_DIR internally to the new
repository.

We can't do that now because .git repository and path outside
repository check occur in two separate stages, the latter after .git
is discovered and .git can't be moved once discovered. We might be
able to move path outside repo check up to discovery phase. But that
could be big change.

Does anybody want such a feature, or it's just my itch? It's probably
not worth doing because few people need it.
-- 
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: DWIM .git repository discovery

[Junio C Hamano]

Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 I often find myself attempting to examine another repository,
 especially in projects that are closely related but put in different
 git repos. It's usually just a diff or log command

 git log --patch ../path/to/another/repo/path/to/file.c

I personally do not think it is _too_ bad to internally do

(cd ../path/to/another/repo/path/to 
 git log --patch file.c)

but I doubt it is worth the numerous implications (I am not talking
about implementation complexity at all, but the conceptual burden).

For example, where in the working tree of the other project should
the command run?  The output from log -p happens to be always
relative to the top of the working tree, but that does not
necessarily hold true for other subcommands.

A worse thing is that there is an oddball case diff[ --no-index]
that changes behaviour depending on the pathspec points at inside or
outside the repository.

I think that this is a road to insanity; anybody who thinks along
this line is already on the other side of the line, I would have to
say ;-).
--
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: How to update a cloned git repository

[Matthieu Moy]

Joachim Schmitz j...@schmitz-digital.de writes:

 I think it is the-merge-commit^2; contrib/git-resurrect.sh might be
 of interest, too.

 Sorry you lost me, this is greek to me...

A commit is an object that contain pointers to its parents. The root
commit has no parent. For ordinary commits, there is one parent which is
the commit on top of which it was created. For merge commits, there are
N commits, the first is the one on top of which the merge was created,
and the N-1 next ones are the commits being merged.

commit^ = first parent of commit
commit^1 = same
commit^2 = second parent, i.e. the one merged in commit.

See in git.git:

$ git show cb10ae9433126ef  one commit to study
commit cb10ae9433126efbc4dcc46779d7ef2fe6b1f597
Merge: 13b608a 9aeaab6   --- list of parents
Author: Junio C Hamano gits...@pobox.com
Date:   Tue Sep 11 15:57:04 2012 -0700

Merge branch 'jc/maint-blame-no-such-path' into pu

* jc/maint-blame-no-such-path:
  blame: allow blame file in the middle of a conflicted merge

$ git show cb10ae9433126ef^1  previous commit in 
origin/pu
commit 13b608a063ce861929322e6bb3862b5364f3fbcf
Merge: fa17a26 bdee397
Author: Junio C Hamano gits...@pobox.com
Date:   Tue Sep 11 11:50:44 2012 -0700

Merge branch 'dg/run-command-child-cleanup' into pu

* dg/run-command-child-cleanup:
  run-command.c: fix broken list iteration in clear_child_for_cleanup

$ git show cb10ae9433126ef^2 - commit being merged by 
cb10ae9433126ef
commit 9aeaab6811dce596b4f6141d76f5300359bfd009
Author: Junio C Hamano gits...@pobox.com
Date:   Tue Sep 11 14:30:03 2012 -0700

blame: allow blame file in the middle of a conflicted merge
[...]

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

How to update a cloned git repository

[Joachim Schmitz]

Hi folks

Probably a beginner's question...

If I did a
   git clone git://guthub.com/git/git.git
and worked on some own branches of pu
   git checkout pu;git checkout -p mybranch;hack;hack;...;git commit -a -s
how to update my repository once the the one on github changed?
A plain
   git pull
or
   git fetch;git merge
keeps failing on my with lots of conflicts, none of which relate to any of 
the changes I did (and hence wouldn't know how to resolve)



Bye, Jojo 



--
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: How to update a cloned git repository

[Matthieu Moy]

Joachim Schmitz j...@schmitz-digital.de writes:

 Hi folks

 Probably a beginner's question...

 If I did a
git clone git://guthub.com/git/git.git
 and worked on some own branches of pu
git checkout pu;git checkout -p mybranch;

I guess you meant git checkout -b mybranch (not -p).

 hack;hack;...;git commit -a -s

 how to update my repository once the the one on github changed? A
 plain git pull or git fetch;git merge keeps failing on my with lots of
 conflicts, none of which relate to any of the changes I did (and hence
 wouldn't know how to resolve)

Short answer: don't work on pu. Work on master unless you have a good
reason not to.

Longer answer: the pu branch in git.git is often re-written, hence the
commit on which you started hacking once existed in git.git's pu, but it
probably no longer is.

You cloned this:

--A---B---C -- origin/pu

Hacked to this

 origin/pu
  |
  v
--A---B---C---D---E -- mybranch

and the next fetch resulted in something like this:

B'---C'---D'---F -- origin/pu
   /
--A---B---C---D---E -- mybranch

while you could have expected that if origin/pu had just been
fast-forwarded with a new commit F:

F -- origin/pu
   /
--A---B---C---D---E -- mybranch

As a result, git merge computes a common ancestor very far backward in
history. Instead of merging only your changes with new pu content, it
merges the old history of pu (plus your changes) with the new history of
pu, and you get spurious conflicts.

The solution is to rebase your changes (and only yours). My advice is to
rebase them on master, like this (replace 42 by the number of commits
you want to rebase in HEAD~42):

  git rebase HEAD~42 --onto origin/master

Once you did this, you can start using git pull (or git pull
--rebase) as usual.

-- 
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: How to update a cloned git repository

[Joachim Schmitz]

 From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]
 Sent: Tuesday, September 11, 2012 1:06 PM
 To: Joachim Schmitz
 Cc: git@vger.kernel.org
 Subject: Re: How to update a cloned git repository
 
 Joachim Schmitz j...@schmitz-digital.de writes:
 
  Hi folks
 
  Probably a beginner's question...
 
  If I did a
 git clone git://guthub.com/git/git.git
  and worked on some own branches of pu
 git checkout pu;git checkout -p mybranch;
 
 I guess you meant git checkout -b mybranch (not -p).

Yes, of course...

  hack;hack;...;git commit -a -s
 
  how to update my repository once the the one on github changed? A
  plain git pull or git fetch;git merge keeps failing on my with lots of
  conflicts, none of which relate to any of the changes I did (and hence
  wouldn't know how to resolve)
 
 Short answer: don't work on pu. Work on master unless you have a good
 reason not to.

There are some changes in pu, that I need as the basis, namely my setitimer 
patch and my 2nd mkdir patch, which haven't yet made it
into the master branch (and in the setitimer case not out of pu)

 Longer answer: the pu branch in git.git is often re-written, hence the
 commit on which you started hacking once existed in git.git's pu, but it
 probably no longer is.
 
 You cloned this:
 
 --A---B---C -- origin/pu
 
 Hacked to this
 
  origin/pu
   |
   v
 --A---B---C---D---E -- mybranch
 
 and the next fetch resulted in something like this:
 
 B'---C'---D'---F -- origin/pu
/
 --A---B---C---D---E -- mybranch
 
 while you could have expected that if origin/pu had just been
 fast-forwarded with a new commit F:
 
 F -- origin/pu
/
 --A---B---C---D---E -- mybranch
 
 As a result, git merge computes a common ancestor very far backward in
 history. Instead of merging only your changes with new pu content, it
 merges the old history of pu (plus your changes) with the new history of
 pu, and you get spurious conflicts.
 
 The solution is to rebase your changes (and only yours). My advice is to
 rebase them on master, like this (replace 42 by the number of commits
 you want to rebase in HEAD~42):
 
   git rebase HEAD~42 --onto origin/master

For pu this would be similar?

 Once you did this, you can start using git pull (or git pull
 --rebase) as usual.


Like this?
git pull --rebase HEAD~42

So far I create patches, wiped out the entire repository, cloned, forked and 
applied the changes, pretty painful.

--
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: How to update a cloned git repository

[Matthieu Moy]

Joachim Schmitz j...@schmitz-digital.de writes:

 From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]

 Short answer: don't work on pu. Work on master unless you have a good
 reason not to.

 There are some changes in pu, that I need as the basis, namely my
 setitimer patch and my 2nd mkdir patch, which haven't yet made it into
 the master branch (and in the setitimer case not out of pu)

Then, work on the tip of the topic branch you depend on instead of pu.
These are more stable, as they will be rewritten only if this particular
topic branch changes.

   git rebase HEAD~42 --onto origin/master

 For pu this would be similar?

Yes. If you insist in working on top of pu, you can rebase --onto
origin/pu.

 Like this?
 git pull --rebase HEAD~42

That would be git fetch and then git rebase, as I don't think git
pull --rebase would allow you to specify the starting point for rebase.

 So far I create patches, wiped out the entire repository, cloned,
 forked and applied the changes, pretty painful.

This is conceptually similar to what git rebase does, but it does it
in a slightly more efficient way ;-).

-- 
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: How to update a cloned git repository

[Matthieu Moy]

[ Re-adding git@vger in Cc, I guess it was meant to be so ]

Joachim Schmitz j...@schmitz-digital.de writes:

 Then, work on the tip of the topic branch you depend on instead of pu.
 These are more stable, as they will be rewritten only if this particular
 topic branch changes.

 These are not available from git hub. Or are they? How?

I think they exist in some of the repos junio pushes to, but I don't
remember how/which one.

Anyway, you can easily get it from the commit that merges the branch
(it's the-merge-commit^1).

  Like this?
  git pull --rebase HEAD~42
 
 That would be git fetch and then git rebase, as I don't think git
 pull --rebase would allow you to specify the starting point for rebase.

 OK, I'll try that next time then. Like this?
   git fetch;git rebase HEAD~42 --onto origin/pu

That should work, yes.

In general, when you have a somehow complex workflow, I recommand
fetch+(merge|rebase) over pull. It gives you more flexibility, and the
opportunity to check what you fetched before starting the merge.

  So far I create patches, wiped out the entire repository, cloned,
  forked and applied the changes, pretty painful.
 
 This is conceptually similar to what git rebase does, but it does it
 in a slightly more efficient way ;-).

 Indeed ;-)




-- 
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: How to update a cloned git repository

[Joachim Schmitz]

 From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]
 Sent: Tuesday, September 11, 2012 2:41 PM
 To: Joachim Schmitz
 Cc: git
 Subject: Re: How to update a cloned git repository
 
 [ Re-adding git@vger in Cc, I guess it was meant to be so ]


Oops, yes it was meant to.

 Joachim Schmitz j...@schmitz-digital.de writes:
 
  Then, work on the tip of the topic branch you depend on instead of pu.
  These are more stable, as they will be rewritten only if this particular
  topic branch changes.
 
  These are not available from git hub. Or are they? How?
 
 I think they exist in some of the repos junio pushes to, but I don't
 remember how/which one.
 
 Anyway, you can easily get it from the commit that merges the branch
 (it's the-merge-commit^1).
 
   Like this?
   git pull --rebase HEAD~42
 
  That would be git fetch and then git rebase, as I don't think git
  pull --rebase would allow you to specify the starting point for rebase.
 
  OK, I'll try that next time then. Like this?
  git fetch;git rebase HEAD~42 --onto origin/pu
 
 That should work, yes.
 
 In general, when you have a somehow complex workflow, I recommand
 fetch+(merge|rebase) over pull. It gives you more flexibility, and the
 opportunity to check what you fetched before starting the merge.

OK, thanks.

I'm sure I'll have more questions later though ;-)

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