Re: git gui crashes ( v 1.8.5.2)

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 in

[PATCH] git-gui: fallback right pane to packed widgets with Tk 8.4

the whole feature should be disabled with Tk version less than 8.5. Signed-off-by: Max Kirillov m...@max630.net --- 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

[PATCH] gitk: fix mistype

Signed-off-by: Max Kirillov m...@max630.net --- 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

[PATCH] gitk: use single blamestuff for all show_line_source{} calls

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 m...@max630.net --- gitk | 13

[PATCH 0/3] gitk: show latest change to region

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 region

[PATCH 2/3] gitk: refactor: separate io from logic in the searching origin of line

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 Kirillov m

[PATCH 1/3] gitk: refactor: separate generic hunk parsing out of find_hunk_blamespecs{}

{}, 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 m...@max630.net --- gitk | 93 ++-- 1

[PATCH 3/3] gitk: pick selection for region blame

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: Max Kirillov m...@max630.net --- gitk

[PATCH 3/3 v2] gitk: show latest change to region

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-by: Max Kirillov m...@max630.net --- Fixed

Re: Rebasing merge commits

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

[PATCH] gitk: switch to patch mode when searching for line origin

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 @@

[PATCH] Documentation: git-gui: describe gui.displayuntracked

Signed-off-by: Max Kirillov m...@max630.net --- 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

RE: Recording the current branch on each commit?

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

RE: Recording the current branch on each commit?

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 specified

Re: Recording the current branch on each commit?

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 random way

Re: A failing attempt to use Git in a centralized environment

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

Re: Pull is Mostly Evil

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

[BUGFIX/RFC] git-show: fix 'git show -s' to not add extra terminator after merge commit

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

[PATCH 1/2] git-show: fix 'git show -s' to not add extra terminator after merge commit

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

[PATCH 0/2] fix 'git show -s' to not add extra terminator after merge commit

* 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 +- t/t7007-show.sh

[PATCH 2/2] t: git-show: adapt tests to fixed '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

[PATCH v2 0/2] fix 'git show -s' to not add extra terminator after merge commit

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: adapt tests to fixed

[PATCH v2 1/2] git-show: fix 'git show -s' to not add extra terminator after merge commit

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 m...@max630.net --- combine-diff.c | 3 ++- t/t7007-show.sh | 8 ++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/combine-diff.c b

[PATCH v2 2/2] t: git-show: adapt tests to fixed '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. Signed-off-by: Max Kirillov m...@max630.net --- t/t1507-rev-parse-upstream.sh | 2 +- t/t7600-merge.sh | 11

Re: [BUGFIX/RFC] git-show: fix 'git show -s' to not add extra terminator after merge commit

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 you

Re: [PATCH v2 2/2] t: git-show: adapt tests to fixed 'git show'

On Tue, May 13, 2014 at 12:26:42PM -0700, Junio C Hamano wrote: Hmph. Having these as two separate commits would mean that 1/2 alone will break the test, hurting bisectability a little bit. The necessary adjustments in this patch is small enough that we may be better off squashing them into

Re: [PATCH v2 1/2] git-show: fix 'git show -s' to not add extra terminator after merge commit

On Tue, May 13, 2014 at 07:57:08AM +0200, Johannes Sixt wrote: Am 5/13/2014 1:10, schrieb Max Kirillov: --- a/t/t7007-show.sh +++ b/t/t7007-show.sh @@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' ' git checkout -b side HEAD^^ test_commit side2 test_commit

[PATCH v3] git-show: fix 'git show -s' to not add extra terminator after merge commit

and msg.nolognoff expected files are replaced by one msg.nolog, because they were diffing because of the bug, and now there should be no difference. Signed-off-by: Max Kirillov m...@max630.net --- Changes compared to v2: * fixed chaining * squashed commit fixing test with commit fixing behavior

[RFC] add detached HEAD to --all listing

Hello. Could HEAD be added to list of heads while using --all switch? Detached heads are not something very unusual and incorrect, in submodules for example, or for some scripts. Having to specify it additionally when I meet such checkout feels like some flaw. What are opinions on that, could it

Re: [RFC] add detached HEAD to --all listing

On Wed, Aug 27, 2014 at 5:22 PM, Jeff King p...@peff.net wrote: If you mean git log, I think it is included there, too: $ git log --decorate --oneline --all 685450f (HEAD) more 1290ebd (master) foo I meant git log, did not know it's there. Where I actually would like to see it in gitk

[PATCH v2] setup.c: set workdir when gitdir is not default

with message internal error: work tree has already been set Fix by setting GIT_WORK_TREE environment also. Add test which demonstrates problem with alias. Signed-off-by: Max Kirillov m...@max630.net --- setup.c| 4 +++- t/t0002-gitfile.sh | 9 + 2 files changed, 12 insertions

[PATCH] gitk: show detached HEAD if --all is specified

is specified. This has been discussed in [1] and stated as expected behavior. So rev-parse's parameters should be tuned in gitk. [1] http://thread.gmane.org/gmane.comp.version-control.git/255996 Signed-off-by: Max Kirillov m...@max630.net --- gitk | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 0/3] gitk: save only changed configuration on exit

existing data in configuration. Max Kirillov (3): gitk refactor: remove boilerplate for configuration variables gitk: write only changed configuration variables gitk: merge views with existing ones gitk | 159 --- 1 file changed

[PATCH 2/3] gitk: write only changed configuration variables

list. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 41 + 1 file changed, 33 insertions(+), 8 deletions(-) diff --git a/gitk b/gitk index 6069afe..6e22024 100755 --- a/gitk +++ b/gitk @@ -2804,12 +2804,25 @@ proc doprogupdate {} { } } +proc

[PATCH 3/3] gitk: merge views with existing ones

Only new and modified views are saved; old ones are saved also if there are no new, modified or deleted view with same name. This allows editing view list in concurrent gitk sessions without losing the changes. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 42

[PATCH 1/3] gitk refactor: remove boilerplate for configuration variables

Signed-off-by: Max Kirillov m...@max630.net --- gitk | 88 1 file changed, 20 insertions(+), 68 deletions(-) diff --git a/gitk b/gitk index 6fb6cb3..6069afe 100755 --- a/gitk +++ b/gitk @@ -2805,23 +2805,11 @@ proc doprogupdate

Re: [PATCH 2/3] gitk: write only changed configuration variables

On Thu, Sep 11, 2014 at 10:19:56AM -0700, Junio C Hamano wrote: Max Kirillov m...@max630.net writes: If a variable is changed in a concurrent gitk or manually it is preserved unless it has changed in this instance It would have been easier to understand why this is a desirable change

[PATCH v2 2/3] gitk: write only changed configuration variables

earlier. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 100 +-- 1 file changed, 92 insertions(+), 8 deletions(-) diff --git a/gitk b/gitk index bc57c11..e76445b 100755 --- a/gitk +++ b/gitk @@ -2771,12 +2771,51 @@ proc

[PATCH v2 1/3] gitk refactor: remove boilerplate for configuration variables

Signed-off-by: Max Kirillov m...@max630.net --- gitk | 88 1 file changed, 20 insertions(+), 68 deletions(-) diff --git a/gitk b/gitk index c8df35d..bc57c11 100755 --- a/gitk +++ b/gitk @@ -2772,23 +2772,11 @@ proc doprogupdate

[PATCH v2 0/3] gitk: save only changed configuration on exit

of config file Max Kirillov (3): gitk refactor: remove boilerplate for configuration variables gitk: write only changed configuration variables gitk: synchronize config write gitk | 215 +++ 1 file changed, 139 insertions(+), 76

[PATCH v2 3/3] gitk: synchronize config write

the saving, because this is how gitk used to handle errors while saving. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/gitk b/gitk index e76445b..c65103e 100755 --- a/gitk +++ b/gitk

[PATCH 0/4] Multiple worktrees vs. submodules fixes

Hi. These are fixes of issues with submodules with use of multiple working trees. To be applied on top of the $gmane/257559, (6b4ce012cb in current pu). Max Kirillov (4): checkout: do not fail if target is an empty directory submodule refactor: use git_path_submodule() in add_submodule_odb

[PATCH 1/4] checkout: do not fail if target is an empty directory

directory. Signed-off-by: Max Kirillov m...@max630.net --- builtin/checkout.c | 2 +- t/t2025-checkout-to.sh | 7 ++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/builtin/checkout.c b/builtin/checkout.c index 01d0f2f..74eabe7 100644 --- a/builtin/checkout.c +++ b/builtin

[PATCH 4/4] path: implement common_dir handling in git_path_submodule()

mean common directory for the parent repository and does not make sense for submodule. Also add test for functionality which uses this call. Signed-off-by: Max Kirillov m...@max630.net --- cache.h | 1 + path.c | 24

[PATCH 3/4] git-common-dir: make modules/ per-working-directory directory

in the common dir of the main repository, and probably this is how checkout --to should initialize them called on the main repository, but they also should work fine being completely separated clones. Testfile t7410-submodule-checkout-to.sh demostrates the behavior. Signed-off-by: Max Kirillov m

[PATCH 2/4] submodule refactor: use git_path_submodule() in add_submodule_odb()

Signed-off-by: Max Kirillov m...@max630.net --- submodule.c | 28 ++-- 1 file changed, 10 insertions(+), 18 deletions(-) diff --git a/submodule.c b/submodule.c index 34094f5..4aad3d4 100644 --- a/submodule.c +++ b/submodule.c @@ -122,43 +122,35 @@ void

Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

On Tue, Oct 14, 2014 at 10:26:42AM -0700, Junio C Hamano wrote: And multiple-worktree _is_ about keeping the same repository and history data (i.e. object database, refs, rerere database, reflogs for refs/*) only once, while allowing multiple working trees attached to that single copy. So

Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

On Tue, Oct 14, 2014 at 07:09:45PM +0200, Jens Lehmann wrote: Until that problem is solved it looks wrong to pass GIT_COMMON_DIR into submodule recursion, I believe GIT_COMMON_DIR should be added to the local_repo_env array (and even if it is passed on later, we might have to append

Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

On Tue, Oct 14, 2014 at 09:51:22PM +0200, Jens Lehmann wrote: Am 14.10.2014 um 20:34 schrieb Max Kirillov: But here are a lot of nuances. For example, it makes sense to have a superproject checkout without submodules being initialized (so that they don't waste space and machine time

Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

On Wed, Oct 15, 2014 at 08:57:20PM +0200, Jens Lehmann wrote: Am 15.10.2014 um 00:15 schrieb Max Kirillov: I think the logic can be simple: it a submodule is not checked-out in the repository checkout --to is called from, then it is not checked-out to the new one also. If it is, then checkout

Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

On Sun, Oct 19, 2014 at 09:30:15PM +0200, Jens Lehmann wrote: Am 16.10.2014 um 22:54 schrieb Max Kirillov: On Wed, Oct 15, 2014 at 08:57:20PM +0200, Jens Lehmann wrote: Am 15.10.2014 um 00:15 schrieb Max Kirillov: I think the logic can be simple: it a submodule is not checked-out

Re: [PATCH v2 2/3] gitk: write only changed configuration variables

]. That would simplify things quite a bit. I liked the idea to exploit that tcl can watch array element uniformly with scalar variables. But I agree that the result is a bit complicated. I will try to use the explicit flag and see how it's going to look. On Sun, Sep 14, 2014 at 11:35:58PM +0300, Max

Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

On Mon, Nov 03, 2014 at 07:54:39PM +0700, Duy Nguyen wrote: Ping.. any idea how to go from here.. I'm sorry, I happen to have little time since the last conversation. As far as I understand, my patches are correct about handling existing submodules, but they may be not enough regarding

[PATCH v3 0/2] gitk: save only changed configuration on exit

Hi. Used explivit changed flag for views instead of trace. Minor style fixes. As I said, could not use namespace for older config read because they leak to globals. Max Kirillov (2): gitk: write only changed configuration variables gitk: synchronize config write gitk | 115

[PATCH v3 2/2] gitk: synchronize config write

the saving, because this is how gitk used to handle errors while saving. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/gitk b/gitk index f6409c2..0613264 100755 --- a/gitk +++ b/gitk

[PATCH v3 1/2] gitk: write only changed configuration variables

, and there is no way to find which one of the geometries is most desired. Just overwrite them unconditionally, like earlier. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 82 +--- 1 file changed, 74 insertions(+), 8 deletions(-) diff

[PATCH v4 0/2] gitk: save only changed configuration on exit

v3 did not actually work for views. Fix it (add global) and also set viewchanged in delview Max Kirillov (2): gitk: write only changed configuration variables gitk: synchronize config write gitk | 120 +++ 1 file changed, 107

[PATCH v4 1/2] gitk: write only changed configuration variables

windows, and there is no way to find which one of the geometries is most desired. Just overwrite them unconditionally, like earlier. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 87 1 file changed, 77 insertions(+), 10

[PATCH v4 2/2] gitk: synchronize config write

the saving, because this is how gitk used to handle errors while saving. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/gitk b/gitk index ed4f71e..692d880 100755 --- a/gitk +++ b/gitk

[PATCH] Add gui.displayuntracked option

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 m...@max630.net --- Hi. I've been using git for some time and have collected

[PATCH] git-gui: right half window is paned

For long descriptions it would be nice to be able to resize the comment text field. Signed-off-by: Max Kirillov m...@max630.net --- 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

[PATCH] gitk: fix race error at click while reading commits

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 m...@max630.net --- gitk-git/gitk | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gitk-git/gitk b/gitk-git/gitk

Re: [PATCH] remote-hg: skip ill-formed references

Felipe Contreras felipe.contreras at 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

Re: [PATCH] remote-hg: skip ill-formed references

On Sat, Aug 31, 2013 at 12:57:34PM -0500, Felipe Contreras wrote: On Sat, Aug 31, 2013 at 8:58 AM, Max Kirillov m...@max630.net 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 contain tags

[PATCH/RFC] Add gui.displayuntracked option

in 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 m...@max630.net --- git-gui/git-gui.sh | 14 ++ git-gui

[PATCH] gitk: make pointer selection visible in highlighted lines

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 m...@max630.net --- gitk-git/gitk | 1 + 1 file changed, 1

RE: How to resume broke clone ?

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 there.

[PATCH v2] gitk: make pointer selection visible in highlighted lines

that 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 m...@max630.net --- Fixed the typo in the comment and selection of text in marked line gitk | 8 +--- 1 file changed

Re: [PATCH v2] gitk: make pointer selection visible in highlighted lines

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.

[RFC] HACK: use anchor mark instead of sel tag

--- 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

[PATCH] gitk: add visiblerefs option, which lists always shown branches

a list of references which are always shown before and many more if they contain the commit. By default it is `{master}', which is compatible with previous behavior. Signed-off-by: Max Kirillov m...@max630.net --- gitk | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[PATCH 0/4 v2] gitk: show latest change to region

Changes vs v1: * Rebase to latest gitk master * Fix typos in commments * Switch to patch mode at showing the found change Max Kirillov (4): gitk: use single blamestuff for all show_line_source{} calls gitk: refactor: separate generic hunk parsing out of find_hunk_blamespecs

[PATCH v2 1/4] gitk: use single blamestuff for all show_line_source{} calls

There seems to be no point to search for several origins at once. Probably is is not 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 m...@max630.net --- gitk | 13

[PATCH v2 2/4] gitk: refactor: separate generic hunk parsing out of find_hunk_blamespecs{}

{}, 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 m...@max630.net --- gitk | 93 ++-- 1

[PATCH v2 3/4] gitk: refactor: separate io from logic in the searching origin of line

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 Kirillov m

Re: [PATCH 1/3] gitk: refactor: separate generic hunk parsing out of find_hunk_blamespecs{}

On Mon, Feb 03, 2014 at 06:20:36PM -0500, Eric Sunshine wrote: On Mon, Feb 3, 2014 at 5:41 PM, Max Kirillov m...@max630.net wrote: For requesting a region blame, it is necessary to parse a hunk and find the region in the parent file corresponding to the selected region. There is already hunk

[PATCH v2 4/4] gitk: show latest change to region

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-by: Max Kirillov m...@max630.net --- gitk

[BUG/RFC] cherry-pick adds newline to last line of file

Hi. If a file does not contain newline in the last line, and the file has changed somewhere in other branch, and the newline has not been not added in that change, when I cherry-pick the commit, the commit does contain the newline in the last line. This sometimes leads to conflict and in general

[PATCH 1/2] t6023-merge-file.sh: fix and mark as broken invalid tests

at time being. Signed-off-by: Max Kirillov m...@max630.net --- t/t6023-merge-file.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh index d9f3439..6da921c 100755 --- a/t/t6023-merge-file.sh +++ b/t/t6023-merge-file.sh @@ -77,10

[PATCH 2/2] git-merge-file: do not add LF at EOF while applying unrelated change

from change in the other file) and merge does not add LF away of change, to demonstrate the changed behavior. Signed-off-by: Max Kirillov m...@max630.net --- t/t6023-merge-file.sh | 66 +++ xdiff/xmerge.c| 4 ++-- 2 files changed, 68

[PATCH 0/2] git-merge-file: do not add LF at EOF while applying unrelated change

they will be fixed some day. Max Kirillov (2): t6023-merge-file.sh: fix and mark as broken invalid tests git-merge-file: do not add LF at EOF while applying unrelated change t/t6023-merge-file.sh | 72 --- xdiff/xmerge.c| 4 +-- 2 files changed

[PATCH v2 0/2] git-merge-file: do not add LF at EOF while applying unrelated change

I realized the case when the newline adding can be needed. The version 2 have this case (union-merge of changes at EOF without LF) fixed, with adding corresponding tests. Max Kirillov (2): t6023-merge-file.sh: fix and mark as broken invalid tests git-merge-file: do not add LF at EOF while

[PATCH v2 2/2] git-merge-file: do not add LF at EOF while applying unrelated change

the functionality well Signed-off-by: Max Kirillov m...@max630.net --- t/t6023-merge-file.sh | 85 +++ xdiff/xmerge.c| 4 +-- 2 files changed, 87 insertions(+), 2 deletions(-) diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh index 6da921c

[PATCH v2 1/2] t6023-merge-file.sh: fix and mark as broken invalid tests

at time being. Signed-off-by: Max Kirillov m...@max630.net --- t/t6023-merge-file.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh index d9f3439..6da921c 100755 --- a/t/t6023-merge-file.sh +++ b/t/t6023-merge-file.sh @@ -77,10

Re: [PATCH v2 2/2] git-merge-file: do not add LF at EOF while applying unrelated change

On Mon, Jun 30, 2014 at 04:55:10PM +0200, Johannes Schindelin wrote: I just wish the tests were a little easier to understand... What could be improved with them? Having said that, here is my ACK for the current revision of the patch series Thanks. By the way, for \r\n eol it did even

Re: [PATCH v2 2/2] git-merge-file: do not add LF at EOF while applying unrelated change

On Wed, Jul 02, 2014 at 04:08:28PM +0200, Johannes Schindelin wrote: What could be improved with them? Oh, I would name the files more appropriately, for example. That is, instead of test1.txt I would call it mixed-endings.txt or lf-only.txt or some such. And instead of the Latin version

Re: [PATCH v5 00/28] Support multiple checkouts

Hi. What future does this have? Currently it is marked as Stalled, but still mergeable with some trivial conflicts and seem to be working (except some bugs in interaction with submodules, see below). It would be very nice if this feature is officially supported. I also have a comment about how

Re: [PATCH v5 00/28] Support multiple checkouts

On Mon, Jul 07, 2014 at 12:49:01PM +0200, Dennis Kaarsemaker wrote: I do intend to use checkout --to and submodule update on the same repository, but have not yet done so. I will poke at that later this month. If you can easily reproduce errors, I would appreciate to know how, because my use

[PATCH] gitk: add keybinding to switch to parent commit

Signed-off-by: Max Kirillov m...@max630.net --- Hi. I was missing this one. Actually the most needed is go to first parent, though the second also may be useful. gitk | 12 1 file changed, 12 insertions(+) diff --git a/gitk b/gitk index 41e5071..de35fe4 100755 --- a/gitk +++ b/gitk

Re: [PATCH v6 26/32] checkout: detach if the branch is already checked out elsewhere

On Wed, Jul 09, 2014 at 02:33:11PM +0700, Nguyễn Thái Ngọc Duy wrote: +static int check_linked_checkout(struct branch_info *new, + const char *name, const char *path) +{ ... + if (!strncmp(start, new-path, end - start) + new-path[end - start] ==

Re: [PATCH v7 22/31] checkout: support checking out into a new working directory

Hi. On Sun, Jul 13, 2014 at 11:50:59AM +0700, Nguyễn Thái Ngọc Duy wrote: +MULTIPLE CHECKOUT MODE +--- This generates incorrect html for me, making all section until next heading EXAMPLES into a preformatted text. If I justify the line of dashes to be the exactly

Re: [PATCH] checkout: indicate when a detached head is checked out for a branch

Hi. On Fri, Jul 18, 2014 at 4:27 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Duy Nguyen venit, vidit, dixit 18.07.2014 12:58: This is what this series needs, user's opinions (bad or good). Actually, if options -b branch works with the --to (does it?), then user probably shouldn't

Re: [PATCH 1/1] gitk: po/ru.po russian translation typo fixed

On Mon, Nov 17, 2014 at 01:59:28PM +0600, Alex Kuleshov wrote: Hello Max and Paul, thank you for your feedback, so what's must be my next workflow? Resend patch with Reviewed-By:... or somethine else? To be honest I don't know. The only time I had such an answer maintainer put the flag

[PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

and checkout to new worktree at submodule update --init path.c, setup.c, submodule.c: fix diff --submodule when submodule is a linked worktree t/t7410-submodule-checkout-to.sh: tests for all the above Signed-off-by: Max Kirillov m...@max630.net --- Hi. Thanks for including my 2 patches. But, while

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Mon, Dec 01, 2014 at 05:43:16PM +0700, Duy Nguyen wrote: On Mon, Dec 1, 2014 at 6:27 AM, Max Kirillov m...@max630.net wrote: But, while hacking the submodule init I became more convinced that the modules directory should be common and submodules in checkout should be a checkouts

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Tue, Dec 02, 2014 at 09:45:24PM +0100, Jens Lehmann wrote: But, while hacking the submodule init I became more convinced that the modules directory should be common and submodules in checkout should be a checkouts of the submodule. Because this is looks like concept of submodules, that

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Thu, Dec 4, 2014 at 10:06 PM, Jens Lehmann jens.lehm...@web.de wrote: But I'd need to have separate settings for our CI server, e.g. to checkout the sources without the largish documentation submodule in one test job (=worktree) while checking out the whole documentation for another job

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote: Am 05.12.2014 um 07:32 schrieb Max Kirillov: Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Sun, Dec 07, 2014 at 08:42:30AM +0200, Max Kirillov wrote: *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Mon, Dec 08, 2014 at 09:40:59PM +0100, Jens Lehmann wrote: Huh? I think we already have that: If you ignore the url config it's as if the submodule was never initialized, so you can just *not* run the git submodule update command at all to get that effect. No new option needed ;-) You are

  1   2   3   4   >