On Feb 4, 2015, at 22:11, Scott Schmit wrote:
In my use of git, I've noticed that "git status" is a lot better at
tracking moves and renames than "git diff", and this has recently
caused
me a lot of headaches because a large number of moves were made in a
single commit, and it was very diffic
When we are parsing a config value, if we see a carriage
return, we fgetc the next character to see if it is a
line feed (in which case we silently drop the CR). If it
isn't, we then ungetc the character, and take the literal
CR.
But we never check whether we in fact got a character at
all. If the
In my use of git, I've noticed that "git status" is a lot better at
tracking moves and renames than "git diff", and this has recently caused
me a lot of headaches because a large number of moves were made in a
single commit, and it was very difficult to figure out which moves were
right and which w
On Feb 4, 2015, at 07:19, Peter Krefting wrote:
Using "git branch --no-merged" I can get a list of branches that I
have that I haven't merged into my current branch. "git tag" doesn't
have such an option, is there a way to achieve something similar
listing tags that point to commits that are
Interesting!
Thanks for the info; unsetting git environment variables as you suggested fixes
my issue on OS X (and Linux I suppose). I’m going to try this on Windows soon.
Would that work as-is on Windows, or would I need to unset the vars using some
other Windows-specific syntax?
Yes, I looke
Remove the need to have duplicated "if there is a change then feed
null_sha1 and otherwise sha1 from the cache entry" for the "new"
side of the diff by introducing two temporary variables to point
at the object name of the old and the new side of the blobs.
This does not intend to change the meani
Johannes Sixt writes:
> Am 04.02.2015 um 16:19 schrieb Peter Krefting:
>> Using "git branch --no-merged" I can get a list of branches that I have
>> that I haven't merged into my current branch.
>
> Assuming v2.0.0 is a tag, using "git branch --no-merged v2.0.0" you can
> see which branches haven
Hi,
Sorry for the rather open-ended email, but I am interested to whether
you would be interested in patches for git-rebase man page, based on a
tutorial page I wrote some ago:
http://matthew-brett.github.io/pydagogue/rebase_without_tears.html
The reason I ask, is because I have found the git-re
Am 04.02.2015 um 16:19 schrieb Peter Krefting:
> Using "git branch --no-merged" I can get a list of branches that I have
> that I haven't merged into my current branch.
Assuming v2.0.0 is a tag, using "git branch --no-merged v2.0.0" you can
see which branches haven't been merged into v2.0.0.
-- H
Peter Krefting writes:
> Using "git branch --no-merged" I can get a list of branches that I
> have that I haven't merged into my current branch. "git tag" doesn't
> have such an option, is there a way to achieve something similar
> listing tags that point to commits that aren't in my history?
Us
Geert Uytterhoeven writes:
> | Oops, I'm afraid automatic-I replied "y" to the git-send-email question
> | "Which 8bit encoding should I declare [UTF-8]?"
> | (happened before with the In-Reply-To questions ;-(
>
> Would it be possible to reject obviously wrong replies ("y", "yes", "n", "no")
> t
Louis BAYLE writes:
> when converting a text file with unix2dos.exe or dos2unix.exe (via git
> bash),
Neither of these executables are part of Git. If you ask the question, I
guess unix2dos.exe and dos2unix.exe are distributed as part of the Git
for Windows distribution (which includes Git plus
Hi!
Using "git branch --no-merged" I can get a list of branches that I
have that I haven't merged into my current branch. "git tag" doesn't
have such an option, is there a way to achieve something similar
listing tags that point to commits that aren't in my history?
Background: In my $DAYJ
Hi Junio,
On 2015-02-04 04:50, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>> [fsck "level"]
>>> missingAuthor = error
>>>
>>> , which looks funny. "level" is a constant, so it seems superfluous.
>
> Yes, it is superfluous, but is one way to avoid the ambiguity with
> "skipli
>From a thread on another mailing list:
| > Content-Type: text/plain; charset=y
| > Content-Transfer-Encoding: 8bit
| >
| > When I try to apply it git am says:
| >
| > $ git am --signoff geert1.patch
| > fatal: cannot convert from y to UTF-8
| >
| > Wut? I never heard of an encoding named "y", and
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
Signed-off-by: Tom G. Christensen
---
v2:
Add S-o-b
v1:
I noticed this on RHEL3 during 2.0.0rc phase but I see that the same
issue was noticed on De
16 matches
Mail list logo
