Feature request : "git fsck" should show the percentage of completeness in step "Checking connectivity:"
as "git fsck" does it already for "Checking objects:" Is this a valid feature request? -- Toralf PGP C4EACDDE 0076E94E
gitk takes a looong time for a subdir of the Gentoo repository
steps to reproduce: $> git clone git://git.gentoo.org/repo/gentoo.git $> cd gentoo $> gitk sys-apps/portage-mgorny For few minutes I do just read here : "Reading commits..." -- Toralf PGP C4EACDDE 0076E94E signature.asc Description: OpenPGP digital signature
Re: enhancement request : If 2 commits to be squashed together do have the same title and comment ...
On 07/09/2017 08:52 PM, Junio C Hamano wrote: > In the form, it is valid---sending a message to git@vger.kernel.org > is the right way to describe a problem and ask for a help (or better > yet, propose a solution ;-). > > I am guessing that you are talking about "squash" in "rebase -i" > command? If so, instead of saying "squash", you can say "fixup", > which will squish the change into the commit to be corrected while > retaining the log message of it, which makes the new feature you > are looking for unnecessary, I think. > > Unless I misunderstood what you want, that is. Thx - answered my questions ! :-) -- Toralf PGP C4EACDDE 0076E94E
enhancement request : If 2 commits to be squashed together do have the same title and comment ...
... then jast squsash them w/o questioning. Is this a valid RFE ? -- Toralf PGP C4EACDDE 0076E94E
Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
On 09/14/2014 10:51 AM, Torsten Bögershausen wrote: > It may be that there is a bug in the tools you are using. I use git 2.1.0 -- Toralf pgp key: 0076 E94E -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
On 09/12/2014 09:10 PM, Rom Walton wrote: > I found this: > http://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft > > That might help in the future. This helped : git reset --hard 9e860d0451 git pull git clean -f git gc git prune -- Toralf pgp key: 0076 E94E -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
On 09/12/2014 08:55 PM, Rom Walton wrote: > Crud... > > Well, personally, I would delete the locale directory and the two translation > files in html. > > Do the 'git pull', and then switch between master and some other branch. > > like: > git checkout -f client_release/7/7.4 > git checkout -f master > > It is round about, but it should get the job done. Re-cloning seems to be the only way, b/c : tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f client_release/7/7.4 Branch client_release/7/7.4 set up to track remote branch client_release/7/7.4 from origin. Switched to a new branch 'client_release/7/7.4' tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master Checking out files: 100% (234/234), done. Switched to branch 'master' Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded. (use "git pull" to update your local branch) tfoerste@n22 ~/devel/boinc-v2 $ git pull Updating ce97e85..d2e5582 error: Your local changes to the following files would be overwritten by merge: ... -- Toralf pgp key: 0076 E94E -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
On 09/12/2014 08:19 PM, Rom Walton wrote: > Try: > git checkout -f master > git pull origin > > I committed fixes for that stuff this morning. doesn't helped : tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master Already on 'master' Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded. (use "git pull" to update your local branch) tfoerste@n22 ~/devel/boinc-v2 $ git pull origin Updating ce97e85..d2e5582 error: Your local changes to the following files would be overwritten by merge: html/languages/translations/hu.po html/languages/translations/nl.po locale/bg/BOINC-Web.po locale/da/BOINC-Web.po locale/el/BOINC-Web.po locale/fr/BOINC-Web.po locale/hr/BOINC-Web.po locale/hu/BOINC-Project-Generic.po locale/hu/BOINC-Web.po locale/it_IT/BOINC-Project-Generic.po locale/lv/BOINC-Web.po locale/nl/BOINC-Project-Generic.po locale/nl/BOINC-Web.po locale/pl/BOINC-Web.po locale/pt_BR/BOINC-Web.po locale/ro/BOINC-Web.po locale/sk/BOINC-Web.po locale/zh_TW/BOINC-Web.po Please, commit your changes or stash them before you can merge. Aborting -- Toralf pgp key: 0076 E94E -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream
ng directory.
warning: CRLF will be replaced by LF in locale/pt_BR/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/ro/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/sk/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/zh_TW/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in html/languages/translations/hu.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in html/languages/translations/nl.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/bg/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/da/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/el/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/fr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/it_IT/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/lv/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/nl/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/nl/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/pl/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/pt_BR/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/ro/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/sk/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/zh_TW/BOINC-Web.po.
The file will have its original line endings in your working directory.
Saved working directory and index state WIP on master: ce97e85 MGR: On MS
Windows, scale Attach Wizard progress indicators according to user's DPI
settings.
HEAD is now at ce97e85 MGR: On MS Windows, scale Attach Wizard progress
indicators according to user's DPI settings.
tfoerste@n22 ~/devel/boinc-v2 $ git pull
Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting
Attached are my ~/.gitconfig and ~/devel/boinc-v2/.git/config
--
Toralf
pgp key: 0076 E94E
[user]
email = toralf.foers...@gmx.de
name = Toralf Förster
signingkey = 0076e94e
[core]
pager = less
[gui]
fontui = -family arial -size 12 -weight bold -slant roman -underline 0
-overstrike 0
fontdiff = -family Courier -size 12 -weight normal -slant roman
-underline 0 -overstrike 0
[color]
diff = auto
status = auto
branch = auto
ui = auto
[sendemail]
smtpserver = mail.gmx.net
smtpencryption = tls
smtpuser = toralf.foers...@gmx.de
from = Toralf Förster
assume8bitEncoding = UTF-8
confirm = never
chainreplyto = true
[diff]
#extern
sort entries numerically
Hi, is there any chance to have "1.8" before "1.10" in an output like the following : ... >From https://code.wireshark.org/review/wireshark 52fe0aa..b69642d master -> origin/master 460db8a..540f061 master-1.10 -> origin/master-1.10 25bb29a..5741a40 master-1.12 -> origin/master-1.12 4ee4fc11..97898a2 master-1.8 -> origin/master-1.8 -- Toralf -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull does no longer work due to a Cr-Lf issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ick, today I run again into a problem with the git tree of the BOINC project: http://boinc.berkeley.edu/git/boinc-v2.git A git pull won't work any longer due to: $ git pull Updating 089459d..01f0ead error: Your local changes to the following files would be overwritten by merge: lib/boinc_win.h Please, commit your changes or stash them before you can merge. Aborting A "git diff" gave : diff --git a/lib/boinc_win.h b/lib/boinc_win.h index 0676372..4c62ed5 100644 - --- a/lib/boinc_win.h +++ b/lib/boinc_win.h @@ -137,7 +137,7 @@ typedef size_t socklen_t; #include #include #else - -#include +#include #include #endif #include which pointed me to a ^M in line 137 of that file. I removed that ^M, but a pull still wonät work. Then I removed the file and checked it out again - no chance, git pull always fails with the same massage. Finally I tried : $ git stash warning: CRLF will be replaced by LF in lib/boinc_win.h. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in lib/boinc_win.h. The file will have its original line endings in your working directory. Saved working directory and index state WIP on master: 089459d locale: Update compiled localization files HEAD is now at 089459d locale: Update compiled localization files but again I run into : $ git pull Updating 089459d..01f0ead error: Your local changes to the following files would be overwritten by merge: lib/boinc_win.h Please, commit your changes or stash them before you can merge. Aborting /me wonders how to solve this w/o cloning the complete repo again. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLrutIACgkQxOrN3gB26U5ZHwD/eGEr4hR+F5TVP7m0/JO6Km+j VN6ak30WMPK8Fe9pWHYBAIWD4EDIspHUkNfq76Vakc6uNaLVne8MFiikniH7WjhL =xwGS -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk: file viewer call even for an binary document ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 dev-vcs/git-1.8.3.2-r1 at a stable 32 bit Gentoo Linux: If I right click onto a file in the right pane and choose "Blame parent commit" then even for a binary file (open doc sheet) the file viewer is started - works as designed or a bug ? - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlK0mVEACgkQxOrN3gB26U60KQD+M4z5rnOiU7uE8524vHP/hyjz S586+WIdGFiCz0k0CZIA/jM+bsWaNuyAZk/9vSbflFIv3doiuC/OKnz1MlB1QQp5 =g1Fd -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(broken ?) output of "git diff --color-word"
I just commented out few lines, "git diff" is fine : @@ -144,10 +145,10 @@ StartUML || exit 2 SHARES="" if [[ $VICTIMS -eq 1 ]]; then -# SHARES="/tmp" -# SHARES="$SHARES /mnt/hostfs" -# SHARES="$SHARES /mnt/nfsv2" -# SHARES="$SHARES /mnt/nfsv3" + SHARES="/tmp" + SHARES="$SHARES /mnt/hostfs" + SHARES="$SHARES /mnt/nfsv2" + SHARES="$SHARES /mnt/nfsv3" # SHARES="$SHARES /mnt/nfsv4" echo $SHARES | grep -q hostfs but "git diff --color-words" places the "#" somehow obscure : @@ -144,10 +145,10 @@ StartUML || exit 2 SHARES="" if [[ $VICTIMS -eq 1 ]]; then # SHARES="/tmp"# SHARES="$SHARES /mnt/hostfs"# SHARES="$SHARES /mnt/nfsv2"# SHARES="$SHARES /mnt/nfsv3" # SHARES="$SHARES /mnt/nfsv4" echo $SHARES | grep -q hostfs -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why doesn't "git bisect visualize" show all commit ids from the bisect log
On 09/20/2013 08:22 PM, Jonathan Nieder wrote: > Hi Toralf, > > Toralf Förster wrote: > >> When run that command immediate after "git bisect start" somebody sees >> the full commit range as defined in "git bisect start". >> >> However running that command later after few git bisect steps" somebody >> is just presented with the remaining commit interval. >> >> Is this intended ? > > "git bisect visualize" is meant as a tool to pin down the culprit > commit that produced a regression. Sometimes after a few steps the > problematic commit is obvious, which can save some test cycles. > > If you want to see the list of commits tested so far, "git bisect log" > can help. To see the entire bisection state, even outside the > regression window, any old "gitk foo..bar" command will do --- the > bisection state is kept in bisect/* refs that show up in blue. > Can you say a little more about what you're trying to do? Is the goal > to have a nice visualization of what "git bisect log" shows? (I'm not > aware of any such tool, and I agree it would be a nice thing.) > I'm trying to bisect a (bastard of an) issue in fs/dcache.c of the linux kernel. Till now I do not have a 100% reliable test scenario. So often I do mark a commit id accidentally wrongly as bad/good. Therefore git bisect lands into the "wrong" half. As a consequence all subsequent bisects are senseless. Visualizing all infos from "git bisect log" would help to see such mistakes. Ick, and now I'm reading your mail again, tried gitk .. - that's what I want, thx. I wasn't aware that gitk uses the info from BISECT_LOG :-) Knowing this helps me to interrupt a "git bisect run ...", restarting my KDE, continuing the bisecting later and still having the full picture of the overall git bisect process. Thx again for clarification. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
why doesn't "git bisect visualize" show all commit ids from the bisect log
When run that command immediate after "git bisect start" somebody sees the full commit range as defined in "git bisect start". However running that command later after few git bisect steps" somebody is just presented with the remaining commit interval. Is this intended ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: git bisect should accept "paths-to-be-excluded"
On 09/17/2013 09:26 AM, Christian Couder wrote: > Hi, > > On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster > wrote: >> I'm bisecting a linux kernel issue and want to ignore all commits just >> touching something in ./drives/staging. >> >> Currently the only way would be to specify all dir/subdir combination >> under ./linux except that particular directory, right ? > > Yeah, you are right, currently the only way would be to specify all > dir/subdir combination > under ./linux except the particular directory you want to exclude. > > It might indeed be useful to have a way to exclude some directories or files. Great to hear > In practice though, as git bisect is a kind of binary search, if what > you want to exclude is exclusively touched by half the commits, it > will only add one more bisection step if you don't exclude it. Unfortunately not. Linus pulls from Greg's staging tree usually once in a merge window. It is not uncommon to have hundreds of commits in that merge. If now (by accident) the merge point is marked as "BAD" and the base is "GOOD", then git bisect falls into that trap and wastes about ld(few hundreds) steps - and this happened here for me and each bisect step took hours ... > Best regards, > Christian. > -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: git bisect should accept "paths-to-be-excluded"
I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that particular directory, right ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk doesn't always shows boths tags in "gitk tag1..tag2"
On 01/29/2013 08:57 PM, Jonathan Nieder wrote: > As you guessed, 7.0.45 seems to live in a different area of history. :) Well, seems be point to the root cause .. BTW $> gitk --simplify-by-decoration client_release_7.0.44..client_release_7.0.45 only 3 rows in the main window where $> gitk client_release_7.0.44..client_release_7.0.45 shows 468 rows. Thx for the quick answer :-) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk doesn't always shows boths tags in "gitk tag1..tag2"
For a cloned BOINC git tree : $> git clone git://boinc.berkeley.edu/boinc.git the following 2 commands shows both starting and ending revisions : $> gitk client_release_7.0.41..client_release_7.0.42 $> gitk client_release_7.0.43..client_release_7.0.44 however this command doesn't show the tag "client_release_7.0.44" : $> gitk client_release_7.0.44..client_release_7.0.45 Now I'm wondering whether this is a side effect of the developer model of BOINC or an issue in gitk ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/18/2012 05:41 PM, Jeff King wrote: > 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. /me still wonders whether this race condition is a feature or an issue in GIT - b/c it means that 2 different people cloning the same repository get different results. > > -Peff > -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: "git config -l" should not expose sensitive information
yep - understood On 12/20/2012 04:49 PM, Aaron Schrab wrote: > At 10:04 -0500 20 Dec 2012, Jeff King wrote: >> The problem seems to be that people are giving bad advice to tell >> people to post "git config -l" output without looking at. Maybe we >> could help them with a "git config --share-config" option that dumps >> all config, but sanitizes the output. It would need to have a list of >> sensitive keys (which does not exist yet), and would need to not just >> mark up things like smtppass, but would also need to pull credential >> information out of remote.*.url strings. And maybe more (I haven't >> thought too long on it). > > If such an option is added, it is likely to cause more people to think > that there is no need to examine the output before sharing it. But, I > don't think that the sanitizing could ever be sufficient to guarantee that. > > Tools outside of the core git tree may add support for new config keys > which are meant to contain sensitive information, and there would be no > way for `git config` to know about those. > > Even for known sensitive keys, the person entering it might have made a > typo in the name (e.g. smptpass) preventing it from being recognized as > sensitive by the software, but easily recognizable as such by a human. > > There's also the problem of varying opinions on what is considered as > sensitive. You mention credential information in URLs, but some people > may consider the entire URL as something which they would not want to > expose. > > I think that attempting to do this would only result in a false sense of > security. > -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/18/2012 05:41 PM, Jeff King wrote: > 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. > Ah - /me was wondering why sometimes (but rarely) I could not exactly reproduce the problem and was really wondering if the underlying file system (ext4) would give an extra layer of trouble or not. Thx for that explanation. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/18/2012 01:15 PM, Torsten Bögershausen wrote: > HTH > /Torsten Thx Torsten - I forwarded this answer (and all the other answers) to the boinc alpha mailing list - there's now a discussion about that. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/18/2012 02:56 AM, Andrew Ardill wrote: > On 18 December 2012 03:01, Toralf Förster wrote: >> On 12/17/2012 12:38 PM, Andrew Ardill wrote: >>> On 17 December 2012 21:23, Toralf Förster 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 ..." to update what will be committed) >> # (use "git checkout -- ..." 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 ..." to update what will be committed) # (use "git checkout -- ..." 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
Re: problem with BOINC repository and CR/LF
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/17/2012 12:38 PM, Andrew Ardill wrote: > On 17 December 2012 21:23, Toralf Förster 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 ..." to update what will be committed) # (use "git checkout -- ..." 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 ... -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: "git config -l" should not expose sensitive information
often the output is requested in help forums - and a "git config -l | wgetpaste" exposes parameters like sendmail.smtppass - so hide those variables in the output (if not explicitly wanted) would makes sense, or ? -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problem with BOINC repository and CR/LF
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. Now /me wonders whether that repository is just screwed up or whether I do have with git.1.8.0.2 at an almost stable Gentoo linux a problem. FWIW I already played (unsuccessful) with this too: $ grep -B 3 crlf .gitconfig confirm = never [core] autocrlf = true -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
