On Sat, Aug 10, 2013 at 12:58 AM, Stephen Haberman
step...@exigencecorp.com wrote:
If a user is working on master, and has merged in their feature branch, but
now
has to git pull because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because git
On Sun, Aug 11, 2013 at 07:16:30AM +0200, Michael Haggerty wrote:
On 08/11/2013 01:20 AM, Fredrik Gustafsson wrote:
[...]
It would be very hard to do a tool such as you describe, the reason is
that there's no sane way to order your tags. Git today show tags
alphabetically, all versions
git under windows doesn't check case of letters in filename. So when
one rename for example images from *.JPG to *.jpg, git doesn't files
in a repository so when one deliver this repo on *nix -system, old
filenames preserve and this matters.
It can be very confusing when some of assets in your
On Sun, Aug 11, 2013 at 2:16 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
Also, it's not clear from the documentation how one would override
pull.rebase=preserve in order to do a normal non-preserving rebase.
From reading the code, one can see that --preserve=true (or
Thanks folks. So that this won't be fixed, I added a new QA to
MsysGit FAQ at
https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions
, I appreciate if you can review and correct if needed. I hope it will
help avoiding further conversations about this matter.
Sedat
--
To unsubscribe
From: Fredrik Gustafsson iv...@iveqy.com
On Sat, Aug 10, 2013 at 11:29:45PM +0100, Kristian Freed wrote:
In our current setup, we have automatic tagging in git of all
successful release builds. This makes it easy to go back to stable
points in history and compare functionality, check when bugs
On 2013-08-11 08.45, Илья Воронцов wrote:
git under windows doesn't check case of letters in filename. So when
one rename for example images from *.JPG to *.jpg, git doesn't files
in a repository so when one deliver this repo on *nix -system, old
filenames preserve and this matters.
It can be
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
receive-pack learns about --no-thin only for testing purposes, hence
no document update.
Signed-off-by: Nguyễn Thái Ngọc
Kristian Freed kristian.fr...@gmail.com writes:
To help with this process further, it would be useful to be able to
use git bisect, but as these are just a sequence of tags, not commits
on a branch, git bisect will not work as is.
git bisect takes arbitrary revisions, there is no restriction
On Sat, Aug 10, 2013 at 5:29 PM, Kristian Freed
kristian.fr...@gmail.com wrote:
In our current setup, we have automatic tagging in git of all
successful release builds. This makes it easy to go back to stable
points in history and compare functionality, check when bugs were
introduced etc.
On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson iv...@iveqy.com wrote:
I don't understand, why is it better to find between which tags a error
was found and not in what commit. It's much easier to find a bug
introduced in a commit than in a tag/release. It sounds like you're
doing the bug
Thomas Rast:
Have you tried moving away .git/gitk.cache?
If that fixes it, perhaps you can share it for inspection.
Yes, I did, just after I sent off that email. It did not fix the
problem, however.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the
al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
Symlink contents in p4 print sometimes have a trailing
new line character, but sometimes it doesn't. git-p4
should only remove the last character if that character
is '\n'.
Your patch looks fine, and harmless if symlinks continue
to have
On Sun, Aug 11, 2013 at 12:13:18PM +0100, Kristian Freed wrote:
On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson iv...@iveqy.com wrote:
I don't understand, why is it better to find between which tags a error
was found and not in what commit. It's much easier to find a bug
introduced in
On Sun, Aug 11, 2013 at 9:28 AM, Sedat Kapanoglu
se...@eksiteknoloji.com wrote:
Thanks folks. So that this won't be fixed, I added a new QA to
MsysGit FAQ at
https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions
, I appreciate if you can review and correct if needed. I hope it
On Sat, Aug 03, 2013 at 11:24:20AM -0700, Jonathan Nieder wrote:
If I have '[submodule favorite] ignore = all' and I then replace
that submodule with a blob, should git submodule status not mention
that path?
Yes, I think it should. I'll fix this in the reroll.
If I just renamed a
brian m. carlson wrote:
module_name uses whatever's in .gitmodules. I'm not sure what you mean
by renamed a submodule, since git mv foo bar fails with:
vauxhall ok % git mv .vim/bundle/ctrlp .vim/bundle/ctrlq
fatal: source directory is empty, source=.vim/bundle/ctrlp,
If a user is working on master, and has merged in their feature branch, but now
has to git pull because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because git pull currently does not know about rebase's preserve
merges flag, which would avoid this
hello, comments inline
On Sun, Aug 11, 2013 at 4:56 PM, Stephen Haberman
step...@exigencecorp.com wrote:
If a user is working on master, and has merged in their feature branch, but
now
has to git pull because master moved, with pull.rebase their feature branch
will be flattened into master.
1. i'm not sure why you are testing $3 == preserve. it looks like a
typo
Yes, good catch. I've added a test that fails, and will fix that.
2. clearer than a string of yoda conditions:
case $2 in
true|false|preserve)
Makes sense, will change.
1. in the error message you say that rebase
Hi Andres,
i just realized that there are ambiguities:
pull --rebase (true|false|preserve) foo # pull from remote named
(true|false|preserve), branch foo
Yeah.
Right now, I did the latter. Around line 125, when parsing --rebase
somearg, we accept somearg only if it's true, false, or
From: Junio C Hamano gits...@pobox.com
The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and
then performs its operations upon those shortened values. This can lead
to an abort if the SHA-1 of a reworded or edited commit is no longer
unique within the abbreviated SHA-1 space and a
The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and
then performs its operations upon those shortened values. This can lead
to an abort if the SHA-1 of a reworded or edited commit is no longer
unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the
todo list has
On 08/08/20130 04:54 PM, Phil Hord wrote:
Luke,
I think the issue is that your working directory receives your cached
file when you say 'git stash --keep-index'. When you restore the
stash, your previous working directory now conflicts with your new
working directory, but neither is the same
Andres Perera andre...@zoho.com writes:
i just realized that there are ambiguities:
pull -r (true|false|preserve) foo
there are 2 ways to interpret this:
pull --rebase=(true|false|preserve) foo # pull from remote named foo
pull --rebase (true|false|preserve) foo # pull from remote named
Jeff King p...@peff.net writes:
On Thu, Aug 08, 2013 at 08:31:44PM +0200, Stefan Beller wrote:
The next occurrences are at:
/* Never use a non-valid filename anywhere if at all possible */
name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
name_b = DIFF_FILE_VALID(two) ? name_b
Кофеин благоприятствует оперативнейшему раздроблению жира внутри клеток
http://is.gd/oFiLKe
Эти цифры знают все на свете
Смело можете кричать,
27 matches
Mail list logo
