if not var:
	print('Ошибка')
if var:
	print('Успех')

for i in list1: # Цикл вставки в Listbox
	lbox1.insert(END,i)

f = open(sa, 'a')

if not (text==''):

n = n + 1

"aY "ap

[guest@localhost git]$ git log -3 --author=Linus
commit 74faaa16f016af9fc429770ba701f2aa598d9f21
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Oct 17 10:00:37 2012 -0700

    Fix "git diff --stat" for interesting - but empty - file changes
    
    The behavior of "git diff --stat" is rather odd for files that have
    zero lines of changes: it will discount them entirely unless they were
    renames.
    
    Which means that the stat output will simply not show files that only
    had "other" changes: they were created or deleted, or their mode was
    changed.
    
    Now, those changes do show up in the summary, but so do renames, so
    the diffstat logic is inconsistent. Why does it show renames with zero
    lines changed, but not mode changes or added files with zero lines
    changed?
    
    So change the logic to not check for "is_renamed", but for
    "is_interesting" instead, where "interesting" is judged to be any
    action but a pure data change (because a pure data change with zero
    data changed really isn't worth showing, if we ever get one in our
    diffpairs).
    
    So if you did
    
       chmod +x Makefile
       git diff --stat
    
    before, it would show empty (" 0 files changed"), with this it shows
    
     Makefile | 0
     1 file changed, 0 insertions(+), 0 deletions(-)
    
    which I think is a more correct diffstat (and then with "--summary" it
    shows *what* the metadata change to Makefile was - this is completely
    consistent with our handling of renamed files).
    
    Side note: the old behavior was *really* odd. With no changes at all,
    "git diff --stat" output was empty. With just a chmod, it said "0
    files changed". No way is our legacy behavior sane.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit 9d55b2e12f82b344709b0f2981eaf142b0b1f7a8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Sep 30 15:10:48 2012 -0700

    mailinfo: don't require "text" mime type for attachments
    
    Currently "git am" does insane things if the mbox it is given contains
    attachments with a MIME type that aren't "text/*".
    
    In particular, it will still decode them, and pass them "one line at a
    time" to the mail body filter, but because it has determined that they
    aren't text (without actually looking at the contents, just at the mime
    type) the "line" will be the encoding line (eg 'base64') rather than a
    line of *content*.
    
    Which then will cause the text filtering to fail, because we won't
    correctly notice when the attachment text switches from the commit message
    to the actual patch. Resulting in a patch failure, even if patch may be a
    perfectly well-formed attachment, it's just that the message type may be
    (for example) "application/octet-stream" instead of "text/plain".
    
    Just remove all the bogus games with the message_type. The only difference
    that code creates is how the data is passed to the filter function
    (chunked per-pred-code line or per post-decode line), and that difference
    is *wrong*, since chunking things per pre-decode line can never be a
    sensible operation, and cannot possibly matter for binary data anyway.
    
    This code goes all the way back to March of 2007, in commit 87ab79923463
    ("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to
    pass random mbox contents to git. However, the pre-decode vs post-decode
    logic really shouldn't matter even for that case, and more importantly, "I
    fed git am crap" is not a valid reason to break *real* patch attachments.
    
    If somebody really cares, and determines that some attachment is binary
    data (by looking at the data, not the MIME-type), the whole attachment
    should be dismissed, rather than fed in random-sized chunks to
    "handle_filter()".
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit 08a94a145c3231c0fa36469682591a3c45222271
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 28 11:24:14 2012 -0700

    commit/commit-tree: correct latin1 to utf-8
    
    When a line in the message is not a valid utf-8, "git mailinfo"
    attempts to convert it to utf-8 assuming the input is latin1 (and
    punt if it does not convert cleanly).  Using the same heuristics in
    "git commit" and "git commit-tree" lets the editor output be in
    latin1 to make the overall system more consistent.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
[guest@localhost git]$

import sys
print(sys.argv)

for line in f.readlines():