* Re: problem with BOINC repository and CR/LF
From: Torsten Bögershausen @ 2012-12-18 12:15 UTC (permalink / raw)
To: Toralf Förster; +Cc: Andrew Ardill, git@vger.kernel.org
In-Reply-To: <50D03D80.3090005@gmx.de>
On 18.12.12 10:55, Toralf Förster wrote:
> On 12/18/2012 02:56 AM, Andrew Ardill wrote:
>> On 18 December 2012 03:01, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>> On 12/17/2012 12:38 PM, Andrew Ardill wrote:
>>>> On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>>>> Hello,
>>>>>
>>>>> I'm faced with this situation :
>>>>> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
>>>>> and even a "git stash" doesn't help.
>>>>
>>>> Hi Toralf,
>>>>
>>>> That list is private and not visible without an account. Can you
>>>> transcribe the relevant parts?
>>>>
>>>> Regards,
>>>>
>>>> Andrew Ardill
>>>>
>>> Oh of course :
>>>
>>>
>>> On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote:
>>>> So if you have further issues with boinc feel free to look in our debian
>>>> git and feel free to download appropriate patches :-)
>>>>
>>>> Gianfranco
>>> thx
>>>
>>> Currently I'm struggling with a git problem of the boinc repository
>>> itself and b/c I'm using git for the linux kernel tree w/o any problems
>>> since eons /me wonders whether this is a BOINC-repository specific problem :
>>>
>>>
>>> After doing the following sequence with git 1.8.0.2 :
>>>
>>> $> git clone git://boinc.berkeley.edu/boinc.git
>>> $> cd boinc
>>> $> git checkout client_release_7.0.39
>>> $> git checkout master
>>> (sometimes I've to repeat this :
>>> $> git checkout client_release_7.0.39
>>> $> git checkout master
>>> )
>>> I'm faced with this situation :
>>>
>>> $ git status
>>> # On branch master
>>> # Changes not staged for commit:
>>> # (use "git add <file>..." to update what will be committed)
>>> # (use "git checkout -- <file>..." to discard changes in working
>>> directory)
>>> #
>>> # modified: clientgui/AsyncRPC.cpp
>>> # modified: clientgui/sg_BoincSimpleFrame.cpp
>>> #
>>> no changes added to commit (use "git add" and/or "git commit -a")
>>>
>>> (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned)
>>>
>>> Now these commands
>>>
>>> $ git checkout -- clientgui/AsyncRPC.cpp
>>> $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp
>>>
>>> doesn't help - the status is still the same (and ofc now I'm no longer
>>> allowed to make a "git checkout" - due to un-commited changes).
>>>
>>> Now I'm wondering where to start to investigate this issue ...
>>
>> Hi Toralf,
>>
>> That does look like a weird issue. What operating system are you on?
>
> I'm running a stable Gentoo Linux x86, 32bit with gcc 4.6.3 and current
> stable kernel 3.6.1x and 3.7.1, file system is ext4 at an external USB
> 2.0 drive.
>
> FWIW from the boinc maintainer I know that all tags till 7.0.3X are
> imported from svn.
>
> I upgraded to git 1.8.0.2 from 1.7.8.6 - situation is the same. The
> emerge gave :
>
> failed test(s): t3600 t7508
>
> fixed 0
> success 8342
> failed 8
> broken 56
> total 8528
>
> Ok, now answering your other questions:
>
>
> $> git stash
> warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp.
> The file will have its original line endings in your working directory.
> Saved working directory and index state WIP on master: 4a296dc - client
> simulator: fix build errors
> HEAD is now at 4a296dc - client simulator: fix build errors
>
> After that the situation is unchanged.
>
>> What happens if you do a hard reset to the branch?
>
> $> git reset --hard HEAD~1
>
> not better.
>
>
>> What is the ouptut of git diff --cached ?
>
> The output is empty but "git status" shows still modified files.
>
>
>
> FWIW there's a related issue I'm wondering about which might help:
>
> $> git clone git://boinc.berkeley.edu/boinc.git
> $> tar -cpf boinc.tar boinc/
> $> rm -rf boinc/
> $> tar -xpf boinc.tar
> $> cd boinc/
> $> git status
> # On branch master
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> directory)
> #
> # modified: client/win/boinc_log.h
> # modified: client/win/boinc_log.rc
> # modified: clientctrl/boincsvcctrl.cpp
> # modified: clientctrl/boincsvcctrl.h
> # modified: clientctrl/boincsvcctrl.rc
> # modified: clientgui/AsyncRPC.cpp
> # modified: clientgui/DlgEventLog.cpp
> # modified: clientgui/DlgEventLog.h
> # modified: clientgui/DlgEventLogListCtrl.cpp
> # modified: clientgui/DlgEventLogListCtrl.h
> # modified: clientgui/DlgExitMessage.h
> # modified: clientgui/DlgItemProperties.h
> # modified: clientgui/TermsOfUsePage.cpp
> # modified: clientgui/TermsOfUsePage.h
> # modified: clientgui/ViewNotices.cpp
> # modified: clientgui/ViewNotices.h
> # modified: clientgui/sg_BoincSimpleFrame.cpp
> # modified: clientscr/boinc_ss_opengl.h
> # modified: clientscr/boinc_ss_opengl.rc
> # modified: clientscr/screensaver.cpp
> # modified: clienttray/boinc_tray.h
> # modified: clienttray/boinc_tray.rc
> # modified: clienttray/tray_win.cpp
> # modified: clienttray/tray_win.h
> # modified: coprocs/NVIDIA/include/nvapi.h
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> $> git diff --cached
> $>
>
>
>
> Meaning, w/o any other interaction a tar'ed archive has modified files -
> and the diff is empty...
>
Hej,
I could re-produce the problem here:
git version 1.8.0.197.g5a90748
Mac OS X (that what I had at hands fastest)
After doing
git checkout 5db4a05b5c8f9c420fc418727cafbb58e6051f1e
(same as master ?)
We see that
clientgui/AsyncRPC.cpp
is full of CRLF and as it seems only CRLF, no single LF.
The file is classified as text:
$git check-attr text clientgui/AsyncRPC.cpp
$clientgui/AsyncRPC.cpp: text: set
(And we can see this in .gitattributes as well)
(And there are more files affected, but I will only look at one of them)
If we remove the text attribute like this:
$mv .gitattributes .gitattributes.sav
we see
$git status
deleted: .gitattributes
# modified: clientgui/sg_BoincSimpleFrame.cpp
If we dig into the file:
$git ls-files -s clientgui/AsyncRPC.cpp
100644 6832333ad133181986ada54fe0229b45a30c614a 0 clientgui/AsyncRPC.cpp
We see that it is recorded under 6832333ad1
And if we look into it:
$git show 6832333 | od -c
[snip]
we can see that the file has CRLF in the repo.
So my conclusion is:
The file has CRLF in the repo, but should have LF.
This is not a good thing, and the files need to be normalized.
A very good instruction how to do this, is found here:
http://kernel.org/pub/software/scm/git/docs/gitattributes.html
(You may want to search for "End-of-line conversion" or "core.autocrlf")
HTH
/Torsten
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Thomas Rast @ 2012-12-18 12:49 UTC (permalink / raw)
To: Johannes Sixt
Cc: Yann Dirson, Junio C Hamano, Andreas Schwab, Christian Couder,
Thomas Rast, git list
In-Reply-To: <50D05BAF.4000200@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 12/18/2012 12:00, schrieb Yann Dirson:
>> On Mon, 17 Dec 2012 13:14:56 -0800
>> Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>
>>>> Christian Couder <christian.couder@gmail.com> writes:
>>>>
>>>>> Yeah, at one point I wanted to have a command that created to craft a
>>>>> new commit based on an existing one.
>>>>
>>>> This isn't hard to do, you only have to resort to plumbing:
>>>>
>>>> $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 |
>>>> sed
>>>> s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
>>>> | git hash-object -t commit --stdin -w
>>>> bb45cc6356eac6c7fa432965090045306dab7026
>>>
>>> Good. I do not think an extra special-purpose command is welcome
>>> here.
>>
>> Well, I'm not sure this is intuitive enough to be useful to the average user :)
>
> When I played with git-replace in the past, I imagined that it could be
>
> git replace <object> --commit ...commit options...
>
> that would do the trick.
>
> We could implement it with a git-replace--commit helper script that
> generates the replacement commit using the ...commit options... (to be
> defined what this should be), and git-replace would just pick its output
> (the SHA1 of the generated commit) as a substitute for the <replacement>
> argument that would have to be given without the --commit option.
I wouldn't even want a script -- we'd end up inventing a complicated
command-line editor for what can simply be done by judicious use of an
actual text editor. How about something like the following?
Documentation/git-replace.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git i/Documentation/git-replace.txt w/Documentation/git-replace.txt
index 51131d0..2502118 100644
--- i/Documentation/git-replace.txt
+++ w/Documentation/git-replace.txt
@@ -61,6 +61,27 @@ OPTIONS
Typing "git replace" without arguments, also lists all replace
refs.
+
+EXAMPLE
+-------
+
+Replacements (and before them, grafts) are often used to replace the
+parent list of a commit. Since commits are stored in a human-readable
+format, you can in fact change any property using the following
+recipe:
+
+------------------------------------------------
+$ git cat-file commit original_commit >tmp
+$ vi tmp
+------------------------------------------------
+In the editor, adjust the commit as needed. For example, you can edit
+the parent lists by adding/removing lines starting with "parent".
+When done, replace the original commit with the edited one:
+------------------------------------------------
+$ git replace original_commit $(git hash-object -w tmp)
+------------------------------------------------
+
+
BUGS
----
Comparing blobs or trees that have been replaced with those that
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-18 13:41 UTC (permalink / raw)
To: Thomas Rast
Cc: Johannes Sixt, Junio C Hamano, Andreas Schwab, Christian Couder,
Thomas Rast, git list
In-Reply-To: <871uentthz.fsf@pctrast.inf.ethz.ch>
On Tue, 18 Dec 2012 13:49:44 +0100
Thomas Rast <trast@inf.ethz.ch> wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
> > Am 12/18/2012 12:00, schrieb Yann Dirson:
> >> On Mon, 17 Dec 2012 13:14:56 -0800
> >> Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >>> Andreas Schwab <schwab@linux-m68k.org> writes:
> >>>
> >>>> Christian Couder <christian.couder@gmail.com> writes:
> >>>>
> >>>>> Yeah, at one point I wanted to have a command that created to craft a
> >>>>> new commit based on an existing one.
> >>>>
> >>>> This isn't hard to do, you only have to resort to plumbing:
> >>>>
> >>>> $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 |
> >>>> sed
> >>>> s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
> >>>> | git hash-object -t commit --stdin -w
> >>>> bb45cc6356eac6c7fa432965090045306dab7026
> >>>
> >>> Good. I do not think an extra special-purpose command is welcome
> >>> here.
> >>
> >> Well, I'm not sure this is intuitive enough to be useful to the average user :)
> >
> > When I played with git-replace in the past, I imagined that it could be
> >
> > git replace <object> --commit ...commit options...
> >
> > that would do the trick.
> >
> > We could implement it with a git-replace--commit helper script that
> > generates the replacement commit using the ...commit options... (to be
> > defined what this should be), and git-replace would just pick its output
> > (the SHA1 of the generated commit) as a substitute for the <replacement>
> > argument that would have to be given without the --commit option.
>
> I wouldn't even want a script -- we'd end up inventing a complicated
> command-line editor for what can simply be done by judicious use of an
> actual text editor. How about something like the following?
Well, while it does the job, it is still hardly as straightforward as the
old "vi .git/info/grafts", or as a single easily-remembered commandline.
I was again thinking the only commandline stuff that does not exist currently in
git-commit is specifying parents. One possiblity would be to add such an
option to git-commit, together with a --replace flag that would cause the
new commit to attached a replace ref (not completely unlike --append, in that
we're doing some non-default action instead of just adding the changes to a
new commit).
But well, I don't think we would want to add to git-commit the ability of playing
with something else than what's in the index/worktree. Abstracting the commit
commandline to make it reusable by a git-replace--commit and possibly other tools
that may want to rw-manipulate arbitrary commits could make sense ?
>
> Documentation/git-replace.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git i/Documentation/git-replace.txt w/Documentation/git-replace.txt
> index 51131d0..2502118 100644
> --- i/Documentation/git-replace.txt
> +++ w/Documentation/git-replace.txt
> @@ -61,6 +61,27 @@ OPTIONS
> Typing "git replace" without arguments, also lists all replace
> refs.
>
> +
> +EXAMPLE
> +-------
> +
> +Replacements (and before them, grafts) are often used to replace the
> +parent list of a commit. Since commits are stored in a human-readable
> +format, you can in fact change any property using the following
> +recipe:
> +
> +------------------------------------------------
> +$ git cat-file commit original_commit >tmp
> +$ vi tmp
> +------------------------------------------------
> +In the editor, adjust the commit as needed. For example, you can edit
> +the parent lists by adding/removing lines starting with "parent".
> +When done, replace the original commit with the edited one:
> +------------------------------------------------
> +$ git replace original_commit $(git hash-object -w tmp)
You probably meant "-t commit" - a sign that it's not so trivial to forge ?
> +------------------------------------------------
> +
> +
> BUGS
> ----
> Comparing blobs or trees that have been replaced with those that
>
>
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Thomas Rast @ 2012-12-18 14:31 UTC (permalink / raw)
To: Yann Dirson
Cc: Johannes Sixt, Junio C Hamano, Andreas Schwab, Christian Couder,
git list
In-Reply-To: <20121218144157.00ccd915@chalon.bertin.fr>
Yann Dirson <dirson@bertin.fr> writes:
>> +EXAMPLE
>> +-------
>> +
>> +Replacements (and before them, grafts) are often used to replace the
>> +parent list of a commit. Since commits are stored in a human-readable
>> +format, you can in fact change any property using the following
>> +recipe:
>> +
>> +------------------------------------------------
>> +$ git cat-file commit original_commit >tmp
>> +$ vi tmp
>> +------------------------------------------------
>> +In the editor, adjust the commit as needed. For example, you can edit
>> +the parent lists by adding/removing lines starting with "parent".
>> +When done, replace the original commit with the edited one:
>> +------------------------------------------------
>> +$ git replace original_commit $(git hash-object -w tmp)
>
> You probably meant "-t commit" - a sign that it's not so trivial to forge ?
Mostly a sign that despite my testing efforts, I still fail at
cut&paste...
But yes, it absolutely needs -t commit. Otherwise the commit would be
replaced by a blob, and confusion ensues.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve N. Pettersen (Developer Opera Software ASA) @ 2012-12-18 14:51 UTC (permalink / raw)
To: git
Hello all,
Today Opera Software released the "Git-splitter", a small tool for
sub-modularizing code in a git repo, with complete commit history, under
the Apache 2.0 license.
It's functionality is similar to "git-subtree", but also include a command
for reversing the process.
The code is hosted on GitHub:
<https://github.com/operasoftware/git-splitter>
We have announced the release as part of another announcement of released
code at the Opera Security Group home page:
<http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* [PATCH] Makefile: track TCLTK_PATH as it used to be tracked
From: Christian Couder @ 2012-12-18 14:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
A long time ago, gitk used to live at the root of the git.git
repository. In 62ba514 (Move gitk to its own subdirectory,
2007-11-17) it was moved to a subdirectory, but some code used
to track TCLTK_PATH was left in the main Makefile instead
of being moved to the new Makefile that was created in gitk-git/.
The code left in the main Makefile in git.git should now have
been removed because it was found useless.
And this patch puts some code back to track TCLTK_PATH properly
where it should be.
Note that there is already some code to do that in git-gui.
At the same time this patch creates a .gitignore and also marks
some targets in the Makefile as PHONY.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Hi Paul,
In this thread:
http://thread.gmane.org/gmane.comp.version-control.git/211641
Junio asked me to send you this patch.
So here it is, for you to apply to your tree.
Thanks,
Christian.
.gitignore | 2 ++
Makefile | 16 ++++++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..d7ebcaf
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+/GIT-TCLTK-VARS
+/gitk-wish
diff --git a/Makefile b/Makefile
index e1b6045..5acdc90 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,16 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+### Detect Tck/Tk interpreter path changes
+TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
+
+GIT-TCLTK-VARS: FORCE
+ @VARS='$(TRACK_TCLTK)'; \
+ if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo 1>&2 " * new Tcl/Tk interpreter location"; \
+ echo "$$VARS" >$@; \
+ fi
+
## po-file creation rules
XGETTEXT ?= xgettext
ifdef NO_MSGFMT
@@ -49,9 +59,9 @@ uninstall::
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
clean::
- $(RM) gitk-wish po/*.msg
+ $(RM) gitk-wish po/*.msg GIT-TCLTK-VARS
-gitk-wish: gitk
+gitk-wish: gitk GIT-TCLTK-VARS
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
chmod +x $@+ && \
@@ -65,3 +75,5 @@ $(ALL_MSGFILES): %.msg : %.po
@echo Generating catalog $@
$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
+.PHONY: all install uninstall clean update-po
+.PHONY: FORCE
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* Re: [PATCH v3 3/4] gitk-git/Makefile: track TCLTK_PATH as it used to be tracked
From: Christian Couder @ 2012-12-18 15:12 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vvcc1m8t9.fsf@alter.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
>
>> .gitignore | 1 -
>> gitk-git/.gitignore | 2 ++
>> gitk-git/Makefile | 16 ++++++++++++++--
>
> I'll apply the .gitignore part to my tree, but could you split the
> rest out and have Paul apply to his tree at
>
> git://ozlabs.org/~paulus/gitk.git
Ok, I just sent the rest to Paul and I am going to send you an updated
series for you.
Regards,
Christian.
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Junio C Hamano @ 2012-12-18 15:22 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Philippe Vaucher, git, Christian Couder
In-Reply-To: <CANiSa6h3Qf=6hw6fzHVw=CeuhnNeq+cuEvwwmVhUaSOcVgCSBA@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> I am guilty of introducing "git reset --soft HEAD^" before I invented
>> "commit --amend" during v1.3.0 timeframe to solve the issue "soft" reset
>> originally wanted to.
>
> I do use "commit --amend" a lot, but I still appreciate having "reset
> --soft". For example, to squash the last few commits:
>
> git reset --soft HEAD^^^ && git commit --amend
Yeah, I do that sometimes myself, but the key word is "sometimes".
These days, I think most users (not just mortals but experienced
ones) use "rebase -i" to squash them altogether, either with "fixup",
with which you lose the messages from the follow-up fixes, just
like the soft reset to an old one with an amen,) or with "squash",
with which you can pick pieces of messages from the follow-up fixes
while updating the message from the original one.
^ permalink raw reply
* [PATCH v4 2/3] Makefile: detect when PYTHON_PATH changes
From: Christian Couder @ 2012-12-18 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When make is run, the python scripts are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
This is nice except when you run make another time setting a
different PYTHON_PATH, because, as the python scripts have already
been created, make finds nothing to do.
The goal of this patch is to detect when the PYTHON_PATH changes and
to create the python scripts again when this happens. To do that we
use the same trick that is done to track other variables like prefix,
flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file
with the PYTHON_PATH and check if it changed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
.gitignore | 1 +
Makefile | 16 ++++++++++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 64a454b..56a4b2b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/GIT-CFLAGS
/GIT-LDFLAGS
/GIT-PREFIX
+/GIT-PYTHON-VARS
/GIT-SCRIPT-DEFINES
/GIT-USER-AGENT
/GIT-VERSION-FILE
diff --git a/Makefile b/Makefile
index 585b2eb..7db8445 100644
--- a/Makefile
+++ b/Makefile
@@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
endif # NO_PERL
ifndef NO_PYTHON
-$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX
+$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \
@@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' >>$@
endif
+### Detect Python interpreter path changes
+ifndef NO_PYTHON
+TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
+
+GIT-PYTHON-VARS: FORCE
+ @VARS='$(TRACK_PYTHON)'; \
+ if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo 1>&2 " * new Python interpreter location"; \
+ echo "$$VARS" >$@; \
+ fi
+endif
+
test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2899,7 +2911,7 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui clean
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
- $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES
+ $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS
.PHONY: all install profile-clean clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH v4 1/3] Makefile: remove tracking of TCLTK_PATH
From: Christian Couder @ 2012-12-18 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason.
This patch removes the useless code used to do this tracking.
Maybe this code should have been moved to gitk-git/Makefile by
62ba514 (Move gitk to its own subdirectory, 2007-11-17).
A patch to do that has just been sent to Paul Mackerras, the gitk
maintainer.
While at it, this patch removes /gitk-git/gitk-wish from
.gitignore as it should be in /gitk-git/.gitignore and the patch
sent to Paul put it there.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Hi Junio,
I removed from the commit message everything that talked about
git-gui. And this patch removes /gitk-git/gitk-wish from
.gitignore.
Regards,
Christian.
.gitignore | 2 --
Makefile | 14 +-------------
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/.gitignore b/.gitignore
index f702415..64a454b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,7 +1,6 @@
/GIT-BUILD-OPTIONS
/GIT-CFLAGS
/GIT-LDFLAGS
-/GIT-GUI-VARS
/GIT-PREFIX
/GIT-SCRIPT-DEFINES
/GIT-USER-AGENT
@@ -171,7 +170,6 @@
/git-whatchanged
/git-write-tree
/git-core-*/?*
-/gitk-git/gitk-wish
/gitweb/GITWEB-BUILD-OPTIONS
/gitweb/gitweb.cgi
/gitweb/static/gitweb.js
diff --git a/Makefile b/Makefile
index 4ad6fbd..585b2eb 100644
--- a/Makefile
+++ b/Makefile
@@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' >>$@
endif
-### Detect Tck/Tk interpreter path changes
-ifndef NO_TCLTK
-TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
-
-GIT-GUI-VARS: FORCE
- @VARS='$(TRACK_VARS)'; \
- if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new Tcl/Tk interpreter location"; \
- echo "$$VARS" >$@; \
- fi
-endif
-
test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2910,7 +2898,7 @@ ifndef NO_TCLTK
$(MAKE) -C gitk-git clean
$(MAKE) -C git-gui clean
endif
- $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
+ $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
$(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES
.PHONY: all install profile-clean clean strip
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH v4 3/3] Makefile: replace "echo 1>..." with "echo >..."
From: Christian Couder @ 2012-12-18 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is clearer to many people this way.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 10 +++++-----
git-gui/Makefile | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 7db8445..e055c9a 100644
--- a/Makefile
+++ b/Makefile
@@ -2183,7 +2183,7 @@ endef
GIT-SCRIPT-DEFINES: FORCE
@FLAGS='$(SCRIPT_DEFINES)'; \
if test x"$$FLAGS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new script parameters"; \
+ echo >&2 " * new script parameters"; \
echo "$$FLAGS" >$@; \
fi
@@ -2564,7 +2564,7 @@ TRACK_PREFIX = $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):\
GIT-PREFIX: FORCE
@FLAGS='$(TRACK_PREFIX)'; \
if test x"$$FLAGS" != x"`cat GIT-PREFIX 2>/dev/null`" ; then \
- echo 1>&2 " * new prefix flags"; \
+ echo >&2 " * new prefix flags"; \
echo "$$FLAGS" >GIT-PREFIX; \
fi
@@ -2573,7 +2573,7 @@ TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):$(USE_GETTEXT_SCHEME)
GIT-CFLAGS: FORCE
@FLAGS='$(TRACK_CFLAGS)'; \
if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
- echo 1>&2 " * new build flags"; \
+ echo >&2 " * new build flags"; \
echo "$$FLAGS" >GIT-CFLAGS; \
fi
@@ -2582,7 +2582,7 @@ TRACK_LDFLAGS = $(subst ','\'',$(ALL_LDFLAGS))
GIT-LDFLAGS: FORCE
@FLAGS='$(TRACK_LDFLAGS)'; \
if test x"$$FLAGS" != x"`cat GIT-LDFLAGS 2>/dev/null`" ; then \
- echo 1>&2 " * new link flags"; \
+ echo >&2 " * new link flags"; \
echo "$$FLAGS" >GIT-LDFLAGS; \
fi
@@ -2631,7 +2631,7 @@ TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
GIT-PYTHON-VARS: FORCE
@VARS='$(TRACK_PYTHON)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new Python interpreter location"; \
+ echo >&2 " * new Python interpreter location"; \
echo "$$VARS" >$@; \
fi
endif
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e22ba5c..e9c2bc3 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -254,7 +254,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS
auto_mkindex lib '*.tcl' \
| $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \
else \
- echo 1>&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
+ echo >&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
rm -f $@ ; \
echo '# Autogenerated by git-gui Makefile' >$@ && \
echo >>$@ && \
@@ -274,8 +274,8 @@ TRACK_VARS = \
GIT-GUI-VARS: FORCE
@VARS='$(TRACK_VARS)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new locations or Tcl/Tk interpreter"; \
- echo 1>$@ "$$VARS"; \
+ echo >&2 " * new locations or Tcl/Tk interpreter"; \
+ echo >$@ "$$VARS"; \
fi
ifdef GITGUI_MACOSXAPP
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* Re: [BUG] Cannot push some grafted branches
From: Junio C Hamano @ 2012-12-18 16:09 UTC (permalink / raw)
To: Yann Dirson; +Cc: Andreas Schwab, Christian Couder, Thomas Rast, git list
In-Reply-To: <20121218120058.0c558ba5@chalon.bertin.fr>
Yann Dirson <dirson@bertin.fr> writes:
> On Mon, 17 Dec 2012 13:14:56 -0800
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>> > Christian Couder <christian.couder@gmail.com> writes:
>> >
>> >> Yeah, at one point I wanted to have a command that created to craft a
>> >> new commit based on an existing one.
>> >
>> > This isn't hard to do, you only have to resort to plumbing:
>> >
>> > $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ | git hash-object -t commit --stdin -w
>> > bb45cc6356eac6c7fa432965090045306dab7026
>>
>> Good. I do not think an extra special-purpose command is welcome
>> here.
>
> Well, I'm not sure this is intuitive enough to be useful to the average user :)
I do not understand why you even want to go in the harder route in
the first place, only to complicate things?
All you want to do is to craft a commit object that records a
specific tree shape, has a set of parents you want, and has the log
information you want. Once you have the commit, you can replace an
unwanted commit with it.
----A----B----o---- ....
X----Y----Z---- ....
Suppose you want to pretend that X is a child of A, even though it
is not in the real life. So you want to create a commit that
- has the same tree as X;
- has A as its parent; and
- records log and authorship of X.
and then use "git replace" to replace X, right? How about doing it
this way?
$ git checkout X^0 ;# detach
$ git reset --soft A
$ git commit -C X
The first gives you the index and the working tree that is the same
as X, the second moves HEAD while keeping the index and the working
tree so that the commit you create will be a child of A, and the
last makes that commit with the metainformation from X [*1*]. If
you want, you can even tweak the contents of the tree before making
the commit in the final step, or tweak the log message during the
final step.
Then you can take the resulting commit and replace X with it, no?
Alternatively, you can do:
$ git checkout X^0 ;# detach
$ git reset --soft B
$ git commit --amend -C X
that is, find an existing commit B that has the desired set of
parents, and amend it with the same tree and the metainformation as
X. This would even work when you want to come up with a commit that
replaces a merge. For example, if you want to pretend that B were a
merge between A and X in the above topology, you could
$ git checkout -b temp A
$ git merge -s ours X ;# the recorded tree does not matter
$ git checkout B^0 ;# detach
$ git reset --soft temp
$ git commit --amend -c B
which would create one merge that has the desired set of parents
(i.e. A and X) in the first two steps on temp branch, prepares the
index and the working tree to match the tree of B, and with that
tree and the metainformation from B, amends that merge. The
resulting commit will be a merge between A and X that has the tree
of B and metainformation of B (with a chance to edit it further, as
I used -c there).
Is this not intuitive enough?
[Footnote]
*1* If you are not tweaking the tree contents, you can do this
all in the index without affecting the working tree, e.g.
$ git checkout HEAD^0 ;# totally random state unrelated to X nor A
$ git read-tree X ;# just update the index to match tree of X
$ git reset --soft A ;# next commit will be child of A
$ git commit -C X ;# and with metainformation from X
After you are done, you can "read-tree $branch" followed by
"checkout $branch" to come back to where you were.
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Jeff King @ 2012-12-18 16:24 UTC (permalink / raw)
To: Yann Dirson
Cc: Thomas Rast, Johannes Sixt, Junio C Hamano, Andreas Schwab,
Christian Couder, Thomas Rast, git list
In-Reply-To: <20121218144157.00ccd915@chalon.bertin.fr>
On Tue, Dec 18, 2012 at 02:41:57PM +0100, Yann Dirson wrote:
> > I wouldn't even want a script -- we'd end up inventing a complicated
> > command-line editor for what can simply be done by judicious use of an
> > actual text editor. How about something like the following?
>
> Well, while it does the job, it is still hardly as straightforward as the
> old "vi .git/info/grafts", or as a single easily-remembered commandline.
I wouldn't discount coming up with something based around "git commit"
that might be easier to use for specific instances, but it does seem
like an obvious feature to "git replace" to encapsulate Thomas's edit
script, which is the most general form.
I am not really interested in pushing this forward myself, but I worked
up this toy that somebody might find interesting (you can "git replace
HEAD~20" to get dumped in an editor). It should probably handle trees,
and it would probably make sense to do per-object-type sanity checks
(e.g., call verify_tag on tags).
diff --git a/builtin/replace.c b/builtin/replace.c
index 398ccd5..90979b6 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -81,6 +81,57 @@ static int delete_replace_ref(const char *name, const char *ref,
return 0;
}
+static void edit_buffer(struct strbuf *out, const char *buf, unsigned long len)
+{
+ char tmpfile[PATH_MAX];
+ int fd;
+
+ fd = git_mkstemp(tmpfile, sizeof(tmpfile), "replace.XXXXXX");
+ if (fd < 0)
+ die_errno("unable to create tempfile");
+ if (write_in_full(fd, buf, len) < 0)
+ die_errno("unable to write to tempfile");
+ if (launch_editor(tmpfile, out, NULL) < 0)
+ die_errno("unable to run editor");
+
+ close(fd);
+ unlink_or_warn(tmpfile);
+}
+
+static void edit_object(unsigned char old[20], unsigned char new[20])
+{
+ enum object_type type;
+ unsigned long size;
+ char *old_buf;
+ struct strbuf new_buf = STRBUF_INIT;
+
+ old_buf = read_sha1_file_extended(old, &type, &size, 0);
+ if (!old_buf)
+ die("unable to read object '%s'", sha1_to_hex(old));
+
+ switch (type) {
+ case OBJ_COMMIT:
+ case OBJ_TAG:
+ case OBJ_BLOB:
+ /* These are OK to edit literally. */
+ edit_buffer(&new_buf, old_buf, size);
+ break;
+ case OBJ_TREE:
+ /*
+ * XXX we'd probably want to massage this into ls-tree format,
+ * and then read the result back via mktree.
+ */
+ die("editing tree objects is not yet supported");
+ default:
+ die("unknown object type for %s", sha1_to_hex(old));
+ }
+
+ if (write_sha1_file(new_buf.buf, new_buf.len, typename(type), new) < 0)
+ die("unable to write replacement object");
+ free(old_buf);
+ strbuf_release(&new_buf);
+}
+
static int replace_object(const char *object_ref, const char *replace_ref,
int force)
{
@@ -90,7 +141,7 @@ static int replace_object(const char *object_ref, const char *replace_ref,
if (get_sha1(object_ref, object))
die("Failed to resolve '%s' as a valid ref.", object_ref);
- if (get_sha1(replace_ref, repl))
+ if (replace_ref && get_sha1(replace_ref, repl))
die("Failed to resolve '%s' as a valid ref.", replace_ref);
if (snprintf(ref, sizeof(ref),
@@ -105,6 +156,9 @@ static int replace_object(const char *object_ref, const char *replace_ref,
else if (!force)
die("replace ref '%s' already exists", ref);
+ if (!replace_ref)
+ edit_object(object, repl);
+
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
die("%s: cannot lock the ref", ref);
@@ -144,7 +198,7 @@ int cmd_replace(int argc, const char **argv, const char *prefix)
/* Replace object */
if (!list && argc) {
- if (argc != 2)
+ if (argc < 1 || argc > 2)
usage_msg_opt("bad number of arguments",
git_replace_usage, options);
return replace_object(argv[0], argv[1], force);
^ permalink raw reply related
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Jeff King @ 2012-12-18 16:30 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Junio C Hamano, Philippe Vaucher, git, Christian Couder
In-Reply-To: <CANiSa6h3Qf=6hw6fzHVw=CeuhnNeq+cuEvwwmVhUaSOcVgCSBA@mail.gmail.com>
On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote:
> On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > I am guilty of introducing "git reset --soft HEAD^" before I invented
> > "commit --amend" during v1.3.0 timeframe to solve the issue "soft" reset
> > originally wanted to.
>
> I do use "commit --amend" a lot, but I still appreciate having "reset
> --soft". For example, to squash the last few commits:
>
> git reset --soft HEAD^^^ && git commit --amend
Me too. Another one I use is:
$ hack hack hack
$ git commit -m wip
$ git checkout something-else
... time passes ...
$ git checkout orig-branch
$ git reset --soft HEAD^
$ hack hack hack
$ git diff
$ git add -p
$ git commit
which ends up with the same history as "commit --amend", but in between
the reset and the commit, the bogus WIP commit is thrown away entirely.
And things like "diff" and "add -p" do what you want, instead of showing
your progress on top of the WIP.
-Peff
^ permalink raw reply
* Re: [PATCH] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-18 16:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk1clb3n.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 17/12/2012 20:42, Junio C Hamano ha scritto:
> [...]
>>> I am not sure how you would handle the last parameter to "git mv",
>>> though. That is by definition a path that does not exist,
>>> i.e. cannot be completed.
>>
>> Right, the code should be changed.
>> No completion should be done for the second parameter.
>
> I deliberately wrote "the last" not "the second", as you can do
>
> $ mkdir X
> $ git mv COPYING README X/.
>
The patch is ready, however I decided to leave git mv completion simple.
Pressing <TAB> will always try to autocomplete using all cached files.
I have added a note to remember it needs more work.
P.S.:
git-completion.bash has a lot of other things that may be improved:
* adding missing commands
(as an example, there is strangely no custom support fot "git status")
* completion support for commands like "git checkout" is not complete.
"git checkout <TAB>" will correctly try to complete the tree-ish,
however "git checkout HEAD -- <TAB>" will try to complete the path
using *all* files in the working directory.
This is easy to fix, using the new functions I have added
* not all long options are supported.
The script documentation says that only common long options are
supported, so I'm not sure it is ok to add support for all available
long options.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDQmQgACgkQscQJ24LbaUSw9QCfT1lCH/yjA4Lgmb2nMspNWM3l
hMMAn26UxWesuoOxMbuwhqaypPjkmN84
=Wh4c
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Jeff King @ 2012-12-18 16:41 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Toralf Förster, Andrew Ardill, git@vger.kernel.org
In-Reply-To: <50D05E62.7090605@web.de>
On Tue, Dec 18, 2012 at 01:15:30PM +0100, Torsten Bögershausen wrote:
> I could re-produce the problem here:
> git version 1.8.0.197.g5a90748
> Mac OS X (that what I had at hands fastest)
I could reproduce it, too, on Linux.
The reason it does not always happen is that git will not re-examine the
file content unless the timestamp on the file is older than what's in
the index. So it is a race condition for git to see whether the file is
stat-dirty.
But you can make sure all files are stat-dirty by just resetting the
index:
$ git clone git://boinc.berkeley.edu/boinc.git
$ rm .git/index
$ git reset
which shows the complete list of files with LF/CRLF normalization
issues.
> So my conclusion is:
> The file has CRLF in the repo, but should have LF.
> This is not a good thing, and the files need to be normalized.
Yes, exactly. The project has told git via .gitattributes that certain
files should have particular line endings in the repository, but that is
not the case with the current versions. Doing:
$ git commit -a -m 'normalize line endings according to gitattributes'
on top of the commands above would fix it (for that commit and onwards,
anyway).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-18 16:43 UTC (permalink / raw)
To: Chris Rorvick
Cc: Andrew Ardill, Philip Oakley, Git List, Tomas Carnecky, Woody Wu,
Johannes Sixt
In-Reply-To: <CAEUsAPa1XMeymEXbLu=iy8VTdLO=iPUeVN3QPH+FbQecL8XnsA@mail.gmail.com>
Chris Rorvick <chris@rorvick.com> writes:
> I like Johannes' suggestion of using "<branch>" in the --detach case
> instead of "<commit>" as I think it makes the reason for the
> separation more obvious at a glance.
Sounds sensible; even though the option does not require its
argument to be a branch name, the user does not have a reason to use
the option if it is not giving a branch name, either, so it all
balances out ;-).
>
> --->8---
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index dcf1a32..4fdf41a 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -61,8 +61,8 @@ $ git checkout <branch>
> that is to say, the branch is not reset/created unless "git checkout" is
> successful.
>
> -'git checkout' --detach [<commit>]::
> 'git checkout' <commit>::
> +'git checkout' --detach [<branch>]::
>
> Prepare to work on top of <commit>, by detaching HEAD at it
> (see "DETACHED HEAD" section), and updating the index and the
> @@ -71,7 +71,8 @@ successful.
> tree will be the state recorded in the commit plus the local
> modifications.
> +
> -Passing `--detach` forces this behavior even if <commit> is a branch.
> +Passing `--detach` forces this behavior in the case of a <branch>, or
> +the current branch if one is not specified.
>
> 'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
^ permalink raw reply
* sys/param.h
From: Junio C Hamano @ 2012-12-18 17:01 UTC (permalink / raw)
To: git
In-Reply-To: <50D02B9A.1040906@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> Junio C Hamano wrote:
>>> It could turn out that we may be able to get rid of sys/param.h
>>> altogether, but one step at a time. Inputs from people on minority
>>> platforms are very much appreciated---does your platform build fine
>>> when the inclusion of the file is removed from git-compat-util.h?
>
> MinGW works fine with sys/param.h removed from git-compat-util.h.
It seems that OpenBSD 5.2 does not mind it getting removed, either.
Debian 5 and Debian 6 seem OK; so do Ubuntu 10.04 and 12.04. I have
a hunch that Fedora or anything based on glibc would be fine, too.
What other platforms do we care deeply about?
^ permalink raw reply
* Re: [PATCH] Makefile: track TCLTK_PATH as it used to be tracked
From: Junio C Hamano @ 2012-12-18 17:07 UTC (permalink / raw)
To: Christian Couder; +Cc: Paul Mackerras, git
In-Reply-To: <20121218145753.28253.98431.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> A long time ago, gitk used to live at the root of the git.git
> repository. In 62ba514 (Move gitk to its own subdirectory,
> 2007-11-17) it was moved to a subdirectory, but some code used
> to track TCLTK_PATH was left in the main Makefile instead
> of being moved to the new Makefile that was created in gitk-git/.
>
> The code left in the main Makefile in git.git should now have
> been removed because it was found useless.
>
> And this patch puts some code back to track TCLTK_PATH properly
> where it should be.
It is more like "should have been moved to gitk's Makefile back
then, but didn't. Make it so.".
>
> Note that there is already some code to do that in git-gui.
>
> At the same time this patch creates a .gitignore and also marks
> some targets in the Makefile as PHONY.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> Hi Paul,
>
> In this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/211641
>
> Junio asked me to send you this patch.
> So here it is, for you to apply to your tree.
Paul, just to clarify, I didn't review the contents of the patch; I
merely redirected the patch in the right direction, so this still
needs to be vetted by you ;-)
> ...
> +GIT-TCLTK-VARS: FORCE
> + @VARS='$(TRACK_TCLTK)'; \
> + if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
> + echo 1>&2 " * new Tcl/Tk interpreter location"; \
I think in a related patch to the top-level Makefile changes it to
lose "1" to read it as "echo >&2" here.
^ permalink raw reply
* [PATCH v3] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-18 17:25 UTC (permalink / raw)
To: git; +Cc: Manlio Perillo
The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.
For these commands, only long options completion was available.
As an example:
git add <TAB>
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths within the current
working directory or the index, as the follow:
* the path completion for the "git mv", "git rm" and "git ls-tree"
commands will suggest all cached files.
* the path completion for the "git add" command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the "git clean" command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the "git commit" command will suggest all
files that have been modified from the HEAD.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
contrib/completion/git-completion.bash | 112 ++++++++++++++++++++++++++++-----
1 file changed, 97 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..923ef37 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
# *) .git/remotes file names
# *) git 'subcommands'
# *) tree paths within 'ref:path/to/file' expressions
+# *) file paths within current working directory and index
# *) common --long-options
#
# To use these routines:
@@ -233,6 +234,59 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
+# Perl filter used to process path list returned by ls-files and
+# diff-index --name-only commands, in order to list file names
+# relative to a specified directory, and append a slash to directory
+# names.
+# The script expects the prefix path in the "pfx" environ variable.
+# The output must be processed with the uniq filter, to remove
+# duplicate directories.
+# XXX remove duplicates in the Perl script ?
+__git_index_file_list_filter='$pfx = $ENV{"pfx"};
+ $idx = index($_, $pfx);
+ if ($idx == 0) {
+ $_ = substr $_, length($pfx);
+ @segments = split("/", $_);
+ if ($segments[1]) {
+ print $segments[0], "/\n"
+ } else {
+ print $segments[0], "\n"
+ }
+ }'
+
+# __git_files accepts 1 or 2 arguments:
+# 1: A string for file index status mode ("c", "m", "d", "o"), as
+# supported by git ls-files command. This is required.
+# 2: An optional directory path. If provided, only files within the
+# specified directory are listed. Sub directories are never recursed.
+# Path must have a trailing slash.
+__git_files ()
+{
+ local dir="$(__gitdir)" flags="-${1}"
+
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" ls-files --exclude-standard ${flags} ${pfx} \
+ | pfx=$2 perl -ne "${__git_index_file_list_filter}" \
+ | uniq
+ return
+ fi
+}
+
+# __git_commit_files accepts 1 optional argument: a directory path.
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing slash.
+__git_commit_files ()
+{
+ local dir="$(__gitdir)"
+
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" diff-index --name-only HEAD \
+ | pfx=$1 perl -ne "${__git_index_file_list_filter}" \
+ | uniq
+ return
+ fi
+}
+
__git_heads ()
{
local dir="$(__gitdir)"
@@ -430,6 +484,25 @@ __git_complete_revlist_file ()
}
+# __git_complete_index_file requires 1 argument, the file index
+# status mode
+_git_complete_index_file ()
+{
+ local pfx cur_="$cur" flags=${1}
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_nl "$(__git_files ${flags} ${pfx})" "$pfx" "$cur_" ""
+ ;;
+ *)
+ __gitcomp_nl "$(__git_files ${flags})" "" "$cur_" ""
+ ;;
+ esac
+}
+
__git_complete_file ()
{
__git_complete_revlist_file
@@ -770,8 +843,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "
@@ -780,7 +851,8 @@ _git_add ()
"
return
esac
- COMPREPLY=()
+ # XXX should we check for --update and --all options ?
+ _git_complete_index_file "om"
}
_git_archive ()
@@ -930,15 +1002,14 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
return
;;
esac
- COMPREPLY=()
+ # XXX should we check for -x option ?
+ _git_complete_index_file "o"
}
_git_clone ()
@@ -969,7 +1040,7 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash && return
+ local pfx cur_=${cur}
case "$cur" in
--cleanup=*)
@@ -997,8 +1068,20 @@ _git_commit ()
--verbose --quiet --fixup= --squash=
"
return
+ ;;
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_nl "$(__git_commit_files ${pfx})" "$pfx" "$cur_" ""
+ return
+ ;;
+ *)
+ __gitcomp_nl "$(__git_commit_files)" "" "$cur_" ""
+ return
+ ;;
esac
- COMPREPLY=()
}
_git_describe ()
@@ -1216,8 +1299,6 @@ _git_init ()
_git_ls_files ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --deleted --modified --others --ignored
@@ -1230,7 +1311,9 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
+ # XXX ignore options like --modified and always suggest all cached
+ # files.
+ _git_complete_index_file "c"
}
_git_ls_remote ()
@@ -1362,7 +1445,8 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ # XXX needs more work
+ _git_complete_index_file "c"
}
_git_name_rev ()
@@ -2068,15 +2152,13 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
- COMPREPLY=()
+ _git_complete_index_file "c"
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
^ permalink raw reply related
* [RFH/PATCH] git-compat-util.h: do not #include <sys/param.h> by default
From: Junio C Hamano @ 2012-12-18 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vobhrgupr.fsf_-_@alter.siamese.dyndns.org>
Earlier we allowed platforms that lack <sys/param.h> not to include
the header file from git-compat-util.h; we have included this header
file since the early days back when we used MAXPATHLEN (which we no
longer use) and also depended on it slurping ULONG_MAX (which we get
by including stdint.h or inttypes.h these days).
It turns out that we can compile our modern codebase just file
without including it on many platforms (so far, Debian, Ubuntu,
MinGW, HP-Nonstop, QNX and z/OS are reported to be OK).
Let's stop including it by default, and on platforms that need it to
be included, leave "make NEEDS_SYS_PARAM_H=YesPlease" as an escape
hatch and ask them to report to us, so that we can find out about
the real dependency and fix it in a more platform agnostic way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I'd propose queuing this on top of dm/port topic, cook it in
'next' for a while and then unleash it to the public.
Makefile | 8 +++++---
configure.ac | 6 ------
git-compat-util.h | 2 +-
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 5cd1de0..2c1f04f 100644
--- a/Makefile
+++ b/Makefile
@@ -167,7 +167,9 @@ all::
# Define NO_POLL if you do not have or don't want to use poll().
# This also implies NO_SYS_POLL_H.
#
-# Define NO_SYS_PARAM_H if you don't have sys/param.h.
+# Define NEEDS_SYS_PARAM_H if you need to include sys/param.h to compile,
+# *PLEASE* REPORT to git@vger.kernel.org if your platform needs this;
+# we want to know more about the issue.
#
# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
#
@@ -1747,8 +1749,8 @@ endif
ifdef NO_SYS_POLL_H
BASIC_CFLAGS += -DNO_SYS_POLL_H
endif
-ifdef NO_SYS_PARAM_H
- BASIC_CFLAGS += -DNO_SYS_PARAM_H
+ifdef NEEDS_SYS_PARAM_H
+ BASIC_CFLAGS += -DNEEDS_SYS_PARAM_H
endif
ifdef NO_INTTYPES_H
BASIC_CFLAGS += -DNO_INTTYPES_H
diff --git a/configure.ac b/configure.ac
index e3ab6fe..8fbb533 100644
--- a/configure.ac
+++ b/configure.ac
@@ -699,12 +699,6 @@ AC_CHECK_HEADER([sys/poll.h],
[NO_SYS_POLL_H=UnfortunatelyYes])
GIT_CONF_SUBST([NO_SYS_POLL_H])
#
-# Define NO_SYS_PARAM_H if you don't have sys/param.h
-AC_CHECK_HEADER([sys/param.h],
-[NO_SYS_PARAM_H=],
-[NO_SYS_PARAM_H=UnfortunatelyYes])
-GIT_CONF_SUBST([NO_SYS_PARAM_H])
-#
# Define NO_INTTYPES_H if you don't have inttypes.h
AC_CHECK_HEADER([inttypes.h],
[NO_INTTYPES_H=],
diff --git a/git-compat-util.h b/git-compat-util.h
index d7359ef..a88147b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -104,7 +104,7 @@
#endif
#include <errno.h>
#include <limits.h>
-#ifndef NO_SYS_PARAM_H
+#ifdef NEEDS_SYS_PARAM_H
#include <sys/param.h>
#endif
#include <sys/types.h>
--
1.8.1.rc2.136.gb42b73a
^ permalink raw reply related
* Incorrect man page for git-diff
From: Manlio Perillo @ 2012-12-18 17:40 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
Documentation seems to suggest this is supported, but it is not true:
$ git diff HEAD:git.c HEAD~100:git.c -- git.c
usage: git diff [<options>] [<commit> [<commit>]] [--] [<path>...]
unless I'm missing something.
Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDQqncACgkQscQJ24LbaUT9XwCfV40P7lGulSWw+dzVo17EhcDQ
YFoAnRb46025qYsKWp9mg6ZTRyuuaG3x
=0gO1
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v3] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2012-12-18 17:53 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git, SZEDER Gábor, Felipe Contreras
In-Reply-To: <1355851510-13438-1-git-send-email-manlio.perillo@gmail.com>
[jch: cc'ed git-completion experts to review implementation details]
Manlio Perillo <manlio.perillo@gmail.com> writes:
> The git-completion.bash script did not implemented full, git aware,
> support for completion, for git commands that operate on files within
> the current working directory or the index.
>
> For these commands, only long options completion was available.
I find the "long options completion" is a misleading phrase. It
sounds as if you changed the current completion that does not
complete "git commit -<TAB>" but does "git commit --<TAB>" to
complete the short options (e.g. "git commit -c"), but I do not
think that is the topic of this patch.
> As an example:
>
> git add <TAB>
>
> will suggest all files in the current working directory, including
> ignored files and files that have not been modified.
>
> Full support for completion is now implemented, for git commands where
s/Full.*implemented/Support more comprehensive completion/; or
something, talking in the imperative mood (i.e. as if you are giving
the order to the codebase to do something).
> the non-option arguments always refer to paths within the current
> working directory or the index, as the follow:
>
> * the path completion for the "git mv", "git rm" and "git ls-tree"
> commands will suggest all cached files.
I thought you dropped "git mv" in this round.
> * the path completion for the "git add" command will suggest all
> untracked and modified files. Ignored files are excluded.
>
> * the path completion for the "git clean" command will suggest all
> untracked files. Ignored files are excluded.
>
> * the path completion for the "git commit" command will suggest all
> files that have been modified from the HEAD.
>
> For all affected commands, completion will always stop at directory
> boundary. Only standard ignored files are excluded, using the
> --exclude-standard option of the ls-files command.
I read "always stop at directory boundary" to mean that
git cmd t<TAB>
will give us "t/ tag.c" (assuming there is a new or modified file in
t/ and tag.c is the only modified file at the root level that begins
with "t") and then
git cmd t/<TAB>
will likewise show the files and top-level subdirectories within t/
directory. That would be great.
> Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
> ---
> contrib/completion/git-completion.bash | 112 ++++++++++++++++++++++++++++-----
> 1 file changed, 97 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0b77eb1..923ef37 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -13,6 +13,7 @@
> # *) .git/remotes file names
> # *) git 'subcommands'
> # *) tree paths within 'ref:path/to/file' expressions
> +# *) file paths within current working directory and index
> # *) common --long-options
> #
> # To use these routines:
> @@ -233,6 +234,59 @@ __gitcomp_nl ()
> COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
> }
>
> +# Perl filter used to process path list returned by ls-files and
> +# diff-index --name-only commands, in order to list file names
> +# relative to a specified directory, and append a slash to directory
> +# names.
> +# The script expects the prefix path in the "pfx" environ variable.
> +# The output must be processed with the uniq filter, to remove
> +# duplicate directories.
> +# XXX remove duplicates in the Perl script ?
Surely, that will remove one fork/exec with pipeline. I am not sure
what the performance implication of using Perl here, but because we
do not have to stick to POSIX shell in this file, the completion
experts would be able to help rewriting this logic as a pure bash
script.
> +__git_index_file_list_filter='$pfx = $ENV{"pfx"};
> + $idx = index($_, $pfx);
> + if ($idx == 0) {
> + $_ = substr $_, length($pfx);
> + @segments = split("/", $_);
> + if ($segments[1]) {
> + print $segments[0], "/\n"
> + } else {
> + print $segments[0], "\n"
> + }
> + }'
> +
> +# __git_files accepts 1 or 2 arguments:
> +# 1: A string for file index status mode ("c", "m", "d", "o"), as
> +# supported by git ls-files command. This is required.
> +# 2: An optional directory path. If provided, only files within the
> +# specified directory are listed. Sub directories are never recursed.
> +# Path must have a trailing slash.
> +__git_files ()
> +{
> + local dir="$(__gitdir)" flags="-${1}"
> +
> + if [ -d "$dir" ]; then
> + git --git-dir="$dir" ls-files --exclude-standard ${flags} ${pfx} \
> + | pfx=$2 perl -ne "${__git_index_file_list_filter}" \
> + | uniq
This is purely a style thing (note that style suggestions are not
optional), but
the data source command |
a filter command |
another filter command
is easier to read and can be spelled without the backslash. The
same comment applies to git-commit-files as well.
Thanks.
^ permalink raw reply
* Re: Re: [PATCH] completion: add option --recurse-submodules to "git push"
From: Heiko Voigt @ 2012-12-18 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Jaeckel, git, Felipe Contreras, Jens Lehmann
In-Reply-To: <7vehj1ixr6.fsf@alter.siamese.dyndns.org>
Hi,
sorry for the late reply.
On Fri, Dec 07, 2012 at 09:21:33AM -0800, Junio C Hamano wrote:
> Steffen Jaeckel <steffen.jaeckel@stzedn.de> writes:
>
> > Signed-off-by: Steffen Jaeckel <steffen.jaeckel@stzedn.de>
> > ---
> > contrib/completion/git-completion.bash | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 0b77eb1..5b4d2e1 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -1434,6 +1434,10 @@ _git_pull ()
> > __git_complete_remote_or_refspec
> > }
> >
> > +__git_push_recurse_submodules_options="
> > + check on-demand
> > +"
>
> Most of the existing completion functions do not seem to define
> separate variables like this; instead, they literally embed their
> choices at the point of use.
>
> Is it expected that the same set of choices will appear in the
> completion of many other subcommand options? [jc: Cc'ed Heiko so
> that we can sanity check the answer to this question]. If so, the
> variable may be justified; otherwise, not.
No I think not. At least not exactly the same. check will be limited to
push since it only makes sense there. on-demand on the other hand is
already used for fetch and pull. Currently no more possible uses come to
my mind. checkout and others will learn to traverse submodules but that will
most likely be a boolean (to switch it on and off).
CC'ed Jens so he can also take a look.
Cheers Heiko
^ permalink raw reply
* Re: Incorrect man page for git-diff
From: Junio C Hamano @ 2012-12-18 18:11 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50D0AA78.5090603@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> Documentation seems to suggest this is supported, but it is not true:
>
> $ git diff HEAD:git.c HEAD~100:git.c -- git.c
> usage: git diff [<options>] [<commit> [<commit>]] [--] [<path>...]
>
> unless I'm missing something.
Neither HEAD:git.c nor HEAD~100:git.c are commits. You are
comparing two blob objects in their raw forms without textconv nor
filter.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox