* [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
* 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
* 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
* [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
* 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
* 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
* 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 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: 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: Johannes Sixt @ 2012-12-18 12:03 UTC (permalink / raw)
To: Yann Dirson
Cc: Junio C Hamano, Andreas Schwab, Christian Couder, Thomas Rast,
git list
In-Reply-To: <20121218120058.0c558ba5@chalon.bertin.fr>
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.
-- Hannes
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-18 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Christian Couder, Thomas Rast, git list
In-Reply-To: <7vwqwgjs8f.fsf@alter.siamese.dyndns.org>
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 :)
Adding git-rev-parse calls for convenience, and calling git-replace, would make it
a more complete recipe, and we could suggest that as an alias in the collection that's
in the wiki (which is not even linked any more from git-scm.com btw), but imho that
would be hiding valuable information in a dark corner.
Anyway, in this form it will only replace a parent with another, whereas a full
graft replacement should allow to write a different number of new parents instead.
That is, instead of this simple sed, something like:
(NEWPARENTS='parent xxx\nparent yyy\nparent zzz\n; git cat-file commit master | perl -ne 'BEGIN { $state=0 }; if ($state eq 0) { if (/^parent/) { $state=1 } else { print } } elsif ($state eq 1) { if (/^author/) { print "'"$NEWPARENTS"'"; print; $state=2 } } else { print }')
Well, a short bash script should be more readable and possibly faster, but that's the
idea. Such a script could be a candidate for contrib ?
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Toralf Förster @ 2012-12-18 9:55 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451=xiipSKrAb_DFXCW=+NAn+mnSm1zPzjhEVc8fZ2KGcnw@mail.gmail.com>
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...
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Toralf Förster @ 2012-12-18 9:58 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <50D03D80.3090005@gmx.de>
On 12/18/2012 10:55 AM, Toralf Förster wrote:
> failed test(s): t3600 t7508
>
> fixed 0
> success 8342
> failed 8
> broken 56
> total 8528
>
ick forgot these :
n22 /usr/portage/dev-vcs/git # grep -i "^not ok" /tmp/git.log | grep -v TODO
not ok - 15 Test that "git rm -f" fails if its rm fails
not ok - 16 When the rm in "git rm -f" fails, it should not remove the file from the index
not ok - 20 Re-add foo and baz
not ok - 21 Modify foo -- rm should refuse
not ok - 22 Modified foo -- rm -f should work
not ok - 23 Re-add foo and baz for HEAD tests
not ok - 24 foo is different in index from HEAD -- rm should refuse
not ok - 55 status succeeds in a read-only repository
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2012, #04; Sun, 16)
From: Johannes Sixt @ 2012-12-18 8:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20121217213730.GA17212@ftbfs.org>
> 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.
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2012, #04; Sun, 16)
From: Joachim Schmitz @ 2012-12-18 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <20121217213730.GA17212@ftbfs.org>
Matt Kraai wrote:
> 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?
>
> QNX builds fine when sys/param.h is not included.
HP-NonStop build fine too without it.
Bye, Jojo
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Martin von Zweigbergk @ 2012-12-18 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philippe Vaucher, git, Christian Couder
In-Reply-To: <7vlir6brjw.fsf@alter.siamese.dyndns.org>
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
or undo "commit --amend":
git reset --soft HEAD@{1} && git commit --amend
Maybe there's a better way of doing that?
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Martin von Zweigbergk @ 2012-12-18 6:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Philippe Vaucher, git
In-Reply-To: <vpq4nxvusty.fsf@bauges.imag.fr>
On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Philippe Vaucher <philippe.vaucher@gmail.com> writes:
>
>> Optional: a new mode would be introduced for consistency:
>> --worktree (or maybe --tree): only updates the worktree but not the index
>
> That would be an alias for "git checkout <rev> -- path", right?
Not quite, in two ways, I think. First, it _would_ update the index,
wouldn't it? Second, "git checkout <rev> -- path" doesn't delete files
that are deleted in <rev> as compared to head.
I'm considering implementing support for an operation that would do
what I expected "git checkout <rev> -- <path>" and "git reset --hard
<rev> -- <path>" to do. I'm currently planning for it to be exactly
"git reset --hard <rev> -- <path>" (which is currently simply not
allowed), but perhaps it would be more natural as an option to
checkout (--also-deleted or something)?
^ permalink raw reply
* Re: bug? 'git log -M100' is different from 'git log -M100%'
From: Sitaram Chamarty @ 2012-12-18 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfw34jgmv.fsf@alter.siamese.dyndns.org>
On Tue, Dec 18, 2012 at 6:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> When using -M with a number to act as a threshold for declaring
>> a change as being a rename, I found a... quirk. Any 2-digit
>> number after the M will work,...
>
> That is not 2-digit number.
>
> A few historical trivia may help.
>
> Originally we said "you can use -M2 to choose 2/10" (like "gzip"
> taking compression levels between "-0" to "-9"). Then Linus came up
> with a clever idea to let people specify arbitrary precision by
> letting you say "-M25" to mean 25/100 and "-M254" to mean 254/1000.
>
> Read the numbers without per-cent as if it has decimal point before
> it (i.e. -M005 is talking about 0.005 which is 0.5%). Full hundred
> per-cent has to be spelled with per-cent sign for obvious reasons
> with this scheme but that cannot be avoided. It is a special case.
Oh nice. Makes sense; thanks!
I submitted a patch to diff-options.txt (separately).
regards
sitaram
^ permalink raw reply
* [PATCH] clarify -M without % symbol in diff-options
From: Sitaram Chamarty @ 2012-12-18 4:15 UTC (permalink / raw)
To: Junio C Hamano, git
---
Documentation/diff-options.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index f4f7e25..39f2c50 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -309,7 +309,11 @@ endif::git-log[]
index (i.e. amount of addition/deletions compared to the
file's size). For example, `-M90%` means git should consider a
delete/add pair to be a rename if more than 90% of the file
- hasn't changed.
+ hasn't changed. Without a `%` sign, the number is to be read as
+ a fraction, with a decimal point before it. I.e., `-M5` becomes
+ 0.5, and is thus the same as `-M50%`. Similarly, `-M05` is
+ the same as `-M5%`. To limit detection to exact renames, use
+ `-M100%`.
-C[<n>]::
--find-copies[=<n>]::
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Chris Rorvick @ 2012-12-18 3:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andrew Ardill, Philip Oakley, Git List, Tomas Carnecky, Woody Wu,
Johannes Sixt
In-Reply-To: <7vvcc0i0rz.fsf@alter.siamese.dyndns.org>
On Mon, Dec 17, 2012 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here is a work-in-progress relative to Chris's 83c9989
> (Documentation/git-checkout.txt: document 70c9ac2 behavior,
> 2012-12-17).
It sounds pretty good to me.
> @@ -54,12 +61,17 @@ $ git checkout <branch>
> that is to say, the branch is not reset/created unless "git checkout" is
> successful.
>
> -'git checkout' [--detach] [<commit>]::
> +'git checkout' --detach [<commit>]::
> +'git checkout' <commit>::
>
> - Update the index and working tree to reflect the specified
> - commit and set HEAD to point directly to <commit> (see
> - "DETACHED HEAD" section.) Passing `--detach` forces this
> - behavior even if <commit> is a branch.
> + Prepare to work on top of <commit>, by detaching HEAD at it
> + (see "DETACHED HEAD" section), and updating the index and the
> + files in the working tree. Local modifications to the files
> + in the working tree are kept, so that the resulting working
> + tree will be the state recorded in the commit plus the local
> + modifications.
> ++
> +Passing `--detach` forces this behavior even if <commit> is a branch.
>
> 'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
>
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. On top of your changes, maybe
something like:
--->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 related
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Chris Rorvick @ 2012-12-18 2:55 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, git, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <50CED5D4.5040705@viscovery.net>
On Mon, Dec 17, 2012 at 2:20 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> +'git checkout' [--detach] [<commit>]::
>
> The title here is better spelled as two lines:
>
> 'git checkout' <commit>::
> 'git checkout' --detach <branch>::
AsciiDoc renders these horizontally separated by a comma when
formatted as a man page instead of vertically as written (and as
rendered by the HTML documentation.) I think this makes this
separation into two less effective, but at least it doesn't line wrap
on an 80-wide terminal like the previous title did.
Chris
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Andrew Ardill @ 2012-12-18 2:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Philip Oakley, Chris Rorvick, Git List, Tomas Carnecky, Woody Wu
In-Reply-To: <7vvcc0i0rz.fsf@alter.siamese.dyndns.org>
I like these, and I think they are conveying the right amount of
information. There is a slight discrepancy between the <branch> and
<commit> versions, where it seems we are assuming that by checking out
a commit you are intending to work 'on top of' it. This could be
avoided by using the term 'with' in both cases. Also, they are in
different tenses, but I'm not sure which is preferred ('Prepare to' vs
'To prepare for').
In the second tense, these opening lines might look like this:
+ To prepare for working with <branch>, switch to it by updating
+ To prepare for working with <commit>, detach HEAD at it
+ (see "DETACHED HEAD" section), and update the index and the
+ files in the working tree.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Andrew Ardill @ 2012-12-18 1:56 UTC (permalink / raw)
To: Toralf Förster; +Cc: git@vger.kernel.org
In-Reply-To: <50CF41EB.1060402@gmx.de>
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?
What happens if you do a hard reset to the branch?
What is the ouptut of git diff --cached ?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-18 1:53 UTC (permalink / raw)
To: Andrew Ardill
Cc: Philip Oakley, Chris Rorvick, Git List, Tomas Carnecky, Woody Wu
In-Reply-To: <7vobhsjq6a.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I agree with you that sightseeing use case where you do not intend
> to make any commit is also important. That is exactly why I said
> "further work is done on that branch" not "to that branch" in the
> message you are responding to.
Here is a work-in-progress relative to Chris's 83c9989
(Documentation/git-checkout.txt: document 70c9ac2 behavior,
2012-12-17).
Even though "switch to that specific branch" may be easy to grasp as
a concept, I do not think "switch to detached HEAD" makes much
sense, so I ended up with "switch" for the <branch> case, and
"detach" for the "--detach" one, at least for now.
diff --git c/Documentation/git-checkout.txt w/Documentation/git-checkout.txt
index db89cf7..dcf1a32 100644
--- c/Documentation/git-checkout.txt
+++ w/Documentation/git-checkout.txt
@@ -21,10 +21,12 @@ or the specified tree. If no paths are given, 'git checkout' will
also update `HEAD` to set the specified branch as the current
branch.
-'git checkout' [<branch>]::
-
- Update the index, working tree, and HEAD to reflect the
- specified branch.
+'git checkout' <branch>::
+ To prepare for working on <branch>, switch to it by updating
+ the index and the files in the working tree, and by pointing
+ HEAD at the branch. Local modifications to the files in the
+ working tree are kept, so that they can be committed to the
+ <branch>.
+
If <branch> is not found but there does exist a tracking branch in
exactly one remote (call it <remote>) with a matching name, treat as
@@ -33,6 +35,11 @@ equivalent to
------------
$ git checkout -b <branch> --track <remote>/<branch>
------------
++
+You could omit <branch>, in which case the command degenerates to
+"check out the current branch", which is a glorified no-op with a
+rather expensive side-effects to show only the tracking information,
+if exists, for the current branch.
'git checkout' -b|-B <new_branch> [<start point>]::
@@ -54,12 +61,17 @@ $ git checkout <branch>
that is to say, the branch is not reset/created unless "git checkout" is
successful.
-'git checkout' [--detach] [<commit>]::
+'git checkout' --detach [<commit>]::
+'git checkout' <commit>::
- Update the index and working tree to reflect the specified
- commit and set HEAD to point directly to <commit> (see
- "DETACHED HEAD" section.) Passing `--detach` forces this
- behavior even if <commit> is a branch.
+ Prepare to work on top of <commit>, by detaching HEAD at it
+ (see "DETACHED HEAD" section), and updating the index and the
+ files in the working tree. Local modifications to the files
+ in the working tree are kept, so that the resulting working
+ tree will be the state recorded in the commit plus the local
+ modifications.
++
+Passing `--detach` forces this behavior even if <commit> is a branch.
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
^ permalink raw reply related
* Re: [PATCH 1/1] tests: Allow customization of how say_color() prints
From: Junio C Hamano @ 2012-12-18 1:42 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <50CF9D4C.9080706@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Junio C Hamano wrote:
> ...
>> Why does your printf die in the first place???
>
> I really don't know. ...
>
> Sorry for wasting your time.
Not a waste. I was hoping somebody (not necessarily you) may be able
to come up with a cleaner solution. Unfortunately it hasn't
happened (yet), but discussing issues on the list is often not a
waste.
We could introduce git_test_print and git_test_println shell
functions that default to the current "printf", and let the users
override these by including a custom scriptllet from t/test-lib.sh,
or something.
^ 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