On Mon, May 12, 2014 at 09:59:39AM -0700, Junio C Hamano wrote:
> A good way to double-check may be to see the fixes to the tests to
> correct their wrong expectations, and if the updated expectation is
> sensible.
I have sent the fixes to tests. To me they look sensible.
Also fixed the things yo
should be in fact
"opt->output_format & DIFF_FORMAT_DIFFSTAT".
Test t7007-show.sh is also modified to cover this case.
Signed-off-by: Max Kirillov
---
combine-diff.c | 3 ++-
t/t7007-show.sh | 8 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c
'git show' used to print extra newline after merge commit, and it was
recorded so into the test reference data. Now when the behavior is
fixed, the tests should be updated.
Signed-off-by: Max Kirillov
---
t/t1507-rev-parse-upstream.sh | 2 +-
t/t7600-merge.sh | 11
Since v1:
* add Signed-off-by
* remove notion about '--format=%s' - found it in the
documentation
Since RFC:
* fix the CC issues
* add fixes for existing tests
Max Kirillov (2):
git-show: fix 'git show -s' to not add extra terminator after merge commit
t: git-show:
'git show' used to print extra newline after merge commit, and it was
recorded so into the test reference data. Now when the behavior is
fixed, the tests should be updated.
Note that '--format=%s' works like '--pretty=tformat:%s'. This
is why non-merging cases pass, like t3505-cherry-pick-empty.sh
* fix the CC issues
* add fixes for existing tests
Max Kirillov (2):
git-show: fix 'git show -s' to not add extra terminator after merge commit
t: git-show: adapt tests to fixed 'git show'
combine-diff.c| 3 ++-
t/t1507-rev-parse-upstream.sh | 2
When git show -s is called for merge commit it prints extra newline
after any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition shoul
When "git show -s" is called for merge commit it prints extra newline
between any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition s
Hi.
I might be late to this discussion, but here either
something I don't understand or something is missed.
On Sat, May 03, 2014 at 03:56:51AM -0400, Richard Hansen wrote:
> In my experience 'git pull' is mostly (only?) used for the following
> three tasks:
>
> 1. update a local branch to inco
Hi.
> Problem #6: push - reject - pull - push sequence sometimes transforms
> into a loop with several iterations and doesn't add happiness.
As far as I undestand, this is the most annoying thing. In
git (like other distributed systems), you cannot push your
changes unless you merge them with a v
On Mon, Apr 28, 2014 at 11:15:10AM -0700, Junio C Hamano wrote:
> "Any additional information about the commit can be added" you
> suggest is exactly the kind of thing we want to avoid, which made
> Linus say in an even older discussion [*2*]:
>
> No "this random field could be used this rando
> Personally, I am _strongly_ opposed. How I name and juggle my private
> branches is nobody else's business in a distributed version control
> system.
>
> They are private. My personal workflow. Not part of a commit.
Mercurial inherits the branch label from previous commit, unless
it's specif
Hi.
> Obviously, the feature would necessarily have to be optional, simply
> because Git would have to keep understanding the old commit object
> format for a LONG time (probably indefinitely), and there's nothing
> you can do to prevent others from creating old-style commit objects.
Doesn't git
Signed-off-by: Max Kirillov
---
Documentation for the option introduced in e632b3c0d3
Documentation/config.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bbba728..41e31ce 100644
--- a/Documentation/config.txt
+++ b
If the "Show origin of this line" is started from tree mode,
it still shows the result in tree mode, which I suppose not
what user expects to see.
---
gitk | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 90764e8..5a99350 100755
--- a/gitk
+++ b/gitk
@@
On Tue, Mar 18, 2014 at 01:11:06PM -0500, Robert Dailey wrote:
> What's the general recommendation on rebasing after
> creating a merge commit on my branch?
Basically, rebase does not do anything magic. It just
cherry-picks commits over a custom revision. You could do it
manually: reset to the mas
-L will be mature
enough to be used for picking the single line origin, for now the best
option is to implement region logic separately, reusing the blame's basic io.
For diffs, the first parent is always searched. This decision is quite
voluntary, just to avoid complications to UI.
Signed-off-
The pattern of maintaining blame command and collecting output
can be reused for searching of latest change to region.
It still can use the blame's global variables, because the two
search commands should not run concurrently as well as two instances
of blame.
Signed-off-by: Max Kir
{}, scans the hunk once and returns
for all hunk lines between $start_diffline and $end_diffline, in which parent
each of them exists and which is its number there.
Signed-off-by: Max Kirillov
---
gitk | 93 ++--
1 file changed, 57
-L will be mature
enough to be used for picking the single line origin, for now the best
option is to implement region logic separately, reusing their basic io.
For diffs, the first parent is always searched. This decision is quite
voluntary, just to avoid complications to UI.
Signed-off-by:
Hi!
I quite like the "Show origin of this line" feature of the
gitk. It is more convenient than blame, because it
directly answers the question which is usually addressed to
blame.
But, sometimes there is no "key" line which one could blame.
Instead there is a function, block, or some other regio
There seems to be no point to search for several origins at once.
I doubt it is even fully working (because there is one blameinst),
but blamestuff for some reason is an array. Also, it is not cleaned
after blame is completed
Signed-off-by: Max Kirillov
---
gitk | 13 -
1 file
Signed-off-by: Max Kirillov
---
gitk-git/gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b217dbc..30a3b20 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7958,7 +7958,7 @@ proc blobdiffmaybeseehere {ateof} {
if {$diffseehere
. So the whole feature should be disabled with Tk
version less than 8.5.
Signed-off-by: Max Kirillov
---
git-gui/git-gui.sh | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index e2e710e..147be8c 100755
-
Hi.
On Mon, Jan 13, 2014 at 05:11:41PM -0800, Jonathan Nieder wrote:
> (just cc-ing some area experts)
> Benoît Bourbié wrote:
>> git gui crashes on my Linux machin since I updated it to 1.8.5.2.
I believe this happens at tk8.4 or earlier. I have not
tested it there, and according to the manpages
---
I hacked somehow around this. It seems that just usilg the
anchor mark should be enough to implement almost the same
behavior. The hard part is that I don't know which feature
is intentional and which is just random consequence of using
sel for search highlight.
One thing which seems to me im
On Mon, Dec 02, 2013 at 11:04:09AM +0100, Stefan Haller wrote:
> I don't think that not selecting the search hint is an
> option: the selection is used to keep track of where to
> search next.
To mark the next found position, should a 0-length selection
be enough? I will try to experiment with it.
it is created once, together
with others, and then only removed from text rather than deleted. Then
it will not get larger priority than the `sel` tag.
Signed-off-by: Max Kirillov
---
Fixed the typo in the comment and selection of text in marked line
gitk | 8 +---
1 file changed, 5 inser
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> I am in china. our bandwidth is very limitation. Less than 50Kb/s.
You could manually download big packed bundled from some http remote.
For example http://repo.or.cz/r/linux.git
* create a new repository, add the remote ther
Custom tags have higher priority than sel, and when they define
their own background, it makes selection invisible. Especially
inconvenient for filesep (to select filenames), but may aslo affect
other tags.
Signed-off-by: Max Kirillov
---
gitk-git/gitk | 1 +
1 file changed, 1 insertion
On Sat, Aug 31, 2013 at 12:57:34PM -0500, Felipe Contreras wrote:
> On Sat, Aug 31, 2013 at 8:58 AM, Max Kirillov wrote:
>> Tha was some of the vim repositories, upstream
>> https://code.google.com/p/vim/ or debian
>> anonscm.debian.org/hg/pkg-vim/vim, or both.
>> They
Felipe Contreras
gmail.com> writes:
> Which repository triggered this?
Tha was some of the vim repositories, upstream
https://code.google.com/p/vim/ or debian
anonscm.debian.org/hg/pkg-vim/vim, or both.
They contain tags with ~ symbol.
I don't have any experience with bazaar yet, so
cannot
References which fail check_refname_format() cause the whole
import to fail. This might be undesirable if the references
are not important.
A better solution would be to provide some mapping, either
by some reversible encoding, or by generating and storing
the associations locally.
But this is al
result in
occasional scrolling to some random commit in history, often very far
from the beginning. So nicer choice is skip the selection if change is
detected
Signed-off-by: Max Kirillov
---
gitk-git/gitk | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-gi
For long descriptions it would be nice to be able to resize
the comment text field.
Signed-off-by: Max Kirillov
---
git-gui/git-gui.sh | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 89f636f..e2e710e 100755
list. They can be staged from commandline or other tools (like
IDE of file manager), then they become visible. Default value of the
option is true, which is compatible with current behavior.
Signed-off-by: Max Kirillov
---
Hi. I've been using git for some time and have collected a
number of ch
files list. They can be staged from commandline or other tools (like
IDE of file manager), then they become visible. Default value of the
option is true, which is compatible with current behavior.
Signed-off-by: Max Kirillov
---
git-gui/git-gui.sh | 14 ++
git-gui/lib/option.tcl
301 - 337 of 337 matches
Mail list logo
