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
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
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
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
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
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
{}, 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
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
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
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
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
@@
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
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
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
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
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
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
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
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
* 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
'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
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
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
'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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
].
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
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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
---
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
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
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
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
{}, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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] ==
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
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
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
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
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
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
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
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
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
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 - 100 of 304 matches
Mail list logo