a new_branch_1 by cherry-pick the
non-merges commits from new_branch, and then you should be fine too (by
merging new_branch_1 into the master)...
just lets hope you don't have too much commits to cherry-pick from your
new_branch :-)
Blind.
--
You received this message because you are subscribed
beleive).
Blind.
27 февруари 2013, сряда, 17:54:44 UTC+2, Dale Worley написа:
From: Konstantin Khomoutov flat...@users.sourceforge.net javascript:
Depends on what you call the same directory.
Git commands also fall into different categories depending on what they
do.
I'm
If people who push to your project use different OS, you may find the
configurations core.autocrlf and core.safecrlf as interesting. (usually
setting both to false works well)
27 февруари 2013, сряда, 04:31:01 UTC+2, José Guilherme Vanz написа:
After clone a github repository in my PC, a file
$ git log --source --all -Sfoo
21 февруари 2013, четвъртък, 09:35:48 UTC+2, lei yang написа:
Hi expert,
Is there a git command to know string foo contains in which branch?
Lei
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To
: Blind stoycho@gmail.com javascript:
there is still nothing wrong here,
just use the -m option for the git log (same for diff-tree -m
infact).
If you go to the end of the new branch (git checkout rebase, but at
the end of the script, that is where you are already), and look
exit code 128 normally means that you are not inside a git repo directory.
anyway, if you mention refs/notes, then it is supposed that you fave a
.git/refs accessible somewhere (in the current dir or upstairs).
02 февруари 2013, събота, 02:45:40 UTC+2, krishna chaitanya kurnala написа:
Hello
if they introduce some changes themselves.
I think it is a good idea if you post this problem to the official git
mailing list (http://news.gmane.org/gmane.comp.version-control.git)
Cheers,
Blind.
31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:
I'm investigating how rebase works
a very quick warning to my previous post:
as they say, don't do this at home kids,
it is completely illegal and will brake the whole rabase,
it was just to demonstrate that the S' commit was wrongly rebuilt by the
rebase.
Blind.
02 февруари 2013, събота, 17:11:14 UTC+2, Blind написа:
you
to?
On Wednesday, January 30, 2013 10:03:47 PM UTC-8, Blind wrote:
Just out of curiosity, what you have as filemode configuration?
Maybe if you do
$git config core.filemode false
the files will no longer show as modified?
31 януари 2013, четвъртък, 03:40:58 UTC+2, Matthew Johnson написа
I tryed your thing, and yes in both cases we end up with a file without 7.5
line in it ...
this is not good from my point of view...
git rebase --preserve-merges still keeps the S,
but he keeps only the info of the changes introduced from the both parents,
he forgot about your manual change.
Just out of curiosity, what you have as filemode configuration?
Maybe if you do
$git config core.filemode false
the files will no longer show as modified?
31 януари 2013, четвъртък, 03:40:58 UTC+2, Matthew Johnson написа:
What differences does it display? It lists about a hundred .ogg files
I suppose its a system difference issue
try:
git config core.filemode false
and then git status again
16 януари 2013, сряда, 02:07:54 UTC+2, JavaSrvcs написа:
I have not changed any code and just tried to do a git pull and get the
following message:
Updating 527f1ee..18cf73e
error:
Thanks alot for your answer, Konstantin, I will try to think a bit more for
some acceptable user-level solution,
and if I don't come up with anything good I will bring up the question to
main Git list, as you suggest.
Thanks again,
Blind.
12 януари 2013, събота, 13:04:45 UTC+2, Konstantin
In other words, do you think something like:
ls -1 | awk '{git log -1 --pretty=format:\%ci %h %an\ -- $1 | getline
g; print g, $1; close(git log -1 --pretty=format:\%ci %h %an\ -- $1)}'
is efficient enough, or you have better ideas?
11 януари 2013, петък, 22:05:56 UTC+2, Blind написа:
Hi
14 matches
Mail list logo
