Stephen Haberman writes:
> I assume I'm doing the right thing by just posting another version of
> this patch to the git list; let me know if I'm missing something.
Thanks. Writing the "story so far..." summary like you did after
the three-dash line was very helpful.
> diff --git a/git-pull.sh
Eric Sunshine writes:
> 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 subseque
Eric Sunshine writes:
> At start of script, t3404 installs a specialized test-editor ($EDITOR)
> upon which many of the interactive rebase tests depend. Late in t3404,
> test "rebase -i respects core.commentchar" installs its own custom
> editor but neglects to restore the specialized editor whe
乙酸鋰 writes:
> Please document git blame --no-follow and git diff --no-follow
I do not think these (and blame/diff --follow) make any sense.
The ideal would be to reject the nonsense optoin at the command
parser level. The second best is not to document it. The worst is
to document them as non
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 thi
Jiang Xin writes:
> 2013/8/10 Junio C Hamano :
>> Jiang Xin writes:
>>
>>> So always show the remote tracking branch in the output of "git status"
>>> and other commands will help users to see where the current branch
>>> will push to and pull from. E.g.
>>> ...
>>
>> Hmmph.
>>
>> I do not know
Nguyễn Thái Ngọc Duy writes:
> 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
Кофеин благоприятствует оперативнейшему раздроблению жира внутри клеток
http://is.gd/oFiLKe
Эти цифры знают все на свете
Смело можете кричать,
Jeff King 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 : n
Andres Perera 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
> (true|f
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 as
This series addresses a bug [1][2] which can manifest during interactive
rebase when the prefix of the new SHA-1 of an edited commit is shared
with the abbreviated SHA-1 of a subsequent commit in the 'todo' list.
When rebase attempts to process the subsequent command, it dies with a
"short SHA1 bad
At start of script, t3404 installs a specialized test-editor ($EDITOR)
upon which many of the interactive rebase tests depend. Late in t3404,
test "rebase -i respects core.commentchar" installs its own custom
editor but neglects to restore the specialized editor when finished.
This oversight will
From: Junio C Hamano
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
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 th
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
", we accept only if it's true, false, or preserve,
and shi
On Sun, Aug 11, 2013 at 6:39 PM, Stephen Haberman
wrote:
>
>> 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)
> 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
hello, comments inline
On Sun, Aug 11, 2013 at 4:56 PM, Stephen Haberman
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
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 thi
On 08/08/2013 01:44 PM, Ramsay Jones wrote:
Fredrik Gustafsson wrote:
On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote:
But we'll have to use sm_path here (like everywhere else in the
submodule script), because we'll run into problems under Windows
otherwise (see 64394e3ae9 for deta
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,
> destina
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 su
On Sun, Aug 11, 2013 at 9:28 AM, Sedat Kapanoglu
wrote:
> Thanks folks. So that this won't be fixed, I added a new Q&A 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
On Sun, Aug 11, 2013 at 12:13:18PM +0100, Kristian Freed wrote:
> On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson 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
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 h
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 line
On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson 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 hunting har
On Sat, Aug 10, 2013 at 5:29 PM, 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 were
> introduced etc.
>
> To help with this pr
Kristian Freed 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 using
tags as bound
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 Du
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 ca
From: "Fredrik Gustafsson"
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 were
introduce
Thanks folks. So that this won't be fixed, I added a new Q&A 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 f
On Sun, Aug 11, 2013 at 2:16 AM, Eric Sunshine 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
s/--preserve=true/--rebase=true/
> --no-r
35 matches
Mail list logo
