Re: [BUG?] worktree setup broken in subdirs with git alias

[Duy Nguyen]

On Thu, Jan 7, 2016 at 4:26 PM, Duy Nguyen  wrote:
> You forgot to mention what version you used.

Gaaah i need to work on my reading skills. You did mention 'next' in

>> sorry I can't dig deeper now, but the worktree code from next seems to

So it matches my expectation. Merge branch
nd/clear-gitenv-upon-use-of-alias to fix 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: Picking up old threads/patches

[Jeff King]

On Wed, Jan 06, 2016 at 08:59:52PM -0700, Stephen & Linda Smith wrote:

> > If Will isn't interested in finishing these two patches I will pick them 
> > up [ ($gmane/271213), ($gmane/272180) ]
> > 
> > After that I will check look at some of the others for which you've 
> > asked for help.
>  
> I started work on both of these rerolls this evening.   Since I do not have 
> the 
> original emails I don't have the Message ID's which  would allow me 
> to add to the threads with the git send-email command.   Do either of you 
> have the 
> message ID's?

If it's an ancient thread, it's not a big deal to just start a new
thread (especially if you reference the old one in the text so people
can dig it up if they really care).

But for reference, you can add `/raw` to the end of a gmane article URL
to get all the headers. E.g.:

  $ gmane=http://article.gmane.org/gmane.comp.version-control.git
  $ curl -s $gmane/271213/raw | grep -i ^message-id:
  Message-ID: 


-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: 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: [BUG?] worktree setup broken in subdirs with git alias

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 07.01.2016 10:40:
> Duy Nguyen venit, vidit, dixit 07.01.2016 10:26:
>> On Thu, Jan 7, 2016 at 2:15 PM, Michael J Gruber
>>  wrote:
>>> Hi there,
>>>
>>> sorry I can't dig deeper now, but the worktree code from next seems to
>>> get confused now as soon as you cd to a subdir of a worktree (other than
>>> the main worktree) and use an alias:
>>>
>>> git help ss
>>> `git ss' is aliased to `status -s -b'
>>> [mjg@skimbleshanks Biomath-WS15 (exam $)]✓ git status -s -b
>>> ## exam
>>> [mjg@skimbleshanks Biomath-WS15 (exam $)]✓ git ss
>>> fatal: internal error: work tree has already been set
>>
>> You forgot to mention what version you used. But it's probably related
>> to d95138e (setup: set env $GIT_WORK_TREE when work tree is set, like
>> $GIT_DIR - 2015-06-26). This commit fixed your problem (and was
>> released) but it introduced some other regressions so it's been
>> reverted in 'next'. 'pu' has a re-fix on top of the revert.
> 
> Well, I mentioned "from next", which I admit is not super-precise (it's
> next not older than a day or two, plus some local additions). In fact it is:
> 
> ef7b32d (Sync with 2.7, 2016-01-04)
> 
> which "has" d95138e (as per git branch contains) but also df1e6ea87
> which reverts it. (I guess --really-contains would be neat but difficult.)
> 
> So while I didn't notice the problems that lead to the revert, I noticed
> the problems the revert created... Early adopters' luck.
> 
> As for the fix on pu, do you mean that one:
> ac78663 (run-command: don't warn on SIGPIPE deaths, 2015-12-29)
> 
> I'll give it a shot then.
> 
> Michael

Meanwhile you had answered my question before I even asked it. Great
user support over here :)

And hooray, merging ac78663 saves my problem, thanks!

Since I didn't notice the problems that the earlier fix caused I can't
say whether the newer fix avoids them.

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

Re: [PATCH v2 1/2] commit: allow editing the commit message even in shared repos

[Jeff King]

On Wed, Jan 06, 2016 at 02:09:43PM +0100, Johannes Schindelin wrote:

> It was pointed out by Yaroslav Halchenko that the file containing the
> commit message is writable only by the owner, which means that we have
> to rewrite it from scratch in a shared repository.
> [...]
> diff --git a/wrapper.c b/wrapper.c
> index b43d437..29a45d2 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -391,6 +391,19 @@ FILE *xfdopen(int fd, const char *mode)
>   return stream;
>  }
>  
> +FILE *fopen_for_writing(const char *path)
> +{
> + FILE *ret = fopen(path, "w");
> +
> + if (!ret && errno == EPERM) {
> + if (!unlink(path))
> + ret = fopen(path, "w");
> + else
> + errno = EPERM;
> + }
> + return ret;
> +}

Thanks, this looks good to me. Having seen the implementation, it really
is just "try harder to fopen()".  I guess calling it "fopen_me_harder()"
would be too obscure. :)

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

Re: [PATCH] interpret-trailers: add option for in-place editing

[Tobias Klauser]

On 2016-01-06 at 20:02:23 +0100, Eric Sunshine  wrote:
> On Wed, Jan 6, 2016 at 8:34 AM, Tobias Klauser
>  wrote:
> > Add a command line option --in-place to support in-place editing akin to
> > sed -i.  This allows to write commands like the following:
> >
> >   git interpret-trailers --trailer "X: Y" a.txt > b.txt && mv b.txt a.txt
> >
> > in a more concise way:
> >
> >   git interpret-trailers --trailer "X: Y" --in-place a.txt
> >
> > Also add the corresponding documentation and tests.
> 
> In addition to Matthieu's comments...
> 
> > Signed-off-by: Tobias Klauser 
> > ---
> > diff --git a/trailer.c b/trailer.c
> > @@ -856,19 +858,28 @@ void process_trailers(const char *file, int 
> > trim_empty, struct string_list *trai
> >
> > lines = read_input_file(file);
> >
> > +   if (in_place) {
> > +   fp = fopen(file, "w");
> > +   if (!fp)
> > +   die_errno(_("could not open file '%s' for 
> > writing"), file);
> > +   }
> 
> The input file should be considered precious, but this implementation
> plays too loosely with it. If the user interrupts the program or a
> die() somewhere within the "trailers" code aborts the program before
> the output file is written, then the original file will be
> irrecoverably lost. Users won't be happy about that.

Indeed, I didn't consider this. Thanks a lot for pointing this out.

> Instead, this code should go through the standard dance of writing the
> output to a new file (with some unique temporary name) and then, only
> once the output has been successfully written in full, rename the new
> file atop the old.

Ok, will do this for v2. I guess with the help of the functions from
tempfile.h it should be fairly easy to implement...

Thanks for your review!
--
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: Picking up old threads/patches

[Stephen & Linda Smith]

On Thursday, January 07, 2016 03:03:50 AM Jeff King wrote:
> If it's an ancient thread, it's not a big deal to just start a new
> thread (especially if you reference the old one in the text so people
> can dig it up if they really care).
> 
> But for reference, you can add `/raw` to the end of a gmane article URL
> to get all the headers. E.g.:
> 
>   $ gmane=http://article.gmane.org/gmane.comp.version-control.git
>   $ curl -s $gmane/271213/raw | grep -i ^message-id:
>   Message-ID: 
> 
> 

Thank you.

--
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 pull --rebase overwrites/deletes empty commits

[Bastian Binder]

Hello,

I have recently encountered a probable bug in git. We have messages we
want to appear in the log and do an empty commit:

git commit --allow-empty -m "message we want to publish"

After this commit, we do a fetch-rebase in order to pull the
intermediate commits into the local branch before pushing:

git pull --rebase branch origin branch

Problem is: the pull --rebase will delete the empty commit. I see git
rebase has a --keep-empty option. I cannot find such option for the
pull --rebase operation.

Thanks in advance,

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

Some issues when trying to set up a shallow git mirror server

[Richard Maw]

Hi all.

I've been working on a service that mirrors open source code into git,
(http://git.baserock.org/cgi-bin/cgit.cgi/?q=delta if interested).

Some repositories are too unwieldy to mirror the whole history,
so we're looking at shallow support,
by fetching specified branches with `--depth=1`.

Since we'll be fetching in only a very shallow history,
we found that most of the time git classifies this as non-fast-forward.

I can see why this happens,
since it ends up with non-overlapping ranges of history
it hasn't fetched enough commits to join the dots.

This is inconvenient for us,
as we were explicitly using refspecs which didn't force the fetch,
since we were using the "non fast-forward update" errors
to detect whether upstream force pushed important refs
which could be a sign of tampering.

While the client doesn't have enough information
the server has those commits.
Would it make sense for the server to be able to tell the client
"trust me, that commit is a descendant of the previous one"?

Here's a patch to the test suite that demonstrates the failure,
since I felt I had to put some commands together to demonstrate,
and I may as well put it in a useful format.

diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index a980574..0996d12 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -186,4 +186,24 @@ EOF
test_cmp expect actual
 '
 
+test_expect_success 'fetch --depth with discontinuous history' '
+   git init --quiet --bare discontinuous.git &&
+   (
+   cd discontinuous.git &&
+   git fetch --quiet ../.git --depth=1 "refs/*:refs/*"
+   ) &&
+   commit 5 &&
+   commit 6 &&
+   (
+   cd discontinuous.git &&
+   git fetch ../.git --depth=1 "refs/*:refs/*" &&
+   git fsck &&
+   git log --format=%s master >actual &&
+   cat /dev/null
)
 '
+
+test_expect_success 'push --mirror from shallow clone' '
+   git --git-dir=full/.git tag r0 &&
+   git init --quiet --bare mirror-pusher.git &&
+   git init --quiet --bare mirror.git &&
+   git --git-dir=mirror.git config receive.shallowUpdate true &&
+   (
+   cd mirror-pusher.git &&
+   git remote add --mirror=fetch origin ../full/.git &&
+   git remote add mirror ../mirror.git &&
+   git fetch --quiet origin --depth=1 &&
+   git push --mirror mirror
# The push should work, but does not.
# The following command works for creations, but not deletions.
#git for-each-ref -s --format "git push mirror +%(refname)" | sh
+   ) &&
+   git --git-dir=mirror.git for-each-ref --format "%(refname)" --sort 
refname >actual &&
+   cat