The latest feature release Git v2.3.0 is now available at the
usual places.
This one ended up to be a release with lots of small corrections and
improvements without big uncomfortably exciting features. It is a
lot smaller release than other recent feature releases, consisting
of 255 non-merge com
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Git 2.3 is out. I'll wait for some time for the dust to settle and
then rewind and rebuild 'next'.
You can find the changes described here in
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
On Feb 5, 2015, at 12:59, Junio C Hamano wrote:
I do not know (and I am not quite sure if I want to know) how
serious your "potential" problems would be, and I do not doubt you
know OS X quirks much better than I do and do not intend to argue
there aren't such problems. I am just curious how "us
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Perhaps something like this instead?
>>
>> git-rebase - Rebuild a branch on top of a different commit
>
> I would say "Replay history on top of a different commit" instead.
> "Rebuild" may be misleading (it's not "build" as in "compile & lin
On Thu, Feb 05, 2015 at 01:16:36PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote:
> >
> >> I also notice that config_buf_ungetc does not actually ungetc the
> >> character we give it; it just rewinds one character in the stream.
Junio C Hamano writes:
> Perhaps something like this instead?
>
> git-rebase - Rebuild a branch on top of a different commit
I would say "Replay history on top of a different commit" instead.
"Rebuild" may be misleading (it's not "build" as in "compile & link"),
and the rebased history does
Jeff King writes:
> On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote:
>
>> I also notice that config_buf_ungetc does not actually ungetc the
>> character we give it; it just rewinds one character in the stream. This
>> is fine, because we always feed the last-retrieved character. I dunno
On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote:
> I also notice that config_buf_ungetc does not actually ungetc the
> character we give it; it just rewinds one character in the stream. This
> is fine, because we always feed the last-retrieved character. I dunno if
> it is worth fixing (
"Kyle J. McKay" writes:
> Now, can you do that easily in a Makefile? ;)
Or is it worth doing it?
I do not mind a full symbolic link as long as it points at the
correct place (Sebastian's version did not under DESTDIR which was
the only issue I had against it), but is there a good reason why we
On Thu, Feb 5, 2015 at 9:45 PM, Jeff King wrote:
>> endif
>> $(RM)·"$$execdir/$$p"·&&·\
>>
>> test·-z·"$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)"·&&·\
>> ln·"$$bindir/$$p"·"$$execdir/$$p"·2>/dev/null·||·\
>> +ln·-s·"../$$p"·"$$execdir/$$p"·2>/dev/
Thanks (and thanks for ungetc one, too).
--
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
On Thu, Feb 05, 2015 at 09:29:04PM +0100, Sebastian Schuberth wrote:
> > We would still want an equivalent to 2/2 to set up a relative symlink
> > for $(ALL_PROGRAMS), though, right?
>
> Probably. But I'm not sure how to calculate the relative path
> correctly so that it'll work with all possible
On Feb 5, 2015, at 11:51, Jeff King wrote:
On Thu, Feb 05, 2015 at 08:26:08PM +0100, Sebastian Schuberth wrote:
It is not even correct, is it?
When DESTDIR is set to allow you to install into a temporary place
only so that you can "tar" up the resulting filesystem tree, bindir
points at the lo
On Thu, Feb 5, 2015 at 8:51 PM, Jeff King wrote:
> On Thu, Feb 05, 2015 at 08:26:08PM +0100, Sebastian Schuberth wrote:
>
>> > It is not even correct, is it?
>> >
>> > When DESTDIR is set to allow you to install into a temporary place
>> > only so that you can "tar" up the resulting filesystem tr
Jeff King writes:
> On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:
>
>> Eric Blake writes:
>>
>> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
>> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>> >>> This series is based on the previous patchset from Chen Fan
On Thu, Feb 5, 2015 at 11:22 AM, Sebastian Schuberth
wrote:
> On Thu, Feb 5, 2015 at 8:19 PM, Sebastian Schuberth
> wrote:
>
>>> Is that an improvement? Is the plural of "dup" (used as an
>>> abbreviation of "duplicate") "dupes" not "dups"?
>>
>> My view is that the abbreviation of "duplicate" i
On Thu, Feb 05, 2015 at 04:13:03PM +0100, Dmitry Neverov wrote:
> I'm using git p4 for synchronization with perforce. Sometimes after 'git
> p4 rebase' git starts a garbage collection. When gc finishes a local
> repository contains no pack files only loose objects, so I have to
> re-import reposit
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> check-builtins.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/check-builtins.sh b/check-builtins.sh
> index 07cff69..a0aaf3a 100755
> --- a/check-builtins.sh
> +++ b/check-builtins.sh
> @@ -3,7
On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:
> Eric Blake writes:
>
> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
> >>> This series is based on the previous patchset from Chen Fan:
> >>> https://lists.nongnu
On Thu, Feb 05, 2015 at 08:26:08PM +0100, Sebastian Schuberth wrote:
> > It is not even correct, is it?
> >
> > When DESTDIR is set to allow you to install into a temporary place
> > only so that you can "tar" up the resulting filesystem tree, bindir
> > points at the location we need to "cp" the
Junio C Hamano writes:
> Tobias Preuss writes:
>
>> I noticed some bizarre behaviour when using: git stash -u.
>> It deletes folders which contain files configured to be ignored.
>
> The files you mark as ignored are expendable and this is not limited
> to "stash".
> ...
> Here is what should ha
Eric Blake writes:
> On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
>> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>>> This series is based on the previous patchset from Chen Fan:
>>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
>>
>> This email has an i
On Thu, Feb 5, 2015 at 8:23 PM, Junio C Hamano wrote:
>> This is wrong.
>>
>> Currently with symlinks you will get installed into bindir something
>> like this:
>>
>> git
>> git-tag -> git
>> git-show -> git
>>
>> etc.
>>
>> With your change you would have
>>
>> git
>> git-tag -> /usr/l
"Kyle J. McKay" writes:
>> -ln -s "git$X" "$$bindir/$$p" 2>/dev/null || \
>> +ln -s "$$bindir/git$X" "$$bindir/$$p" 2>/dev/null || \
>
> This is wrong.
>
> Currently with symlinks you will get installed into bindir something
> like this:
>
> git
> git-tag -> git
> git-show -
On Thu, Feb 5, 2015 at 8:19 PM, Sebastian Schuberth
wrote:
>> Is that an improvement? Is the plural of "dup" (used as an
>> abbreviation of "duplicate") "dupes" not "dups"?
>
> My view is that the abbreviation of "duplicate" is not "dup" but
> "dupe", hence the plural "dupes".
For "duplicate" t
On Thu, Feb 5, 2015 at 8:17 PM, Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
>> Signed-off-by: Sebastian Schuberth
>> ---
>
> Is that an improvement? Is the plural of "dup" (used as an
> abbreviation of "duplicate") "dupes" not "dups"?
My view is that the abbreviation of "duplicate"
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
Is that an improvement? Is the plural of "dup" (used as an
abbreviation of "duplicate") "dupes" not "dups"?
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index c
Tobias Preuss writes:
> I noticed some bizarre behaviour when using: git stash -u.
> It deletes folders which contain files configured to be ignored.
The files you mark as ignored are expendable and this is not limited
to "stash".
$ git init
Initialized empty Git repository in /var/tmp/
Luke Diamand writes:
> (Resending as plain text).
>
> I could be wrong about this, but my correction above doesn't seem to
> be in 'next'. Does that mean (reading your last "what's cooking") that
> the broken version is going to go out to 'master' soon?
The current copy of "What's cooking" I hav
"Kyle J. McKay" writes:
> On Feb 4, 2015, at 22:11, Scott Schmit wrote:
>
>> In my use of git, I've noticed that "git status" is a lot better at
>> tracking moves and renames than "git diff", and this has recently
>> caused
>> me a lot of headaches because a large number of moves were made in a
>
Matthieu Moy writes:
> NAME
>git-rebase - Forward-port local commits to the updated upstream head
>
> => Quite technical already.
Very much true, and I would say the description is "technically
correct" in the sense that "it is not wrong per-se". There are a
few points that this fails
On Feb 5, 2015, at 07:51, Sebastian Schuberth wrote:
For consistency, we should use the same source for symbolic links as
for
hard links and copies.
Signed-off-by: Sebastian Schuberth
---
Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
ind
On Feb 5, 2015, at 07:52, Sebastian Schuberth wrote:
We do this for BUILT_INS and REMOTE_CURL_ALIASES, so we should do so
here,
too.
Signed-off-by: Sebastian Schuberth
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 21f23cb..d2849c3 100644
--- a/Makef
[adding git list to cc]
On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>> This series is based on the previous patchset from Chen Fan:
>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
>
> This email has an inva
Makes _is_git handle the case where the path is a "gitdir: ..." file.
---
lib/choose_repository.tcl | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 92d6022..abc6b1d 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_r
If _is_git follows a "gitdir: ..." file link to get to the actual
repository, we want _gitdir to be set to that final path.
---
lib/choose_repository.tcl | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index abc6
New patch series. I hadn't realized Git doesn't recurse on "gitdir: ..."
links itself, it only follows one.
Also normalizes the path to the Git repository as requested.
Remi Rampin (2):
Fixes chooser not accepting gitfiles
Makes chooser set 'gitdir' to the resolved path
lib/choose_repositor
We do this for BUILT_INS and REMOTE_CURL_ALIASES, so we should do so here,
too.
Signed-off-by: Sebastian Schuberth
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 21f23cb..d2849c3 100644
--- a/Makefile
+++ b/Makefile
@@ -2258,6 +2258,7 @@ endif
For consistency, we should use the same source for symbolic links as for
hard links and copies.
Signed-off-by: Sebastian Schuberth
---
Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index c44eb3a..21f23cb 100644
--- a/Makefile
+++ b/Makefil
Hi,
I'm experiencing a strange behavior of automatic git gc which corrupts a
local repository. Git version 2.2.2 on Mac OS X 10.10.1.
I'm using git p4 for synchronization with perforce. Sometimes after 'git
p4 rebase' git starts a garbage collection. When gc finishes a local
repository contains n
Signed-off-by: Sebastian Schuberth
---
check-builtins.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/check-builtins.sh b/check-builtins.sh
index 07cff69..a0aaf3a 100755
--- a/check-builtins.sh
+++ b/check-builtins.sh
@@ -3,7 +3,7 @@
{
cat <<\EOF
sayIt:
-$(foreac
Signed-off-by: Sebastian Schuberth
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index c44eb3a..6f8ae23 100644
--- a/Makefile
+++ b/Makefile
@@ -2447,7 +2447,7 @@ check-docs::
esac; \
done ) | sort
-### Make sure built-ins do n
Matthew Brett writes:
> Obviously my page as it is now is very different in tone from the
> git-rebase page, but I think there are some aspects that could be
> fruitfully merged. Would you be interested in patches of this sort,
> or does the page seem too far from the intention of the man page?
Hello.
I noticed some bizarre behaviour when using: git stash -u.
It deletes folders which contain files configured to be ignored. I
actually lost files by this which I could not restore.
Here is how you can reproduce the case.
1. Create a project folder to act as the root of the repository. `cd
Kyle J. McKay:
I think something like this might do what you want:
git for-each-ref --format='%(refname)' refs/tags | \
while read t; do
if ! git merge-base --is-ancestor $t HEAD; then
echo ${t#refs/tags/}
fi
done
That works like a charm, thank you!
--
\\// Peter - http://www.softwolves.pp
(Resending as plain text).
I could be wrong about this, but my correction above doesn't seem to
be in 'next'. Does that mean (reading your last "what's cooking") that
the broken version is going to go out to 'master' soon?
Thanks,
Luke
On 5 February 2015 at 08:19, Luke Diamand wrote:
> I could
The decimal_width function originally appeared in blame.c as
"lineno_width", and was designed for calculating the
print-width of small-ish integer values (line numbers in
text files). In ec7ff5b, it was made into a reusable
function, and in dc801e7, we started using it to align
diffstats.
Binary f
On Wed, Feb 4, 2015 at 4:52 AM, Rémi Rampin wrote:
> 2015-02-02 12:24 UTC-05:00, Remi Rampin :
>>> proc _is_git {path} {
>>> + if {[file isfile $path]} {
>>> + set fp [open $path r]
>>> + gets $fp line
>>> + close $fp
>>> + if {[regexp
49 matches
Mail list logo
